On 2015-02-16 11:34:10 +0200, Heikki Linnakangas wrote:
> Yes, thanks. Note to self and everyone else looking at this: It's important
> to keep in mind is that the replication IDs are completely internal to the
> local cluster. They are *not* sent over the wire.
Well, if you *want* to, you could send the external (free form text)
replication identifiers over the wire in the output plugin. There are
scenarios where that might make sense.
> That's not completely true if you also use physical replication, though. The
> replication IDs will be included in the WAL stream.
Right. But then a physical rep server isn't realy a different server.
> Can you have logical decoding running in a hot standby server?
Not at the moment, there's some minor stuff missing (following
timelines, enforcing tuple visibility on the primary).
> And how does the progress report stuff that's checkpointed in
> pg_logical/checkpoints work in a hot standby? (Sorry if I'm not
> making sense, I haven't really thought hard about this myself)
It doesn't work that greatly atm, they'd need to be WAL logged for that
- which would not be hard. It'd be better to include the information in
the checkpoint, but that unfortunately doesn't really work, because we
store the checkpoint in the control file. And that has to be <=
512 bytes.
What, I guess, we could do is log it in the checkpoint, after
determining the redo pointer, and store the LSN for it in the checkpoint
record proper. That'd mean we'd read one more record at startup, but
that isn't particularly bad.
> At a quick glance, this basic design seems workable. I would suggest
> expanding the replication IDs to regular 4 byte oids. Two extra bytes is a
> small price to pay, to make it work more like everything else in the system.
I don't know. Growing from 3 to 5 byte overhead per relevant record (or
even 0 to 5 in case the padding is reused) is rather noticeable. If we
later find it to be a limit (I seriously doubt that), we can still
increase it in a major release without anybody really noticing.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
