Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Tom Lane wrote:
>>> I don't see much problem with rejecting VAC FULL in a HS master,
>>> whether or not it gets removed altogether. Why not just do that
>>> rather than write a lot of kluges?
>
>> Hmm. At the moment, no action is required in the master to allow hot
>> standby in the slave, except for turning on archiving. The additional
>> overhead of the extra logging that's needed in the master is small
>> enough that there has been no need for a switch.
>
> There's no equivalent of XLogArchivingActive()? I think there probably
> should be. I find it really hard to believe that there won't be any
> places where we need to know that we're an HS master. The original
> design of WAL archiving didn't think we needed to know we were archiving
> WAL, either, and look how many cases there are for that now.
XLogArchivingMode() == false enables us to skip WAL-logging in
operations like CLUSTER or COPY, which is a big optimization. I don't
see anything like that in Hot Standby. There is a few small things that
could be skipped, but nothing noticeable.
It's great from usability point of view that you don't need to enable it
beforehand, especially because HS is also very useful when doing PITR
from a backup; it's too late to turn on the switch at that point. As
soon as we have a good reason to introduce a switch, let's do so, but
not before that.
If we want cop out of VACUUM FULL and HS issues, maybe we could just
kick out all clients from the standby when we see a WAL record from
VACUUM FULL. Not very elegant, but should work.
Anyway, I think I have enough courage now to just rip out the VACUUM
FULL support from HS. If VACUUM FULL is still there when we're ready to
go to beta, we can introduce a "do you want VACUUM FULL or hot standby?"
switch in the master, or some other ugly workaround.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com