Re: [HACKERS] SSI SLRU low-level functions first cut
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
Re: [HACKERS] SSI SLRU low-level functions first cut
Heikki Linnakangas wrote: Nothing checking for the hi-bit flag AFAICS. I guess the code that uses that would do check it. Right. After getting this layer done, I went off to watch the Badgers in the Rose Bowl, leaving that coding for today. ;-) But wouldn't it be simpler to mark the unused slots with zero commitseqno, instead of messing with the hi-bit in valid values? This is the earliest commitSeqNo of rw-conflicts out which the transaction we're looking up had. I'm using zero to mean that there was no conflict. Perhaps instead of setting the high bit I could just use a special value (like all bits set) instead of zero to mean no conflict. In any event, it's clear that all zero should mean not found and I need some other way to indicate no conflict. 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. Good point. That slims things down by 22 lines and eliminates a distracting special case. 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. I'll take a look. I went 'round a few time on how best to handle the empty window, which was complicated a little bit by wanting to keep track of the tail even when the window was currently empty. Because xids won't be submitted in strictly sequential order, I might need to go back a ways in the sequence to update something, so I need to keep track of existing segment files even when there are currently no xids to track; and I wanted the searches to have a fast path out for such cases. OldSerXidGetMinConflictCommitSeqNo() calls LWLockRelease twice. That's because the function calls SimpleLruReadPage_ReadOnly: Control lock must NOT be held at entry, but will be held at exit. That strikes me as an odd API, but it is what it is. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] SSI SLRU low-level functions first cut
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 -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers