Re: There's some sort of race condition with the new FSM stuff - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: There's some sort of race condition with the new FSM stuff
Date
Msg-id 48F4FAF0.9010306@enterprisedb.com
Whole thread Raw
In response to Re: There's some sort of race condition with the new FSM stuff  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: There's some sort of race condition with the new FSM stuff
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: There's some sort of race condition with the new FSM stuff
Next
From: Tom Lane
Date:
Subject: Re: spoonbill is failing citext test