Skip site navigation (1) Skip section navigation (2)

Re: SSI SLRU low-level functions first cut

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSI SLRU low-level functions first cut
Date: 2011-01-02 08:56:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 01.01.2011 23:21, Kevin Grittner wrote:
> I've got low-level routines coded for interfacing predicate.c to SLRU
> to handle old committed transactions, so that SSI can deal with
> situations where a large number of transactions are run during the
> lifetime of a single serializable transaction.  I'm not actually
> *using* these new functions yet, but that's what I do next.  I would
> love it if someone could review this commit and let me know whether
> it looks generally sane.

Nothing checking for the hi-bit flag AFAICS. I guess the code that uses 
that would do check it. But wouldn't it be simpler to mark the unused 
slots with zero commitseqno, instead of messing with the hi-bit in valid 

It's probably not necessary to explicitly truncate the slru at startup. 
We don't do that for pg_subtrans, which also doesn't survive restarts. 
The next checkpoint will truncate it.

It would possibly be simpler to not reset headXid and tailXid to 
InvalidTransactionId when the "window" is empty, but represent that as 
tailXid == headXid + 1.

OldSerXidGetMinConflictCommitSeqNo() calls LWLockRelease twice.

   Heikki Linnakangas

In response to

pgsql-hackers by date

Next:From: Stefan KaltenbrunnerDate: 2011-01-02 09:20:39
Subject: Re: Sync Rep Design
Previous:From: Heikki LinnakangasDate: 2011-01-02 08:35:07
Subject: Re: Sync Rep Design

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group