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

Re: [HACKERS] Non-transactional pg_class, try 2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Non-transactional pg_class, try 2
Date: 2006-06-29 23:34:55
Message-ID: 18246.1151624095@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> I think we could give autovac a "reason for being started", which would
> normally be the periodic stuff, but if the postmaster got the signal
> from a backend, pass that info to autovac and it could use a different
> database selection algorithm -- say, just select the oldest database,
> even if it's not in danger of Xid wraparound.

I don't think it's worth the trouble to provide such a signaling
mechanism (it'd be a bit of a PITA to make it work in both fork and
EXEC_BACKEND cases).  ISTM it's sufficient for autovac to look at the
GUC state and notice whether it's nominally enabled or not.  If not,
it should only consider anti-wraparound vacuum operations.

If the signal is given just when VACUUM sees a datvacuumxid value that's
old enough to cause autovac to decide it had better go prevent
wraparound, then this will work without any additional data transfer.
We could negotiate exactly how old DBs need to be to cause this; if you
want to make it less than a billion xacts so that we can keep pg_clog
cut down to size, that's fine with me.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Marc MunroDate: 2006-06-29 23:52:58
Subject: [Re: Index corruption]
Previous:From: Tom LaneDate: 2006-06-29 23:27:07
Subject: Re: Index corruption

pgsql-patches by date

Next:From: Robert TreatDate: 2006-06-30 19:10:16
Subject: update commercial services link
Previous:From: Tom LaneDate: 2006-06-29 22:01:08
Subject: Re: [HACKERS] Non-transactional pg_class, try 2

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