Re: Hot standby and removing VACUUM FULL - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Hot standby and removing VACUUM FULL
Date
Msg-id 407d949e0911242143r40bc92baoc6341310391213b4@mail.gmail.com
Whole thread Raw
In response to Re: Hot standby and removing VACUUM FULL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Nov 25, 2009 at 3:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <gsstark@mit.edu> writes:
>> Well the only thing that's been discussed is having vacuum require a
>> minimum age before considering a transaction visible to all to reduce
>> the chance of conflicts on cleanup records.
>
> [ shrug... ]  Call me Cassandra.  I am not concerned about what has or
> has not been discussed.  I am concerned about what effects we are going
> to be blindsided by, a few months from now when it is too late to
> conveniently add a way to detect that the system is being run as an HS
> master.  If we design it in, perhaps we won't need it --- but if we
> design it out, we will need it.  You have heard of Finagle's law, no?

Well the point here was that the only inkling of a possible need for
this that we have is going to require more than an on/off switch
anyways. That's likely to be true of any need which arises.

And you didn't answer my questions about the semantics of this switch
will be. That a replica which starts up while reading wal logs
generated by this database will refuse connections even if it's
configured to allow them? How will it determine what the switch was on
the master? The value of the switch at what point in time? The answers
to these questions seem to depend on what the need which triggered the
existence of the switch was.

--
greg


pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
Next
From: Itagaki Takahiro
Date:
Subject: Re: Syntax for partitioning