Re: CSStorm occurred again by postgreSQL8.2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CSStorm occurred again by postgreSQL8.2
Date
Msg-id 13251.1157299738@sss.pgh.pa.us
Whole thread Raw
In response to Re: CSStorm occurred again by postgreSQL8.2  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: CSStorm occurred again by postgreSQL8.2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> I added a subxid array to Snapshot and running subxids are gathered from
> PGPROC->subxids cache. There are two overflowed case; any of PGPROC->subxids
> are overflowed or the number of total subxids exceeds pre-allocated buffers.
> If overflowed, we cannot avoid to call SubTransGetTopmostTransaction.

Applied after some editorialization (you really need to pay more
attention to keeping comments in sync with code ;-))

I cannot measure any consistent speed difference in plain pgbench
scenarios with and without the patch, so at least as a rough
approximation the extra cycles in GetSnapshotData aren't hurting.
And I confirm that the test case you posted before no longer exhibits
a context-swap storm.

This change makes it even more obvious than before that we really want
to stay out of the subxids-overflowed regime.  I don't especially want
to make those arrays even bigger, but I wonder if there isn't more we
can do to use them efficiently.  In particular, it seems like in the
case where RecordSubTransactionCommit detects that the subxact has not
stored its XID anywhere, we could immediately remove the XID from
the PGPROC array, just as if it had aborted.  This would avoid chewing
subxid slots for cases such as exception blocks in plpgsql that are
not modifying the database, but just catching computational errors.
Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Second try committing the path
Next
From: Tom Lane
Date:
Subject: Re: CSStorm occurred again by postgreSQL8.2