On 05/04/12 08:02, Boszormenyi Zoltan wrote: > 2012-04-04 21:30 keltezéssel, Alvaro Herrera írta: >> I think this patch is doing two things: first touching infrastructure >> stuff and then adding lock_timeout on top of that. Would it work to >> split the patch in two pieces? >> > > Sure. Attached is the split version. > > Best regards, > Zoltán Böszörményi > Hi,
I've started looking at and testing both patches. Technically speaking, I think the source looks much better than the first version of lock timeout, and may help adding other timeouts in the future. I haven't tested it in depth though, because I encountered the following problem: While testing the patch, I found a way to crash PG. But what's weird is that it crashes also with an unpatched git version. Here is the way to reproduce it (I have done it with a pgbench schema): - Set a small statement_timeout (just to save time during the tests) Session1: =#BEGIN; =#lock TABLE pgbench_accounts ; Session 2: =#BEGIN; =#lock TABLE pgbench_accounts ; ERROR: canceling statement due to statement timeout =# lock TABLE pgbench_accounts ; I'm using \set ON_ERROR_ROLLBACK INTERACTIVE by the way. It can also be done with a rollback to savepoint of course. Session 2 crashes with this : TRAP : FailedAssertion(« !(locallock->holdsStrongLockCount == 0) », fichier : « lock.c », ligne : 749). It can also be done without a statement_timeout, and a control-C on the second lock table. I didn't touch anything but this. It occurs everytime, when asserts are activated. I tried it on 9.1.3, and I couldn't make it crash with the same sequence of events. So maybe it's something introduced since ? Or is the assert still valid ? Cheers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
