Re: Re: Hot Standby query cancellation and Streaming Replication integration - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Re: Hot Standby query cancellation and Streaming Replication integration
Date
Msg-id 603c8f071002271700t1bffd309r8b8838189d4c827e@mail.gmail.com
Whole thread Raw
In response to Re: Re: Hot Standby query cancellation and Streaming Replication integration  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Hot Standby query cancellation and Streaming Replication integration
List pgsql-hackers
On Fri, Feb 26, 2010 at 1:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <gsstark@mit.edu> writes:
>> In the model you describe any long-lived queries on the slave cause
>> tables in the master to bloat with dead records.
>
> Yup, same as they would do on the master.
>
>> I think this model is on the roadmap but it's not appropriate for
>> everyone and I think one of the benefits of having delayed it is that
>> it forces us to get the independent model right before throwing in
>> extra complications. It would be too easy to rely on the slave
>> feedback as an answer for hard questions about usability if we had it
>> and just ignore the question of what to do when it's not the right
>> solution for the user.
>
> I'm going to make an unvarnished assertion here.  I believe that the
> notion of synchronizing the WAL stream against slave queries is
> fundamentally wrong and we will never be able to make it work.
> The information needed isn't available in the log stream and can't be
> made available without very large additions (and consequent performance
> penalties).  As we start getting actual beta testing we are going to
> uncover all sorts of missed cases that are not going to be fixable
> without piling additional ugly kluges on top of the ones Simon has
> already crammed into the system.  Performance and reliability will both
> suffer.
>
> I think that what we are going to have to do before we can ship 9.0
> is rip all of that stuff out and replace it with the sort of closed-loop
> synchronization Greg Smith is pushing.  It will probably be several
> months before everyone is forced to accept that, which is why 9.0 is
> not going to ship this year.

Somewhat unusually for me, I haven't been able to keep up with my
email over the last few days, so I'm weighing in on this one a bit
late.  It seems to me that if we're forced to pass the xmin from the
slave back to the master, that would be a huge step backward in terms
of both scalability and performance, so I really hope it doesn't come
to that.  I wish I understood better exactly what you mean by "the
notion of synchronizing the WAL stream against slave queries" and why
you don't think it will work.  Can you elaborate?

...Robert


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: Anyone know if Alvaro is OK?
Next
From: Robert Haas
Date:
Subject: Re: Avoiding bad prepared-statement plans.