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

At 06:59 PM 4/24/02 -0400, Tom Lane wrote:

>Actually that vacuum should get rid of everything older than t=10.
>What I'm concerned about is this scenario:
>
>Until client A returns from his lunch break, you'll not be able to
>vacuum the trash that client B generated, even though B has committed
>his changes.

Does just a BEGIN without anything else hold up vacuum? It doesn't seem to
for 7.1.3. Whereas a BEGIN followed by a select from a table holds up
vacuum once vacuum reaches the relevant table. BEGIN followed by select
(1), causes vacuum to stop with:
ERROR:  Parent tuple was not found

Once begin is rolled back, then vacuum works but you get:
NOTICE:  RegisterSharedInvalid: SI buffer overflow
NOTICE:  InvalidateSharedInvalid: cache state reset

Trying select (1) again gives:
NOTICE:  InvalidateSharedInvalid: cache state reset
  ?column?
----------
         1
(1 row)

Has this behaviour changed for 7.2?

If so the scenario is worse. It affects lots of people who use Perl DBI.

Typical perl webapp scenario:
initialize.
  make DB connection.

Serve requests:
while (wait for http request)
  rollback (implicit begin to get timestamps right)
  Serve up page
  commit/rollback (implicit begin)

Simple perl daemon app scenario:
make DB connection:
while (things ok and things to do)
  rollback (implicit begin)
  do stuff
  commit/rollback (implicit begin)
  sleep.

If just a plain BEGIN holds up vacuum, I won't be able to vacuum without
shutting down ALL my perl apps.

I understand why BEGIN might hold up vacuums, but 7.1 didn't (maybe
erroneously), so people who are migrating should be warned.

How can this problem be fixed? Perl DBI changed? Transactions don't begin
until first statement after BEGIN?

Regards,
Link.