Re: transaction timeout

On Tue, Jul 26, 2005 at 02:33:04PM -0400, Tom Lane wrote:
> Well, it ought to, but I for one don't consider that code path
> adequately tested --- and we have seen at least one report (from Rod
> Taylor if memory serves) suggesting that there are in fact bugs in it.
>
> We know that SIGTERM'ing all the backends at once leaves the database
> with a good state on disk; that path is tested everytime someone shuts
> down Postgres. It does not follow that SIGTERM'ing a single backend
> leaves consistent state in shared memory. Rod's report suggested a
> corrupt lock table in particular.

Well, is there debugging you can enable to check for corrupted locak
tables? If so, would it we worthwhile to setup a system with lots of
concurrent transactions and kill processes regularly and see if
anything strange happens.

Also, I've tended to use -INT to abort the current query, then -TERM to
kill the backend. Would this be safer, given you know exactly where
everything is at that point (aborted transaction)?

Does an aborted transaction release its locks straight away or does it
wait until the client issues a ROLLBACK?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.