Re: No long-lived transaction, still can't delete tuples - Mailing list pgsql-general

From Jeffrey Baker
Subject Re: No long-lived transaction, still can't delete tuples
Date
Msg-id 20020424223544.GA19503@heat
Whole thread Raw
In response to Re: No long-lived transaction, still can't delete tuples  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: No long-lived transaction, still can't delete tuples
List pgsql-general
On Wed, Apr 24, 2002 at 06:21:31PM -0400, Tom Lane wrote:
> Jeffrey Baker <jwbaker@acm.org> writes:
> > So I believe the transaction is not long-lived.  Also, I checked
> > with tethereal to make absolutely certain that the commit was
> > happening:
>
> > ->    0  5163 6f6d 6d69 7400                       Qcommit.
> > <-    0  4343 4f4d 4d49 5400 5a                    CCOMMIT.Z
> > ->    0  5162 6567 696e 00                         Qbegin.
> > <-    0  4342 4547 494e 005a                       CBEGIN.Z
>
> Isn't that BEGIN opening a new transaction?

Sure is.  Very next thing.  That's how the Perl DBI operates.

> Some front-end libraries have a bad habit of issuing a BEGIN instantly
> after a commit, rather than waiting for the next command to be issued.
> That means your app goes to sleep with an open transaction.

Right, but it's the *next* transaction it goes to sleep in, correct?
So the time sequence looks like this:

   proc 1 | proc 2

00 connect
01 begin
02 work
03 commit
04 begin
05 work
06 commit
07 begin    connect
08 work     begin
09 commit   delete everything
10 begin    commit
11 work     vacuum <= this should get rid of everything < t = 07
12 commit   disconnect
13 begin
14 work
15 commit

Unless I totally misunderstand.

(BTW in the intervening hours I have updated to 7.2.1 to see if that
changes anything.)

Regards,
Jeffrey Baker

pgsql-general by date:

Previous
From: "Robert J. Sanford, Jr."
Date:
Subject: Re: odd psql behaviour on OSX
Next
From: Tom Lane
Date:
Subject: Re: odd psql behaviour on OSX