On Sun, 2010-01-31 at 14:35 -0500, Tom Lane wrote:
> 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.
All transactional invalidations are already handled by HS. It was the
non-transactional invalidations in VACUUM FULL INPLACE that still
require additional handling.
> 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.
Very little really; not enough to force the sort of changes that I am
now seeing will be required in the way catalogs and caches operate.
There was some difficulty around the fact that VFI issues two commits
for the same transaction, but that is now correctly handled in the code
after discussion.
I'm not known as a risk-averse person but (2) is a step too far for me.
-- Simon Riggs www.2ndQuadrant.com
