From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Assuming that TAS() will succeed the first time is verboten |
Date: | 2001-01-08 19:00:27 |
Message-ID: | 18557.978980427@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
One last followup on that bizarreness about shutdown's checkpoint
failing on Alpha platforms ---
After changing the checkpoint code to loop, rather than assuming TAS()
must succeed the first time, I noticed that it always looped exactly
once. This didn't make sense to me at the time, but after querying some
Alpha experts at DEC^H^H^HCompaq, it does now. If a new process's first
write to a shared memory page is a stq_c, that stq_c is guaranteed to
fail (at least on Tru64 Unix), because it will page fault. The shared
memory page is inherited read-only and is converted to read-write on
first fault. This doesn't seem really necessary, but I suppose it's
done to share code with the copy-on-write case for non-shared pages
that are inherited via fork().
It makes sense that the checkpoint process's first write to shared
memory would be stq_c, because after all it shouldn't be scribbling
on shared memory until it's got the spinlock, n'est ce pas?
So a failure the first time through the TAS loop is entirely expected
for Alpha. I wouldn't be surprised to see similar behavior on other
architectures, now that I see the first-write-from-a-process connection.
Bottom line is the same: always call TAS() in a retry loop.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Swan | 2001-01-08 22:37:59 | Install Failure [7.1beta2 tarballs] |
Previous Message | Jan Wieck | 2001-01-08 18:37:04 | Re: Should heap_update/heap_delete hold buffer locks while toasting? |