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