From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CSStorm occurred again by postgreSQL8.2 |
Date: | 2006-09-03 16:08:58 |
Message-ID: | 13251.1157299738@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-03 16:15:27 | Re: CSStorm occurred again by postgreSQL8.2 |
Previous Message | Andrew Dunstan | 2006-09-03 15:44:52 | Re: [COMMITTERS] pgsql: Second try committing the path |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-03 16:15:27 | Re: CSStorm occurred again by postgreSQL8.2 |
Previous Message | Bruce Momjian | 2006-09-03 13:37:41 | Re: [HACKERS] [COMMITTERS] pgsql: Change FETCH/MOVE |