Re: There's some sort of race condition with the new FSM stuff

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: There's some sort of race condition with the new FSM stuff
Дата
Msg-id 48F4FAF0.9010306@enterprisedb.com
обсуждение исходный текст
Ответ на Re: There's some sort of race condition with the new FSM stuff  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: There's some sort of race condition with the new FSM stuff  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Zdenek Kotala wrote:
>>> For security reason any OS should clean memory pages before process 
>>> first touches them.
> 
>> Yeah. But it doesn't necessarily need to fill them with zeros, any 
>> garbage will do.
> 
> Yeah, but the observed symptoms seem to indicate that the fill is mostly
> zeroes with a very occasional one.  This seems less than probable.
> 
> The only theory I've thought of that seems to fit the facts is that
> someplace we have a wild store that is clobbering that particular word.
> Which is a pretty unpleasant thought.

The bug only affected fsync/forget requests that are forwarded from 
backends, not the ones that bgwriter puts into the hash table itself. If 
the fsync request is queued by the bgwriter itself, and the forget 
request comes from a backend, you get the error that we saw, I think. I 
noted that kudu has a small shared_buffers setting, 5.6 MB, compared to 
most buildfarm members, which might explain different behavior wrt. 
which buffers are written by backends and which are written by bgwriter.

(kudu is green now BTW)

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: There's some sort of race condition with the new FSM stuff
Следующее
От: Tom Lane
Дата:
Сообщение: Re: spoonbill is failing citext test