Re: BUG #5915: OldSerXidAdd inflates pg_serial too much

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: YAMAMOTO Takashi <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5915: OldSerXidAdd inflates pg_serial too much
Date: 2011-03-05 21:18:19
Message-ID: 4D72A89B.1050804@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 04.03.2011 23:28, Kevin Grittner wrote:
> I wrote:
>
>> I think what we're protecting against is disk I/O at COMMIT time,
>> not transaction startup.
>
> One more thought on this -- on a properly configured server, this
> code should rarely be exercised unless there is a long-running READ
> WRITE transaction. The delay, if any, would be on the connection
> which is committing that long running transaction.

What worries me most is that the cleanup happens while
SerializableXactHashLock is held. It's probably not a big deal in
practice, but it seems safer and probably more readable too to do the
cleanup at checkpoint.

Here's what I had in mind. Can you review, and do you have something to
test this with?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Attachment Content-Type Size
truncate-serial-at-checkpoint.patch text/x-diff 8.7 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message depstein 2011-03-06 13:29:28 Can't use WITH in a PERFORM query in PL/pgSQL?
Previous Message Bruce Momjian 2011-03-05 20:14:10 Re: BUG #5705: btree_gist: Index on inet changes query result