Skip site navigation (1) Skip section navigation (2)

Re: PATCH to allow concurrent VACUUMs to not lock each

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each
Date: 2005-05-23 15:13:47
Message-ID: 1116861227.4849.20.camel@fuji.krosing.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On E, 2005-05-23 at 10:16 -0400, Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > I'm a little worried about having this set to "true" after a VACUUM is 
> > executed, and only reset to false when the next transaction is begun: it 
> > shouldn't affect correctness right now, but it seems like asking for 
> > trouble. Resetting the flag to "false" after processing a transaction 
> > would probably be worth doing.
> 
> These days I'd be inclined to use a PG_TRY construct to guarantee the
> flag is cleared, rather than loading another cleanup operation onto
> unrelated code.

Ok, will check out PG_TRY. I hoped that there is some way not to set
inVacuum to false at each transaction start and still be sure that it
will be reverted after vacuum_rel.

So I'll set it once at the start of connection and then maintain it in
vacuum_rel() using PG_TRY.

> The MyProc != NULL tests are a waste of code space.  You can't even
> acquire an LWLock without MyProc being set, let alone access tables.

Thanks, I'll get rid of them.

> The real issue here though is whether anyone can blow a hole in the
> xmin assumptions: is there any situation where ignoring a vacuum
> transaction breaks things?  I haven't had time to think about it
> in any detail, but it definitely needs to be thought about.

There may be need to exclude vacuum/analyse on system relations from
being ignored by vacuum_rel() as I suspect that the info they both write
to pg_class, pg_attribute, and possibly other tables may be vulnerable
to crashes at right moment. 

Also it may be prudent to not exclude other vacuums, when the vacuum_rel
() itself is run on a system relation.

I'm not sure which way it is, as my head gets all thick each time I try
to figure it out ;p.

I can't think of any other cases where it could matter, as at least the
work done inside vacuum_rel() itself seema non-rollbackable.

-- 
Hannu Krosing <hannu(at)skype(dot)net>


In response to

Responses

pgsql-hackers by date

Next:From: Douglas McNaughtDate: 2005-05-23 15:19:22
Subject: Re: inet increment w/ int8
Previous:From: Jan B.Date: 2005-05-23 15:01:12
Subject: Re: INSTEAD OF trigger on VIEWs

pgsql-patches by date

Next:From: Tom LaneDate: 2005-05-23 15:42:31
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each
Previous:From: Tom LaneDate: 2005-05-23 14:16:06
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group