Re: No long-lived transaction, still can't delete tuples
От | Jeffrey Baker |
---|---|
Тема | Re: No long-lived transaction, still can't delete tuples |
Дата | |
Msg-id | 20020424223544.GA19503@heat обсуждение исходный текст |
Ответ на | Re: No long-lived transaction, still can't delete tuples (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: No long-lived transaction, still can't delete tuples
|
Список | 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 по дате отправления: