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

Re: Postgresql 8.4.1 segfault, backtrace

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Michael Brown" <mbrown(at)fensystems(dot)co(dot)uk>
Cc: rn214(at)hermes(dot)cam(dot)ac(dot)uk, pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: Postgresql 8.4.1 segfault, backtrace
Date: 2009-09-25 00:50:13
Message-ID: 2741.1253839813@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Michael Brown" <mbrown(at)fensystems(dot)co(dot)uk> writes:
> If temporary table drops count towards this, then yes.

Yeah, they do.

> I could fairly easily change this procedure to truncate rather than drop
> the temporary table, if that would lessen the exposure to the problem. 
> Would that be likely to help?

Very probably.  It's not a complete fix but it would probably reduce the
cache inval traffic (and hence the risk) by an order of magnitude.
However, please be prepared to change back after I send you the backend
fix, so you can stress-test it ;-)

> (Alternatively, given that the temporary table usage here is quite
> inelegant, is there a better way to obtain a consistent database snapshot
> across multiple queries without using SERIALIZABLE when inside a PL/pgSQL
> function that has to be marked VOLATILE?)

Maybe you could accumulate the data you need in a local array instead,
but that would be a big rewrite.  A cursor might be a possibility too.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-09-25 02:08:07
Subject: Re: Postgresql 8.4.1 segfault, backtrace
Previous:From: Michael BrownDate: 2009-09-25 00:41:43
Subject: Re: Postgresql 8.4.1 segfault, backtrace

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