Re: determine snapshot after obtaining locks for first statement

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: determine snapshot after obtaining locks for first statement
Date: 2009-12-17 13:07:28
Message-ID: 4B29D8B0020000250002D67F@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane 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.

The question was about whether we could change the timing of when
we get the current locks, not about getting different locks than we
currently do. Clearly, adding a table lock would make no sense.

> 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.

That would be the fatal difference then. InnoDB doesn't actually
keep old versions of a row; it generates them from "undo" records in
the log when needed, which might be why it was feasible to get the
lock before the snapshot there. If we need the snapshot before we
can get the lock, it's not an optimization which is available to us.

Thanks,

-Kevin

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-12-17 13:18:55 Re: Hot Standby and prepared transactions
Previous Message Simon Riggs 2009-12-17 13:05:13 Re: Hot Standby and prepared transactions