| 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: | Whole Thread | Raw Message | 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) |