Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan <zb(at)cybertec(dot)at> wrote:

> Boszormenyi Zoltan írta:
> >
> > Okay, we implemented only the lock_timeout GUC.
> > Patch attached, hopefully in an acceptable form.
> > Documentation included in the patch, lock_timeout
> > works the same way as statement_timeout, takes
> > value in milliseconds and 0 disables the timeout.
> >
> > Best regards,
> > Zoltán Böszörményi
> >
>
> New patch attached. It's only regenerated for current CVS
> so it should apply cleanly.
>

I'm getting segfaults, built in 32 bit linux with gcc

bin/pg_ctl -D data start -l logfile -o "--lock_timeout=5"

Session 1:
jjanes=# begin;
BEGIN
jjanes=# select * from pgbench_branches where bid=3 for update;
bid | bbalance | filler
-----+----------+--------
3 | -3108950 |
(1 row)

Session 2:
jjanes=# select * from pgbench_branches where bid=3 for update;
ERROR: could not obtain lock on row in relation "pgbench_branches"
jjanes=# select * from pgbench_branches where bid=3 for update;
ERROR: could not obtain lock on row in relation "pgbench_branches"
jjanes=# select * from pgbench_branches where bid=3 for update;
ERROR: could not obtain lock on row in relation "pgbench_branches"
jjanes=# set lock_timeout = 0 ;
SET
jjanes=# select * from pgbench_branches where bid=3 for update;

<Session 2 is now blocked>

Session1:
jjanes=# commit;
<long pause>
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

I just realized I should have built with asserts turned on. I'll do that
tomorrow, but don't want to delay this info until then, so I am sending it
now.

Cheers,

Jeff