| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Guido Ostkamp <postgresql(at)ostkamp(dot)fastmail(dot)fm> |
| Cc: | pgsql-general(at)postgresql(dot)org, bruce(at)momjian(dot)us |
| Subject: | Re: BufferSync() performance |
| Date: | 2009-03-05 20:38:56 |
| Message-ID: | 10376.1236285536@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Guido Ostkamp <postgresql(at)ostkamp(dot)fastmail(dot)fm> writes:
> Would this work or is there a special reason why the original check was
> done with lock held?
This will fail, very nastily, on multiple-CPU machines with weak memory
ordering guarantees. You can't assume you are seeing an up-to-date
value of the flag bit if you don't take the spinlock first.
There are places where we can get away with such things because a
slightly stale answer is okay, but not in BufferSync(). Failing to
include a dirty page in the checkpoint is fatal.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pierre Racine | 2009-03-05 21:52:00 | Keeping only one postgres.exe instance running |
| Previous Message | Richard Greenwood | 2009-03-05 20:28:44 | Re: not quite a cross tab query... |