Re: WAL fsync scheduling - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WAL fsync scheduling
Date
Msg-id 5936.974575264@sss.pgh.pa.us
Whole thread Raw
In response to Re: WAL fsync scheduling  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
>> Now all you need is a free signal number. Unfortunately we're already
>> using both SIGUSR1 and SIGUSR2.

> Maybe you could dump the old meaning SIGQUIT (externally invoked error),
> move quickdie() to SIGQUIT, and you got SIGUSR1 free.

> (That would even make sense in two ways:  1) SIGQUIT would actually cause
> the guy to quit; 2) there is a correspondence between postmaster and
> postgres signals.)

Seems like a plan.  The current definition of backend SIGQUIT is really
stupid anyway --- what's the value of forcing an error asynchronously?

Also, it always bothered me that the postmaster and backend signals
weren't consistent, so I'd be inclined to make this change even if we
end up not using SIGUSR1 for Bruce's idea ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Re: BIT/BIT VARYING status
Next
From: devik@cdi.cz
Date:
Subject: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam (xact.c xlog.c)