public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v39 4/8] Add Incremental View Maintenance support to pg_dump 9+ messages / 5 participants [nested] [flat]
* [PATCH v39 4/8] Add Incremental View Maintenance support to pg_dump @ 2020-11-11 08:01 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 9+ messages in thread From: Yugo Nagata @ 2020-11-11 08:01 UTC (permalink / raw) Support CREATE INCREMENTAL MATERIALIZED VIEW syntax. --- src/bin/pg_dump/pg_dump.c | 14 +++++++++++++- src/bin/pg_dump/pg_dump.h | 2 ++ src/bin/pg_dump/t/002_pg_dump.pl | 18 ++++++++++++++++++ 3 files changed, 33 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c index f67daf85911..9a5f65659e3 100644 --- a/src/bin/pg_dump/pg_dump.c +++ b/src/bin/pg_dump/pg_dump.c @@ -7196,6 +7196,7 @@ getTables(Archive *fout, int *numTables) int i_relacl; int i_acldefault; int i_ispartition; + int i_isivm; /* * Find all the tables and table-like objects. @@ -7277,6 +7278,13 @@ getTables(Archive *fout, int *numTables) appendPQExpBufferStr(query, "c.relispartition AS ispartition "); + if (fout->remoteVersion >= 200000) + appendPQExpBufferStr(query, + "c.relisivm AS isivm "); + else + appendPQExpBufferStr(query, + "false AS isivm "); + /* * Left join to pg_depend to pick up dependency info linking sequences to * their owning column, if any (note this dependency is AUTO except for @@ -7387,6 +7395,7 @@ getTables(Archive *fout, int *numTables) i_relacl = PQfnumber(res, "relacl"); i_acldefault = PQfnumber(res, "acldefault"); i_ispartition = PQfnumber(res, "ispartition"); + i_isivm = PQfnumber(res, "isivm"); if (dopt->lockWaitTimeout) { @@ -7469,6 +7478,7 @@ getTables(Archive *fout, int *numTables) tblinfo[i].amname = pg_strdup(PQgetvalue(res, i, i_amname)); tblinfo[i].is_identity_sequence = (strcmp(PQgetvalue(res, i, i_is_identity_sequence), "t") == 0); tblinfo[i].ispartition = (strcmp(PQgetvalue(res, i, i_ispartition), "t") == 0); + tblinfo[i].isivm = (strcmp(PQgetvalue(res, i, i_isivm), "t") == 0); /* other fields were zeroed above */ @@ -17202,10 +17212,12 @@ dumpTableSchema(Archive *fout, const TableInfo *tbinfo) * PostgreSQL 18 has disabled UNLOGGED for partitioned tables, so * ignore it when dumping if it was set in this case. */ - appendPQExpBuffer(q, "CREATE %s%s %s", + appendPQExpBuffer(q, "CREATE %s%s%s %s", (tbinfo->relpersistence == RELPERSISTENCE_UNLOGGED && tbinfo->relkind != RELKIND_PARTITIONED_TABLE) ? "UNLOGGED " : "", + tbinfo->relkind == RELKIND_MATVIEW && tbinfo->isivm ? + "INCREMENTAL " : "", reltypename, qualrelname); diff --git a/src/bin/pg_dump/pg_dump.h b/src/bin/pg_dump/pg_dump.h index 5a6726d8b12..4408c504323 100644 --- a/src/bin/pg_dump/pg_dump.h +++ b/src/bin/pg_dump/pg_dump.h @@ -347,6 +347,8 @@ typedef struct _tableInfo int numParents; /* number of (immediate) parent tables */ struct _tableInfo **parents; /* TableInfos of immediate parents */ + bool isivm; /* is incrementally maintainable materialized view? */ + /* * These fields are computed only if we decide the table is interesting * (it's either a table to dump, or a direct parent of a dumpable table). diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_dump.pl index 9258948b583..8abde57e4f3 100644 --- a/src/bin/pg_dump/t/002_pg_dump.pl +++ b/src/bin/pg_dump/t/002_pg_dump.pl @@ -3033,6 +3033,24 @@ my %tests = ( }, }, + 'CREATE MATERIALIZED VIEW matview_ivm' => { + create_order => 21, + create_sql => 'CREATE INCREMENTAL MATERIALIZED VIEW dump_test.matview_ivm (col1) AS + SELECT col1 FROM dump_test.test_table;', + regexp => qr/^ + \QCREATE INCREMENTAL MATERIALIZED VIEW dump_test.matview_ivm AS\E + \n\s+\QSELECT col1\E + \n\s+\QFROM dump_test.test_table\E + \n\s+\QWITH NO DATA;\E + /xm, + like => + { %full_runs, %dump_test_schema_runs, section_pre_data => 1, }, + unlike => { + exclude_dump_test_schema => 1, + only_dump_measurement => 1, + }, + }, + 'CREATE POLICY p1 ON test_table' => { create_order => 22, create_sql => 'CREATE POLICY p1 ON dump_test.test_table -- 2.43.0 --Multipart=_Fri__3_Jul_2026_19_11_16_+0900_CskxSIu_iGcDMEyM Content-Type: text/x-diff; name="v39-0003-Allow-to-prolong-life-span-of-transition-tables-.patch" Content-Disposition: attachment; filename="v39-0003-Allow-to-prolong-life-span-of-transition-tables-.patch" Content-Transfer-Encoding: 7bit ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Column Filtering in Logical Replication @ 2022-04-18 11:04 Amit Kapila <[email protected]> 0 siblings, 2 replies; 9+ messages in thread From: Amit Kapila @ 2022-04-18 11:04 UTC (permalink / raw) To: Masahiko Sawada <[email protected]>; Petr Jelinek <[email protected]>; +Cc: Tomas Vondra <[email protected]>; [email protected] <[email protected]>; Peter Eisentraut <[email protected]>; Alvaro Herrera <[email protected]>; Justin Pryzby <[email protected]>; Rahila Syed <[email protected]>; Peter Smith <[email protected]>; pgsql-hackers; [email protected] <[email protected]> On Thu, Apr 14, 2022 at 9:09 AM Amit Kapila <[email protected]> wrote: > > On Thu, Apr 14, 2022 at 8:32 AM Masahiko Sawada <[email protected]> wrote: > > > > > > The other part of the puzzle is the below check in the code: > > > /* > > > * If we reached the sync worker limit per subscription, just exit > > > * silently as we might get here because of an otherwise harmless race > > > * condition. > > > */ > > > if (nsyncworkers >= max_sync_workers_per_subscription) > > > > > > It is not clear to me why this check is there, if this wouldn't be > > > there, the user would have got either a WARNING to increase the > > > max_logical_replication_workers or the apply worker would have been > > > restarted. Do you have any idea about this? > > > > Yeah, I'm also puzzled with this check. It seems that this function > > doesn't work well when the apply worker is not running and some > > tablesync workers are running. I initially thought that the apply > > worker calls to this function as many as tables that needs to be > > synced, but it checks the max_sync_workers_per_subscription limit > > before calling to logicalrep_worker_launch(). So I'm not really sure > > we need this check. > > > > I just hope that the original author Petr J. responds to this point. I > have added him to this email. This will help us to find the best > solution for this problem. > I did some more investigation for this code. It is added by commit [1] and the patch that led to this commit is first time posted on -hackers in email [2]. Now, neither the commit message nor the patch (comments) gives much idea as to why this part of code is added but I think there is some hint in the email [2]. In particular, read the paragraph in the email [2] that has the lines: ".... and limiting sync workers per subscription theoretically wasn't either (although I don't think it could happen in practice).". It seems that this check has been added to theoretically limit the sync workers even though that can't happen because apply worker ensures that before trying to launch the sync worker. Does this theory make sense to me? If so, I think we can change the check as: "if (OidIsValid(relid) && nsyncworkers >= max_sync_workers_per_subscription)" in launcher.c. This will serve the purpose of the original code and will solve the issue being discussed here. I think we can even backpatch this. What do you think? [1] commit de4389712206d2686e09ad8d6dd112dc4b6c6d42 Author: Peter Eisentraut <[email protected]> Date: Wed Apr 26 10:43:04 2017 -0400 Fix various concurrency issues in logical replication worker launching [2] - https://www.postgresql.org/message-id/fa387e24-0e26-c02d-ef16-7e46ada200dd%402ndquadrant.com -- With Regards, Amit Kapila. ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Column Filtering in Logical Replication @ 2022-04-18 12:36 Tomas Vondra <[email protected]> parent: Amit Kapila <[email protected]> 1 sibling, 0 replies; 9+ messages in thread From: Tomas Vondra @ 2022-04-18 12:36 UTC (permalink / raw) To: Amit Kapila <[email protected]>; Masahiko Sawada <[email protected]>; Petr Jelinek <[email protected]>; +Cc: [email protected] <[email protected]>; Peter Eisentraut <[email protected]>; Alvaro Herrera <[email protected]>; Justin Pryzby <[email protected]>; Rahila Syed <[email protected]>; Peter Smith <[email protected]>; pgsql-hackers; [email protected] <[email protected]> On 4/18/22 13:04, Amit Kapila wrote: > On Thu, Apr 14, 2022 at 9:09 AM Amit Kapila <[email protected]> wrote: >> >> On Thu, Apr 14, 2022 at 8:32 AM Masahiko Sawada <[email protected]> wrote: >>>> >>>> The other part of the puzzle is the below check in the code: >>>> /* >>>> * If we reached the sync worker limit per subscription, just exit >>>> * silently as we might get here because of an otherwise harmless race >>>> * condition. >>>> */ >>>> if (nsyncworkers >= max_sync_workers_per_subscription) >>>> >>>> It is not clear to me why this check is there, if this wouldn't be >>>> there, the user would have got either a WARNING to increase the >>>> max_logical_replication_workers or the apply worker would have been >>>> restarted. Do you have any idea about this? >>> >>> Yeah, I'm also puzzled with this check. It seems that this function >>> doesn't work well when the apply worker is not running and some >>> tablesync workers are running. I initially thought that the apply >>> worker calls to this function as many as tables that needs to be >>> synced, but it checks the max_sync_workers_per_subscription limit >>> before calling to logicalrep_worker_launch(). So I'm not really sure >>> we need this check. >>> >> >> I just hope that the original author Petr J. responds to this point. I >> have added him to this email. This will help us to find the best >> solution for this problem. >> > > I did some more investigation for this code. It is added by commit [1] > and the patch that led to this commit is first time posted on -hackers > in email [2]. Now, neither the commit message nor the patch (comments) > gives much idea as to why this part of code is added but I think there > is some hint in the email [2]. In particular, read the paragraph in > the email [2] that has the lines: ".... and limiting sync workers per > subscription theoretically wasn't either (although I don't think it > could happen in practice).". > > It seems that this check has been added to theoretically limit the > sync workers even though that can't happen because apply worker > ensures that before trying to launch the sync worker. Does this theory > make sense to me? If so, I think we can change the check as: "if > (OidIsValid(relid) && nsyncworkers >= > max_sync_workers_per_subscription)" in launcher.c. This will serve the > purpose of the original code and will solve the issue being discussed > here. I think we can even backpatch this. What do you think? > Sounds reasonable to me. It's unfortunate there's no explanation of what exactly is the commit message fixing (and why), but I doubt anyone will remember the details after 5 years. +1 to backpatching, I consider this to be a bug regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Column Filtering in Logical Replication @ 2022-04-19 01:27 Masahiko Sawada <[email protected]> parent: Amit Kapila <[email protected]> 1 sibling, 1 reply; 9+ messages in thread From: Masahiko Sawada @ 2022-04-19 01:27 UTC (permalink / raw) To: Amit Kapila <[email protected]>; +Cc: Petr Jelinek <[email protected]>; Tomas Vondra <[email protected]>; [email protected] <[email protected]>; Peter Eisentraut <[email protected]>; Alvaro Herrera <[email protected]>; Justin Pryzby <[email protected]>; Rahila Syed <[email protected]>; Peter Smith <[email protected]>; pgsql-hackers; [email protected] <[email protected]> On Mon, Apr 18, 2022 at 8:04 PM Amit Kapila <[email protected]> wrote: > > On Thu, Apr 14, 2022 at 9:09 AM Amit Kapila <[email protected]> wrote: > > > > On Thu, Apr 14, 2022 at 8:32 AM Masahiko Sawada <[email protected]> wrote: > > > > > > > > The other part of the puzzle is the below check in the code: > > > > /* > > > > * If we reached the sync worker limit per subscription, just exit > > > > * silently as we might get here because of an otherwise harmless race > > > > * condition. > > > > */ > > > > if (nsyncworkers >= max_sync_workers_per_subscription) > > > > > > > > It is not clear to me why this check is there, if this wouldn't be > > > > there, the user would have got either a WARNING to increase the > > > > max_logical_replication_workers or the apply worker would have been > > > > restarted. Do you have any idea about this? > > > > > > Yeah, I'm also puzzled with this check. It seems that this function > > > doesn't work well when the apply worker is not running and some > > > tablesync workers are running. I initially thought that the apply > > > worker calls to this function as many as tables that needs to be > > > synced, but it checks the max_sync_workers_per_subscription limit > > > before calling to logicalrep_worker_launch(). So I'm not really sure > > > we need this check. > > > > > > > I just hope that the original author Petr J. responds to this point. I > > have added him to this email. This will help us to find the best > > solution for this problem. > > > > I did some more investigation for this code. It is added by commit [1] > and the patch that led to this commit is first time posted on -hackers > in email [2]. Now, neither the commit message nor the patch (comments) > gives much idea as to why this part of code is added but I think there > is some hint in the email [2]. In particular, read the paragraph in > the email [2] that has the lines: ".... and limiting sync workers per > subscription theoretically wasn't either (although I don't think it > could happen in practice).". > > It seems that this check has been added to theoretically limit the > sync workers even though that can't happen because apply worker > ensures that before trying to launch the sync worker. Does this theory > make sense to me? If so, I think we can change the check as: "if > (OidIsValid(relid) && nsyncworkers >= > max_sync_workers_per_subscription)" in launcher.c. This will serve the > purpose of the original code and will solve the issue being discussed > here. I think we can even backpatch this. What do you think? +1. I also think it's a bug so back-patching makes sense to me. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/ ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Column Filtering in Logical Replication @ 2022-04-19 04:53 Amit Kapila <[email protected]> parent: Masahiko Sawada <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Amit Kapila @ 2022-04-19 04:53 UTC (permalink / raw) To: Masahiko Sawada <[email protected]>; +Cc: Petr Jelinek <[email protected]>; Tomas Vondra <[email protected]>; [email protected] <[email protected]>; Peter Eisentraut <[email protected]>; Alvaro Herrera <[email protected]>; Justin Pryzby <[email protected]>; Rahila Syed <[email protected]>; Peter Smith <[email protected]>; pgsql-hackers; [email protected] <[email protected]> On Tue, Apr 19, 2022 at 6:58 AM Masahiko Sawada <[email protected]> wrote: > > On Mon, Apr 18, 2022 at 8:04 PM Amit Kapila <[email protected]> wrote: > > > > On Thu, Apr 14, 2022 at 9:09 AM Amit Kapila <[email protected]> wrote: > > > > > > On Thu, Apr 14, 2022 at 8:32 AM Masahiko Sawada <[email protected]> wrote: > > > > > > > > > > The other part of the puzzle is the below check in the code: > > > > > /* > > > > > * If we reached the sync worker limit per subscription, just exit > > > > > * silently as we might get here because of an otherwise harmless race > > > > > * condition. > > > > > */ > > > > > if (nsyncworkers >= max_sync_workers_per_subscription) > > > > > > > > > > It is not clear to me why this check is there, if this wouldn't be > > > > > there, the user would have got either a WARNING to increase the > > > > > max_logical_replication_workers or the apply worker would have been > > > > > restarted. Do you have any idea about this? > > > > > > > > Yeah, I'm also puzzled with this check. It seems that this function > > > > doesn't work well when the apply worker is not running and some > > > > tablesync workers are running. I initially thought that the apply > > > > worker calls to this function as many as tables that needs to be > > > > synced, but it checks the max_sync_workers_per_subscription limit > > > > before calling to logicalrep_worker_launch(). So I'm not really sure > > > > we need this check. > > > > > > > > > > I just hope that the original author Petr J. responds to this point. I > > > have added him to this email. This will help us to find the best > > > solution for this problem. > > > > > > > I did some more investigation for this code. It is added by commit [1] > > and the patch that led to this commit is first time posted on -hackers > > in email [2]. Now, neither the commit message nor the patch (comments) > > gives much idea as to why this part of code is added but I think there > > is some hint in the email [2]. In particular, read the paragraph in > > the email [2] that has the lines: ".... and limiting sync workers per > > subscription theoretically wasn't either (although I don't think it > > could happen in practice).". > > > > It seems that this check has been added to theoretically limit the > > sync workers even though that can't happen because apply worker > > ensures that before trying to launch the sync worker. Does this theory > > make sense to me? If so, I think we can change the check as: "if > > (OidIsValid(relid) && nsyncworkers >= > > max_sync_workers_per_subscription)" in launcher.c. This will serve the > > purpose of the original code and will solve the issue being discussed > > here. I think we can even backpatch this. What do you think? > > +1. I also think it's a bug so back-patching makes sense to me. > Pushed. Thanks Tomas and Sawada-San. -- With Regards, Amit Kapila. ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Column Filtering in Logical Replication @ 2022-05-10 13:55 Jonathan S. Katz <[email protected]> parent: Amit Kapila <[email protected]> 0 siblings, 2 replies; 9+ messages in thread From: Jonathan S. Katz @ 2022-05-10 13:55 UTC (permalink / raw) To: Amit Kapila <[email protected]>; Masahiko Sawada <[email protected]>; +Cc: Petr Jelinek <[email protected]>; Tomas Vondra <[email protected]>; [email protected] <[email protected]>; Peter Eisentraut <[email protected]>; Alvaro Herrera <[email protected]>; Justin Pryzby <[email protected]>; Rahila Syed <[email protected]>; Peter Smith <[email protected]>; pgsql-hackers; [email protected] <[email protected]> Hi, On 4/19/22 12:53 AM, Amit Kapila wrote: > On Tue, Apr 19, 2022 at 6:58 AM Masahiko Sawada <[email protected]> wrote: >> >> +1. I also think it's a bug so back-patching makes sense to me. >> > > Pushed. Thanks Tomas and Sawada-San. This is still on the PG15 open items list[1] though marked as with a fix. Did dd4ab6fd resolve the issue, or does this need more work? Thanks, Jonathan [1] https://wiki.postgresql.org/wiki/PostgreSQL_15_Open_Items Attachments: [application/pgp-signature] OpenPGP_signature (840B, ../../[email protected]/2-OpenPGP_signature) download ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Column Filtering in Logical Replication @ 2022-05-10 19:17 Tomas Vondra <[email protected]> parent: Jonathan S. Katz <[email protected]> 1 sibling, 1 reply; 9+ messages in thread From: Tomas Vondra @ 2022-05-10 19:17 UTC (permalink / raw) To: Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Masahiko Sawada <[email protected]>; +Cc: Petr Jelinek <[email protected]>; [email protected] <[email protected]>; Peter Eisentraut <[email protected]>; Alvaro Herrera <[email protected]>; Justin Pryzby <[email protected]>; Rahila Syed <[email protected]>; Peter Smith <[email protected]>; pgsql-hackers; [email protected] <[email protected]> On 5/10/22 15:55, Jonathan S. Katz wrote: > Hi, > > On 4/19/22 12:53 AM, Amit Kapila wrote: >> On Tue, Apr 19, 2022 at 6:58 AM Masahiko Sawada >> <[email protected]> wrote: >>> >>> +1. I also think it's a bug so back-patching makes sense to me. >>> >> >> Pushed. Thanks Tomas and Sawada-San. > > This is still on the PG15 open items list[1] though marked as with a fix. > > Did dd4ab6fd resolve the issue, or does this need more work? > I believe that's fixed, the buildfarm does not seem to show any relevant failures in subscriptionCheck since dd4ab6fd got committed. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Column Filtering in Logical Replication @ 2022-05-10 19:28 Jonathan S. Katz <[email protected]> parent: Tomas Vondra <[email protected]> 0 siblings, 0 replies; 9+ messages in thread From: Jonathan S. Katz @ 2022-05-10 19:28 UTC (permalink / raw) To: Tomas Vondra <[email protected]>; Amit Kapila <[email protected]>; Masahiko Sawada <[email protected]>; +Cc: Petr Jelinek <[email protected]>; [email protected] <[email protected]>; Peter Eisentraut <[email protected]>; Alvaro Herrera <[email protected]>; Justin Pryzby <[email protected]>; Rahila Syed <[email protected]>; Peter Smith <[email protected]>; pgsql-hackers; [email protected] <[email protected]> On 5/10/22 3:17 PM, Tomas Vondra wrote: > On 5/10/22 15:55, Jonathan S. Katz wrote: >> Hi, >> >> On 4/19/22 12:53 AM, Amit Kapila wrote: >>> On Tue, Apr 19, 2022 at 6:58 AM Masahiko Sawada >>> <[email protected]> wrote: >>>> >>>> +1. I also think it's a bug so back-patching makes sense to me. >>>> >>> >>> Pushed. Thanks Tomas and Sawada-San. >> >> This is still on the PG15 open items list[1] though marked as with a fix. >> >> Did dd4ab6fd resolve the issue, or does this need more work? >> > > I believe that's fixed, the buildfarm does not seem to show any relevant > failures in subscriptionCheck since dd4ab6fd got committed. Great. I'm moving it off of open items. Thanks for confirming! Jonathan Attachments: [application/pgp-signature] OpenPGP_signature (840B, ../../[email protected]/2-OpenPGP_signature) download ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Column Filtering in Logical Replication @ 2022-05-11 03:20 Amit Kapila <[email protected]> parent: Jonathan S. Katz <[email protected]> 1 sibling, 0 replies; 9+ messages in thread From: Amit Kapila @ 2022-05-11 03:20 UTC (permalink / raw) To: Jonathan S. Katz <[email protected]>; +Cc: Masahiko Sawada <[email protected]>; Petr Jelinek <[email protected]>; Tomas Vondra <[email protected]>; [email protected] <[email protected]>; Peter Eisentraut <[email protected]>; Alvaro Herrera <[email protected]>; Justin Pryzby <[email protected]>; Rahila Syed <[email protected]>; Peter Smith <[email protected]>; pgsql-hackers; [email protected] <[email protected]> On Tue, May 10, 2022 at 7:25 PM Jonathan S. Katz <[email protected]> wrote: > > On 4/19/22 12:53 AM, Amit Kapila wrote: > > On Tue, Apr 19, 2022 at 6:58 AM Masahiko Sawada <[email protected]> wrote: > >> > >> +1. I also think it's a bug so back-patching makes sense to me. > >> > > > > Pushed. Thanks Tomas and Sawada-San. > > This is still on the PG15 open items list[1] though marked as with a fix. > > Did dd4ab6fd resolve the issue, or does this need more work? > The commit dd4ab6fd resolved this issue. I didn't notice it after that commit. -- With Regards, Amit Kapila. ^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2022-05-11 03:20 UTC | newest] Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-11 08:01 [PATCH v39 4/8] Add Incremental View Maintenance support to pg_dump Yugo Nagata <[email protected]> 2022-04-18 11:04 Re: Column Filtering in Logical Replication Amit Kapila <[email protected]> 2022-04-18 12:36 ` Re: Column Filtering in Logical Replication Tomas Vondra <[email protected]> 2022-04-19 01:27 ` Re: Column Filtering in Logical Replication Masahiko Sawada <[email protected]> 2022-04-19 04:53 ` Re: Column Filtering in Logical Replication Amit Kapila <[email protected]> 2022-05-10 13:55 ` Re: Column Filtering in Logical Replication Jonathan S. Katz <[email protected]> 2022-05-10 19:17 ` Re: Column Filtering in Logical Replication Tomas Vondra <[email protected]> 2022-05-10 19:28 ` Re: Column Filtering in Logical Replication Jonathan S. Katz <[email protected]> 2022-05-11 03:20 ` Re: Column Filtering in Logical Replication Amit Kapila <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox