On Sat, Jan 14, 2012 at 6:44 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> With the exception of EXPLAIN
>> support which I think is merely an oversight, all of those issues,
>> including the problems in Hot Standby mode, remain because nobody
>> knows exactly what we ought to do to fix th
Robert Haas writes:
> With the exception of EXPLAIN
> support which I think is merely an oversight, all of those issues,
> including the problems in Hot Standby mode, remain because nobody
> knows exactly what we ought to do to fix them. When somebody figures
> it out, I predict they'll get fixed
On Sat, Jan 14, 2012 at 11:17 AM, Noah Misch wrote:
> On Sat, Jan 14, 2012 at 08:08:29AM +, Simon Riggs wrote:
>> On Sat, Jan 14, 2012 at 1:02 AM, Noah Misch wrote:
>> > However, CLUSTER/VACUUM FULL already
>> > remove tuples still-visible to standby snapshots without provoking a
>> > recove
On Sat, Jan 14, 2012 at 08:08:29AM +, Simon Riggs wrote:
> On Sat, Jan 14, 2012 at 1:02 AM, Noah Misch wrote:
> > However, CLUSTER/VACUUM FULL already
> > remove tuples still-visible to standby snapshots without provoking a
> > recovery
> > conflict. ?(Again only with hot_standby_feedback=off
On Sat, Jan 14, 2012 at 5:42 AM, Robert Haas wrote:
> Other than that, it seems like we might be converging on a workable
> solution: if hot_standby_feedback=off, disable index-only scans for
> snapshots taken during recovery; if hot_standby_feedback=on, generate
> recovery conflicts when a snaps
On Sat, Jan 14, 2012 at 1:02 AM, Noah Misch wrote:
>> Also, what happens if an all-visible bit gets set on the standby
>> through some other mechanism - e.g. restored from an FPI or
>> XLOG_HEAP_NEWPAGE? I'm not sure whether we ever do an FPI of the
>> visibility map page itself, but we certainl
On Sat, Jan 14, 2012 at 12:42:02AM -0500, Robert Haas wrote:
> On Fri, Jan 13, 2012 at 8:02 PM, Noah Misch wrote:
> > Simon spoke to the FPI side of the question. ?For heap pages, the
> > XLOG_HEAP_NEWPAGE consumers are CLUSTER, VACUUM FULL and ALTER TABLE SET
> > TABLESPACE. ?For the last, we wil
On Fri, Jan 13, 2012 at 12:18 PM, Simon Riggs wrote:
> On Fri, Jan 13, 2012 at 5:08 PM, Robert Haas wrote:
>> Also, what happens if an all-visible bit gets set on the standby
>> through some other mechanism - e.g. restored from an FPI or
>> XLOG_HEAP_NEWPAGE? I'm not sure whether we ever do an F
On Fri, Jan 13, 2012 at 8:02 PM, Noah Misch wrote:
> Simon spoke to the FPI side of the question. For heap pages, the
> XLOG_HEAP_NEWPAGE consumers are CLUSTER, VACUUM FULL and ALTER TABLE SET
> TABLESPACE. For the last, we will have already logged any PD_ALL_VISIBLE bits
> through normal channe
On Fri, Jan 13, 2012 at 5:37 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Well, I disagree. The fact that all-visible info can't be trusted in
>> standby mode is a problem that has existed since Hot Standby was
>> committed, and I don't feel obliged to fix it just because I was
>> involv
On Fri, Jan 13, 2012 at 12:08:05PM -0500, Robert Haas wrote:
> On Fri, Jan 13, 2012 at 11:13 AM, Simon Riggs wrote:
> > Many WAL records have latestRemovedXid on them. We can use the same
> > idea with XLOG_HEAP2_VISIBLE records, so we add a field to send the
> > latest vacrelstats->latestRemovedX
Robert Haas writes:
> Well, I disagree. The fact that all-visible info can't be trusted in
> standby mode is a problem that has existed since Hot Standby was
> committed, and I don't feel obliged to fix it just because I was
> involved in developing a new feature that happens to rely on
I'm very
On Fri, Jan 13, 2012 at 5:08 PM, Robert Haas wrote:
> Also, what happens if an all-visible bit gets set on the standby
> through some other mechanism - e.g. restored from an FPI or
> XLOG_HEAP_NEWPAGE? I'm not sure whether we ever do an FPI of the
> visibility map page itself, but we certainly d
On Fri, Jan 13, 2012 at 11:13 AM, Simon Riggs wrote:
> I think it should be you that comes up with a fix, not for me to
> respond to your concerns about how hard it is. Many things that don't
> fully work are rejected for that reason.
Well, I disagree. The fact that all-visible info can't be tru
On Fri, Jan 13, 2012 at 3:22 PM, Robert Haas wrote:
> On Fri, Jan 13, 2012 at 10:17 AM, Simon Riggs wrote:
>> On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas wrote:
>>
>>> Since the xmin horizon on the standby may precede the xmin horizon on
>>> the master
>>
>> When hot_standby_feedback is turned
On Fri, Jan 13, 2012 at 10:31 AM, Jim Nasby wrote:
> Perhaps it would be possible to keep older copies of pages around when there
> are older transactions running on the standby?
I've thought about that... it's basically a rollback segment, which
for that matter might be judged superior to what
On Jan 13, 2012, at 8:03 AM, Robert Haas wrote:
> Or,
> we could try to lift this restriction in the special case when
> hot_standby_feedback is set, though I have a feeling that's not really
> robust - any time you lose the connection to the master, it'll lose
> your xmin holdback and possibly mar
On Fri, Jan 13, 2012 at 10:17 AM, Simon Riggs wrote:
> On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas wrote:
>
>> Since the xmin horizon on the standby may precede the xmin horizon on
>> the master
>
> When hot_standby_feedback is turned on, the xmin of the standby is
> provided to the master to en
On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas wrote:
> Since the xmin horizon on the standby may precede the xmin horizon on
> the master
When hot_standby_feedback is turned on, the xmin of the standby is
provided to the master to ensure the situation you describe never
happens.
Surely that mean
On Fri, Jan 13, 2012 at 8:27 AM, Simon Riggs wrote:
> The open items list for 9.2 says
>
> "Index-only scans need to be disabled when running under Hot Standby"
>
> There is no explanation, so please explain here so we can change it,
> if possible.
>
> Not sure its great policy to keep implementin
The open items list for 9.2 says
"Index-only scans need to be disabled when running under Hot Standby"
There is no explanation, so please explain here so we can change it,
if possible.
Not sure its great policy to keep implementing things that don't work
on HS, while not giving a proper chance f
21 matches
Mail list logo
