pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: CSStorm occurred again by postgreSQL8.2
3+ messages / 2 participants
[nested] [flat]
* Re: CSStorm occurred again by postgreSQL8.2
@ 2007-09-11 09:42 Simon Riggs <simon@2ndquadrant.com>
2007-09-11 13:58 ` Re: CSStorm occurred again by postgreSQL8.2 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 3+ messages in thread
From: Simon Riggs @ 2007-09-11 09:42 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>; Bruce Momjian <bruce@momjian.us>; pgsql-hackers
On Wed, 2006-09-13 at 21:45 -0400, Tom Lane wrote:
> Anyway, given that there's this one nonobvious gotcha, there might be
> others. My recommendation is that we take this off the open-items list
> for 8.2 and revisit it in the 8.3 cycle when there's more time.
Well, its still 8.3 just...
As discussed in the other thread "Final Thoughts for 8.3 on LWLocking
and Scalability", XidCacheRemoveRunningXids() is now the only holder of
an X lock during normal processing, so I would like to remove it.
Here's how:
Currently, we take the lock, remove the subxact and then shuffle down
all the other subxactIds so that the subxact cache is contiguous.
I propose that we simply zero out the subxact entry without re-arranging
the cache; this will be atomic, so we need not acquire an X lock. We
then increment ndeletedxids. When we enter a new subxact into the cache,
if ndeletedxids > 0 we scan the cache to find an InvalidTransactionId
that we can use, then decrement ndeletedxids. So ndeletedxids is just a
hint, not an absolute requirement. nxids then becomes the number of
cache entries and never goes down until EOXact. The subxact cache is no
longer in order, but then it doesn't need to be either.
When we take a snapshot we will end up taking a copy of zeroed cache
entries, so the snapshots will be slightly larger than previously.
Though still no larger than the max. The size reduction was not so large
as to make a significant difference across the whole array, so
scalability is the main issue to resolve.
The snapshots will be valid with no change, since InvalidTransactionId
will never match against any recorded Xid.
I would also like to make the size of the subxact cache configurable
with a parameter such as subtransaction_cache_size = 64 (default), valid
range 4-256.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: CSStorm occurred again by postgreSQL8.2
2007-09-11 09:42 Re: CSStorm occurred again by postgreSQL8.2 Simon Riggs <simon@2ndquadrant.com>
@ 2007-09-11 13:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-09-11 15:26 ` Re: CSStorm occurred again by postgreSQL8.2 Simon Riggs <simon@2ndquadrant.com>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2007-09-11 13:58 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>; Bruce Momjian <bruce@momjian.us>; pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> As discussed in the other thread "Final Thoughts for 8.3 on LWLocking
> and Scalability", XidCacheRemoveRunningXids() is now the only holder of
> an X lock during normal processing,
Nonsense. Main transaction exit also takes an exclusive lock, and is
far more likely to be exercised in typical workloads than a
subtransaction abort.
In any case: there has still not been any evidence presented by anyone
that optimizing XidCacheRemoveRunningXids will help one bit. Given the
difficulty of measuring any benefit from the last couple of
optimizations in this general area, I'm thinking that such evidence
will be hard to come by. And we have got way more than enough on our
plates already. Can we let go of this for 8.3, please?
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: CSStorm occurred again by postgreSQL8.2
2007-09-11 09:42 Re: CSStorm occurred again by postgreSQL8.2 Simon Riggs <simon@2ndquadrant.com>
2007-09-11 13:58 ` Re: CSStorm occurred again by postgreSQL8.2 Tom Lane <tgl@sss.pgh.pa.us>
@ 2007-09-11 15:26 ` Simon Riggs <simon@2ndquadrant.com>
0 siblings, 0 replies; 3+ messages in thread
From: Simon Riggs @ 2007-09-11 15:26 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>; Bruce Momjian <bruce@momjian.us>; pgsql-hackers
On Tue, 2007-09-11 at 09:58 -0400, Tom Lane wrote:
> Can we let go of this for 8.3, please?
OK, we've moved forward, so its a good place to break.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2007-09-11 15:26 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-09-11 09:42 Re: CSStorm occurred again by postgreSQL8.2 Simon Riggs <simon@2ndquadrant.com>
2007-09-11 13:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-09-11 15:26 ` Simon Riggs <simon@2ndquadrant.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox