public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v30 04/11] Add Incremental View Maintenance support to pg_dump 4+ messages / 4 participants [nested] [flat]
* [PATCH v30 04/11] Add Incremental View Maintenance support to pg_dump @ 2020-11-11 08:01 Yugo Nagata <[email protected]> 0 siblings, 0 replies; 4+ 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 | 18 +++++++++++++++--- src/bin/pg_dump/pg_dump.h | 2 ++ src/bin/pg_dump/t/002_pg_dump.pl | 18 ++++++++++++++++++ 3 files changed, 35 insertions(+), 3 deletions(-) diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c index 2225a12718..009958fdd4 100644 --- a/src/bin/pg_dump/pg_dump.c +++ b/src/bin/pg_dump/pg_dump.c @@ -6648,6 +6648,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. @@ -6750,10 +6751,17 @@ getTables(Archive *fout, int *numTables) if (fout->remoteVersion >= 100000) appendPQExpBufferStr(query, - "c.relispartition AS ispartition "); + "c.relispartition AS ispartition, "); else appendPQExpBufferStr(query, - "false AS ispartition "); + "false AS ispartition, "); + + if (fout->remoteVersion >= 170000) + 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 @@ -6862,6 +6870,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) { @@ -6941,6 +6950,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 */ @@ -15977,9 +15987,11 @@ dumpTableSchema(Archive *fout, const TableInfo *tbinfo) binary_upgrade_set_pg_class_oids(fout, q, tbinfo->dobj.catId.oid, false); - appendPQExpBuffer(q, "CREATE %s%s %s", + appendPQExpBuffer(q, "CREATE %s%s%s %s", tbinfo->relpersistence == RELPERSISTENCE_UNLOGGED ? "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 77db42e354..7f05cbaec6 100644 --- a/src/bin/pg_dump/pg_dump.h +++ b/src/bin/pg_dump/pg_dump.h @@ -325,6 +325,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 00b5092713..fff9419347 100644 --- a/src/bin/pg_dump/t/002_pg_dump.pl +++ b/src/bin/pg_dump/t/002_pg_dump.pl @@ -2832,6 +2832,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.25.1 --Multipart=_Mon__4_Mar_2024_11_58_46_+0900_UaponF/qQhQrVCFt Content-Type: text/x-diff; name="v30-0005-Add-Incremental-View-Maintenance-support-to-psql.patch" Content-Disposition: attachment; filename="v30-0005-Add-Incremental-View-Maintenance-support-to-psql.patch" Content-Transfer-Encoding: 7bit ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Memory leak in WAL sender with pgoutput (v10~) @ 2024-12-03 06:56 Peter Smith <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Peter Smith @ 2024-12-03 06:56 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]>; Postgres hackers <[email protected]> On Tue, Dec 3, 2024 at 5:47 PM Michael Paquier <[email protected]> wrote: > > On Mon, Dec 02, 2024 at 03:29:56PM +0530, Amit Kapila wrote: > > We can look at it from a different angle which is that the > > FreePublication(s) relies on how the knowledge of Publication > > structure is built. So, it doesn't look weird if we think from that > > angle. > > OK, I can live with that on all the stable branches with an extra > list free rather than a deep list free. > > I agree that the memory handling of this whole area needs some rework > to make such leaks harder to introduce in the WAL sender. Still, > let's first solve the problem at hand :) > > So how about the attached that introduces a FreePublication() matching > with GetPublication(), used to do the cleanup? Feel free to comment. > -- Perhaps the patch can use foreach_ptr macro instead of foreach? ====== Kind Regards, Peter Smith. Fujitsu Australia ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Memory leak in WAL sender with pgoutput (v10~) @ 2024-12-03 07:49 Alvaro Herrera <[email protected]> parent: Peter Smith <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Alvaro Herrera @ 2024-12-03 07:49 UTC (permalink / raw) To: Peter Smith <[email protected]>; +Cc: Michael Paquier <[email protected]>; Amit Kapila <[email protected]>; Postgres hackers <[email protected]> On 2024-Dec-03, Peter Smith wrote: > Perhaps the patch can use foreach_ptr macro instead of foreach? That cannot be backpatched, though. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end." (2nd Commandment for C programmers) ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Memory leak in WAL sender with pgoutput (v10~) @ 2024-12-03 07:56 Michael Paquier <[email protected]> parent: Alvaro Herrera <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Michael Paquier @ 2024-12-03 07:56 UTC (permalink / raw) To: Alvaro Herrera <[email protected]>; +Cc: Peter Smith <[email protected]>; Amit Kapila <[email protected]>; Postgres hackers <[email protected]> On Tue, Dec 03, 2024 at 08:49:41AM +0100, Alvaro Herrera wrote: > That cannot be backpatched, though. Extra code churn is always annoying across stable branches, so I'd rather avoid it if we can. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-12-03 07:56 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-11 08:01 [PATCH v30 04/11] Add Incremental View Maintenance support to pg_dump Yugo Nagata <[email protected]> 2024-12-03 06:56 Re: Memory leak in WAL sender with pgoutput (v10~) Peter Smith <[email protected]> 2024-12-03 07:49 ` Re: Memory leak in WAL sender with pgoutput (v10~) Alvaro Herrera <[email protected]> 2024-12-03 07:56 ` Re: Memory leak in WAL sender with pgoutput (v10~) Michael Paquier <[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