Re: Duplicated Keys in PITR - Mailing list pgsql-hackers
| From | Ygor Degani |
|---|---|
| Subject | Re: Duplicated Keys in PITR |
| Date | |
| Msg-id | [email protected] Whole thread Raw |
| In response to | Re: Duplicated Keys in PITR (Greg Stark <[email protected]>) |
| 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="/service/mailto:[email protected]">[email protected]</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="/service/mailto:[email protected]">[email protected]</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://www.postgrespro.com/%3Ca%20href="http://mit.edu/%7Egsstark/resume.pdf">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: