Re: Re: [COMMITTERS] pgsql: Checkpointer starts before bgwriter to avoid missing fsync reque
От | Simon Riggs |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Checkpointer starts before bgwriter to avoid missing fsync reque |
Дата | |
Msg-id | CA+U5nMJgBu5_9hcExbXNiq=Ld4xpQV21bymbZ0PcstLkc97erw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Checkpointer starts before bgwriter to avoid missing fsync reque (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Checkpointer starts before bgwriter to avoid missing fsync reque
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: