From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | andrew(at)supernews(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bug: Unreferenced temp tables disables vacuum to update xid |
Date: | 2008-01-08 00:25:04 |
Message-ID: | 27971.1199751904@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew - Supernews <andrew+nonews(at)supernews(dot)com> writes:
> On 2008-01-07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
(BTW, if the parent table *was* there then Josh hardly needed any fancy
jujitsu to clear the problem -- "drop table pg_temp_24.tmp_isp_blk_chk"
as a superuser should've worked. I wouldn't try this if the originating
backend were still around, but if it's not then there's not going to be
anything all that special about the temp table.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Devrim GÜNDÜZ | 2008-01-08 00:32:56 | Re: 8.3.0 release schedule (Was:Re: [BUGS] BUG #3852: Could not create complex aggregate) |
Previous Message | Darcy Buskermolen | 2008-01-08 00:24:13 | Re: 8.3.0 release schedule (Was:Re: [BUGS] BUG #3852: Could not create complex aggregate) |