"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 Lane||Date: 2009-09-25 02:08:07|
|Subject: Re: Postgresql 8.4.1 segfault, backtrace |
|Previous:||From: Michael Brown||Date: 2009-09-25 00:41:43|
|Subject: Re: Postgresql 8.4.1 segfault, backtrace|