From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ian West <ian(at)niw(dot)com(dot)au> |
Cc: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Locking |
Date: | 2000-08-13 13:42:15 |
Message-ID: | 8117.966174135@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ian West <ian(at)niw(dot)com(dot)au> writes:
> The question I think is more can I set the default action on requiring a
> lock on a record which is in use to be fail, rather than wait. Or can I
> specify how long to wait.
OK, I see. No, there's no such facility at the moment, though it seems
like something worth thinking about.
> I understand that I can use non-blocking io, and poll for data, and send
> an abort after a delay if I don't get my lock within a reasonable time,
> but this doesn't help with ecpg as far as I can tell. (Although I may
> very well be missing the obvious here :-)
Well, you could fire off a subprocess that would simply sleep for X
amount of time and then issue the cancel request if it hadn't been
killed meanwhile. (There's no restriction that the cancel request
come from the same process that issued the query.) A tad tedious but
it'd work.
Perhaps a better answer is to restructure your application's queries
so that you avoid holding FOR UPDATE locks for long periods.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-08-13 14:02:58 | Re: Optimizer confusion? |
Previous Message | Philip Warner | 2000-08-13 12:41:19 | Re: Optimizer confusion? |