Duplicated Keys in PITR

Started by Ygor Deganiover 16 years ago3 messageshackers
Jump to latest
#1Ygor Degani
ygordegani@gmail.com

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

#2Bruce Momjian
bruce@momjian.us
In reply to: Ygor Degani (#1)
Re: Duplicated Keys in PITR

On Thu, Aug 20, 2009 at 4:13 PM, Ygor Degani<ygordegani@gmail.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

#3Ygor Degani
ygordegani@gmail.com
In reply to: Bruce Momjian (#2)
Re: Duplicated Keys in PITR

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@mit.edu>

On Thu, Aug 20, 2009 at 4:13 PM, Ygor Degani<ygordegani@gmail.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&gt;

--
Ygor Degani