Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] CSStorm occurred again by postgreSQL8.2

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-patches(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] CSStorm occurred again by postgreSQL8.2
Date: 2006-08-28 10:17:41
Message-ID: 20060828181312.5638.ITAGAKI.TAKAHIRO@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Is there anything to do for 8.2 here?

I'm working on Tom's idea. It is not a feature and does not change
the on-disk-structures, so I hope it meet the 8.2 deadline...

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm wondering about doing something similar to what
> TransactionIdIsInProgress does, ie, make use of the PGPROC lists
> of live subtransactions.  Suppose that GetSnapshotData copies not
> only top xids but live subxids into the snapshot, and adds a flag
> indicating whether the subxids are complete (ie, none of the subxid
> lists have overflowed).  Then if the flag is set, tqual.c doesn't
> need to do SubTransGetTopmostTransaction() before searching the
> list.

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.

I tested the patch and did not see any context switch storm which comes
from pg_subtrans, but there may be some bugs in the visibility checking.
It would be very nice if you could review or test the patch.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center


Attachment: snapshot_subtrans.patch
Description: application/octet-stream (7.9 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2006-08-28 12:03:22
Subject: Re: pg_upgrade: What is changed?
Previous:From: Gregory StarkDate: 2006-08-28 09:08:09
Subject: Re: [HACKERS] Trivial patch to double vacuum speed on tables with no indexes

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2006-08-28 14:18:35
Subject: Re: [HACKERS] Trivial patch to double vacuum speed on tables with no indexes
Previous:From: Gregory StarkDate: 2006-08-28 09:08:09
Subject: Re: [HACKERS] Trivial patch to double vacuum speed on tables with no indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group