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
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 |