On 2013-09-04 10:02:05 -0400, Robert Haas wrote:
> On Tue, Sep 3, 2013 at 7:10 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> I don't think it particularly needs to be configurable, but I wonder
> >> if we can't be a bit smarter about when we do it. For example,
> >> suppose we logged it every 15 s but only until we log a non-overflowed
> >> snapshot.
> >
> > There's actually more benefits than just overflowed snapshots (pruning
> > of the known xids machinery, exclusive lock cleanup).
> I know that, but I thought the master and slave could only lose sync
> on those things after a master crash and that once per checkpoint
> cycle was enough for those other benefits. Am I wrong?
The xid tracking can keep track without the additional records but it
sometimes needs a good bit more memory to do so if the primary burns to
xids quite fast. Everytime we see an running xacts record we can do
cleanup (that's the ExpireOldKnownAssignedTransactionIds() in
ProcArrayApplyRecoveryInfo()).
> > The problem with using dbname=replication as a trigger for anything is
> > that we actually allow databases to be created with that name. Perhaps
> > that was a design mistake.
>
> It seemed like a good idea at the time, but maybe it wasn't. I'm not
> sure where to go with it at this point; a forcible backward
> compatibility break would probably screw things up for a lot of
> people.
Yes, breaking things now doesn't seem like a good idea.
> > I wondered about turning replication from a boolean into something like
> > off|0, on|1, database. dbname= gets only used in the latter
> > variant. That would be compatible with previous versions and would even
> > support using old tools (since all of them seem to do replication=1).
>
> I don't love that, but I don't hate it, either.
Ok. Will update the patch that way. Seems better than it's current state.
> But it still doesn't
> answer the following question, which I think is important: if I (or
> someone else) commits this patch, how will that make things better for
> users? At the moment it's just adding a knob that doesn't do anything
> for you when you twist it.
I am not sure it's a good idea to commit it before we're sure were going
to commit the changeset extraction. It's an independently reviewable and
testable piece of code that's simple enough to understand quickly in
contrast to the large changeset extraction patch. That's why I kept it
separate.
On the other hand, as you know, it's not without precedent to commit
pieces of infrastructure that aren't really useful for the enduser
(think FDW).
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services