| From: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Szymon Guz <mabewlun(at)gmail(dot)com> |
| Subject: | Re: Transaction-scope advisory locks |
| Date: | 2010-12-14 14:23:51 |
| Message-ID: | 4D077DF7.5010206@cs.helsinki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2010-12-14 4:19 PM +0200, Merlin Moncure wrote:
> On Tue, Dec 14, 2010 at 7:07 AM, Andres Freund<andres(at)anarazel(dot)de> wrote:
>> On Tuesday 14 December 2010 00:14:22 Marko Tiikkaja wrote:
>>> The lock space is the same though, but I don't feel strongly about it.
>> I feel strongly that it needs the same locking space. I pretty frequently have
>> the need for multiple clients trying to acquiring a lock in transaction scope
>> (i.e. for accessing the cache) and one/few acquiring it in session scope (for
>> building the cache).
>
> Not that I'm necessarily against the proposal, but what does this do
> that can't already be done by locking a table or a table's row?
Try without throwing an error.
Regards,
Marko Tiikkaja
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2010-12-14 14:29:05 | Re: Instrument checkpoint sync calls |
| Previous Message | Merlin Moncure | 2010-12-14 14:19:32 | Re: Transaction-scope advisory locks |