Re: [HACKERS] Race condition in backend process exit

2005-08-11 Thread Andrew Sullivan
On Sun, Aug 07, 2005 at 03:45:10PM -0400, Tom Lane wrote: > > I'm a bit hesitant to back-patch such a nontrivial and hard-to-test > change, but it sure looks badly broken to me. Any thoughts about the > risks involved? If there were some way to test it reliably, it'd make me feel a lot better.

Re: [HACKERS] Race condition in backend process exit

2005-08-07 Thread Tom Lane
I wrote: >> I could not provoke the same crash in 8.0, but I suspect this may just >> be a chance timing difference, and that the bug may be of long standing. > I haven't done the experiment, but I'm pretty certain that it's possible > to provoke this same crash in 8.0 if the timing is right, whic

Re: [HACKERS] Race condition in backend process exit

2005-08-07 Thread Alvaro Herrera
On Sun, Aug 07, 2005 at 03:45:10PM -0400, Tom Lane wrote: > I'm thinking that the correct fix is to forget the notion that it's > safer to do a subset of AbortTransaction than to do the whole thing. > We should make ShutdownPostgres do this: > > AbortOutOfAnyTransaction(); > > /* Dro

Re: [HACKERS] Race condition in backend process exit

2005-08-07 Thread Tom Lane
I wrote: > I can fairly consistently crash CVS tip with the following: > ... > Apparently, session 1's locks are being released while it still shows as > an active transaction in the PGPROC array, causing XactLockTableWait to > suppose it was a subtransaction and look for the parent. This indicate

[HACKERS] Race condition in backend process exit

2005-08-07 Thread Tom Lane
I can fairly consistently crash CVS tip with the following: Session 1: regression=# begin; BEGIN regression=# select * from int4_tbl where f1 = 123456 for update; f1 123456 (1 row) Session 2: regression=# begin; BEGIN regression=# select * from int4_tbl where f1 = 123456 for upd