On Mon, Sep 27, 2010 at 14:34, Dave Page <dp...@pgadmin.org> wrote: > On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>> It's hard to say what the safest option is, I think. There seem to be >>> basically three proposals on the table: >> >>> 1. Back-port the dead-man switch, and ignore exit 128. >>> 2. Don't back-port the dead-man switch, but ignore exit 128 anyway. >>> 3. Revert to Magnus's original solution. >> >>> Each of these has advantages and disadvantages. The advantage of #1 >>> is that it is safer than #2, and that is usually something we prize >>> fairly highly. The disadvantage of #1 is that it involves >>> back-porting the dead-man switch, but on the flip side that code has >>> been out in the field for over a year now in 8.4, and AFAIK we haven't >>> any trouble with it. Solution #3 should be approximately as safe as >>> solution #1, and has the advantage of touching less code in the back >>> branches, but on the other hand it is also NEW code. So I think it's >>> arguable which is the best solution. I think I like option #2 least >>> as among those choices, but it's a tough call. >> >> Well, I don't want to use Magnus' original solution in 8.4 or up, >> so I don't like #3 much: it's not only new code but code which would >> get very limited testing. And I don't believe that the risk of >> unexpected use of exit(128) is large enough to make #1 preferable to #2. >> YMMV. > > So, can we go with #2 for the next point releases of <= 8.3? I > understand that our customer who has been testing that approach hasn't > seen any unexpected side-effects.
Do we feel this is safe enough? Also, just to be clear - they tested the "ignore 128 only" patch? Or did they test the patch that also had some global events implementing a "win32-only deadman switch"? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers