Re: Issues with two-server Synch Rep

> That's probably not going to happen until we have a way to update
> postgresql.conf via SQL. Which, I maintain, as I have maintained
> before, is not going to happen until we get rid of the comments,
> because otherwise absolutely any implementation anyone proposes will
> get criticized for failing to handle them sensibly (because it is not
> possible to rewrite the file while handling the comments sensibly).

Well, you know my viewpoint on that. I'm still bitter about the .conf
directory patch.

>>> What is your source for those numbers? They could be right, but I
>>> simply don't know.
>> pg_bench tests with asynch rep and standby_delay = 0. Not rigorous, but
>> enough to show that there is a problem there. Doing pg_bench with a
>> small database
>
> Interesting.

Yeah, it occurs to me that we can "fix" this with cleanup_delay on the
master, but that's a much worse solution than XID publication from the
standby. It means bloat *all* the time instead of just some of the time.

I think we have Yet Another Knob here: users whose standby is
essentially idle will NOT want XID publication, and users whose standby
is for load-balancing will.

Note that XID publication needn't mean extraordinary extra bloat
provided that the queries on the standby are short-lived. Long-running
reporting queries, of course, should be run on an asynch standby.

> Sure. But we can't forever ignore the fact that trigger-based
> replication is not as performant as log-based replication.

Watch me. ;-)

>> This problem certainly exists with async, it's just less likely so
>> people are ignoring it. With a high enough transaction rate, and a
>> standby in "apply" mode, it's *certain* to happen on synch rep. So we
>> can't ignore it as a problem anymore.
>
> It exists with no replication at all...

Oh, I see what you mean, now. Point taken.

> Yes, that's my viewpoint. I think both this an the previous item are
> pretty basic database theory - and you can probably read about them in
> any good database theory textbook.

I doubt anything we're doing here is covering new ground, really.
Binary log-based replication has been around for a while in proprietary
products. We just don't necessarily want to make the *same* tradeoffs
other DBs have.

> Fair enough. I was just replying because (1) nobody else had and (2)
> I thought it might help to try to separate out which of the issues you
> raised are most relevant to the patches at hand.

Sure. Simon is apparently on vacation right now. Not sure where Fujii is.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com