Re: Disable Transaction - plans ?

From: Mike Mascari <mascarm(at)mascari(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: thomas(at)pgsql(dot)com, Doug McNaught <doug(at)wireboard(dot)com>, "Dominic J(dot) Eidson" <sauron(at)the-infinite(dot)org>, Ben-Nes Michael <miki(at)canaan(dot)co(dot)il>, pgsql-general(at)postgresql(dot)org
Subject: Re: Disable Transaction - plans ?
Date: 2001-10-25 01:14:09
Message-ID: 3BD76761.532AC5D3@mascari.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
>
> Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> > There is a client-side termination handshake, and it could be tied to
> > that. If we can distinguish between an intentional exit and an
> > unexpected termination, then istm that a commit would be safe to apply
> > for the former.
>
> I assert that we cannot safely determine that; it's too easy for a
> client logic error to tell libpq to close the connection at the wrong
> time, and we should NOT default to committing when that happens.
>
> I think a client using this mode should be expected to send an explicit
> commit command before exiting.

With respect to Oracle, use of the libpq's equivalent to PQFinish(),
OCISessionEnd(), implicitly issues a COMMIT before disconnecting, so
it appears to be the client's responsibility wrt Oracle. SQL*Plus
users will note that, if their SQL*Plus session is exited normally
via the QUIT command, their work will also be committed, since it is
probably just calling OCISessionEnd() itself. So would it be
possible to modify PQFinish() to examine whether autocommit = true,
and if so, issue a commit before disconnect, else just disconnect?

Mike Mascari
mascarm(at)mascari(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marc G. Fournier 2001-10-25 01:15:38 Re: CVS server stumbling?
Previous Message Bruce Momjian 2001-10-25 00:58:06 Re: Disable Transaction - plans ?