Re: [HACKERS] WAL logging freezing - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] WAL logging freezing
Date
Msg-id 18776.1162392656@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] WAL logging freezing  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-patches
"Simon Riggs" <simon@2ndquadrant.com> writes:
> Do we need another GUC? I thought your observation about a PITR slave
> having that set lower than its master still remains unresolved.

No, AFAICS that's not an issue in this design.  The facts-on-the-ground
are whatever is recorded in pg_class.relvacuumxid, and whether a
particular table has been vacuumed with a shorter or longer freeze
window doesn't affect correctness.  In particular, a slave with
ambitions towards having a shorter window would still be unable to
truncate its clog before having re-vacuumed everything.

So, not only could we have a GUC variable, but it could be USERSET;
there's no breakage risk as long as we constrain the value range to
something sane.

It strikes me that VACUUM FREEZE could be replaced by
    SET vacuum_freeze_limit = 0
    VACUUM ...
which would be a good thing because the FREEZE keyword has to be
partially reserved in this syntax, and that is contrary to spec.

            regards, tom lane

pgsql-patches by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: [HACKERS] WAL logging freezing
Next
From: Tom Lane
Date:
Subject: Re: Writing WAL for relcache invalidation: pg_internal.init