Re: determine snapshot after obtaining locks for first statement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: determine snapshot after obtaining locks for first statement
Date: 2009-12-16 23:33:43
Message-ID: 18798.1261006423@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> (Besides which the lock acquired by UPDATE isn't exclusive and
>> wouldn't block anyway...)

> It blocks other UPDATEs.

Not at the table level. If you could lock only at the tuple level
maybe you'd have something, but it seems like you can't find the
target tuples without having acquired a snapshot.

>> If he's talking about automatically taking an exclusive lock, I
>> doubt very many of our users would find that an improvement.

> I don't believe he's talking about a lock which excludes SELECTs on
> the data.

Well, you could take such a lock (one that blocks other UPDATEs but
not SELECTs) but it would be a clear loss of concurrency compared to
what we have now. Unless I misunderstand what you're talking about,
it'd serialize all updates on a given table whether they conflict or
not.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira de Oliveira 2009-12-17 00:53:33 Re: Does "verbose" Need to be Reserved?
Previous Message Robert Haas 2009-12-16 23:29:48 Re: PATCH: Add hstore_to_json()