Re: Assuming that TAS() will succeed the first time is verboten - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Assuming that TAS() will succeed the first time is verboten
Date
Msg-id 18557.978980427@sss.pgh.pa.us
Whole thread Raw
In response to RE: Assuming that TAS() will succeed the first time is verboten  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Responses Re: Assuming that TAS() will succeed the first time is verboten
List 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


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Should heap_update/heap_delete hold buffer locks while toasting?
Next
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: Quite strange crash