On Mon, Feb 3, 2014 at 11:29 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Feb 3, 2014 at 10:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> So >>> exit(0) - done, permanently >>> exit(1) - done until restart interval >>> exit(other) - crash >>> and there's no way to obtain the "restart immediately" behavior? > >> That's what I was thinking about, yes. Of course, when the restart >> interval is 0, "done until restart interval" is the same as "restart >> immediately", so for anyone who wants to *always* restart immediately >> there is no problem. Where you will run into trouble is if you >> sometimes want to wait for the restart interval and other times want >> to restart immediately. But I'm not sure that's a real use case. If >> it is, I suggest that we assign it some other, more obscure exit code >> and reserve 0 and 1 for what I believe will probably be the common >> cases. > > Agreed, but after further reflection it seems like if you've declared > a restart interval, then "done until restart interval" is probably the > common case. So how about > > exit(0) - done until restart interval, or permanently if there is none > exit(1) - done permanently, even if a restart interval was declared > exit(other) - crash
I think what I proposed is better for two reasons: 1. It doesn't change the meaning of exit(1) vs. 9.3. All background worker code I've seen or heard about (which is admittedly not all there is) does exit(1) because the current exit(0) behavior doesn't seem to be what anyone wants. So I don't think it matters much whether we redefine exit(0), but redefining exit(1) will require version-dependent changes to the background workers in contrib and, most likely, every other background worker anyone has written. 2. If you want a worker that starts up, does something, and doesn't need to be further restarted when that succeeds, then under your definition you return 0 when you fail and 1 when you succeed. Under my definition you do the opposite, which I think is more natural. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
