Обсуждение: Re: [COMMITTERS] pgsql: Checkpointer starts before bgwriter to avoid missing fsync reque
On 1 June 2012 08:55, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > On 01.06.2012 10:28, Simon Riggs wrote: >> >> Checkpointer starts before bgwriter to avoid missing fsync requests. >> Noted while testing Hot Standby startup. > > > The processes are just forked and it will take some time for them to > initialize. Isn't there still a race condition, where the bgwriter starts up > first, and you still miss fsync requests? Possibly... How do we handle that same situation if the check pointer crashes? And if normal backends can't send? We don't seem that tense about that either. How hard do we need to try to avoid this potential hole? I'm not sure, so opinions please. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 1 June 2012 08:55, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> On 01.06.2012 10:28, Simon Riggs wrote:
>>> Checkpointer starts before bgwriter to avoid missing fsync requests.
>>> Noted while testing Hot Standby startup.
>> The processes are just forked and it will take some time for them to
>> initialize. Isn't there still a race condition, where the bgwriter starts up
>> first, and you still miss fsync requests?
> Possibly...
> How do we handle that same situation if the check pointer crashes?
Surely that commit is useless. Fsync requests go into a queue in shared
memory, which had better have been set up by the postmaster. There is
no requirement that the receiving process exist before somebody can put
a request into the queue. If the queue overflows, the requestor has to
take care of the fsync itself, but that is independent of whether the
checkpointer is running yet.
regards, tom lane
On 1 June 2012 14:29, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Surely that commit is useless. Fsync requests go into a queue in shared > memory, which had better have been set up by the postmaster. There is > no requirement that the receiving process exist before somebody can put > a request into the queue. If the queue overflows, the requestor has to > take care of the fsync itself, but that is independent of whether the > checkpointer is running yet. The problem I saw was about fsync queue message overflow, not actually missing fsyncs, so perhaps I worded the commit message poorly. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 1 June 2012 14:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Surely that commit is useless. �Fsync requests go into a queue in shared
>> memory, which had better have been set up by the postmaster. �There is
>> no requirement that the receiving process exist before somebody can put
>> a request into the queue. �If the queue overflows, the requestor has to
>> take care of the fsync itself, but that is independent of whether the
>> checkpointer is running yet.
> The problem I saw was about fsync queue message overflow, not actually
> missing fsyncs, so perhaps I worded the commit message poorly.
Ah. Well, as long as the overflowed fsyncs do get handled on the
requesting side, I see no bug here. No objection to changing the order
in which we launch the processes, but as Heikki says, it's not clear
that that is really going to make much difference.
regards, tom lane
On 1 June 2012 14:59, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> On 1 June 2012 14:29, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Surely that commit is useless. Fsync requests go into a queue in shared >>> memory, which had better have been set up by the postmaster. There is >>> no requirement that the receiving process exist before somebody can put >>> a request into the queue. If the queue overflows, the requestor has to >>> take care of the fsync itself, but that is independent of whether the >>> checkpointer is running yet. > >> The problem I saw was about fsync queue message overflow, not actually >> missing fsyncs, so perhaps I worded the commit message poorly. > > Ah. Well, as long as the overflowed fsyncs do get handled on the > requesting side, I see no bug here. No objection to changing the order > in which we launch the processes, but as Heikki says, it's not clear > that that is really going to make much difference. If I see those messages again, I guess you'll be right. If that happens I suggest just adding a short wait at bgwriter startup. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 1 June 2012 14:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Ah. �Well, as long as the overflowed fsyncs do get handled on the
>> requesting side, I see no bug here. �No objection to changing the order
>> in which we launch the processes, but as Heikki says, it's not clear
>> that that is really going to make much difference.
> If I see those messages again, I guess you'll be right.
> If that happens I suggest just adding a short wait at bgwriter startup.
Why? Surely we are not that concerned about performance during the
startup transient. Also, it is very easy to imagine that adding a delay
would make startup performance worse not better anyway.
regards, tom lane