Re: adding partitioned tables to publications
amit <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Rafia Sabih <rafia.pghackers@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-03-27T13:10:28Z
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
Attachments
- v14-0003-Publish-partitioned-table-inserts-as-its-own.patch (application/octet-stream) patch v14-0003
- v1-0001-worker.c-refactor-code-to-look-up-local-tuple.patch (application/octet-stream) patch v1-0001
- v14-0002-Add-subscription-support-to-replicate-into-parti.patch (application/octet-stream) patch v14-0002
On Thu, Mar 26, 2020 at 11:23 PM Amit Langote <amitlangote09@gmail.com> wrote: > On Wed, Mar 25, 2020 at 9:29 PM Peter Eisentraut > <peter.eisentraut@2ndquadrant.com> wrote: > > 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. > > While trying some tests around the code you mentioned, I found what > looks like a bug, which looking into now. Turns out the code in apply_handle_tuple_routing() for the UPDATE message was somewhat bogus, which fixed in the updated version. I ended up with anothing refactoring patch, which attached as 0001. It appears to me that the tests now seem enough to cover apply_handle_tuple_routing(), although more could still be added. > > 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. > > Will check and fix as necessary. Removed that memset. I have added a comment about one- vs. zero-based indexes contained in the maps coming from two different modules, viz. tuple routing and logical replication, resp. -- Thank you, Amit Langote EnterpriseDB: http://www.enterprisedb.com