Robert Haas wrote: > On Thu, Sep 9, 2010 at 3:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> We certainly now have MANY documented field complaints at least of the > >> exit-128-on-Windows problem, if not the more general > >> backend-exits-without-going-through-the-normal-cleanup-path problem. > > > > Right, which is why I still don't care to risk back-porting a fix for > > the latter. > > 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, the dead-man timer is for all platforms, while the 128 return failure is Win32-only, so I don't see why applying the dead-man timer makes sense when it might destabalize all platforms, when the bug is just on Win32, and I don't think using defines to make the dead-man timer Win32-only makes sense. I think we have clear enough evidence that 128 on Win32 means no-such-child and we can be sure the child never got started on that platform. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers