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.
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=00a0bc6c47c8173e82e5927d9b75fe570280860f
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
values?
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
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
