From: | Chris Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: The vacuum-ignore-vacuum patch |
Date: | 2006-07-28 18:25:23 |
Message-ID: | 60odv98u3w.fsf@dba2.int.libertyrms.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
jnasby(at)pervasive(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-07-28 18:36:46 | Re: Do we need multiple forms of the SQL2003 statistics aggregates? |
Previous Message | Kenneth Marshall | 2006-07-28 17:44:12 | Re: Hash indexes (was: On-disk bitmap index patch) |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-07-28 19:25:06 | Re: [HACKERS] pg_regress breaks on msys |
Previous Message | Jim C. Nasby | 2006-07-28 17:38:41 | Re: The vacuum-ignore-vacuum patch |