Re: Re: Hot Standby query cancellation and Streaming Replication integration
| От | Tom Lane |
|---|---|
| Тема | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
| Дата | |
| Msg-id | 2425.1267211800@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Re: Hot Standby query cancellation and Streaming Replication integration (Josh Berkus <josh@agliodbs.com>) |
| Ответы |
Re: Re: Hot Standby query cancellation and Streaming Replication
integration
Re: Re: Hot Standby query cancellation and Streaming Replication integration Re: Hot Standby query cancellation and Streaming Replication integration Re: Re: Hot Standby query cancellation and Streaming Replication integration |
| Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes:
> On 2/26/10 10:53 AM, Tom Lane wrote:
>> 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.
> I don't think that publishing visibility info back to the master ... and
> subsequently burdening the master substantially for each additional
> slave ... are what most users want.
I don't see a "substantial additional burden" there. What I would
imagine is needed is that the slave transmits a single number back
--- its current oldest xmin --- and the walsender process publishes
that number as its transaction xmin in its PGPROC entry on the master.
I don't doubt that this approach will have its own gotchas that we
find as we get into it. But it looks soluble. I have no faith in
either the correctness or the usability of the approach currently
being pursued.
regards, tom lane
В списке pgsql-hackers по дате отправления: