On 5/29/08, Joshua D. Drake <jd@commandprompt.com> wrote:
> On Thu, 2008-05-29 at 08:21 -0700, David Fetter wrote:
> > On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote:
> > This part is a deal-killer. It's a giant up-hill slog to sell warm
> > standby to those in charge of making resources available because the
> > warm standby machine consumes SA time, bandwidth, power, rack space,
> > etc., but provides no tangible benefit, and this feature would have
> > exactly the same problem.
> >
> > IMHO, without the ability to do read-only queries on slaves, it's not
> > worth doing this feature at all.
>
> The only question I have is... what does this give us that PITR doesn't
> give us?
Tom is talking about synchronous WAL replication.
So you can do lossless failover. Currently there is no good
solution for this.
And it needs to live in core backend. Yes, it could somehow be implemented
by filling backend with hooks, but the question is how it will get synced
with changes in core backend after couple of releases? The WAL writing
and txid/snapshot handling receive heavy changes on each release.
No external project that needs deep hooks has been able to keep pace with
core changes thus far. Unless heavily commercially backed which means
not open-source. Companies can tell the price they pay for such syncing..
Other solution would be indeed to have fixed hooks guaranteed to be stable
between releases. (replica-hooks-discuss?) But that would mean limiting
the changes we can do with WAL-writing/snapshot handling code and that
does not seem like attractive solution.
By having such replication code that tightly ties into core code
included in main Postgres source, we are still free to do any changes
we feel like and not be tied into external API promises.
--
marko
