Re: adding partitioned tables to publications
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Rafia Sabih <rafia.pghackers@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-03-25T12:29:52Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix RELCACHE_FORCE_RELEASE issue
- 12fb189bfeaf 13.0 landed
-
Allow publishing partition changes via ancestors
- 83fd4532a721 13.0 landed
-
Add logical replication support to replicate into partitioned tables
- f1ac27bfda6c 13.0 landed
-
Refactor code to look up local replication tuple
- d8653f468789 13.0 landed
-
Some refactoring of logical/worker.c
- 97ee604d9bce 13.0 landed
-
Prepare to support non-tables in publications
- c314c147c056 13.0 landed
-
Support adding partitioned tables to publication
- 17b9e7f9fe23 13.0 landed
On 2020-03-23 06:02, Amit Langote wrote: > Okay, added some tests. > > Attached updated patches. I have committed the worker.c refactoring patch. "Add subscription support to replicate into partitioned tables" still has lacking test coverage. Your changes in relation.c are not exercised at all because the partitioned table branch in apply_handle_update() is never taken. This is critical and tricky code, so I would look for significant testing. The code looks okay to me. I would remove this code + memset(entry->attrmap->attnums, -1, + entry->attrmap->maplen * sizeof(AttrNumber)); because the entries are explicitly filled right after anyway, and filling the bytes with -1 has an unclear effect. There is also seemingly some fishiness in this code around whether attribute numbers are zero- or one-based. Perhaps this could be documented briefly. Maybe I'm misunderstanding something. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services