Horton

Re: Remove HeapTuple and Buffer dependency for predicate locking functions

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Ashwin Agrawal <aagrawal@pivotal.io>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, Kuntal Ghosh <kuntalghosh.2007@gmail.com>
Date: 2019-07-31T17:50:52Z
Lists: pgsql-hackers 
Hi,

On 2019-07-31 09:57:58 +1200, Thomas Munro wrote:
> On Tue, Jun 25, 2019 at 6:02 AM Andres Freund <andres@anarazel.de> wrote:
> > Hm.  I wonder if we somehow ought to generalize the granularity scheme
> > for predicate locks to not be tuple/page/relation.  But even if, that's
> > probably a separate patch.
> 
> What do you have in mind?

My concern is that continuing to inferring the granularity levels from
the tid doesn't seem like a great path forward. An AMs use of tids might
not necessarily be very amenable to that, if the mapping isn't actually
block based.


> Perhaps you just want to give those things different labels, "TID
> range" instead of page, for the benefit of "logical" TID users?
> Perhaps you want to permit more levels?  That seems premature as long
> as TIDs are defined in terms of blocks and offsets, so this stuff is
> reflected all over the source tree...

I'm mostly wondering if the different levels shouldn't be computed
outside of predicate.c.

Greetings,

Andres Freund

Commits

  1. Remove dependency on HeapTuple from predicate locking functions.

  2. Optimize PredicateLockTuple().

  3. Optimize TransactionIdIsCurrentTransactionId().

  4. Fix predicate-locking of HOT updated rows.

  5. Introduce logical decoding.

  6. Fix bugs in SSI tuple locking.

  7. Implement genuine serializable isolation level.