Re: Duplicate values found when reindexing unique index
От | Simon Riggs |
---|---|
Тема | Re: Duplicate values found when reindexing unique index |
Дата | |
Msg-id | 1199123279.9558.185.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: Duplicate values found when reindexing unique index (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Duplicate values found when reindexing unique index
|
Список | pgsql-bugs |
On Mon, 2007-12-31 at 12:33 -0500, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > On Mon, 2007-12-31 at 11:53 -0500, Tom Lane wrote: > >> The state of the ...0058 file might be explained by the theory that > >> you'd archived it a bit too late (after the first page had been > >> overwritten with newer WAL data), > > > The interlock with .ready and .done should prevent reuse of a file. So > > the only way this could happen is if the archive_command queued a > > request to copy, rather than performing the copy immediately. > > So I was going to say "thats not possible", but perhaps rsync might > > become confused by the file renaming mechanism we use? > > Actually, the other problem with that theory is that the slave swallowed > the file without complaint. No, it barfed. Mason showed us a recovery script, so it came from the slave. > Since the WAL reader code does check that > the page header contains the expected address, this seems to imply that > what the slave saw must have had 422/58 in it, not the 423/C1 we see > now. So what needs to be explained is why what Mason is looking at now > is different from what the slave saw ten days ago. So the slave did see a problem ten days ago, though I take your point that the problem we see now may not be the as it was back then. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
В списке pgsql-bugs по дате отправления: