From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <Robert(dot)Creager(at)Sun(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: auto vacuum lock on 8.1beta1 |
Date: | 2005-10-13 19:20:46 |
Message-ID: | s34e6d47.092@gwmta.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I can confirm that the patch was in the snapshot I picked up this
morning at about 10:30 CDT. We've been using it since then and
have not seen the problem in spite of attempting to provoke it with
database vacuums.
-Kevin
>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 10/13/05 2:09 PM >>>
Robert Creager <Robert(dot)Creager(at)Sun(dot)com> writes:
> Might this be the same problem as the recent thread "database vacuum from cron
> hanging" where Tom is: "I'm busy volatile-izing all the code in bufmgr.c ...
> should be able to commit a fix soon."?
Seems reasonably likely, seeing that the original report involved gcc
3.3.something IIRC, and you're using 3.3.1. Is this an SMP box? The
bug could theoretically manifest on a uniprocessor but it seems more
likely to happen on a multiprocessor.
Too bad you didn't have it built with --enable-debug; I can't think of
any very easy way to verify a negative refcount for that buffer without
gdb support.
You could try inspecting the assembly code generated for PinBuffer, as
we did with Kevin's compiler. If it's generating the same code sequence
then that would make it pretty likely that you're seeing the same thing.
The volatile patch should be available in last night's nightly snapshot,
if you just want to update.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2005-10-13 19:36:39 | Re: pg_config --pgxs on Win32 |
Previous Message | Andrew Dunstan | 2005-10-13 19:14:42 | Re: pg_config --pgxs on Win32 |