Re: Duplicated Keys in PITR - Mailing list pgsql-hackers

From Ygor Degani
Subject Re: Duplicated Keys in PITR
Date
Msg-id 4bb7c9f80908201222g31fd8e11ldb14b0647d623e69@mail.gmail.com
Whole thread Raw
In response to Re: Duplicated Keys in PITR  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
<span style="color: rgb(51, 204, 0);">></span> <span style="color: rgb(0, 153, 0);">How are your duplicate keys
beinggenerated? Is there a unique index on them?</span><br />They are generated during recover. Yes, there is a unique
index.<br /><br /><span style="color: rgb(0, 153, 0);">> Are the keys there if you use a sequential scan or only if
youuse an</span><br style="color: rgb(0, 153, 0);" /><span style="color: rgb(0, 153, 0);">> index to look them
up?</span><br/> I used a sequential scan.<br />            <br /><span style="color: rgb(0, 153, 0);">>Have you been
running8.3.5 the whole time or were you running older</span><br style="color: rgb(0, 153, 0);" /><span style="color:
rgb(0,153, 0);">>8.3 releases for some of the time? Why aren't you running 8.3.7 --</span><br style="color: rgb(0,
153,0);" /><span style="color: rgb(0, 153, 0);">>there are known bugs in 8.3.5 though none which look to be
related.</span><br/>I can migrate for version 8.3.7, but it will fix my problem?<br /><br /><span style="color: rgb(0,
153,0);">>How long has the archive been running, is it feasible to give someone</span><br style="color: rgb(0, 153,
0);"/><span style="color: rgb(0, 153, 0);">>the backup and complete archives going back to when it was
taken?</span><br/>At least 6 months. This database has 270GB. Soon, it is impossible to use pg_dump, because the
restoretakes around 22 hours to finish.<br /><br /><span style="color: rgb(0, 153, 0);">>Can you dump the pages with
thebad keys using the pageinspect contrib</span><br style="color: rgb(0, 153, 0);" /><span style="color: rgb(0, 153,
0);">>module?Do you need instructions on how to do that?</span><br /> Yes. I do. <br /><br /><br />Thanks,<br /><br
/><br/>Ygor Degani<br /><br /><div class="gmail_quote">2009/8/20 Greg Stark <span dir="ltr"><<a
href="mailto:gsstark@mit.edu">gsstark@mit.edu</a>></span><br/><blockquote class="gmail_quote" style="border-left:
1pxsolid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Thu, Aug 20, 2009 at
4:13PM, Ygor Degani<<a href="mailto:ygordegani@gmail.com">ygordegani@gmail.com</a>> wrote:<br /> > When
recovera database using a continuous archive backup, i detected some<br /> > duplicated keys. This there isn't in
theproduction database.<br /> > I use postgres-8.3.5.<br /> > anyone know why this happens?<br /><br /></div>Uhm,
wellit's not supposed to. Do you have more information?<br /><br /> How are your duplicate keys being generated? Is
therea unique index on them?<br /><br /> Are the keys there if you use a sequential scan or only if you use an<br />
indexto look them up?<br /><br /> Have you been running 8.3.5 the whole time or were you running older<br /> 8.3
releasesfor some of the time? Why aren't you running 8.3.7 --<br /> there are known bugs in 8.3.5 though none which
lookto be related.<br /><br /> How long has the archive been running, is it feasible to give someone<br /> the backup
andcomplete archives going back to when it was taken?<br /><br /> Can you dump the pages with the bad keys using the
pageinspectcontrib<br /> module? Do you need instructions on how to do that?<br /><font color="#888888"><br /><br /><br
/>--<br /> greg<br /><a href="http://mit.edu/%7Egsstark/resume.pdf"
target="_blank">http://mit.edu/~gsstark/resume.pdf</a><br/></font></blockquote></div><br /><br clear="all" /><br />--
<br/>Ygor Degani<br /> 

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: GRANT ON ALL IN schema
Next
From: Alvaro Herrera
Date:
Subject: UPDATE ... SET (a, b, c) = (expr)