Re: Minor race-condition problem during database startup - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Minor race-condition problem during database startup
Date
Msg-id 492A6757.1020003@sun.com
Whole thread Raw
In response to Minor race-condition problem during database startup  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Minor race-condition problem during database startup
List pgsql-hackers
Tom Lane napsal(a):

> What seems to have happened is that the bgwriter didn't get as far as
> the first line of BackgroundWriterMain before the client backend tried
> to issue a checkpoint request.
> 
> This is obviously a pretty minor issue, but it still seems worth fixing.
> We could either try to make sure that BgWriterShmem->bgwriter_pid gets
> set before the postmaster "opens its doors" for clients, or allow
> RequestCheckpoint() to wait a little bit if needed for the bgwriter
> to come ready.  The latter seems like a more localized change.

I think, postmaster should wait until bgwriter is not up.

Another strange thing in RequestCheckpoint() is following code:

00926         else if (kill(BgWriterShmem->bgwriter_pid, SIGINT) != 0)
00927         {
00928             if (ntries >= 20)       /* max wait 2.0 sec */
00929             {
00930                 elog((flags & CHECKPOINT_WAIT) ? ERROR : LOG,
00931                      "could not signal for checkpoint: %m");
00932                 break;
00933             }
00934         }

By my opinion there is not reason to retry kill call, because it fails only in 
situation if process does not exist or caller does not have permission to send a 
signal. If one of these situation happens it means that bgwriter is dead or 
memory is corrupted. Maybe it is time for panic (or fatal)?
    Zdenek


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Visibility map, partial vacuums
Next
From: Peter Eisentraut
Date:
Subject: Re: TODO item: adding VERBOSE option to CLUSTER [with patch]