Re: Assuming that TAS() will succeed the first time is verboten

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Assuming that TAS() will succeed the first time is verboten
Дата
Msg-id 18557.978980427@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: Assuming that TAS() will succeed the first time is verboten  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Ответы Re: Assuming that TAS() will succeed the first time is verboten  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: Should heap_update/heap_delete hold buffer locks while toasting?
Следующее
От: ncm@zembu.com (Nathan Myers)
Дата:
Сообщение: Re: Quite strange crash