Re: No long-lived transaction, still can't delete tuples

From: Jeffrey Baker <jwbaker(at)acm(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: No long-lived transaction, still can't delete tuples
Date: 2002-04-24 22:35:44
Message-ID: 20020424223544.GA19503@heat
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Apr 24, 2002 at 06:21:31PM -0400, Tom Lane wrote:
> Jeffrey Baker <jwbaker(at)acm(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2002-04-24 22:41:41 Re: odd psql behaviour on OSX
Previous Message Robert J. Sanford, Jr. 2002-04-24 22:34:59 Re: odd psql behaviour on OSX