Re: The vacuum-ignore-vacuum patch - Mailing list pgsql-hackers

From Chris Browne
Subject Re: The vacuum-ignore-vacuum patch
Date
Msg-id 60odv98u3w.fsf@dba2.int.libertyrms.com
Whole thread Raw
In response to Re: [PATCHES] The vacuum-ignore-vacuum patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
jnasby@pervasive.com ("Jim C. Nasby") writes:
> There are other transactions to consider: user transactions that will
> run a long time, but only hit a limited number of relations. These are
> as big a problem in an OLTP environment as vacuum is.
>
> Rather than coming up with machinery that will special-case vacuum or
> pg_dump, etc., I'd suggest thinking about a generic framework that would
> work for any long-runnnig transaction. One possibility:
>
> Transaction flags itself as 'long-running' and provides a list of
> exactly what relations it will be touching.
>
> That list is stored someplace a future vacuum can get at.
>
> The transaction runs, with additional checks that ensure it will not
> touch any relations that aren't in the list it provided. 

One thought that's a bit different...

How about we mark transactions that are in serializable mode?  That
would merely be a flag...

We would know that, for each such transaction, we could treat all
tuples "deadified" after those transactions as being dead and
cleanable.

That doesn't require any knowledge of relations that are
touched/locked...
-- 
"cbbrowne","@","cbbrowne.com"
http://www.ntlug.org/~cbbrowne/nonrdbms.html
To err is human, to moo bovine. 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Role incompatibilities
Next
From: Alvaro Herrera
Date:
Subject: Re: Hash indexes (was: On-disk bitmap index patch)