Re: Bug: Unreferenced temp tables disables vacuum to update xid
От | Joshua D. Drake |
---|---|
Тема | Re: Bug: Unreferenced temp tables disables vacuum to update xid |
Дата | |
Msg-id | 4782DE25.2040809@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Bug: Unreferenced temp tables disables vacuum to update xid (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Bug: Unreferenced temp tables disables vacuum to
update xid
|
Список | pgsql-hackers |
Alvaro Herrera wrote: > Tom Lane wrote: >> Andrew - Supernews <andrew+nonews@supernews.com> writes: >>> On 2008-01-07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> The real question that Josh's report brings up to me is why the heck was >>>> there an orphaned temp table? Especially if it was only a toast table >>>> and not the linked "regular" temp table? Something happened there that >>>> should not have. >>> The regular table was there too, but the regular table's relfrozenxid >>> was apparently recent, only the toast table's was old: >> Hmm, that's even more odd, since AFAICS vacuum will always vacuum a >> toast table immediately after vacuuming the parent. I wonder whether >> we have a bug somewhere that allows a toast table's relfrozenxid to >> get initially set to something substantially different from the >> parent's. > > Hmm ... that would be strange. Off-the-cuff idea: we introduced code to > advance relfrozenxid in CLUSTER, TRUNCATE and table-rewriting forms of > ALTER TABLE. Perhaps the problem is that we're neglecting to update it > for the toast table there. AFAIR I analyzed the cases and they were all > handled, but perhaps I forgot something. Just to throw another variable into the mix. This machine was a PITR slave that was pushed into production about two weeks ago. Joshua D. Drake
В списке pgsql-hackers по дате отправления: