Re: Hot Standby and VACUUM FULL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hot Standby and VACUUM FULL
Date
Msg-id 14766.1264966549@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hot Standby and VACUUM FULL  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Hot Standby and VACUUM FULL
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote:
>> Simon Riggs <simon@2ndQuadrant.com> writes:
>>> The options to do this were and still are:
>>> (1) Add WAL messages for non-transactional relcache invalidations
>>> (2) Allow system relations to be cluster-ed/vacuum full-ed.

>> Refresh my memory on why (1) lets us avoid fixing (2)?  

> (1) allows us to retain VACUUM FULL INPLACE for system relations, thus
> avoiding the need to do (2). Non-transactional invalidations need to be
> replayed in recovery for the same reason they exist on the primary.

Well, I would expect that invalidation events need to be transmitted to
hot-standby slaves no matter what --- backends running queries on an HS
slave need to hear about inval events just as much as backends on the
master do.  So my take on it is that all inval events will have to have
associated WAL records when in HS mode, independently of what we choose
to do about VACUUM.

Anyway, it's still not apparent to me exactly what the connection is
between VACUUM FULL and Hot Standby.  I remember that we said HS didn't
work with VACUUM FULL (INPLACE) but I don't recall why that is, and the
links on the open-items pages are not leading me to any useful
discussion.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot Standby and VACUUM FULL
Next
From: Simon Riggs
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to