| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [COMMITTERS] pgsql: Checkpointer starts before bgwriter to avoid missing fsync reque |
| Date: | 2012-06-01 08:33:46 |
| Message-ID: | CA+U5nMJenRvgd-u_GO9cU_XivRQaB9qZy2Eoh9zn8OdZOiHn9A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On 1 June 2012 08:55, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Page | 2012-06-01 08:46:12 | pginstaller - pginst: Update for 8.3.19 |
| Previous Message | Simon Riggs | 2012-06-01 08:25:33 | pgsql: After any checkpoint, close all smgr files handles in bgwriter |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergey Koposov | 2012-06-01 11:34:19 | Re: slow dropping of tables, DropRelFileNodeBuffers, tas |
| Previous Message | Heikki Linnakangas | 2012-06-01 07:55:28 | Re: pgsql: Checkpointer starts before bgwriter to avoid missing fsync reque |