Re: logical decoding and replication of sequences
От | Tomas Vondra |
---|---|
Тема | Re: logical decoding and replication of sequences |
Дата | |
Msg-id | 9da788c7-01eb-f11d-aa08-c5f61fe9f33a@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: logical decoding and replication of sequences (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: logical decoding and replication of sequences
Re: logical decoding and replication of sequences |
Список | pgsql-hackers |
Hi, Attached is a rebased patch, addressing most of the remaining issues. The main improvements are: 1) pg_publication_namespace.pntype and type checks Originally, the patch used pnsequences flag to distinguish which entries added by FOR ALL TABLES IN SCHEMA and FOR ALL SEQUENCES IN SCHEMA. I've decided to replace this with a simple char column, called pntype, where 't' means tables and 's' sequences. As explained before, relkind doesn't work well because of partitioned tables. A char, with a function to match it to relkind values works fairly well. I've revisited the question how to represent publications publishing the same schema twice - once for tables, once for sequences. There were proposals to represent this with a single row, i.e. turn pntype into an array of char values. So it'd be either ['t'], ['s'] or ['s', 't']. I spent some time working on that, but I've decided to keep the current approach with two separate rows - it's easier to manage, lookup etc. 2) pg_get_object_address I've updated the objectaddress code to consider pntype when looking-up the pntype value, so each row in pg_publication_namespace gets the correct ObjectAddress. 3) for all [tables | sequences] The original patch did not allow creating publication for all tables and all sequences at the same time. I've tweaked the grammar to allow this: CREATE PUBLICATION p FOR ALL list_of_types; where list_of_types is arbitrary combination of TABLES and SEQUENCES. It's implemented in a slightly awkward way - partially in the grammar, partially in the publicationcmds.c. I suspect there's a (cleaner) way to do this entirely in the grammar but I haven't succeeded yet. 4) prevent 'ADD TABLE sequence' and 'ADD SEQUENCE table' It was possible to do "ADD TABLE" and pass it a sequence, which would fail to notice if the publication already includes all sequences from the schema. I've added a check preventing that (and a similar one for ADD SEQUENCE). 5) missing block in AlterTableNamespace to cross-check moving published sequence to already published schema A block of code was missing from AlterTableNamespace, checking that we're not moving a sequence into a schema that is already published (all the sequences from it). 6) a couple comment fixes Various comment improvements and fixes. At this point there's a couple trivial FIXME/XXX comments remaining. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: