Hi,
On Tuesday, June 19, 2012 06:11:20 PM Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On Tuesday, June 19, 2012 04:30:59 PM Tom Lane wrote:
> >>> ... (If you are thinking
> >>> of something sufficiently high-level that merging could possibly work,
> >>> then it's not WAL, and we shouldn't be trying to make the WAL
> >>> representation cater for it.)
> >
> > Do you really see this as such a big problem?
> It looks suspiciously like "I have a hammer, therefore every problem
> must be a nail". I don't like the design concept of cramming logical
> replication records into WAL in the first place.
There are - so far - no specific "logical replication records". Its a
relatively minor amount of additional data under wal_level=logical for
existing records. HEAP_UPDATE gets the old primary key on updates changing the
pkey and HEAP_DELETE always has the pkey. HEAP_INSERT|UPDATE|
DELETE,HEAP2_MULTI_INSERT put their information in another XLogRecData block
than the page to handle full page writes. Thats it.
I can definitely understand hesitation about that, but I simply see no
realistic way to solve the issues of existing replication solutions otherwise.
Do you have a better idea to solve those than the above? Without significant
complications of the backend code and without loads of additional writes going
on?
I *really* would like to hear them if you do.
> However, if we're dead set on doing it that way, let us put information
> that is only relevant to logical replication records into only the
> logical replication records.
I found, and still do, the idea of having the origin_id in there rather
elegant. If people prefer adding the same block to all of the above xlog
records: I can live with that and will then do so. It makes some things more
complicated, but its not too bad.
Greetings,
Andres
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services