From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | "Gavin M(dot) Roy" <gmr(at)myyearbook(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 8.3.0 Core with concurrent vacuum fulls |
Date: | 2008-03-05 14:16:52 |
Message-ID: | 23355.1204726612@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> Why not just unconditionally finish the phase 2 as part of InitPostgres ?
You're jumping to a patch before we even understand what's happening.
In particular, if that's the problem, why has this not been seen before?
The fact that it's going through heap_page_prune doesn't seem very
relevant --- VACUUM FULL has certainly always had to invoke
CacheInvalidateHeapTuple someplace or other. So I still want to see
the deadlock report ... we at least need to know which tables are
involved in the deadlock.
A separate line of thought is whether it's a good idea that
heap_page_prune calls the inval code inside a critical section.
That's what's turning an ordinary deadlock failure into a PANIC.
Even without the possibility of having to do cache initialization,
that's a lot of code to be invoking, and it has obvious failure
modes (eg, out of memory for the new inval list item).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-03-05 14:50:02 | Re: CopyReadLineText optimization |
Previous Message | Heikki Linnakangas | 2008-03-05 13:57:00 | Re: CopyReadLineText optimization |