Re: Missing CONCURRENT VACUUM (Was: Release notes for

On E, 2005-08-22 at 01:14 +0300, Hannu Krosing wrote:

> > I fixed this in a more local way by adding an extra "xmin" to proc for
> > transactions where inVacuum is false (proc->nonInVacuumXmin) which is
> > calculated together with proc->xmin.
>
> Somehow this still did not fix the issue of getting the xmin of long
> vacuum through concurrent transactions.

Actually it seems to work, if the "other" transaction actually does
something. It does not work when the only thing the other transactions
has doen is BEGIN WORK;

> My initial testing was wrong.

And my second testing was wrong too!

I tested in the following way (

create bigtable (i serial primary key, t text);
-- filled bigtable with 8 M rows
create tinytable(i serial primary key, t text);
insert into tinytable select * from bigtable limit 50;

opened 3 psql connections and did the following

1) vacuum bigtable;
2) update tinytable set t = random(); -- this creates dead tuples in
-- parallel with vacuum bigtable
3) begin;
2) vacuum verbose tinytable; -- cant free tuples
3) select 1;
2) vacuum verbose tinytable; -- can free the tuples

+ 30 sec

1) vacuum bigtable finishes

initially I just did begin and thought that concurrent transactions are
still blocking.

When I added a notice inside GetSnapshotData, I saw that it was not
called by plain BEGIN WORK;

Probably nonInVacuumXmin needs more care, i.e. initialising and setting
it outside GetSnapshotData, at trx start and/or end. I'm too sleepy now
to investigate further (it's 2:10 am here).

> Probably you should ignore the whole thing until I figure out why this
> does not work ...

Please try to apply the patch, even if dangling BEGIN WORK; still causes
problems - I'll fix this tomorrow.

I'd really like to see this in 8.1.

--
Hannu Krosing <hannu(at)tm(dot)ee>