Re: auto-reconnect: temp schemas, sequences, transactions

From: Marek Więckowski <wieckom(at)foxi(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: auto-reconnect: temp schemas, sequences, transactions
Date: 2011-05-02 15:17:11
Message-ID: 201105021717.12058.wieckom@foxi.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

On Monday 02 May 2011 16:43:54 Tom Lane wrote:
> Marek Wieckowski <wieckom(at)foxi(dot)nl> writes:
> > If I understand correctly, Tom's reply in:
> > http://archives.postgresql.org/pgsql-general/2007-06/msg01668.php
> > suggests that temp schemas are kept when a session gets disconnected
> > because connections get automatically re-established with the same
> > backend id, and if this succeeds the old temp tables get picked up by the
> > new connection as if there was no disconnection at all.
>
> Uh, no, surely not. The schema itself is re-used if it exists, but all
> the contained tables get flushed by the new session (if for some reason
> the old session failed to do that, as it would in case of a crash).

Clear. Thanks for your answer.

But what happens with a db transaction upon disconnect? If I have (say, in c++
code or a script):

begin;
query1;
query2;
query3;
query4;
query5;
commit;

(with possibly some extra c++ or script code in between queries), and
somewhere at the time when query2 is being executed some other backend
crashes; session gets disconnected and automatically connected: what would
happen to next queries which would be executed by the external code (query3, 4
and so on)? They would not be executed outside of db transaction, wouldn't
they? I would hope that they all keep failing up until next commit/rollback or
something similar...

Best,
~Marek

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2011-05-02 15:32:26 Re: auto-reconnect: temp schemas, sequences, transactions
Previous Message Greg Smith 2011-05-02 15:10:38 Re: pervasiveness of surrogate (also called synthetic) keys