Re: Duplicated Keys in PITR

When recover a database using a continuous archive backup, i detected some
duplicated keys. This there isn't in the production database.
I use postgres-8.3.5.
anyone know why this happens?

Regards,

--
Ygor Degani

On Thu, Aug 20, 2009 at 4:13 PM, Ygor Degani<ygordegani(at)gmail(dot)com> wrote:
> When recover a database using a continuous archive backup, i detected some
> duplicated keys. This there isn't in the production database.
> I use postgres-8.3.5.
> anyone know why this happens?

Uhm, well it's not supposed to. Do you have more information?

How are your duplicate keys being generated? Is there a unique index on them?

Are the keys there if you use a sequential scan or only if you use an
index to look them up?

Have you been running 8.3.5 the whole time or were you running older
8.3 releases for some of the time? Why aren't you running 8.3.7 --
there are known bugs in 8.3.5 though none which look to be related.

How long has the archive been running, is it feasible to give someone
the backup and complete archives going back to when it was taken?

Can you dump the pages with the bad keys using the pageinspect contrib
module? Do you need instructions on how to do that?

--
greg
http://mit.edu/~gsstark/resume.pdf

> How are your duplicate keys being generated? Is there a unique index on
them?
They are generated during recover. Yes, there is a unique index.

> Are the keys there if you use a sequential scan or only if you use an
> index to look them up?
I used a sequential scan.

>Have you been running 8.3.5 the whole time or were you running older
>8.3 releases for some of the time? Why aren't you running 8.3.7 --
>there are known bugs in 8.3.5 though none which look to be related.
I can migrate for version 8.3.7, but it will fix my problem?

>How long has the archive been running, is it feasible to give someone
>the backup and complete archives going back to when it was taken?
At least 6 months. This database has 270GB. Soon, it is impossible to use
pg_dump, because the restore takes around 22 hours to finish.

>Can you dump the pages with the bad keys using the pageinspect contrib
>module? Do you need instructions on how to do that?
Yes. I do.

Thanks,

Ygor Degani

2009/8/20 Greg Stark <gsstark(at)mit(dot)edu>

> On Thu, Aug 20, 2009 at 4:13 PM, Ygor Degani<ygordegani(at)gmail(dot)com> wrote:
> > When recover a database using a continuous archive backup, i detected
> some
> > duplicated keys. This there isn't in the production database.
> > I use postgres-8.3.5.
> > anyone know why this happens?
>
> Uhm, well it's not supposed to. Do you have more information?
>
> How are your duplicate keys being generated? Is there a unique index on
> them?
>
> Are the keys there if you use a sequential scan or only if you use an
> index to look them up?
>
> Have you been running 8.3.5 the whole time or were you running older
> 8.3 releases for some of the time? Why aren't you running 8.3.7 --
> there are known bugs in 8.3.5 though none which look to be related.
>
> How long has the archive been running, is it feasible to give someone
> the backup and complete archives going back to when it was taken?
>
> Can you dump the pages with the bad keys using the pageinspect contrib
> module? Do you need instructions on how to do that?
>
>
>
> --
> greg
> http://mit.edu/~gsstark/resume.pdf <http://mit.edu/%7Egsstark/resume.pdf>
>

--
Ygor Degani