public inbox for [email protected]
help / color / mirror / Atom feedpg_upgrade failing for 200+ million Large Objects
49+ messages / 16 participants
[nested] [flat]
* pg_upgrade failing for 200+ million Large Objects
@ 2021-03-03 11:36 Tharakan, Robins <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Tharakan, Robins @ 2021-03-03 11:36 UTC (permalink / raw)
To: pgsql-hackers
Hi,
While reviewing a failed upgrade from Postgres v9.5 (to v9.6) I saw that the
instance had ~200 million (in-use) Large Objects. I was able to reproduce
this on a test instance which too fails with a similar error.
pg_restore: executing BLOB 4980622
pg_restore: WARNING: database with OID 0 must be vacuumed within 1000001
transactions
HINT: To avoid a database shutdown, execute a database-wide VACUUM in that
database.
You might also need to commit or roll back old prepared transactions.
pg_restore: executing BLOB 4980623
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2565; 2613 4980623 BLOB
4980623 postgres
pg_restore: [archiver (db)] could not execute query: ERROR: database is not
accepting commands to avoid wraparound data loss in database with OID 0
HINT: Stop the postmaster and vacuum that database in single-user mode.
You might also need to commit or roll back old prepared transactions.
Command was: SELECT pg_catalog.lo_create('4980623');
To remove the obvious possibilities, these Large Objects that are still
in-use (so vacuumlo wouldn't help), giving more system resources doesn't
help, moving Large Objects around to another database doesn't help (since
this is cluster-wide restriction), the source instance is nowhere close to
wraparound and lastly recent-most minor versions don't help either (I tried
compiling 9_6_STABLE + upgrade database with 150 million LO and still
encountered the same issue).
Do let me know if I am missing something obvious but it appears that this is
happening owing to 2 things coming together:
* Each Large Object is migrated in its own transaction during pg_upgrade
* pg_resetxlog appears to be narrowing the window (available for pg_upgrade)
to ~146 Million XIDs (2^31 - 1 million XID wraparound margin - 2 billion
which is a hard-coded constant - see [1] - in what appears to be an attempt
to force an Autovacuum Wraparound session soon after upgrade completes).
Ideally such an XID based restriction, is limiting for an instance that's
actively using a lot of Large Objects. Besides forcing AutoVacuum Wraparound
logic to kick in soon after, I am unclear what much else it aims to do. What
it does seem to be doing is to block Major Version upgrades if the
pre-upgrade instance has >146 Million Large Objects (half that, if the LO
additionally requires ALTER LARGE OBJECT OWNER TO for each of those objects
during pg_restore)
For long-term these ideas came to mind, although am unsure which are
low-hanging fruits and which outright impossible - For e.g. clubbing
multiple objects in a transaction [2] / Force AutoVacuum post upgrade (and
thus remove this limitation altogether) or see if "pg_resetxlog -x" (from
within pg_upgrade) could help in some way to work-around this limitation.
Is there a short-term recommendation for this scenario?
I can understand a high number of small-sized objects is not a great way to
use pg_largeobject (since Large Objects was intended to be for, well, 'large
objects') but this magic number of Large Objects is now a stalemate at this
point (with respect to v9.5 EOL).
Reference:
1) pg_resetxlog -
https://github.com/postgres/postgres/blob/ca3b37487be333a1d241dab1bbdd17a211
a88f43/src/bin/pg_resetwal/pg_resetwal.c#L444
2)
https://www.postgresql.org/message-id/ed7d86a1-b907-4f53-9f6e-63482d2f2bac%4
0manitou-mail.org
-
Thanks
Robins Tharakan
Attachments:
[application/pkcs7-signature] smime.p7s (5.0K, 2-smime.p7s)
download
^ permalink raw reply [nested|flat] 49+ messages in thread
* RE: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-07 08:43 Tharakan, Robins <[email protected]>
0 siblings, 2 replies; 49+ messages in thread
From: Tharakan, Robins @ 2021-03-07 08:43 UTC (permalink / raw)
To: pgsql-hackers
Hi all,
Attached is a proof-of-concept patch that allows Postgres to perform
pg_upgrade if the instance has Millions of objects.
It would be great if someone could take a look and see if this patch is in
the right direction. There are some pending tasks (such as documentation /
pg_resetxlog vs pg_resetwal related changes) but for now, the patch helps
remove a stalemate where if a Postgres instance has a large number
(accurately speaking 146+ Million) of Large Objects, pg_upgrade fails. This
is easily reproducible and besides deleting Large Objects before upgrade,
there is no other (apparent) way for pg_upgrade to complete.
The patch (attached):
- Applies cleanly on REL9_6_STABLE -
c7a4fc3dd001646d5938687ad59ab84545d5d043
- 'make check' passes
- Allows the user to provide a constant via pg_upgrade command-line, that
overrides the 2 billion constant in pg_resetxlog [1] thereby increasing the
(window of) Transaction IDs available for pg_upgrade to complete.
Sample argument for pg_upgrade:
$ /opt/postgres/96/bin/pg_upgrade --max-limit-xid 1000000000 --old-bindir
...
With this patch, pg_upgrade is now able to upgrade a v9.5 cluster with 500
million Large Objects successfully to v9.6 - some stats below:
Source Postgres - v9.5.24
Target Version - v9.6.21
Large Object Count: 500 Million Large Objects
Machine - r5.4xlarge (16vCPU / 128GB RAM + 1TB swap)
Memory used during pg_upgrade - ~350GB
Time taken - 25+ hrs. (tested twice) - (All LOs processed sequentially ->
Scope for optimization)
Although counter-intuitive, for this testing purpose all Large Objects were
small (essentially the idea was to test the count) and created by using
something like this:
seq 1 50000 | xargs -n 1 -i -P 10 /opt/postgres/95/bin/psql -c "select
lo_from_bytea(0, '\xffffff00') from generate_series(1,10000);" > /dev/null
I am not married to the patch (especially the argument name) but ideally I'd
prefer a way to get this upgrade going without a patch. For now, I am unable
to find any other way to upgrade a v9.5 Postgres database in this scenario,
facing End-of-Life.
Reference:
1) 2 Billion constant -
https://github.com/postgres/postgres/blob/ca3b37487be333a1d241dab1bbdd17a211
a88f43/src/bin/pg_resetwal/pg_resetwal.c#L444
Thanks,
Robins Tharakan
> -----Original Message-----
> From: Tharakan, Robins
> Sent: Wednesday, 3 March 2021 10:36 PM
> To: [email protected]
> Subject: pg_upgrade failing for 200+ million Large Objects
>
> Hi,
>
> While reviewing a failed upgrade from Postgres v9.5 (to v9.6) I saw that
> the
> instance had ~200 million (in-use) Large Objects. I was able to reproduce
> this on a test instance which too fails with a similar error.
>
>
> pg_restore: executing BLOB 4980622
> pg_restore: WARNING: database with OID 0 must be vacuumed within 1000001
> transactions
> HINT: To avoid a database shutdown, execute a database-wide VACUUM in
> that
> database.
> You might also need to commit or roll back old prepared transactions.
> pg_restore: executing BLOB 4980623
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 2565; 2613 4980623 BLOB
> 4980623 postgres
> pg_restore: [archiver (db)] could not execute query: ERROR: database is
> not
> accepting commands to avoid wraparound data loss in database with OID 0
> HINT: Stop the postmaster and vacuum that database in single-user mode.
> You might also need to commit or roll back old prepared transactions.
> Command was: SELECT pg_catalog.lo_create('4980623');
>
>
>
> To remove the obvious possibilities, these Large Objects that are still
> in-use (so vacuumlo wouldn't help), giving more system resources doesn't
> help, moving Large Objects around to another database doesn't help (since
> this is cluster-wide restriction), the source instance is nowhere close
> to
> wraparound and lastly recent-most minor versions don't help either (I
> tried
> compiling 9_6_STABLE + upgrade database with 150 million LO and still
> encountered the same issue).
>
> Do let me know if I am missing something obvious but it appears that this
> is
> happening owing to 2 things coming together:
>
> * Each Large Object is migrated in its own transaction during pg_upgrade
> * pg_resetxlog appears to be narrowing the window (available for
> pg_upgrade)
> to ~146 Million XIDs (2^31 - 1 million XID wraparound margin - 2 billion
> which is a hard-coded constant - see [1] - in what appears to be an
> attempt
> to force an Autovacuum Wraparound session soon after upgrade completes).
>
> Ideally such an XID based restriction, is limiting for an instance that's
> actively using a lot of Large Objects. Besides forcing AutoVacuum
> Wraparound
> logic to kick in soon after, I am unclear what much else it aims to do.
> What
> it does seem to be doing is to block Major Version upgrades if the
> pre-upgrade instance has >146 Million Large Objects (half that, if the LO
> additionally requires ALTER LARGE OBJECT OWNER TO for each of those
> objects
> during pg_restore)
>
> For long-term these ideas came to mind, although am unsure which are
> low-hanging fruits and which outright impossible - For e.g. clubbing
> multiple objects in a transaction [2] / Force AutoVacuum post upgrade
> (and
> thus remove this limitation altogether) or see if "pg_resetxlog -x" (from
> within pg_upgrade) could help in some way to work-around this limitation.
>
> Is there a short-term recommendation for this scenario?
>
> I can understand a high number of small-sized objects is not a great way
> to
> use pg_largeobject (since Large Objects was intended to be for, well,
> 'large
> objects') but this magic number of Large Objects is now a stalemate at
> this
> point (with respect to v9.5 EOL).
>
>
> Reference:
> 1) pg_resetxlog -
> https://github.com/postgres/postgres/blob/ca3b37487be333a1d241dab1bbdd17a
> 211
> a88f43/src/bin/pg_resetwal/pg_resetwal.c#L444
> 2)
> https://www.postgresql.org/message-id/ed7d86a1-b907-4f53-9f6e-
> 63482d2f2bac%4
> 0manitou-mail.org
>
> -
> Thanks
> Robins Tharakan
Attachments:
[application/octet-stream] pgupgrade_lo_v2.patch (5.4K, 2-pgupgrade_lo_v2.patch)
download | inline diff:
diff --git a/src/bin/pg_resetxlog/pg_resetxlog.c b/src/bin/pg_resetxlog/pg_resetxlog.c
index 3e79482ca2..f2e9824cb5 100644
--- a/src/bin/pg_resetxlog/pg_resetxlog.c
+++ b/src/bin/pg_resetxlog/pg_resetxlog.c
@@ -67,6 +67,7 @@ static TransactionId set_xid = 0;
static TransactionId set_oldest_commit_ts_xid = 0;
static TransactionId set_newest_commit_ts_xid = 0;
static Oid set_oid = 0;
+static Oid max_limit_xid = 2000000000;
static MultiXactId set_mxid = 0;
static MultiXactOffset set_mxoff = (MultiXactOffset) -1;
static uint32 minXlogTli = 0;
@@ -116,7 +117,7 @@ main(int argc, char *argv[])
}
- while ((c = getopt(argc, argv, "c:D:e:fl:m:no:O:x:")) != -1)
+ while ((c = getopt(argc, argv, "c:D:e:fl:L:m:no:O:x:")) != -1)
{
switch (c)
{
@@ -210,6 +211,21 @@ main(int argc, char *argv[])
}
break;
+ case 'L':
+ max_limit_xid = strtoul(optarg, &endptr, 0);
+ if (endptr == optarg || *endptr != '\0')
+ {
+ fprintf(stderr, _("%s: invalid argument for option %s\n"), progname, "-L");
+ fprintf(stderr, _("Try \"%s --help\" for more information.\n"), progname);
+ exit(1);
+ }
+ if (max_limit_xid <= 500000000)
+ {
+ fprintf(stderr, _("%s: Max Limit XID (-L) must not be less than 500 Million\n"), progname);
+ exit(1);
+ }
+ break;
+
case 'm':
set_mxid = strtoul(optarg, &endptr, 0);
if (endptr == optarg || *endptr != ',')
@@ -381,7 +397,7 @@ main(int argc, char *argv[])
* reasonably safe. The magic constant here corresponds to the
* maximum allowed value of autovacuum_freeze_max_age.
*/
- ControlFile.checkPointCopy.oldestXid = set_xid - 2000000000;
+ ControlFile.checkPointCopy.oldestXid = set_xid - max_limit_xid;
if (ControlFile.checkPointCopy.oldestXid < FirstNormalTransactionId)
ControlFile.checkPointCopy.oldestXid += FirstNormalTransactionId;
ControlFile.checkPointCopy.oldestXidDB = InvalidOid;
@@ -1239,6 +1255,7 @@ usage(void)
printf(_(" -e XIDEPOCH set next transaction ID epoch\n"));
printf(_(" -f force update to be done\n"));
printf(_(" -l XLOGFILE force minimum WAL starting location for new transaction log\n"));
+ printf(_(" -L MAXLIMITXID force max XID starting location for new transaction log\n"));
printf(_(" -m MXID,MXID set next and oldest multitransaction ID\n"));
printf(_(" -n no update, just show what would be done (for testing)\n"));
printf(_(" -o OID set next OID\n"));
diff --git a/src/bin/pg_upgrade/option.c b/src/bin/pg_upgrade/option.c
index 7ab284a51b..3a861739f7 100644
--- a/src/bin/pg_upgrade/option.c
+++ b/src/bin/pg_upgrade/option.c
@@ -53,6 +53,7 @@ parseCommandLine(int argc, char *argv[])
{"link", no_argument, NULL, 'k'},
{"retain", no_argument, NULL, 'r'},
{"jobs", required_argument, NULL, 'j'},
+ {"max-limit-xid", required_argument, NULL, 'L'},
{"verbose", no_argument, NULL, 'v'},
{NULL, 0, NULL, 0}
};
@@ -64,6 +65,7 @@ parseCommandLine(int argc, char *argv[])
time_t run_time = time(NULL);
user_opts.transfer_mode = TRANSFER_MODE_COPY;
+ user_opts.maxlimitxid = 2000000000;
os_info.progname = get_progname(argv[0]);
@@ -101,7 +103,7 @@ parseCommandLine(int argc, char *argv[])
if ((log_opts.internal = fopen_priv(INTERNAL_LOG_FILE, "a")) == NULL)
pg_fatal("cannot write to log file %s\n", INTERNAL_LOG_FILE);
- while ((option = getopt_long(argc, argv, "d:D:b:B:cj:ko:O:p:P:rU:v",
+ while ((option = getopt_long(argc, argv, "d:D:b:B:cj:ko:L:O:p:P:rU:v",
long_options, &optindex)) != -1)
{
switch (option)
@@ -132,6 +134,10 @@ parseCommandLine(int argc, char *argv[])
user_opts.jobs = atoi(optarg);
break;
+ case 'L':
+ user_opts.maxlimitxid = atoi(optarg);
+ break;
+
case 'k':
user_opts.transfer_mode = TRANSFER_MODE_LINK;
break;
@@ -287,6 +293,7 @@ Options:\n\
-D, --new-datadir=DATADIR new cluster data directory\n\
-j, --jobs=NUM number of simultaneous processes or threads to use\n\
-k, --link link instead of copying files to new cluster\n\
+ -L, --max-limit-xid=NUM max-limit XIDs to consider\n\
-o, --old-options=OPTIONS old cluster options to pass to the server\n\
-O, --new-options=OPTIONS new cluster options to pass to the server\n\
-p, --old-port=PORT old cluster port number (default %d)\n\
diff --git a/src/bin/pg_upgrade/pg_upgrade.c b/src/bin/pg_upgrade/pg_upgrade.c
index 02078c0357..2d0f3a7e04 100644
--- a/src/bin/pg_upgrade/pg_upgrade.c
+++ b/src/bin/pg_upgrade/pg_upgrade.c
@@ -411,8 +411,10 @@ copy_clog_xlog_xid(void)
/* set the next transaction id and epoch of the new cluster */
prep_status("Setting next transaction ID and epoch for new cluster");
exec_prog(UTILITY_LOG_FILE, NULL, true,
- "\"%s/pg_resetxlog\" -f -x %u \"%s\"",
- new_cluster.bindir, old_cluster.controldata.chkpnt_nxtxid,
+ "\"%s/pg_resetxlog\" -L %u -f -x %u \"%s\"",
+ new_cluster.bindir,
+ user_opts.maxlimitxid,
+ old_cluster.controldata.chkpnt_nxtxid,
new_cluster.pgdata);
exec_prog(UTILITY_LOG_FILE, NULL, true,
"\"%s/pg_resetxlog\" -f -e %u \"%s\"",
diff --git a/src/bin/pg_upgrade/pg_upgrade.h b/src/bin/pg_upgrade/pg_upgrade.h
index 9fbdacc53e..50fe73ae09 100644
--- a/src/bin/pg_upgrade/pg_upgrade.h
+++ b/src/bin/pg_upgrade/pg_upgrade.h
@@ -298,6 +298,7 @@ typedef struct
* changes */
transferMode transfer_mode; /* copy files or link them? */
int jobs;
+ int maxlimitxid;
} UserOpts;
[application/pkcs7-signature] smime.p7s (5.0K, 3-smime.p7s)
download
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-07 22:41 Daniel Gustafsson <[email protected]>
parent: Tharakan, Robins <[email protected]>
1 sibling, 0 replies; 49+ messages in thread
From: Daniel Gustafsson @ 2021-03-07 22:41 UTC (permalink / raw)
To: Tharakan, Robins <[email protected]>; +Cc: pgsql-hackers
> On 7 Mar 2021, at 09:43, Tharakan, Robins <[email protected]> wrote:
> The patch (attached):
> - Applies cleanly on REL9_6_STABLE -
> c7a4fc3dd001646d5938687ad59ab84545d5d043
Did you target 9.6 because that's where you want to upgrade to, or is this not
a problem on HEAD? If it's still a problem on HEAD you should probably submit
the patch against there. You probably also want to add it to the next commit
fest to make sure it's not forgotten about: https://commitfest.postgresql.org/33/
> I am not married to the patch (especially the argument name) but ideally I'd
> prefer a way to get this upgrade going without a patch. For now, I am unable
> to find any other way to upgrade a v9.5 Postgres database in this scenario,
> facing End-of-Life.
It's obviously not my call to make in any shape or form, but this doesn't
really seem to fall under what is generally backported into a stable release?
--
Daniel Gustafsson https://vmware.com/
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-08 10:25 Peter Eisentraut <[email protected]>
parent: Tharakan, Robins <[email protected]>
1 sibling, 0 replies; 49+ messages in thread
From: Peter Eisentraut @ 2021-03-08 10:25 UTC (permalink / raw)
To: Tharakan, Robins <[email protected]>; pgsql-hackers
On 07.03.21 09:43, Tharakan, Robins wrote:
> Attached is a proof-of-concept patch that allows Postgres to perform
> pg_upgrade if the instance has Millions of objects.
>
> It would be great if someone could take a look and see if this patch is in
> the right direction. There are some pending tasks (such as documentation /
> pg_resetxlog vs pg_resetwal related changes) but for now, the patch helps
> remove a stalemate where if a Postgres instance has a large number
> (accurately speaking 146+ Million) of Large Objects, pg_upgrade fails. This
> is easily reproducible and besides deleting Large Objects before upgrade,
> there is no other (apparent) way for pg_upgrade to complete.
>
> The patch (attached):
> - Applies cleanly on REL9_6_STABLE -
> c7a4fc3dd001646d5938687ad59ab84545d5d043
> - 'make check' passes
> - Allows the user to provide a constant via pg_upgrade command-line, that
> overrides the 2 billion constant in pg_resetxlog [1] thereby increasing the
> (window of) Transaction IDs available for pg_upgrade to complete.
Could you explain what your analysis of the problem is and why this
patch (might) fix it?
Right now, all I see here is, pass a big number via a command-line
option and hope it works.
^ permalink raw reply [nested|flat] 49+ messages in thread
* RE: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-08 11:00 Tharakan, Robins <[email protected]>
0 siblings, 0 replies; 49+ messages in thread
From: Tharakan, Robins @ 2021-03-08 11:00 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: pgsql-hackers
Thanks Daniel for the input / next-steps.
I see that 'master' too has this same magic constant [1] and so I expect it
to have similar restrictions, although I haven't tested this yet.
I do agree that the need then is to re-submit a patch that works with
'master'. (I am travelling the next few days but) Unless discussions go
tangential, I expect to revert with an updated patch by the end of this week
and create a commitfest entry while at it.
Reference:
1)
https://github.com/postgres/postgres/blob/master/src/bin/pg_resetwal/pg_rese
twal.c#L444
-
Robins Tharakan
> -----Original Message-----
> From: Daniel Gustafsson <[email protected]>
> Sent: Monday, 8 March 2021 9:42 AM
> To: Tharakan, Robins <[email protected]>
> Cc: [email protected]
> Subject: RE: [EXTERNAL] pg_upgrade failing for 200+ million Large Objects
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and
> know the content is safe.
>
>
>
> > On 7 Mar 2021, at 09:43, Tharakan, Robins <[email protected]> wrote:
>
> > The patch (attached):
> > - Applies cleanly on REL9_6_STABLE -
> > c7a4fc3dd001646d5938687ad59ab84545d5d043
>
> Did you target 9.6 because that's where you want to upgrade to, or is
> this not a problem on HEAD? If it's still a problem on HEAD you should
> probably submit the patch against there. You probably also want to add
> it to the next commit fest to make sure it's not forgotten about:
> https://commitfest.postgresql.org/33/
>
> > I am not married to the patch (especially the argument name) but
> > ideally I'd prefer a way to get this upgrade going without a patch.
> > For now, I am unable to find any other way to upgrade a v9.5 Postgres
> > database in this scenario, facing End-of-Life.
>
> It's obviously not my call to make in any shape or form, but this doesn't
> really seem to fall under what is generally backported into a stable
> release?
>
> --
> Daniel Gustafsson https://vmware.com/
Attachments:
[application/pkcs7-signature] smime.p7s (5.0K, 2-smime.p7s)
download
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-08 11:02 Tharakan, Robins <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Tharakan, Robins @ 2021-03-08 11:02 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: pgsql-hackers
Thanks Peter.
The original email [1] had some more context that somehow didn't get
associated with this recent email. Apologies for any confusion.
In short, pg_resetxlog (and pg_resetwal) employs a magic constant [2] (for
both v9.6 as well as master) which seems to have been selected to force an
aggressive autovacuum as soon as the upgrade completes. Although that works
as planned, it narrows the window of Transaction IDs available for the
upgrade (before which XID wraparound protection kicks and aborts the
upgrade) to 146 Million.
Reducing this magic constant allows a larger XID window, which is what the
patch is trying to do. With the patch, I was able to upgrade a cluster with
500m Large Objects successfully (which otherwise reliably fails). In the
original email [1] I had also listed a few other possible workarounds, but
was unsure which would be a good direction to start working on.... thus this
patch to make a start.
Reference:
1) https://www.postgresql.org/message-id/12601596dbbc4c01b86b4ac4d2bd4d48%40
EX13D05UWC001.ant.amazon.com
2) https://github.com/postgres/postgres/blob/master/src/bin/pg_resetwal/pg_r
esetwal.c#L444
-
robins | tharar@ | syd12
> -----Original Message-----
> From: Peter Eisentraut <[email protected]>
> Sent: Monday, 8 March 2021 9:25 PM
> To: Tharakan, Robins <[email protected]>; [email protected]
> Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: pg_upgrade failing for 200+
> million Large Objects
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and
> know the content is safe.
>
>
>
> On 07.03.21 09:43, Tharakan, Robins wrote:
> > Attached is a proof-of-concept patch that allows Postgres to perform
> > pg_upgrade if the instance has Millions of objects.
> >
> > It would be great if someone could take a look and see if this patch
> > is in the right direction. There are some pending tasks (such as
> > documentation / pg_resetxlog vs pg_resetwal related changes) but for
> > now, the patch helps remove a stalemate where if a Postgres instance
> > has a large number (accurately speaking 146+ Million) of Large
> > Objects, pg_upgrade fails. This is easily reproducible and besides
> > deleting Large Objects before upgrade, there is no other (apparent) way
> for pg_upgrade to complete.
> >
> > The patch (attached):
> > - Applies cleanly on REL9_6_STABLE -
> > c7a4fc3dd001646d5938687ad59ab84545d5d043
> > - 'make check' passes
> > - Allows the user to provide a constant via pg_upgrade command-line,
> > that overrides the 2 billion constant in pg_resetxlog [1] thereby
> > increasing the (window of) Transaction IDs available for pg_upgrade to
> complete.
>
> Could you explain what your analysis of the problem is and why this patch
> (might) fix it?
>
> Right now, all I see here is, pass a big number via a command-line option
> and hope it works.
Attachments:
[application/pkcs7-signature] smime.p7s (5.0K, 2-smime.p7s)
download
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-08 12:33 Magnus Hagander <[email protected]>
parent: Tharakan, Robins <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Magnus Hagander @ 2021-03-08 12:33 UTC (permalink / raw)
To: Tharakan, Robins <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
On Mon, Mar 8, 2021 at 12:02 PM Tharakan, Robins <[email protected]> wrote:
>
> Thanks Peter.
>
> The original email [1] had some more context that somehow didn't get
> associated with this recent email. Apologies for any confusion.
Please take a look at your email configuration -- all your emails are
lacking both References and In-reply-to headers, so every email starts
a new thread, both for each reader and in the archives. It seems quite
broken. It makes it very hard to follow.
> In short, pg_resetxlog (and pg_resetwal) employs a magic constant [2] (for
> both v9.6 as well as master) which seems to have been selected to force an
> aggressive autovacuum as soon as the upgrade completes. Although that works
> as planned, it narrows the window of Transaction IDs available for the
> upgrade (before which XID wraparound protection kicks and aborts the
> upgrade) to 146 Million.
>
> Reducing this magic constant allows a larger XID window, which is what the
> patch is trying to do. With the patch, I was able to upgrade a cluster with
> 500m Large Objects successfully (which otherwise reliably fails). In the
> original email [1] I had also listed a few other possible workarounds, but
> was unsure which would be a good direction to start working on.... thus this
> patch to make a start.
This still seems to just fix the symptoms and not the actual problem.
What part of the pg_upgrade process is it that actually burns through
that many transactions?
Without looking, I would guess it's the schema reload using
pg_dump/pg_restore and not actually pg_upgrade itself. This is a known
issue in pg_dump/pg_restore. And if that is the case -- perhaps just
running all of those in a single transaction would be a better choice?
One could argue it's still not a proper fix, because we'd still have a
huge memory usage etc, but it would then only burn 1 xid instead of
500M...
AFAICT at a quick check, pg_dump in binary upgrade mode emits one
lo_create() and one ALTER ... OWNER TO for each large object - so with
500M large objects that would be a billion statements, and thus a
billion xids. And without checking, I'm fairly sure it doesn't load in
a single transaction...
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-08 14:13 Robins Tharakan <[email protected]>
parent: Magnus Hagander <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Robins Tharakan @ 2021-03-08 14:13 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
Hi Magnus,
On Mon, 8 Mar 2021 at 23:34, Magnus Hagander <[email protected]> wrote:
> AFAICT at a quick check, pg_dump in binary upgrade mode emits one
lo_create() and one ALTER ... OWNER TO for each large object - so with
> 500M large objects that would be a billion statements, and thus a
> billion xids. And without checking, I'm fairly sure it doesn't load in
> a single transaction...
>
Your assumptions are pretty much correct.
The issue isn't with pg_upgrade itself. During pg_restore, each Large
Object (and separately each ALTER LARGE OBJECT OWNER TO) consumes an XID
each. For background, that's the reason the v9.5 production instance I was
reviewing, was unable to process more than 73 Million large objects since
each object required a CREATE + ALTER. (To clarify, 73 million = (2^31 - 2
billion magic constant - 1 Million wraparound protection) / 2)
Without looking, I would guess it's the schema reload using
> pg_dump/pg_restore and not actually pg_upgrade itself. This is a known
> issue in pg_dump/pg_restore. And if that is the case -- perhaps just
> running all of those in a single transaction would be a better choice?
> One could argue it's still not a proper fix, because we'd still have a
> huge memory usage etc, but it would then only burn 1 xid instead of
> 500M...
>
(I hope I am not missing something but) When I tried to force pg_restore to
use a single transaction (by hacking pg_upgrade's pg_restore call to use
--single-transaction), it too failed owing to being unable to lock so many
objects in a single transaction.
This still seems to just fix the symptoms and not the actual problem.
>
I agree that the patch doesn't address the root-cause, but it did get the
upgrade to complete on a test-setup. Do you think that (instead of all
objects) batching multiple Large Objects in a single transaction (and
allowing the caller to size that batch via command line) would be a good /
acceptable idea here?
Please take a look at your email configuration -- all your emails are
> lacking both References and In-reply-to headers.
>
Thanks for highlighting the cause here. Hopefully switching mail clients
would help.
-
Robins Tharakan
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-08 16:33 Tom Lane <[email protected]>
parent: Robins Tharakan <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Tom Lane @ 2021-03-08 16:33 UTC (permalink / raw)
To: Robins Tharakan <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
Robins Tharakan <[email protected]> writes:
> On Mon, 8 Mar 2021 at 23:34, Magnus Hagander <[email protected]> wrote:
>> Without looking, I would guess it's the schema reload using
>> pg_dump/pg_restore and not actually pg_upgrade itself. This is a known
>> issue in pg_dump/pg_restore. And if that is the case -- perhaps just
>> running all of those in a single transaction would be a better choice?
>> One could argue it's still not a proper fix, because we'd still have a
>> huge memory usage etc, but it would then only burn 1 xid instead of
>> 500M...
> (I hope I am not missing something but) When I tried to force pg_restore to
> use a single transaction (by hacking pg_upgrade's pg_restore call to use
> --single-transaction), it too failed owing to being unable to lock so many
> objects in a single transaction.
It does seem that --single-transaction is a better idea than fiddling with
the transaction wraparound parameters, since the latter is just going to
put off the onset of trouble. However, we'd have to do something about
the lock consumption. Would it be sane to have the backend not bother to
take any locks in binary-upgrade mode?
regards, tom lane
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-08 16:35 Magnus Hagander <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Magnus Hagander @ 2021-03-08 16:35 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Mon, Mar 8, 2021 at 5:33 PM Tom Lane <[email protected]> wrote:
>
> Robins Tharakan <[email protected]> writes:
> > On Mon, 8 Mar 2021 at 23:34, Magnus Hagander <[email protected]> wrote:
> >> Without looking, I would guess it's the schema reload using
> >> pg_dump/pg_restore and not actually pg_upgrade itself. This is a known
> >> issue in pg_dump/pg_restore. And if that is the case -- perhaps just
> >> running all of those in a single transaction would be a better choice?
> >> One could argue it's still not a proper fix, because we'd still have a
> >> huge memory usage etc, but it would then only burn 1 xid instead of
> >> 500M...
>
> > (I hope I am not missing something but) When I tried to force pg_restore to
> > use a single transaction (by hacking pg_upgrade's pg_restore call to use
> > --single-transaction), it too failed owing to being unable to lock so many
> > objects in a single transaction.
>
> It does seem that --single-transaction is a better idea than fiddling with
> the transaction wraparound parameters, since the latter is just going to
> put off the onset of trouble. However, we'd have to do something about
> the lock consumption. Would it be sane to have the backend not bother to
> take any locks in binary-upgrade mode?
I believe the problem occurs when writing them rather than when
reading them, and I don't think we have a binary upgrade mode there.
We could invent one of course. Another option might be to exclusively
lock pg_largeobject, and just say that if you do that, we don't have
to lock the individual objects (ever)?
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-08 16:58 Tom Lane <[email protected]>
parent: Magnus Hagander <[email protected]>
0 siblings, 2 replies; 49+ messages in thread
From: Tom Lane @ 2021-03-08 16:58 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
Magnus Hagander <[email protected]> writes:
> On Mon, Mar 8, 2021 at 5:33 PM Tom Lane <[email protected]> wrote:
>> It does seem that --single-transaction is a better idea than fiddling with
>> the transaction wraparound parameters, since the latter is just going to
>> put off the onset of trouble. However, we'd have to do something about
>> the lock consumption. Would it be sane to have the backend not bother to
>> take any locks in binary-upgrade mode?
> I believe the problem occurs when writing them rather than when
> reading them, and I don't think we have a binary upgrade mode there.
You're confusing pg_dump's --binary-upgrade switch (indeed applied on
the dumping side) with the backend's -b switch (IsBinaryUpgrade,
applied on the restoring side).
> We could invent one of course. Another option might be to exclusively
> lock pg_largeobject, and just say that if you do that, we don't have
> to lock the individual objects (ever)?
What was in the back of my mind is that we've sometimes seen complaints
about too many locks needed to dump or restore a database with $MANY
tables; so the large-object case seems like just a special case.
The answer up to now has been "raise max_locks_per_transaction enough
so you don't see the failure". Having now consumed a little more
caffeine, I remember that that works in pg_upgrade scenarios too,
since the user can fiddle with the target cluster's postgresql.conf
before starting pg_upgrade.
So it seems like the path of least resistance is
(a) make pg_upgrade use --single-transaction when calling pg_restore
(b) document (better) how to get around too-many-locks failures.
regards, tom lane
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-08 17:18 Magnus Hagander <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 0 replies; 49+ messages in thread
From: Magnus Hagander @ 2021-03-08 17:18 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Mon, Mar 8, 2021 at 5:58 PM Tom Lane <[email protected]> wrote:
>
> Magnus Hagander <[email protected]> writes:
> > On Mon, Mar 8, 2021 at 5:33 PM Tom Lane <[email protected]> wrote:
> >> It does seem that --single-transaction is a better idea than fiddling with
> >> the transaction wraparound parameters, since the latter is just going to
> >> put off the onset of trouble. However, we'd have to do something about
> >> the lock consumption. Would it be sane to have the backend not bother to
> >> take any locks in binary-upgrade mode?
>
> > I believe the problem occurs when writing them rather than when
> > reading them, and I don't think we have a binary upgrade mode there.
>
> You're confusing pg_dump's --binary-upgrade switch (indeed applied on
> the dumping side) with the backend's -b switch (IsBinaryUpgrade,
> applied on the restoring side).
Ah. Yes, I am.
> > We could invent one of course. Another option might be to exclusively
> > lock pg_largeobject, and just say that if you do that, we don't have
> > to lock the individual objects (ever)?
>
> What was in the back of my mind is that we've sometimes seen complaints
> about too many locks needed to dump or restore a database with $MANY
> tables; so the large-object case seems like just a special case.
It is -- but I guess it's more likely to have 100M large objects than
to have 100M tables. (and the cutoff point comes a lot earlier than
100M). But the fundamental onei s the same.
> The answer up to now has been "raise max_locks_per_transaction enough
> so you don't see the failure". Having now consumed a little more
> caffeine, I remember that that works in pg_upgrade scenarios too,
> since the user can fiddle with the target cluster's postgresql.conf
> before starting pg_upgrade.
>
> So it seems like the path of least resistance is
>
> (a) make pg_upgrade use --single-transaction when calling pg_restore
>
> (b) document (better) how to get around too-many-locks failures.
Agreed. Certainly seems like a better path forward than arbitrarily
pushing the limit on number of transactions which just postpones the
problem.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-09 20:08 Justin Pryzby <[email protected]>
parent: Tharakan, Robins <[email protected]>
0 siblings, 0 replies; 49+ messages in thread
From: Justin Pryzby @ 2021-03-09 20:08 UTC (permalink / raw)
To: Tharakan, Robins <[email protected]>; +Cc: pgsql-hackers
On Wed, Mar 03, 2021 at 11:36:26AM +0000, Tharakan, Robins wrote:
> While reviewing a failed upgrade from Postgres v9.5 (to v9.6) I saw that the
> instance had ~200 million (in-use) Large Objects. I was able to reproduce
> this on a test instance which too fails with a similar error.
If pg_upgrade can't handle millions of objects/transactions/XIDs, that seems
like a legitimate complaint, since apparently the system is working okay
otherwise.
But it also seems like you're using it outside the range of its intended use
(See also [1]). I'm guessing that not many people are going to spend time
running tests of pg_upgrade, each of which takes 25hr, not to mention some
multiple of 128GB RAM+swap.
Creating millions of large objects was too slow for me to test like this:
| time { echo 'begin;'; for a in `seq 1 99999`; do echo '\lo_import /dev/null'; done; echo 'commit;'; } |psql -qh /tmp postgres&
This seems to be enough for what's needed:
| ALTER SYSTEM SET fsync=no; ALTER SYSTEM SET full_page_writes=no; SELECT pg_reload_conf();
| INSERT INTO pg_largeobject_metadata SELECT a, 0 FROM generate_series(100000, 200111222)a;
Now, testing the pg_upgrade was killed after runnning 100min and using 60GB
RAM, so you might say that's a problem too. I converted getBlobs() to use a
cursor, like dumpBlobs(), but it was still killed. I think a test case and a
way to exercizes this failure with a more reasonable amount of time and
resources might be a prerequisite for a patch to fix it.
pg_upgrade is meant for "immediate" upgrades, frequently allowing upgrade in
minutes, where pg_dump |pg_restore might take hours or days. There's two
components to consider: the catalog/metadata part, and the data part. If the
data is large (let's say more than 100GB), then pg_upgrade is expected to be an
improvement over the "dump and restore" process, which is usually infeasible
for large DBs measure in TB.
But the *catalog* part is large, and pg_upgrade still has to run pg_dump, and
pg_restore. The time to do this might dominate over the data part. Our own
customers DBs are 100s of GB to 10TB. For large customers, pg_upgrade takes
45min. In the past, we had tables with many column defaults, which caused the
dump+restore to be slow at a larger fraction of customers.
If it were me, in an EOL situation, I would look at either: 1) find a way to do
dump+restore rather than pg_upgrade; and/or, 2) separately pg_dump the large
objects, drop as many as you can, then pg_upgrade the DB, then restore the
large objects. (And find a better way to store them in the future).
I was able to hack pg_upgrade to call pg_restore --single (with a separate
invocation to handle --create). That passes tests...but I can't say much
beyond that.
Regarding your existing patch: "make check" only tests SQL features.
For development, you'll want to configure like:
|./configure --enable-debug --enable-cassert --enable-tap-tests
And then use "make check-world", and in particular:
time make check -C src/bin/pg_resetwal
time make check -C src/bin/pg_upgrade
I don't think pg_restore needs a user-facing option for XIDs. I think it
should "just work", since a user might be as likely to shoot themselves in the
foot with a commandline option as they are to make an upgrade succeed that
would otherwise fail. pg_upgrade has a --check mode, and if that passes, the
upgrade is intended to work, and not fail halfway through between the schema
dump and restore, with the expectation that the user know to rerun with some
commandline flags. If you pursue the patch with setting a different XID
threshold, maybe you could count the number of objects to be created, or
transactions to be used, and use that as the argument to resetxlog ? I'm not
sure, but pg_restore -l might be a good place to start looking.
I think a goal for this patch should be to allow an increased number of
objects to be handled by pg_upgrade. Large objects may be a special case, and
increasing the number of other objects to be restored to the 100s of millions
might be unimportant.
--
Justin
[1] https://www.postgresql.org/message-id/502641.1606334432%40sss.pgh.pa.us
| Does pg_dump really have sane performance for that situation, or
| are we soon going to be fielding requests to make it not be O(N^2)
| in the number of listed tables?
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-20 04:39 Jan Wieck <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 2 replies; 49+ messages in thread
From: Jan Wieck @ 2021-03-20 04:39 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; +Cc: Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/8/21 11:58 AM, Tom Lane wrote:
> The answer up to now has been "raise max_locks_per_transaction enough
> so you don't see the failure". Having now consumed a little more
> caffeine, I remember that that works in pg_upgrade scenarios too,
> since the user can fiddle with the target cluster's postgresql.conf
> before starting pg_upgrade.
>
> So it seems like the path of least resistance is
>
> (a) make pg_upgrade use --single-transaction when calling pg_restore
>
> (b) document (better) how to get around too-many-locks failures.
That would first require to fix how pg_upgrade is creating the
databases. It uses "pg_restore --create", which is mutually exclusive
with --single-transaction because we cannot create a database inside of
a transaction. On the way pg_upgrade also mangles the pg_database.datdba
(all databases are owned by postgres after an upgrade; will submit a
separate patch for that as I consider that a bug by itself).
All that aside, the entire approach doesn't scale.
In a hacked up pg_upgrade that does "createdb" first before calling
pg_upgrade with --single-transaction. I can upgrade 1M large objects with
max_locks_per_transaction = 5300
max_connectinons=100
which contradicts the docs. Need to find out where that math went off
the rails because that config should only have room for 530,000 locks,
not 1M. The same test fails with max_locks_per_transaction = 5200.
But this would mean that one has to modify the postgresql.conf to
something like 530,000 max_locks_per_transaction at 100 max_connections
in order to actually run a successful upgrade of 100M large objects.
This config requires 26GB of memory just for locks. Add to that the
memory pg_restore needs to load the entire TOC before even restoring a
single object.
Not going to work. But tests are still ongoing ...
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-20 15:17 Andrew Dunstan <[email protected]>
parent: Jan Wieck <[email protected]>
1 sibling, 0 replies; 49+ messages in thread
From: Andrew Dunstan @ 2021-03-20 15:17 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; +Cc: Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/20/21 12:39 AM, Jan Wieck wrote:
> On 3/8/21 11:58 AM, Tom Lane wrote:
>> The answer up to now has been "raise max_locks_per_transaction enough
>> so you don't see the failure". Having now consumed a little more
>> caffeine, I remember that that works in pg_upgrade scenarios too,
>> since the user can fiddle with the target cluster's postgresql.conf
>> before starting pg_upgrade.
>>
>> So it seems like the path of least resistance is
>>
>> (a) make pg_upgrade use --single-transaction when calling pg_restore
>>
>> (b) document (better) how to get around too-many-locks failures.
>
> That would first require to fix how pg_upgrade is creating the
> databases. It uses "pg_restore --create", which is mutually exclusive
> with --single-transaction because we cannot create a database inside
> of a transaction. On the way pg_upgrade also mangles the
> pg_database.datdba (all databases are owned by postgres after an
> upgrade; will submit a separate patch for that as I consider that a
> bug by itself).
>
> All that aside, the entire approach doesn't scale.
>
> In a hacked up pg_upgrade that does "createdb" first before calling
> pg_upgrade with --single-transaction. I can upgrade 1M large objects with
> max_locks_per_transaction = 5300
> max_connectinons=100
> which contradicts the docs. Need to find out where that math went off
> the rails because that config should only have room for 530,000 locks,
> not 1M. The same test fails with max_locks_per_transaction = 5200.
>
> But this would mean that one has to modify the postgresql.conf to
> something like 530,000 max_locks_per_transaction at 100
> max_connections in order to actually run a successful upgrade of 100M
> large objects. This config requires 26GB of memory just for locks. Add
> to that the memory pg_restore needs to load the entire TOC before even
> restoring a single object.
>
> Not going to work. But tests are still ongoing ...
I thought Tom's suggestion upthread:
> Would it be sane to have the backend not bother to
> take any locks in binary-upgrade mode?
was interesting. Could we do that on the restore side? After all, what
are we locking against in binary upgrade mode?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-20 15:23 Tom Lane <[email protected]>
parent: Jan Wieck <[email protected]>
1 sibling, 2 replies; 49+ messages in thread
From: Tom Lane @ 2021-03-20 15:23 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
Jan Wieck <[email protected]> writes:
> On 3/8/21 11:58 AM, Tom Lane wrote:
>> So it seems like the path of least resistance is
>> (a) make pg_upgrade use --single-transaction when calling pg_restore
>> (b) document (better) how to get around too-many-locks failures.
> That would first require to fix how pg_upgrade is creating the
> databases. It uses "pg_restore --create", which is mutually exclusive
> with --single-transaction because we cannot create a database inside of
> a transaction.
Ugh.
> All that aside, the entire approach doesn't scale.
Yeah, agreed. When we gave large objects individual ownership and ACL
info, it was argued that pg_dump could afford to treat each one as a
separate TOC entry because "you wouldn't have that many of them, if
they're large". The limits of that approach were obvious even at the
time, and I think now we're starting to see people for whom it really
doesn't work.
I wonder if pg_dump could improve matters cheaply by aggregating the
large objects by owner and ACL contents. That is, do
select distinct lomowner, lomacl from pg_largeobject_metadata;
and make just *one* BLOB TOC entry for each result. Then dump out
all the matching blobs under that heading.
A possible objection is that it'd reduce the ability to restore blobs
selectively, so maybe we'd need to make it optional.
Of course, that just reduces the memory consumption on the client
side; it does nothing for the locks. Can we get away with releasing the
lock immediately after doing an ALTER OWNER or GRANT/REVOKE on a blob?
regards, tom lane
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-20 16:45 Bruce Momjian <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 1 reply; 49+ messages in thread
From: Bruce Momjian @ 2021-03-20 16:45 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Jan Wieck <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Sat, Mar 20, 2021 at 11:23:19AM -0400, Tom Lane wrote:
> I wonder if pg_dump could improve matters cheaply by aggregating the
> large objects by owner and ACL contents. That is, do
>
> select distinct lomowner, lomacl from pg_largeobject_metadata;
>
> and make just *one* BLOB TOC entry for each result. Then dump out
> all the matching blobs under that heading.
>
> A possible objection is that it'd reduce the ability to restore blobs
> selectively, so maybe we'd need to make it optional.
>
> Of course, that just reduces the memory consumption on the client
> side; it does nothing for the locks. Can we get away with releasing the
> lock immediately after doing an ALTER OWNER or GRANT/REVOKE on a blob?
Well, in pg_upgrade mode you can, since there are no other cluster
users, but you might be asking for general pg_dump usage.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-20 16:53 Tom Lane <[email protected]>
parent: Bruce Momjian <[email protected]>
0 siblings, 0 replies; 49+ messages in thread
From: Tom Lane @ 2021-03-20 16:53 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Jan Wieck <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
Bruce Momjian <[email protected]> writes:
> On Sat, Mar 20, 2021 at 11:23:19AM -0400, Tom Lane wrote:
>> Of course, that just reduces the memory consumption on the client
>> side; it does nothing for the locks. Can we get away with releasing the
>> lock immediately after doing an ALTER OWNER or GRANT/REVOKE on a blob?
> Well, in pg_upgrade mode you can, since there are no other cluster
> users, but you might be asking for general pg_dump usage.
Yeah, this problem doesn't only affect pg_upgrade scenarios, so it'd
really be better to find a way that isn't dependent on binary-upgrade
mode.
regards, tom lane
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-20 16:55 Jan Wieck <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 1 reply; 49+ messages in thread
From: Jan Wieck @ 2021-03-20 16:55 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/20/21 11:23 AM, Tom Lane wrote:
> Jan Wieck <[email protected]> writes:
>> All that aside, the entire approach doesn't scale.
>
> Yeah, agreed. When we gave large objects individual ownership and ACL
> info, it was argued that pg_dump could afford to treat each one as a
> separate TOC entry because "you wouldn't have that many of them, if
> they're large". The limits of that approach were obvious even at the
> time, and I think now we're starting to see people for whom it really
> doesn't work.
It actually looks more like some users have millions of "small objects".
I am still wondering where that is coming from and why they are abusing
LOs in that way, but that is more out of curiosity. Fact is that they
are out there and that they cannot upgrade from their 9.5 databases,
which are now past EOL.
>
> I wonder if pg_dump could improve matters cheaply by aggregating the
> large objects by owner and ACL contents. That is, do
>
> select distinct lomowner, lomacl from pg_largeobject_metadata;
>
> and make just *one* BLOB TOC entry for each result. Then dump out
> all the matching blobs under that heading.
What I am currently experimenting with is moving the BLOB TOC entries
into the parallel data phase of pg_restore "when doing binary upgrade".
It seems to scale nicely with the number of cores in the system. In
addition to that have options for pg_upgrade and pg_restore that cause
the restore to batch them into transactions, like 10,000 objects at a
time. There was a separate thread for that but I guess it is better to
keep it all together here now.
>
> A possible objection is that it'd reduce the ability to restore blobs
> selectively, so maybe we'd need to make it optional.
I fully intend to make all this into new "options". I am afraid that
there is no one-size-fits-all solution here.
>
> Of course, that just reduces the memory consumption on the client
> side; it does nothing for the locks. Can we get away with releasing the
> lock immediately after doing an ALTER OWNER or GRANT/REVOKE on a blob?
I'm not very fond of the idea going lockless when at the same time
trying to parallelize the restore phase. That can lead to really nasty
race conditions. For now I'm aiming at batches in transactions.
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-21 11:47 Andrew Dunstan <[email protected]>
parent: Jan Wieck <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Andrew Dunstan @ 2021-03-21 11:47 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; Tom Lane <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/20/21 12:55 PM, Jan Wieck wrote:
> On 3/20/21 11:23 AM, Tom Lane wrote:
>> Jan Wieck <[email protected]> writes:
>>> All that aside, the entire approach doesn't scale.
>>
>> Yeah, agreed. When we gave large objects individual ownership and ACL
>> info, it was argued that pg_dump could afford to treat each one as a
>> separate TOC entry because "you wouldn't have that many of them, if
>> they're large". The limits of that approach were obvious even at the
>> time, and I think now we're starting to see people for whom it really
>> doesn't work.
>
> It actually looks more like some users have millions of "small
> objects". I am still wondering where that is coming from and why they
> are abusing LOs in that way, but that is more out of curiosity. Fact
> is that they are out there and that they cannot upgrade from their 9.5
> databases, which are now past EOL.
>
One possible (probable?) source is the JDBC driver, which currently
treats all Blobs (and Clobs, for that matter) as LOs. I'm working on
improving that some: <https://github.com/pgjdbc/pgjdbc/pull/2093;
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-21 16:56 Jan Wieck <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Jan Wieck @ 2021-03-21 16:56 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/21/21 7:47 AM, Andrew Dunstan wrote:
> One possible (probable?) source is the JDBC driver, which currently
> treats all Blobs (and Clobs, for that matter) as LOs. I'm working on
> improving that some: <https://github.com/pgjdbc/pgjdbc/pull/2093;
You mean the user is using OID columns pointing to large objects and the
JDBC driver is mapping those for streaming operations?
Yeah, that would explain a lot.
Thanks, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-21 18:18 Andrew Dunstan <[email protected]>
parent: Jan Wieck <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Andrew Dunstan @ 2021-03-21 18:18 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; Tom Lane <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/21/21 12:56 PM, Jan Wieck wrote:
> On 3/21/21 7:47 AM, Andrew Dunstan wrote:
>> One possible (probable?) source is the JDBC driver, which currently
>> treats all Blobs (and Clobs, for that matter) as LOs. I'm working on
>> improving that some: <https://github.com/pgjdbc/pgjdbc/pull/2093;
>
> You mean the user is using OID columns pointing to large objects and
> the JDBC driver is mapping those for streaming operations?
>
> Yeah, that would explain a lot.
>
>
>
Probably in most cases the database is designed by Hibernate, and the
front end programmers know nothing at all of Oids or LOs, they just ask
for and get a Blob.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-22 21:36 Zhihong Yu <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Zhihong Yu @ 2021-03-22 21:36 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Jan Wieck <[email protected]>; Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
>
> Hi,
>
w.r.t. pg_upgrade_improvements.v2.diff.
+ blobBatchCount = 0;
+ blobInXact = false;
The count and bool flag are always reset in tandem. It seems
variable blobInXact is not needed.
Cheers
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-22 23:18 Jan Wieck <[email protected]>
parent: Zhihong Yu <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Jan Wieck @ 2021-03-22 23:18 UTC (permalink / raw)
To: Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; +Cc: Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/22/21 5:36 PM, Zhihong Yu wrote:
> Hi,
>
> w.r.t. pg_upgrade_improvements.v2.diff.
>
> + blobBatchCount = 0;
> + blobInXact = false;
>
> The count and bool flag are always reset in tandem. It seems
> variable blobInXact is not needed.
You are right. I will fix that.
Thanks, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 12:51 Jan Wieck <[email protected]>
parent: Jan Wieck <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Jan Wieck @ 2021-03-23 12:51 UTC (permalink / raw)
To: Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; +Cc: Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/22/21 7:18 PM, Jan Wieck wrote:
> On 3/22/21 5:36 PM, Zhihong Yu wrote:
>> Hi,
>>
>> w.r.t. pg_upgrade_improvements.v2.diff.
>>
>> + blobBatchCount = 0;
>> + blobInXact = false;
>>
>> The count and bool flag are always reset in tandem. It seems
>> variable blobInXact is not needed.
>
> You are right. I will fix that.
New patch v3 attached.
Thanks, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
Attachments:
[text/x-patch] pg_upgrade_improvements.v3.diff (22.8K, 2-pg_upgrade_improvements.v3.diff)
download | inline diff:
diff --git a/src/bin/pg_dump/parallel.c b/src/bin/pg_dump/parallel.c
index c7351a4..4a611d0 100644
--- a/src/bin/pg_dump/parallel.c
+++ b/src/bin/pg_dump/parallel.c
@@ -864,6 +864,11 @@ RunWorker(ArchiveHandle *AH, ParallelSlot *slot)
WaitForCommands(AH, pipefd);
/*
+ * Close an eventually open BLOB batch transaction.
+ */
+ CommitBlobTransaction((Archive *)AH);
+
+ /*
* Disconnect from database and clean up.
*/
set_cancel_slot_archive(slot, NULL);
diff --git a/src/bin/pg_dump/pg_backup.h b/src/bin/pg_dump/pg_backup.h
index 0296b9b..cd8a590 100644
--- a/src/bin/pg_dump/pg_backup.h
+++ b/src/bin/pg_dump/pg_backup.h
@@ -203,6 +203,8 @@ typedef struct Archive
int numWorkers; /* number of parallel processes */
char *sync_snapshot_id; /* sync snapshot id for parallel operation */
+ int blobBatchSize; /* # of blobs to restore per transaction */
+
/* info needed for string escaping */
int encoding; /* libpq code for client_encoding */
bool std_strings; /* standard_conforming_strings */
@@ -269,6 +271,7 @@ extern void WriteData(Archive *AH, const void *data, size_t dLen);
extern int StartBlob(Archive *AH, Oid oid);
extern int EndBlob(Archive *AH, Oid oid);
+extern void CommitBlobTransaction(Archive *AH);
extern void CloseArchive(Archive *AH);
extern void SetArchiveOptions(Archive *AH, DumpOptions *dopt, RestoreOptions *ropt);
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index 1f82c64..8331e8a 100644
--- a/src/bin/pg_dump/pg_backup_archiver.c
+++ b/src/bin/pg_dump/pg_backup_archiver.c
@@ -68,6 +68,7 @@ typedef struct _parallelReadyList
bool sorted; /* are valid entries currently sorted? */
} ParallelReadyList;
+static int blobBatchCount = 0;
static ArchiveHandle *_allocAH(const char *FileSpec, const ArchiveFormat fmt,
const int compression, bool dosync, ArchiveMode mode,
@@ -265,6 +266,8 @@ CloseArchive(Archive *AHX)
int res = 0;
ArchiveHandle *AH = (ArchiveHandle *) AHX;
+ CommitBlobTransaction(AHX);
+
AH->ClosePtr(AH);
/* Close the output */
@@ -279,6 +282,23 @@ CloseArchive(Archive *AHX)
/* Public */
void
+CommitBlobTransaction(Archive *AHX)
+{
+ ArchiveHandle *AH = (ArchiveHandle *) AHX;
+
+ if (blobBatchCount > 0)
+ {
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- End BLOB restore batch\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "COMMIT;\n\n");
+
+ blobBatchCount = 0;
+ }
+}
+
+/* Public */
+void
SetArchiveOptions(Archive *AH, DumpOptions *dopt, RestoreOptions *ropt)
{
/* Caller can omit dump options, in which case we synthesize them */
@@ -3531,6 +3551,57 @@ _printTocEntry(ArchiveHandle *AH, TocEntry *te, bool isData)
{
RestoreOptions *ropt = AH->public.ropt;
+ /* We restore BLOBs in batches to reduce XID consumption */
+ if (strcmp(te->desc, "BLOB") == 0 && AH->public.blobBatchSize > 0)
+ {
+ if (blobBatchCount > 0)
+ {
+ /* We are inside a BLOB restore transaction */
+ if (blobBatchCount >= AH->public.blobBatchSize)
+ {
+ /*
+ * We did reach the batch size with the previous BLOB.
+ * Commit and start a new batch.
+ */
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- BLOB batch size reached\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "COMMIT;\n");
+ ahprintf(AH, "BEGIN;\n\n");
+
+ blobBatchCount = 1;
+ }
+ else
+ {
+ /* This one still fits into the current batch */
+ blobBatchCount++;
+ }
+ }
+ else
+ {
+ /* Not inside a transaction, start a new batch */
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- Start BLOB restore batch\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "BEGIN;\n\n");
+
+ blobBatchCount = 1;
+ }
+ }
+ else
+ {
+ /* Not a BLOB. If we have a BLOB batch open, close it. */
+ if (blobBatchCount > 0)
+ {
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- End BLOB restore batch\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "COMMIT;\n\n");
+
+ blobBatchCount = 0;
+ }
+ }
+
/* Select owner, schema, tablespace and default AM as necessary */
_becomeOwner(AH, te);
_selectOutputSchema(AH, te->namespace);
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index f8bec3f..f153f08 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -165,12 +165,20 @@ static void guessConstraintInheritance(TableInfo *tblinfo, int numTables);
static void dumpComment(Archive *fout, const char *type, const char *name,
const char *namespace, const char *owner,
CatalogId catalogId, int subid, DumpId dumpId);
+static bool dumpCommentQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId);
static int findComments(Archive *fout, Oid classoid, Oid objoid,
CommentItem **items);
static int collectComments(Archive *fout, CommentItem **items);
static void dumpSecLabel(Archive *fout, const char *type, const char *name,
const char *namespace, const char *owner,
CatalogId catalogId, int subid, DumpId dumpId);
+static bool dumpSecLabelQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId);
static int findSecLabels(Archive *fout, Oid classoid, Oid objoid,
SecLabelItem **items);
static int collectSecLabels(Archive *fout, SecLabelItem **items);
@@ -227,6 +235,13 @@ static DumpId dumpACL(Archive *fout, DumpId objDumpId, DumpId altDumpId,
const char *nspname, const char *owner,
const char *acls, const char *racls,
const char *initacls, const char *initracls);
+static bool dumpACLQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ DumpId objDumpId, DumpId altDumpId,
+ const char *type, const char *name,
+ const char *subname,
+ const char *nspname, const char *owner,
+ const char *acls, const char *racls,
+ const char *initacls, const char *initracls);
static void getDependencies(Archive *fout);
static void BuildArchiveDependencies(Archive *fout);
@@ -3468,11 +3483,44 @@ dumpBlob(Archive *fout, const BlobInfo *binfo)
{
PQExpBuffer cquery = createPQExpBuffer();
PQExpBuffer dquery = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+ teSection section = SECTION_PRE_DATA;
appendPQExpBuffer(cquery,
"SELECT pg_catalog.lo_create('%s');\n",
binfo->dobj.name);
+ /*
+ * In binary upgrade mode we put all the queries to restore
+ * one large object into a single TOC entry and emit it as
+ * SECTION_DATA so that they can be restored in parallel.
+ */
+ if (fout->dopt->binary_upgrade)
+ {
+ section = SECTION_DATA;
+
+ /* Dump comment if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_COMMENT)
+ dumpCommentQuery(fout, cquery, tag, "LARGE OBJECT",
+ binfo->dobj.name, NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
+
+ /* Dump security label if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
+ dumpSecLabelQuery(fout, cquery, tag, "LARGE OBJECT",
+ binfo->dobj.name,
+ NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
+
+ /* Dump ACL if any */
+ if (binfo->blobacl && (binfo->dobj.dump & DUMP_COMPONENT_ACL))
+ dumpACLQuery(fout, cquery, tag,
+ binfo->dobj.dumpId, InvalidDumpId, "LARGE OBJECT",
+ binfo->dobj.name, NULL,
+ NULL, binfo->rolname, binfo->blobacl, binfo->rblobacl,
+ binfo->initblobacl, binfo->initrblobacl);
+ }
+
appendPQExpBuffer(dquery,
"SELECT pg_catalog.lo_unlink('%s');\n",
binfo->dobj.name);
@@ -3482,28 +3530,31 @@ dumpBlob(Archive *fout, const BlobInfo *binfo)
ARCHIVE_OPTS(.tag = binfo->dobj.name,
.owner = binfo->rolname,
.description = "BLOB",
- .section = SECTION_PRE_DATA,
+ .section = section,
.createStmt = cquery->data,
.dropStmt = dquery->data));
- /* Dump comment if any */
- if (binfo->dobj.dump & DUMP_COMPONENT_COMMENT)
- dumpComment(fout, "LARGE OBJECT", binfo->dobj.name,
- NULL, binfo->rolname,
- binfo->dobj.catId, 0, binfo->dobj.dumpId);
-
- /* Dump security label if any */
- if (binfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
- dumpSecLabel(fout, "LARGE OBJECT", binfo->dobj.name,
- NULL, binfo->rolname,
- binfo->dobj.catId, 0, binfo->dobj.dumpId);
-
- /* Dump ACL if any */
- if (binfo->blobacl && (binfo->dobj.dump & DUMP_COMPONENT_ACL))
- dumpACL(fout, binfo->dobj.dumpId, InvalidDumpId, "LARGE OBJECT",
- binfo->dobj.name, NULL,
- NULL, binfo->rolname, binfo->blobacl, binfo->rblobacl,
- binfo->initblobacl, binfo->initrblobacl);
+ if (!fout->dopt->binary_upgrade)
+ {
+ /* Dump comment if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_COMMENT)
+ dumpComment(fout, "LARGE OBJECT", binfo->dobj.name,
+ NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
+
+ /* Dump security label if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
+ dumpSecLabel(fout, "LARGE OBJECT", binfo->dobj.name,
+ NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
+
+ /* Dump ACL if any */
+ if (binfo->blobacl && (binfo->dobj.dump & DUMP_COMPONENT_ACL))
+ dumpACL(fout, binfo->dobj.dumpId, InvalidDumpId, "LARGE OBJECT",
+ binfo->dobj.name, NULL,
+ NULL, binfo->rolname, binfo->blobacl, binfo->rblobacl,
+ binfo->initblobacl, binfo->initrblobacl);
+ }
destroyPQExpBuffer(cquery);
destroyPQExpBuffer(dquery);
@@ -9868,25 +9919,56 @@ dumpComment(Archive *fout, const char *type, const char *name,
const char *namespace, const char *owner,
CatalogId catalogId, int subid, DumpId dumpId)
{
+ PQExpBuffer query = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+
+ if (dumpCommentQuery(fout, query, tag, type, name, namespace, owner,
+ catalogId, subid, dumpId))
+ {
+ /*
+ * We mark comments as SECTION_NONE because they really belong in the
+ * same section as their parent, whether that is pre-data or
+ * post-data.
+ */
+ ArchiveEntry(fout, nilCatalogId, createDumpId(),
+ ARCHIVE_OPTS(.tag = tag->data,
+ .namespace = namespace,
+ .owner = owner,
+ .description = "COMMENT",
+ .section = SECTION_NONE,
+ .createStmt = query->data,
+ .deps = &dumpId,
+ .nDeps = 1));
+ }
+ destroyPQExpBuffer(query);
+ destroyPQExpBuffer(tag);
+}
+
+static bool
+dumpCommentQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId)
+{
DumpOptions *dopt = fout->dopt;
CommentItem *comments;
int ncomments;
/* do nothing, if --no-comments is supplied */
if (dopt->no_comments)
- return;
+ return false;
/* Comments are schema not data ... except blob comments are data */
if (strcmp(type, "LARGE OBJECT") != 0)
{
if (dopt->dataOnly)
- return;
+ return false;
}
else
{
/* We do dump blob comments in binary-upgrade mode */
if (dopt->schemaOnly && !dopt->binary_upgrade)
- return;
+ return false;
}
/* Search for comments associated with catalogId, using table */
@@ -9905,9 +9987,6 @@ dumpComment(Archive *fout, const char *type, const char *name,
/* If a comment exists, build COMMENT ON statement */
if (ncomments > 0)
{
- PQExpBuffer query = createPQExpBuffer();
- PQExpBuffer tag = createPQExpBuffer();
-
appendPQExpBuffer(query, "COMMENT ON %s ", type);
if (namespace && *namespace)
appendPQExpBuffer(query, "%s.", fmtId(namespace));
@@ -9917,24 +9996,10 @@ dumpComment(Archive *fout, const char *type, const char *name,
appendPQExpBuffer(tag, "%s %s", type, name);
- /*
- * We mark comments as SECTION_NONE because they really belong in the
- * same section as their parent, whether that is pre-data or
- * post-data.
- */
- ArchiveEntry(fout, nilCatalogId, createDumpId(),
- ARCHIVE_OPTS(.tag = tag->data,
- .namespace = namespace,
- .owner = owner,
- .description = "COMMENT",
- .section = SECTION_NONE,
- .createStmt = query->data,
- .deps = &dumpId,
- .nDeps = 1));
-
- destroyPQExpBuffer(query);
- destroyPQExpBuffer(tag);
+ return true;
}
+
+ return false;
}
/*
@@ -15070,18 +15135,63 @@ dumpACL(Archive *fout, DumpId objDumpId, DumpId altDumpId,
const char *initacls, const char *initracls)
{
DumpId aclDumpId = InvalidDumpId;
+ PQExpBuffer query = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+
+ if (dumpACLQuery(fout, query, tag, objDumpId, altDumpId,
+ type, name, subname, nspname, owner,
+ acls, racls, initacls, initracls))
+ {
+ DumpId aclDeps[2];
+ int nDeps = 0;
+
+ if (subname)
+ appendPQExpBuffer(tag, "COLUMN %s.%s", name, subname);
+ else
+ appendPQExpBuffer(tag, "%s %s", type, name);
+
+ aclDeps[nDeps++] = objDumpId;
+ if (altDumpId != InvalidDumpId)
+ aclDeps[nDeps++] = altDumpId;
+
+ aclDumpId = createDumpId();
+
+ ArchiveEntry(fout, nilCatalogId, aclDumpId,
+ ARCHIVE_OPTS(.tag = tag->data,
+ .namespace = nspname,
+ .owner = owner,
+ .description = "ACL",
+ .section = SECTION_NONE,
+ .createStmt = query->data,
+ .deps = aclDeps,
+ .nDeps = nDeps));
+
+ }
+
+ destroyPQExpBuffer(query);
+ destroyPQExpBuffer(tag);
+
+ return aclDumpId;
+}
+
+static bool
+dumpACLQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ DumpId objDumpId, DumpId altDumpId,
+ const char *type, const char *name, const char *subname,
+ const char *nspname, const char *owner,
+ const char *acls, const char *racls,
+ const char *initacls, const char *initracls)
+{
DumpOptions *dopt = fout->dopt;
- PQExpBuffer sql;
+ bool haveACL = false;
/* Do nothing if ACL dump is not enabled */
if (dopt->aclsSkip)
- return InvalidDumpId;
+ return false;
/* --data-only skips ACLs *except* BLOB ACLs */
if (dopt->dataOnly && strcmp(type, "LARGE OBJECT") != 0)
- return InvalidDumpId;
-
- sql = createPQExpBuffer();
+ return false;
/*
* Check to see if this object has had any initial ACLs included for it.
@@ -15093,54 +15203,31 @@ dumpACL(Archive *fout, DumpId objDumpId, DumpId altDumpId,
*/
if (strlen(initacls) != 0 || strlen(initracls) != 0)
{
- appendPQExpBufferStr(sql, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(true);\n");
+ haveACL = true;
+ appendPQExpBufferStr(query, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(true);\n");
if (!buildACLCommands(name, subname, nspname, type,
initacls, initracls, owner,
- "", fout->remoteVersion, sql))
+ "", fout->remoteVersion, query))
fatal("could not parse initial GRANT ACL list (%s) or initial REVOKE ACL list (%s) for object \"%s\" (%s)",
initacls, initracls, name, type);
- appendPQExpBufferStr(sql, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(false);\n");
+ appendPQExpBufferStr(query, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(false);\n");
}
if (!buildACLCommands(name, subname, nspname, type,
acls, racls, owner,
- "", fout->remoteVersion, sql))
+ "", fout->remoteVersion, query))
fatal("could not parse GRANT ACL list (%s) or REVOKE ACL list (%s) for object \"%s\" (%s)",
acls, racls, name, type);
- if (sql->len > 0)
+ if (haveACL && tag != NULL)
{
- PQExpBuffer tag = createPQExpBuffer();
- DumpId aclDeps[2];
- int nDeps = 0;
-
if (subname)
appendPQExpBuffer(tag, "COLUMN %s.%s", name, subname);
else
appendPQExpBuffer(tag, "%s %s", type, name);
-
- aclDeps[nDeps++] = objDumpId;
- if (altDumpId != InvalidDumpId)
- aclDeps[nDeps++] = altDumpId;
-
- aclDumpId = createDumpId();
-
- ArchiveEntry(fout, nilCatalogId, aclDumpId,
- ARCHIVE_OPTS(.tag = tag->data,
- .namespace = nspname,
- .owner = owner,
- .description = "ACL",
- .section = SECTION_NONE,
- .createStmt = sql->data,
- .deps = aclDeps,
- .nDeps = nDeps));
-
- destroyPQExpBuffer(tag);
}
- destroyPQExpBuffer(sql);
-
- return aclDumpId;
+ return haveACL;
}
/*
@@ -15166,34 +15253,58 @@ dumpSecLabel(Archive *fout, const char *type, const char *name,
const char *namespace, const char *owner,
CatalogId catalogId, int subid, DumpId dumpId)
{
+ PQExpBuffer query = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+
+ if (dumpSecLabelQuery(fout, query, tag, type, name,
+ namespace, owner, catalogId, subid, dumpId))
+ {
+ ArchiveEntry(fout, nilCatalogId, createDumpId(),
+ ARCHIVE_OPTS(.tag = tag->data,
+ .namespace = namespace,
+ .owner = owner,
+ .description = "SECURITY LABEL",
+ .section = SECTION_NONE,
+ .createStmt = query->data,
+ .deps = &dumpId,
+ .nDeps = 1));
+ }
+
+ destroyPQExpBuffer(query);
+ destroyPQExpBuffer(tag);
+}
+
+static bool
+dumpSecLabelQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId)
+{
DumpOptions *dopt = fout->dopt;
SecLabelItem *labels;
int nlabels;
int i;
- PQExpBuffer query;
/* do nothing, if --no-security-labels is supplied */
if (dopt->no_security_labels)
- return;
+ return false;
/* Security labels are schema not data ... except blob labels are data */
if (strcmp(type, "LARGE OBJECT") != 0)
{
if (dopt->dataOnly)
- return;
+ return false;
}
else
{
/* We do dump blob security labels in binary-upgrade mode */
if (dopt->schemaOnly && !dopt->binary_upgrade)
- return;
+ return false;
}
/* Search for security labels associated with catalogId, using table */
nlabels = findSecLabels(fout, catalogId.tableoid, catalogId.oid, &labels);
- query = createPQExpBuffer();
-
for (i = 0; i < nlabels; i++)
{
/*
@@ -15214,22 +15325,11 @@ dumpSecLabel(Archive *fout, const char *type, const char *name,
if (query->len > 0)
{
- PQExpBuffer tag = createPQExpBuffer();
-
appendPQExpBuffer(tag, "%s %s", type, name);
- ArchiveEntry(fout, nilCatalogId, createDumpId(),
- ARCHIVE_OPTS(.tag = tag->data,
- .namespace = namespace,
- .owner = owner,
- .description = "SECURITY LABEL",
- .section = SECTION_NONE,
- .createStmt = query->data,
- .deps = &dumpId,
- .nDeps = 1));
- destroyPQExpBuffer(tag);
+ return true;
}
- destroyPQExpBuffer(query);
+ return false;
}
/*
diff --git a/src/bin/pg_dump/pg_restore.c b/src/bin/pg_dump/pg_restore.c
index 589b4ae..b16db03 100644
--- a/src/bin/pg_dump/pg_restore.c
+++ b/src/bin/pg_dump/pg_restore.c
@@ -59,6 +59,7 @@ main(int argc, char **argv)
int c;
int exit_code;
int numWorkers = 1;
+ int blobBatchSize = 0;
Archive *AH;
char *inputFileSpec;
static int disable_triggers = 0;
@@ -120,6 +121,7 @@ main(int argc, char **argv)
{"no-publications", no_argument, &no_publications, 1},
{"no-security-labels", no_argument, &no_security_labels, 1},
{"no-subscriptions", no_argument, &no_subscriptions, 1},
+ {"restore-blob-batch-size", required_argument, NULL, 4},
{NULL, 0, NULL, 0}
};
@@ -280,6 +282,10 @@ main(int argc, char **argv)
set_dump_section(optarg, &(opts->dumpSections));
break;
+ case 4: /* # of blobs to restore per transaction */
+ blobBatchSize = atoi(optarg);
+ break;
+
default:
fprintf(stderr, _("Try \"%s --help\" for more information.\n"), progname);
exit_nicely(1);
@@ -434,6 +440,7 @@ main(int argc, char **argv)
SortTocFromFile(AH);
AH->numWorkers = numWorkers;
+ AH->blobBatchSize = blobBatchSize;
if (opts->tocSummary)
PrintTOCSummary(AH);
@@ -506,6 +513,8 @@ usage(const char *progname)
printf(_(" --use-set-session-authorization\n"
" use SET SESSION AUTHORIZATION commands instead of\n"
" ALTER OWNER commands to set ownership\n"));
+ printf(_(" --restore-blob-batch-size=NUM\n"
+ " attempt to restore NUM large objects per transaction\n"));
printf(_("\nConnection options:\n"));
printf(_(" -h, --host=HOSTNAME database server host or socket directory\n"));
diff --git a/src/bin/pg_upgrade/option.c b/src/bin/pg_upgrade/option.c
index 9c9b313..868e9f6 100644
--- a/src/bin/pg_upgrade/option.c
+++ b/src/bin/pg_upgrade/option.c
@@ -57,6 +57,8 @@ parseCommandLine(int argc, char *argv[])
{"verbose", no_argument, NULL, 'v'},
{"clone", no_argument, NULL, 1},
{"index-collation-versions-unknown", no_argument, NULL, 2},
+ {"restore-jobs", required_argument, NULL, 3},
+ {"restore-blob-batch-size", required_argument, NULL, 4},
{NULL, 0, NULL, 0}
};
@@ -208,6 +210,14 @@ parseCommandLine(int argc, char *argv[])
user_opts.ind_coll_unknown = true;
break;
+ case 3:
+ user_opts.restore_jobs = atoi(optarg);
+ break;
+
+ case 4:
+ user_opts.blob_batch_size = atoi(optarg);
+ break;
+
default:
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
os_info.progname);
@@ -314,6 +324,8 @@ usage(void)
printf(_(" --clone clone instead of copying files to new cluster\n"));
printf(_(" --index-collation-versions-unknown\n"));
printf(_(" mark text indexes as needing to be rebuilt\n"));
+ printf(_(" --restore-blob-batch-size=NUM attempt to restore NUM large objects per\n"));
+ printf(_(" transaction\n"));
printf(_(" -?, --help show this help, then exit\n"));
printf(_("\n"
"Before running pg_upgrade you must:\n"
diff --git a/src/bin/pg_upgrade/pg_upgrade.c b/src/bin/pg_upgrade/pg_upgrade.c
index e23b8ca..095e980 100644
--- a/src/bin/pg_upgrade/pg_upgrade.c
+++ b/src/bin/pg_upgrade/pg_upgrade.c
@@ -385,10 +385,13 @@ create_new_objects(void)
parallel_exec_prog(log_file_name,
NULL,
"\"%s/pg_restore\" %s %s --exit-on-error --verbose "
+ "--jobs %d --restore-blob-batch-size %d "
"--dbname template1 \"%s\"",
new_cluster.bindir,
cluster_conn_opts(&new_cluster),
create_opts,
+ user_opts.restore_jobs,
+ user_opts.blob_batch_size,
sql_file_name);
}
diff --git a/src/bin/pg_upgrade/pg_upgrade.h b/src/bin/pg_upgrade/pg_upgrade.h
index 919a784..5647f96 100644
--- a/src/bin/pg_upgrade/pg_upgrade.h
+++ b/src/bin/pg_upgrade/pg_upgrade.h
@@ -291,6 +291,8 @@ typedef struct
* changes */
transferMode transfer_mode; /* copy files or link them? */
int jobs; /* number of processes/threads to use */
+ int restore_jobs; /* number of pg_restore --jobs to use */
+ int blob_batch_size; /* number of blobs to restore per xact */
char *socketdir; /* directory to use for Unix sockets */
bool ind_coll_unknown; /* mark unknown index collation versions */
} UserOpts;
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 14:56 Bruce Momjian <[email protected]>
parent: Jan Wieck <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Bruce Momjian @ 2021-03-23 14:56 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Tue, Mar 23, 2021 at 08:51:32AM -0400, Jan Wieck wrote:
> On 3/22/21 7:18 PM, Jan Wieck wrote:
> > On 3/22/21 5:36 PM, Zhihong Yu wrote:
> > > Hi,
> > >
> > > w.r.t. pg_upgrade_improvements.v2.diff.
> > >
> > > + blobBatchCount = 0;
> > > + blobInXact = false;
> > >
> > > The count and bool flag are always reset in tandem. It seems
> > > variable blobInXact is not needed.
> >
> > You are right. I will fix that.
>
> New patch v3 attached.
Would it be better to allow pg_upgrade to pass arbitrary arguments to
pg_restore, instead of just these specific ones?
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 17:25 Jan Wieck <[email protected]>
parent: Bruce Momjian <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Jan Wieck @ 2021-03-23 17:25 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/23/21 10:56 AM, Bruce Momjian wrote:
> On Tue, Mar 23, 2021 at 08:51:32AM -0400, Jan Wieck wrote:
>> On 3/22/21 7:18 PM, Jan Wieck wrote:
>> > On 3/22/21 5:36 PM, Zhihong Yu wrote:
>> > > Hi,
>> > >
>> > > w.r.t. pg_upgrade_improvements.v2.diff.
>> > >
>> > > + blobBatchCount = 0;
>> > > + blobInXact = false;
>> > >
>> > > The count and bool flag are always reset in tandem. It seems
>> > > variable blobInXact is not needed.
>> >
>> > You are right. I will fix that.
>>
>> New patch v3 attached.
>
> Would it be better to allow pg_upgrade to pass arbitrary arguments to
> pg_restore, instead of just these specific ones?
>
That would mean arbitrary parameters to pg_dump as well as pg_restore.
But yes, that would probably be better in the long run.
Any suggestion as to how that would actually look like? Unfortunately
pg_restore has -[dDoOr] already used, so it doesn't look like there will
be any naturally intelligible short options for that.
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 18:06 Bruce Momjian <[email protected]>
parent: Jan Wieck <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Bruce Momjian @ 2021-03-23 18:06 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Tue, Mar 23, 2021 at 01:25:15PM -0400, Jan Wieck wrote:
> On 3/23/21 10:56 AM, Bruce Momjian wrote:
> > Would it be better to allow pg_upgrade to pass arbitrary arguments to
> > pg_restore, instead of just these specific ones?
> >
>
> That would mean arbitrary parameters to pg_dump as well as pg_restore. But
> yes, that would probably be better in the long run.
>
> Any suggestion as to how that would actually look like? Unfortunately
> pg_restore has -[dDoOr] already used, so it doesn't look like there will be
> any naturally intelligible short options for that.
We have the postmaster which can pass arbitrary arguments to postgres
processes using -o.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 18:23 Jan Wieck <[email protected]>
parent: Bruce Momjian <[email protected]>
0 siblings, 2 replies; 49+ messages in thread
From: Jan Wieck @ 2021-03-23 18:23 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/23/21 2:06 PM, Bruce Momjian wrote:
> We have the postmaster which can pass arbitrary arguments to postgres
> processes using -o.
Right, and -o is already taken in pg_upgrade for sending options to the
old postmaster.
What we are looking for are options for sending options to pg_dump and
pg_restore, which are not postmasters or children of postmaster, but
rather clients. There is no option to send options to clients of
postmasters.
So the question remains, how do we name this?
--pg-dump-options "<string>"
--pg-restore-options "<string>"
where "<string>" could be something like "--whatever[=NUM] [...]" would
be something unambiguous.
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 18:25 Bruce Momjian <[email protected]>
parent: Jan Wieck <[email protected]>
1 sibling, 0 replies; 49+ messages in thread
From: Bruce Momjian @ 2021-03-23 18:25 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Tue, Mar 23, 2021 at 02:23:03PM -0400, Jan Wieck wrote:
> On 3/23/21 2:06 PM, Bruce Momjian wrote:
> > We have the postmaster which can pass arbitrary arguments to postgres
> > processes using -o.
>
> Right, and -o is already taken in pg_upgrade for sending options to the old
> postmaster.
>
> What we are looking for are options for sending options to pg_dump and
> pg_restore, which are not postmasters or children of postmaster, but rather
> clients. There is no option to send options to clients of postmasters.
>
> So the question remains, how do we name this?
>
> --pg-dump-options "<string>"
> --pg-restore-options "<string>"
>
> where "<string>" could be something like "--whatever[=NUM] [...]" would be
> something unambiguous.
Sure. I don't think the letter you use is a problem.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 18:35 Tom Lane <[email protected]>
parent: Jan Wieck <[email protected]>
1 sibling, 1 reply; 49+ messages in thread
From: Tom Lane @ 2021-03-23 18:35 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
Jan Wieck <[email protected]> writes:
> So the question remains, how do we name this?
> --pg-dump-options "<string>"
> --pg-restore-options "<string>"
If you're passing multiple options, that is
--pg-dump-options "--foo=x --bar=y"
it seems just horribly fragile. Lose the double quotes and suddenly
--bar is a separate option to pg_upgrade itself, not part of the argument
for the previous option. That's pretty easy to do when passing things
through shell scripts, too. So it'd likely be safer to write
--pg-dump-option=--foo=x --pg-dump-option=--bar=y
which requires pg_upgrade to allow aggregating multiple options,
but you'd probably want it to act that way anyway.
regards, tom lane
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 18:54 Jan Wieck <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Jan Wieck @ 2021-03-23 18:54 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/23/21 2:35 PM, Tom Lane wrote:
> Jan Wieck <[email protected]> writes:
>> So the question remains, how do we name this?
>
>> --pg-dump-options "<string>"
>> --pg-restore-options "<string>"
>
> If you're passing multiple options, that is
>
> --pg-dump-options "--foo=x --bar=y"
>
> it seems just horribly fragile. Lose the double quotes and suddenly
> --bar is a separate option to pg_upgrade itself, not part of the argument
> for the previous option. That's pretty easy to do when passing things
> through shell scripts, too. So it'd likely be safer to write
>
> --pg-dump-option=--foo=x --pg-dump-option=--bar=y
>
> which requires pg_upgrade to allow aggregating multiple options,
> but you'd probably want it to act that way anyway.
... which would be all really easy if pg_upgrade wouldn't be assembling
a shell script string to pass into parallel_exec_prog() by itself.
But I will see what I can do ...
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 18:59 Tom Lane <[email protected]>
parent: Jan Wieck <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Tom Lane @ 2021-03-23 18:59 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
Jan Wieck <[email protected]> writes:
> On 3/23/21 2:35 PM, Tom Lane wrote:
>> If you're passing multiple options, that is
>> --pg-dump-options "--foo=x --bar=y"
>> it seems just horribly fragile. Lose the double quotes and suddenly
>> --bar is a separate option to pg_upgrade itself, not part of the argument
>> for the previous option. That's pretty easy to do when passing things
>> through shell scripts, too.
> ... which would be all really easy if pg_upgrade wouldn't be assembling
> a shell script string to pass into parallel_exec_prog() by itself.
No, what I was worried about is shell script(s) that invoke pg_upgrade
and have to pass down some of these options through multiple levels of
option parsing.
BTW, it doesn't seem like the "pg-" prefix has any value-add here,
so maybe "--dump-option" and "--restore-option" would be suitable
spellings.
regards, tom lane
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 19:22 Jan Wieck <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Jan Wieck @ 2021-03-23 19:22 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/23/21 2:59 PM, Tom Lane wrote:
> Jan Wieck <[email protected]> writes:
>> On 3/23/21 2:35 PM, Tom Lane wrote:
>>> If you're passing multiple options, that is
>>> --pg-dump-options "--foo=x --bar=y"
>>> it seems just horribly fragile. Lose the double quotes and suddenly
>>> --bar is a separate option to pg_upgrade itself, not part of the argument
>>> for the previous option. That's pretty easy to do when passing things
>>> through shell scripts, too.
>
>> ... which would be all really easy if pg_upgrade wouldn't be assembling
>> a shell script string to pass into parallel_exec_prog() by itself.
>
> No, what I was worried about is shell script(s) that invoke pg_upgrade
> and have to pass down some of these options through multiple levels of
> option parsing.
The problem here is that pg_upgrade itself is invoking a shell again. It
is not assembling an array of arguments to pass into exec*(). I'd be a
happy camper if it did the latter. But as things are we'd have to add
full shell escapeing for arbitrary strings.
>
> BTW, it doesn't seem like the "pg-" prefix has any value-add here,
> so maybe "--dump-option" and "--restore-option" would be suitable
> spellings.
Agreed.
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 19:35 Tom Lane <[email protected]>
parent: Jan Wieck <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Tom Lane @ 2021-03-23 19:35 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
Jan Wieck <[email protected]> writes:
> The problem here is that pg_upgrade itself is invoking a shell again. It
> is not assembling an array of arguments to pass into exec*(). I'd be a
> happy camper if it did the latter. But as things are we'd have to add
> full shell escapeing for arbitrary strings.
Surely we need that (and have it already) anyway?
I think we've stayed away from exec* because we'd have to write an
emulation for Windows. Maybe somebody will get fed up and produce
such code, but it's not likely to be the least-effort route to the
goal.
regards, tom lane
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 19:59 Jan Wieck <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Jan Wieck @ 2021-03-23 19:59 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/23/21 3:35 PM, Tom Lane wrote:
> Jan Wieck <[email protected]> writes:
>> The problem here is that pg_upgrade itself is invoking a shell again. It
>> is not assembling an array of arguments to pass into exec*(). I'd be a
>> happy camper if it did the latter. But as things are we'd have to add
>> full shell escapeing for arbitrary strings.
>
> Surely we need that (and have it already) anyway?
There are functions to shell escape a single string, like
appendShellString()
but that is hardly enough when a single optarg for --restore-option
could look like any of
--jobs 8
--jobs=8
--jobs='8'
--jobs '8'
--jobs "8"
--jobs="8"
--dont-bother-about-jobs
When placed into a shell string, those things have very different
effects on your args[].
I also want to say that we are overengineering this whole thing. Yes,
there is the problem of shell quoting possibly going wrong as it passes
from one shell to another. But for now this is all about passing a few
numbers down from pg_upgrade to pg_restore (and eventually pg_dump).
Have we even reached a consensus yet on that doing it the way, my patch
is proposing, is the right way to go? Like that emitting BLOB TOC
entries into SECTION_DATA when in binary upgrade mode is a good thing?
Or that bunching all the SQL statements for creating the blob, changing
the ACL and COMMENT and SECLABEL all in one multi-statement-query is.
Maybe we should focus on those details before getting into all the
parameter naming stuff.
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-23 20:55 Tom Lane <[email protected]>
parent: Jan Wieck <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Tom Lane @ 2021-03-23 20:55 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
Jan Wieck <[email protected]> writes:
> Have we even reached a consensus yet on that doing it the way, my patch
> is proposing, is the right way to go? Like that emitting BLOB TOC
> entries into SECTION_DATA when in binary upgrade mode is a good thing?
> Or that bunching all the SQL statements for creating the blob, changing
> the ACL and COMMENT and SECLABEL all in one multi-statement-query is.
Now you're asking for actual review effort, which is a little hard
to come by towards the tail end of the last CF of a cycle. I'm
interested in this topic, but I can't justify spending much time
on it right now.
regards, tom lane
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-24 16:04 Jan Wieck <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Jan Wieck @ 2021-03-24 16:04 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/23/21 4:55 PM, Tom Lane wrote:
> Jan Wieck <[email protected]> writes:
>> Have we even reached a consensus yet on that doing it the way, my patch
>> is proposing, is the right way to go? Like that emitting BLOB TOC
>> entries into SECTION_DATA when in binary upgrade mode is a good thing?
>> Or that bunching all the SQL statements for creating the blob, changing
>> the ACL and COMMENT and SECLABEL all in one multi-statement-query is.
>
> Now you're asking for actual review effort, which is a little hard
> to come by towards the tail end of the last CF of a cycle. I'm
> interested in this topic, but I can't justify spending much time
> on it right now.
Understood.
In any case I changed the options so that they behave the same way, the
existing -o and -O (for old/new postmaster options) work. I don't think
it would be wise to have option forwarding work differently between
options for postmaster and options for pg_dump/pg_restore.
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-03-24 16:05 Jan Wieck <[email protected]>
parent: Jan Wieck <[email protected]>
0 siblings, 2 replies; 49+ messages in thread
From: Jan Wieck @ 2021-03-24 16:05 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 3/24/21 12:04 PM, Jan Wieck wrote:
> In any case I changed the options so that they behave the same way, the
> existing -o and -O (for old/new postmaster options) work. I don't think
> it would be wise to have option forwarding work differently between
> options for postmaster and options for pg_dump/pg_restore.
Attaching the actual diff might help.
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
Attachments:
[text/x-patch] pg_upgrade_improvements.v4.diff (24.3K, 2-pg_upgrade_improvements.v4.diff)
download | inline diff:
diff --git a/src/bin/pg_dump/parallel.c b/src/bin/pg_dump/parallel.c
index c7351a4..4a611d0 100644
--- a/src/bin/pg_dump/parallel.c
+++ b/src/bin/pg_dump/parallel.c
@@ -864,6 +864,11 @@ RunWorker(ArchiveHandle *AH, ParallelSlot *slot)
WaitForCommands(AH, pipefd);
/*
+ * Close an eventually open BLOB batch transaction.
+ */
+ CommitBlobTransaction((Archive *)AH);
+
+ /*
* Disconnect from database and clean up.
*/
set_cancel_slot_archive(slot, NULL);
diff --git a/src/bin/pg_dump/pg_backup.h b/src/bin/pg_dump/pg_backup.h
index 0296b9b..cd8a590 100644
--- a/src/bin/pg_dump/pg_backup.h
+++ b/src/bin/pg_dump/pg_backup.h
@@ -203,6 +203,8 @@ typedef struct Archive
int numWorkers; /* number of parallel processes */
char *sync_snapshot_id; /* sync snapshot id for parallel operation */
+ int blobBatchSize; /* # of blobs to restore per transaction */
+
/* info needed for string escaping */
int encoding; /* libpq code for client_encoding */
bool std_strings; /* standard_conforming_strings */
@@ -269,6 +271,7 @@ extern void WriteData(Archive *AH, const void *data, size_t dLen);
extern int StartBlob(Archive *AH, Oid oid);
extern int EndBlob(Archive *AH, Oid oid);
+extern void CommitBlobTransaction(Archive *AH);
extern void CloseArchive(Archive *AH);
extern void SetArchiveOptions(Archive *AH, DumpOptions *dopt, RestoreOptions *ropt);
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index 1f82c64..8331e8a 100644
--- a/src/bin/pg_dump/pg_backup_archiver.c
+++ b/src/bin/pg_dump/pg_backup_archiver.c
@@ -68,6 +68,7 @@ typedef struct _parallelReadyList
bool sorted; /* are valid entries currently sorted? */
} ParallelReadyList;
+static int blobBatchCount = 0;
static ArchiveHandle *_allocAH(const char *FileSpec, const ArchiveFormat fmt,
const int compression, bool dosync, ArchiveMode mode,
@@ -265,6 +266,8 @@ CloseArchive(Archive *AHX)
int res = 0;
ArchiveHandle *AH = (ArchiveHandle *) AHX;
+ CommitBlobTransaction(AHX);
+
AH->ClosePtr(AH);
/* Close the output */
@@ -279,6 +282,23 @@ CloseArchive(Archive *AHX)
/* Public */
void
+CommitBlobTransaction(Archive *AHX)
+{
+ ArchiveHandle *AH = (ArchiveHandle *) AHX;
+
+ if (blobBatchCount > 0)
+ {
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- End BLOB restore batch\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "COMMIT;\n\n");
+
+ blobBatchCount = 0;
+ }
+}
+
+/* Public */
+void
SetArchiveOptions(Archive *AH, DumpOptions *dopt, RestoreOptions *ropt)
{
/* Caller can omit dump options, in which case we synthesize them */
@@ -3531,6 +3551,57 @@ _printTocEntry(ArchiveHandle *AH, TocEntry *te, bool isData)
{
RestoreOptions *ropt = AH->public.ropt;
+ /* We restore BLOBs in batches to reduce XID consumption */
+ if (strcmp(te->desc, "BLOB") == 0 && AH->public.blobBatchSize > 0)
+ {
+ if (blobBatchCount > 0)
+ {
+ /* We are inside a BLOB restore transaction */
+ if (blobBatchCount >= AH->public.blobBatchSize)
+ {
+ /*
+ * We did reach the batch size with the previous BLOB.
+ * Commit and start a new batch.
+ */
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- BLOB batch size reached\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "COMMIT;\n");
+ ahprintf(AH, "BEGIN;\n\n");
+
+ blobBatchCount = 1;
+ }
+ else
+ {
+ /* This one still fits into the current batch */
+ blobBatchCount++;
+ }
+ }
+ else
+ {
+ /* Not inside a transaction, start a new batch */
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- Start BLOB restore batch\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "BEGIN;\n\n");
+
+ blobBatchCount = 1;
+ }
+ }
+ else
+ {
+ /* Not a BLOB. If we have a BLOB batch open, close it. */
+ if (blobBatchCount > 0)
+ {
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- End BLOB restore batch\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "COMMIT;\n\n");
+
+ blobBatchCount = 0;
+ }
+ }
+
/* Select owner, schema, tablespace and default AM as necessary */
_becomeOwner(AH, te);
_selectOutputSchema(AH, te->namespace);
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index f8bec3f..f153f08 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -165,12 +165,20 @@ static void guessConstraintInheritance(TableInfo *tblinfo, int numTables);
static void dumpComment(Archive *fout, const char *type, const char *name,
const char *namespace, const char *owner,
CatalogId catalogId, int subid, DumpId dumpId);
+static bool dumpCommentQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId);
static int findComments(Archive *fout, Oid classoid, Oid objoid,
CommentItem **items);
static int collectComments(Archive *fout, CommentItem **items);
static void dumpSecLabel(Archive *fout, const char *type, const char *name,
const char *namespace, const char *owner,
CatalogId catalogId, int subid, DumpId dumpId);
+static bool dumpSecLabelQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId);
static int findSecLabels(Archive *fout, Oid classoid, Oid objoid,
SecLabelItem **items);
static int collectSecLabels(Archive *fout, SecLabelItem **items);
@@ -227,6 +235,13 @@ static DumpId dumpACL(Archive *fout, DumpId objDumpId, DumpId altDumpId,
const char *nspname, const char *owner,
const char *acls, const char *racls,
const char *initacls, const char *initracls);
+static bool dumpACLQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ DumpId objDumpId, DumpId altDumpId,
+ const char *type, const char *name,
+ const char *subname,
+ const char *nspname, const char *owner,
+ const char *acls, const char *racls,
+ const char *initacls, const char *initracls);
static void getDependencies(Archive *fout);
static void BuildArchiveDependencies(Archive *fout);
@@ -3468,11 +3483,44 @@ dumpBlob(Archive *fout, const BlobInfo *binfo)
{
PQExpBuffer cquery = createPQExpBuffer();
PQExpBuffer dquery = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+ teSection section = SECTION_PRE_DATA;
appendPQExpBuffer(cquery,
"SELECT pg_catalog.lo_create('%s');\n",
binfo->dobj.name);
+ /*
+ * In binary upgrade mode we put all the queries to restore
+ * one large object into a single TOC entry and emit it as
+ * SECTION_DATA so that they can be restored in parallel.
+ */
+ if (fout->dopt->binary_upgrade)
+ {
+ section = SECTION_DATA;
+
+ /* Dump comment if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_COMMENT)
+ dumpCommentQuery(fout, cquery, tag, "LARGE OBJECT",
+ binfo->dobj.name, NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
+
+ /* Dump security label if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
+ dumpSecLabelQuery(fout, cquery, tag, "LARGE OBJECT",
+ binfo->dobj.name,
+ NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
+
+ /* Dump ACL if any */
+ if (binfo->blobacl && (binfo->dobj.dump & DUMP_COMPONENT_ACL))
+ dumpACLQuery(fout, cquery, tag,
+ binfo->dobj.dumpId, InvalidDumpId, "LARGE OBJECT",
+ binfo->dobj.name, NULL,
+ NULL, binfo->rolname, binfo->blobacl, binfo->rblobacl,
+ binfo->initblobacl, binfo->initrblobacl);
+ }
+
appendPQExpBuffer(dquery,
"SELECT pg_catalog.lo_unlink('%s');\n",
binfo->dobj.name);
@@ -3482,28 +3530,31 @@ dumpBlob(Archive *fout, const BlobInfo *binfo)
ARCHIVE_OPTS(.tag = binfo->dobj.name,
.owner = binfo->rolname,
.description = "BLOB",
- .section = SECTION_PRE_DATA,
+ .section = section,
.createStmt = cquery->data,
.dropStmt = dquery->data));
- /* Dump comment if any */
- if (binfo->dobj.dump & DUMP_COMPONENT_COMMENT)
- dumpComment(fout, "LARGE OBJECT", binfo->dobj.name,
- NULL, binfo->rolname,
- binfo->dobj.catId, 0, binfo->dobj.dumpId);
-
- /* Dump security label if any */
- if (binfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
- dumpSecLabel(fout, "LARGE OBJECT", binfo->dobj.name,
- NULL, binfo->rolname,
- binfo->dobj.catId, 0, binfo->dobj.dumpId);
-
- /* Dump ACL if any */
- if (binfo->blobacl && (binfo->dobj.dump & DUMP_COMPONENT_ACL))
- dumpACL(fout, binfo->dobj.dumpId, InvalidDumpId, "LARGE OBJECT",
- binfo->dobj.name, NULL,
- NULL, binfo->rolname, binfo->blobacl, binfo->rblobacl,
- binfo->initblobacl, binfo->initrblobacl);
+ if (!fout->dopt->binary_upgrade)
+ {
+ /* Dump comment if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_COMMENT)
+ dumpComment(fout, "LARGE OBJECT", binfo->dobj.name,
+ NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
+
+ /* Dump security label if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
+ dumpSecLabel(fout, "LARGE OBJECT", binfo->dobj.name,
+ NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
+
+ /* Dump ACL if any */
+ if (binfo->blobacl && (binfo->dobj.dump & DUMP_COMPONENT_ACL))
+ dumpACL(fout, binfo->dobj.dumpId, InvalidDumpId, "LARGE OBJECT",
+ binfo->dobj.name, NULL,
+ NULL, binfo->rolname, binfo->blobacl, binfo->rblobacl,
+ binfo->initblobacl, binfo->initrblobacl);
+ }
destroyPQExpBuffer(cquery);
destroyPQExpBuffer(dquery);
@@ -9868,25 +9919,56 @@ dumpComment(Archive *fout, const char *type, const char *name,
const char *namespace, const char *owner,
CatalogId catalogId, int subid, DumpId dumpId)
{
+ PQExpBuffer query = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+
+ if (dumpCommentQuery(fout, query, tag, type, name, namespace, owner,
+ catalogId, subid, dumpId))
+ {
+ /*
+ * We mark comments as SECTION_NONE because they really belong in the
+ * same section as their parent, whether that is pre-data or
+ * post-data.
+ */
+ ArchiveEntry(fout, nilCatalogId, createDumpId(),
+ ARCHIVE_OPTS(.tag = tag->data,
+ .namespace = namespace,
+ .owner = owner,
+ .description = "COMMENT",
+ .section = SECTION_NONE,
+ .createStmt = query->data,
+ .deps = &dumpId,
+ .nDeps = 1));
+ }
+ destroyPQExpBuffer(query);
+ destroyPQExpBuffer(tag);
+}
+
+static bool
+dumpCommentQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId)
+{
DumpOptions *dopt = fout->dopt;
CommentItem *comments;
int ncomments;
/* do nothing, if --no-comments is supplied */
if (dopt->no_comments)
- return;
+ return false;
/* Comments are schema not data ... except blob comments are data */
if (strcmp(type, "LARGE OBJECT") != 0)
{
if (dopt->dataOnly)
- return;
+ return false;
}
else
{
/* We do dump blob comments in binary-upgrade mode */
if (dopt->schemaOnly && !dopt->binary_upgrade)
- return;
+ return false;
}
/* Search for comments associated with catalogId, using table */
@@ -9905,9 +9987,6 @@ dumpComment(Archive *fout, const char *type, const char *name,
/* If a comment exists, build COMMENT ON statement */
if (ncomments > 0)
{
- PQExpBuffer query = createPQExpBuffer();
- PQExpBuffer tag = createPQExpBuffer();
-
appendPQExpBuffer(query, "COMMENT ON %s ", type);
if (namespace && *namespace)
appendPQExpBuffer(query, "%s.", fmtId(namespace));
@@ -9917,24 +9996,10 @@ dumpComment(Archive *fout, const char *type, const char *name,
appendPQExpBuffer(tag, "%s %s", type, name);
- /*
- * We mark comments as SECTION_NONE because they really belong in the
- * same section as their parent, whether that is pre-data or
- * post-data.
- */
- ArchiveEntry(fout, nilCatalogId, createDumpId(),
- ARCHIVE_OPTS(.tag = tag->data,
- .namespace = namespace,
- .owner = owner,
- .description = "COMMENT",
- .section = SECTION_NONE,
- .createStmt = query->data,
- .deps = &dumpId,
- .nDeps = 1));
-
- destroyPQExpBuffer(query);
- destroyPQExpBuffer(tag);
+ return true;
}
+
+ return false;
}
/*
@@ -15070,18 +15135,63 @@ dumpACL(Archive *fout, DumpId objDumpId, DumpId altDumpId,
const char *initacls, const char *initracls)
{
DumpId aclDumpId = InvalidDumpId;
+ PQExpBuffer query = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+
+ if (dumpACLQuery(fout, query, tag, objDumpId, altDumpId,
+ type, name, subname, nspname, owner,
+ acls, racls, initacls, initracls))
+ {
+ DumpId aclDeps[2];
+ int nDeps = 0;
+
+ if (subname)
+ appendPQExpBuffer(tag, "COLUMN %s.%s", name, subname);
+ else
+ appendPQExpBuffer(tag, "%s %s", type, name);
+
+ aclDeps[nDeps++] = objDumpId;
+ if (altDumpId != InvalidDumpId)
+ aclDeps[nDeps++] = altDumpId;
+
+ aclDumpId = createDumpId();
+
+ ArchiveEntry(fout, nilCatalogId, aclDumpId,
+ ARCHIVE_OPTS(.tag = tag->data,
+ .namespace = nspname,
+ .owner = owner,
+ .description = "ACL",
+ .section = SECTION_NONE,
+ .createStmt = query->data,
+ .deps = aclDeps,
+ .nDeps = nDeps));
+
+ }
+
+ destroyPQExpBuffer(query);
+ destroyPQExpBuffer(tag);
+
+ return aclDumpId;
+}
+
+static bool
+dumpACLQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ DumpId objDumpId, DumpId altDumpId,
+ const char *type, const char *name, const char *subname,
+ const char *nspname, const char *owner,
+ const char *acls, const char *racls,
+ const char *initacls, const char *initracls)
+{
DumpOptions *dopt = fout->dopt;
- PQExpBuffer sql;
+ bool haveACL = false;
/* Do nothing if ACL dump is not enabled */
if (dopt->aclsSkip)
- return InvalidDumpId;
+ return false;
/* --data-only skips ACLs *except* BLOB ACLs */
if (dopt->dataOnly && strcmp(type, "LARGE OBJECT") != 0)
- return InvalidDumpId;
-
- sql = createPQExpBuffer();
+ return false;
/*
* Check to see if this object has had any initial ACLs included for it.
@@ -15093,54 +15203,31 @@ dumpACL(Archive *fout, DumpId objDumpId, DumpId altDumpId,
*/
if (strlen(initacls) != 0 || strlen(initracls) != 0)
{
- appendPQExpBufferStr(sql, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(true);\n");
+ haveACL = true;
+ appendPQExpBufferStr(query, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(true);\n");
if (!buildACLCommands(name, subname, nspname, type,
initacls, initracls, owner,
- "", fout->remoteVersion, sql))
+ "", fout->remoteVersion, query))
fatal("could not parse initial GRANT ACL list (%s) or initial REVOKE ACL list (%s) for object \"%s\" (%s)",
initacls, initracls, name, type);
- appendPQExpBufferStr(sql, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(false);\n");
+ appendPQExpBufferStr(query, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(false);\n");
}
if (!buildACLCommands(name, subname, nspname, type,
acls, racls, owner,
- "", fout->remoteVersion, sql))
+ "", fout->remoteVersion, query))
fatal("could not parse GRANT ACL list (%s) or REVOKE ACL list (%s) for object \"%s\" (%s)",
acls, racls, name, type);
- if (sql->len > 0)
+ if (haveACL && tag != NULL)
{
- PQExpBuffer tag = createPQExpBuffer();
- DumpId aclDeps[2];
- int nDeps = 0;
-
if (subname)
appendPQExpBuffer(tag, "COLUMN %s.%s", name, subname);
else
appendPQExpBuffer(tag, "%s %s", type, name);
-
- aclDeps[nDeps++] = objDumpId;
- if (altDumpId != InvalidDumpId)
- aclDeps[nDeps++] = altDumpId;
-
- aclDumpId = createDumpId();
-
- ArchiveEntry(fout, nilCatalogId, aclDumpId,
- ARCHIVE_OPTS(.tag = tag->data,
- .namespace = nspname,
- .owner = owner,
- .description = "ACL",
- .section = SECTION_NONE,
- .createStmt = sql->data,
- .deps = aclDeps,
- .nDeps = nDeps));
-
- destroyPQExpBuffer(tag);
}
- destroyPQExpBuffer(sql);
-
- return aclDumpId;
+ return haveACL;
}
/*
@@ -15166,34 +15253,58 @@ dumpSecLabel(Archive *fout, const char *type, const char *name,
const char *namespace, const char *owner,
CatalogId catalogId, int subid, DumpId dumpId)
{
+ PQExpBuffer query = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+
+ if (dumpSecLabelQuery(fout, query, tag, type, name,
+ namespace, owner, catalogId, subid, dumpId))
+ {
+ ArchiveEntry(fout, nilCatalogId, createDumpId(),
+ ARCHIVE_OPTS(.tag = tag->data,
+ .namespace = namespace,
+ .owner = owner,
+ .description = "SECURITY LABEL",
+ .section = SECTION_NONE,
+ .createStmt = query->data,
+ .deps = &dumpId,
+ .nDeps = 1));
+ }
+
+ destroyPQExpBuffer(query);
+ destroyPQExpBuffer(tag);
+}
+
+static bool
+dumpSecLabelQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId)
+{
DumpOptions *dopt = fout->dopt;
SecLabelItem *labels;
int nlabels;
int i;
- PQExpBuffer query;
/* do nothing, if --no-security-labels is supplied */
if (dopt->no_security_labels)
- return;
+ return false;
/* Security labels are schema not data ... except blob labels are data */
if (strcmp(type, "LARGE OBJECT") != 0)
{
if (dopt->dataOnly)
- return;
+ return false;
}
else
{
/* We do dump blob security labels in binary-upgrade mode */
if (dopt->schemaOnly && !dopt->binary_upgrade)
- return;
+ return false;
}
/* Search for security labels associated with catalogId, using table */
nlabels = findSecLabels(fout, catalogId.tableoid, catalogId.oid, &labels);
- query = createPQExpBuffer();
-
for (i = 0; i < nlabels; i++)
{
/*
@@ -15214,22 +15325,11 @@ dumpSecLabel(Archive *fout, const char *type, const char *name,
if (query->len > 0)
{
- PQExpBuffer tag = createPQExpBuffer();
-
appendPQExpBuffer(tag, "%s %s", type, name);
- ArchiveEntry(fout, nilCatalogId, createDumpId(),
- ARCHIVE_OPTS(.tag = tag->data,
- .namespace = namespace,
- .owner = owner,
- .description = "SECURITY LABEL",
- .section = SECTION_NONE,
- .createStmt = query->data,
- .deps = &dumpId,
- .nDeps = 1));
- destroyPQExpBuffer(tag);
+ return true;
}
- destroyPQExpBuffer(query);
+ return false;
}
/*
diff --git a/src/bin/pg_dump/pg_restore.c b/src/bin/pg_dump/pg_restore.c
index 589b4ae..b16db03 100644
--- a/src/bin/pg_dump/pg_restore.c
+++ b/src/bin/pg_dump/pg_restore.c
@@ -59,6 +59,7 @@ main(int argc, char **argv)
int c;
int exit_code;
int numWorkers = 1;
+ int blobBatchSize = 0;
Archive *AH;
char *inputFileSpec;
static int disable_triggers = 0;
@@ -120,6 +121,7 @@ main(int argc, char **argv)
{"no-publications", no_argument, &no_publications, 1},
{"no-security-labels", no_argument, &no_security_labels, 1},
{"no-subscriptions", no_argument, &no_subscriptions, 1},
+ {"restore-blob-batch-size", required_argument, NULL, 4},
{NULL, 0, NULL, 0}
};
@@ -280,6 +282,10 @@ main(int argc, char **argv)
set_dump_section(optarg, &(opts->dumpSections));
break;
+ case 4: /* # of blobs to restore per transaction */
+ blobBatchSize = atoi(optarg);
+ break;
+
default:
fprintf(stderr, _("Try \"%s --help\" for more information.\n"), progname);
exit_nicely(1);
@@ -434,6 +440,7 @@ main(int argc, char **argv)
SortTocFromFile(AH);
AH->numWorkers = numWorkers;
+ AH->blobBatchSize = blobBatchSize;
if (opts->tocSummary)
PrintTOCSummary(AH);
@@ -506,6 +513,8 @@ usage(const char *progname)
printf(_(" --use-set-session-authorization\n"
" use SET SESSION AUTHORIZATION commands instead of\n"
" ALTER OWNER commands to set ownership\n"));
+ printf(_(" --restore-blob-batch-size=NUM\n"
+ " attempt to restore NUM large objects per transaction\n"));
printf(_("\nConnection options:\n"));
printf(_(" -h, --host=HOSTNAME database server host or socket directory\n"));
diff --git a/src/bin/pg_upgrade/dump.c b/src/bin/pg_upgrade/dump.c
index 33d9591..183bb6d 100644
--- a/src/bin/pg_upgrade/dump.c
+++ b/src/bin/pg_upgrade/dump.c
@@ -52,8 +52,11 @@ generate_old_dump(void)
parallel_exec_prog(log_file_name, NULL,
"\"%s/pg_dump\" %s --schema-only --quote-all-identifiers "
+ "%s "
"--binary-upgrade --format=custom %s %s --file=\"%s\" %s",
new_cluster.bindir, cluster_conn_opts(&old_cluster),
+ user_opts.pg_dump_opts ?
+ user_opts.pg_dump_opts : "",
log_opts.verbose ? "--verbose" : "",
user_opts.ind_coll_unknown ?
"--index-collation-versions-unknown" : "",
diff --git a/src/bin/pg_upgrade/option.c b/src/bin/pg_upgrade/option.c
index 9c9b313..d0efb9f 100644
--- a/src/bin/pg_upgrade/option.c
+++ b/src/bin/pg_upgrade/option.c
@@ -57,6 +57,8 @@ parseCommandLine(int argc, char *argv[])
{"verbose", no_argument, NULL, 'v'},
{"clone", no_argument, NULL, 1},
{"index-collation-versions-unknown", no_argument, NULL, 2},
+ {"dump-options", required_argument, NULL, 3},
+ {"restore-options", required_argument, NULL, 4},
{NULL, 0, NULL, 0}
};
@@ -208,6 +210,34 @@ parseCommandLine(int argc, char *argv[])
user_opts.ind_coll_unknown = true;
break;
+ case 3:
+ /* append option? */
+ if (!user_opts.pg_dump_opts)
+ user_opts.pg_dump_opts = pg_strdup(optarg);
+ else
+ {
+ char *old_opts = user_opts.pg_dump_opts;
+
+ user_opts.pg_dump_opts = psprintf("%s %s",
+ old_opts, optarg);
+ free(old_opts);
+ }
+ break;
+
+ case 4:
+ /* append option? */
+ if (!user_opts.pg_restore_opts)
+ user_opts.pg_restore_opts = pg_strdup(optarg);
+ else
+ {
+ char *old_opts = user_opts.pg_restore_opts;
+
+ user_opts.pg_restore_opts = psprintf("%s %s",
+ old_opts, optarg);
+ free(old_opts);
+ }
+ break;
+
default:
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
os_info.progname);
@@ -314,6 +344,8 @@ usage(void)
printf(_(" --clone clone instead of copying files to new cluster\n"));
printf(_(" --index-collation-versions-unknown\n"));
printf(_(" mark text indexes as needing to be rebuilt\n"));
+ printf(_(" --dump-options=OPTIONS options to pass to pg_dump\n"));
+ printf(_(" --restore-options=OPTIONS options to pass to pg_restore\n"));
printf(_(" -?, --help show this help, then exit\n"));
printf(_("\n"
"Before running pg_upgrade you must:\n"
diff --git a/src/bin/pg_upgrade/pg_upgrade.c b/src/bin/pg_upgrade/pg_upgrade.c
index e23b8ca..6f6b12d 100644
--- a/src/bin/pg_upgrade/pg_upgrade.c
+++ b/src/bin/pg_upgrade/pg_upgrade.c
@@ -348,10 +348,13 @@ create_new_objects(void)
true,
true,
"\"%s/pg_restore\" %s %s --exit-on-error --verbose "
+ "%s "
"--dbname postgres \"%s\"",
new_cluster.bindir,
cluster_conn_opts(&new_cluster),
create_opts,
+ user_opts.pg_restore_opts ?
+ user_opts.pg_restore_opts : "",
sql_file_name);
break; /* done once we've processed template1 */
@@ -385,10 +388,13 @@ create_new_objects(void)
parallel_exec_prog(log_file_name,
NULL,
"\"%s/pg_restore\" %s %s --exit-on-error --verbose "
+ "%s "
"--dbname template1 \"%s\"",
new_cluster.bindir,
cluster_conn_opts(&new_cluster),
create_opts,
+ user_opts.pg_restore_opts ?
+ user_opts.pg_restore_opts : "",
sql_file_name);
}
diff --git a/src/bin/pg_upgrade/pg_upgrade.h b/src/bin/pg_upgrade/pg_upgrade.h
index 919a784..4b7959e 100644
--- a/src/bin/pg_upgrade/pg_upgrade.h
+++ b/src/bin/pg_upgrade/pg_upgrade.h
@@ -293,6 +293,8 @@ typedef struct
int jobs; /* number of processes/threads to use */
char *socketdir; /* directory to use for Unix sockets */
bool ind_coll_unknown; /* mark unknown index collation versions */
+ char *pg_dump_opts; /* options to pass to pg_dump */
+ char *pg_restore_opts; /* options to pass to pg_dump */
} UserOpts;
typedef struct
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2021-12-11 22:43 Justin Pryzby <[email protected]>
parent: Jan Wieck <[email protected]>
1 sibling, 0 replies; 49+ messages in thread
From: Justin Pryzby @ 2021-12-11 22:43 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Wed, Mar 24, 2021 at 12:05:27PM -0400, Jan Wieck wrote:
> On 3/24/21 12:04 PM, Jan Wieck wrote:
> > In any case I changed the options so that they behave the same way, the
> > existing -o and -O (for old/new postmaster options) work. I don't think
> > it would be wise to have option forwarding work differently between
> > options for postmaster and options for pg_dump/pg_restore.
>
> Attaching the actual diff might help.
I think the original issue with XIDs was fixed by 74cf7d46a.
Are you still planning to progress the patches addressing huge memory use of
pg_restore?
Note this other, old thread on -general, which I believe has variations on the
same patches.
https://www.postgresql.org/message-id/flat/[email protected]
There was discussion about using pg_restore --single. Note that that was used
at some point in the past: see 12ee6ec71 and 861ad67bd.
The immediate problem is that --single conflicts with --create.
I cleaned up a patch I'd written to work around that. It preserves DB settings
and passes pg_upgrade's test. It's probably not portable as written, but if need be
could pass an empty file instead of /dev/null...
diff --git a/src/bin/pg_upgrade/pg_upgrade.c b/src/bin/pg_upgrade/pg_upgrade.c
index 3628bd74a7..9c504aff79 100644
--- a/src/bin/pg_upgrade/pg_upgrade.c
+++ b/src/bin/pg_upgrade/pg_upgrade.c
@@ -364,6 +364,16 @@ create_new_objects(void)
DbInfo *old_db = &old_cluster.dbarr.dbs[dbnum];
const char *create_opts;
+ PQExpBufferData connstr,
+ escaped_connstr;
+
+ initPQExpBuffer(&connstr);
+ initPQExpBuffer(&escaped_connstr);
+ appendPQExpBufferStr(&connstr, "dbname=");
+ appendConnStrVal(&connstr, old_db->db_name);
+ appendShellString(&escaped_connstr, connstr.data);
+ termPQExpBuffer(&connstr);
+
/* Skip template1 in this pass */
if (strcmp(old_db->db_name, "template1") == 0)
continue;
@@ -378,18 +388,31 @@ create_new_objects(void)
* propagate its database-level properties.
*/
if (strcmp(old_db->db_name, "postgres") == 0)
- create_opts = "--clean --create";
+ create_opts = "--clean";
else
- create_opts = "--create";
+ create_opts = "";
+ /* Create the DB but exclude all objects */
parallel_exec_prog(log_file_name,
NULL,
"\"%s/pg_restore\" %s %s --exit-on-error --verbose "
+ "--create -L /dev/null "
"--dbname template1 \"%s\"",
new_cluster.bindir,
cluster_conn_opts(&new_cluster),
create_opts,
sql_file_name);
+
+ parallel_exec_prog(log_file_name,
+ NULL,
+ "\"%s/pg_restore\" %s %s --exit-on-error --verbose --single "
+ "--dbname=%s \"%s\"",
+ new_cluster.bindir,
+ cluster_conn_opts(&new_cluster),
+ create_opts,
+ escaped_connstr.data,
+ sql_file_name);
+
}
/* reap all children */
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2022-08-25 00:32 Nathan Bossart <[email protected]>
parent: Jan Wieck <[email protected]>
1 sibling, 1 reply; 49+ messages in thread
From: Nathan Bossart @ 2022-08-25 00:32 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Wed, Mar 24, 2021 at 12:05:27PM -0400, Jan Wieck wrote:
> On 3/24/21 12:04 PM, Jan Wieck wrote:
>> In any case I changed the options so that they behave the same way, the
>> existing -o and -O (for old/new postmaster options) work. I don't think
>> it would be wise to have option forwarding work differently between
>> options for postmaster and options for pg_dump/pg_restore.
>
> Attaching the actual diff might help.
I'd like to revive this thread, so I've created a commitfest entry [0] and
attached a hastily rebased patch that compiles and passes the tests. I am
aiming to spend some more time on this in the near future.
[0] https://commitfest.postgresql.org/39/3841/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Attachments:
[text/x-diff] pg_upgrade_improvements_v5.diff (24.2K, 2-pg_upgrade_improvements_v5.diff)
download | inline diff:
diff --git a/src/bin/pg_dump/parallel.c b/src/bin/pg_dump/parallel.c
index c8a70d9bc1..faf1953e18 100644
--- a/src/bin/pg_dump/parallel.c
+++ b/src/bin/pg_dump/parallel.c
@@ -858,6 +858,11 @@ RunWorker(ArchiveHandle *AH, ParallelSlot *slot)
*/
WaitForCommands(AH, pipefd);
+ /*
+ * Close an eventually open BLOB batch transaction.
+ */
+ CommitBlobTransaction((Archive *)AH);
+
/*
* Disconnect from database and clean up.
*/
diff --git a/src/bin/pg_dump/pg_backup.h b/src/bin/pg_dump/pg_backup.h
index fcc5f6bd05..f16ecdecc0 100644
--- a/src/bin/pg_dump/pg_backup.h
+++ b/src/bin/pg_dump/pg_backup.h
@@ -220,6 +220,8 @@ typedef struct Archive
int numWorkers; /* number of parallel processes */
char *sync_snapshot_id; /* sync snapshot id for parallel operation */
+ int blobBatchSize; /* # of blobs to restore per transaction */
+
/* info needed for string escaping */
int encoding; /* libpq code for client_encoding */
bool std_strings; /* standard_conforming_strings */
@@ -290,6 +292,7 @@ extern void WriteData(Archive *AH, const void *data, size_t dLen);
extern int StartBlob(Archive *AH, Oid oid);
extern int EndBlob(Archive *AH, Oid oid);
+extern void CommitBlobTransaction(Archive *AH);
extern void CloseArchive(Archive *AH);
extern void SetArchiveOptions(Archive *AH, DumpOptions *dopt, RestoreOptions *ropt);
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index 233198afc0..7cfbed5e75 100644
--- a/src/bin/pg_dump/pg_backup_archiver.c
+++ b/src/bin/pg_dump/pg_backup_archiver.c
@@ -68,6 +68,7 @@ typedef struct _parallelReadyList
bool sorted; /* are valid entries currently sorted? */
} ParallelReadyList;
+static int blobBatchCount = 0;
static ArchiveHandle *_allocAH(const char *FileSpec, const ArchiveFormat fmt,
const int compression, bool dosync, ArchiveMode mode,
@@ -266,6 +267,8 @@ CloseArchive(Archive *AHX)
int res = 0;
ArchiveHandle *AH = (ArchiveHandle *) AHX;
+ CommitBlobTransaction(AHX);
+
AH->ClosePtr(AH);
/* Close the output */
@@ -279,6 +282,23 @@ CloseArchive(Archive *AHX)
pg_fatal("could not close output file: %m");
}
+/* Public */
+void
+CommitBlobTransaction(Archive *AHX)
+{
+ ArchiveHandle *AH = (ArchiveHandle *) AHX;
+
+ if (blobBatchCount > 0)
+ {
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- End BLOB restore batch\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "COMMIT;\n\n");
+
+ blobBatchCount = 0;
+ }
+}
+
/* Public */
void
SetArchiveOptions(Archive *AH, DumpOptions *dopt, RestoreOptions *ropt)
@@ -3489,6 +3509,57 @@ _printTocEntry(ArchiveHandle *AH, TocEntry *te, bool isData)
{
RestoreOptions *ropt = AH->public.ropt;
+ /* We restore BLOBs in batches to reduce XID consumption */
+ if (strcmp(te->desc, "BLOB") == 0 && AH->public.blobBatchSize > 0)
+ {
+ if (blobBatchCount > 0)
+ {
+ /* We are inside a BLOB restore transaction */
+ if (blobBatchCount >= AH->public.blobBatchSize)
+ {
+ /*
+ * We did reach the batch size with the previous BLOB.
+ * Commit and start a new batch.
+ */
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- BLOB batch size reached\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "COMMIT;\n");
+ ahprintf(AH, "BEGIN;\n\n");
+
+ blobBatchCount = 1;
+ }
+ else
+ {
+ /* This one still fits into the current batch */
+ blobBatchCount++;
+ }
+ }
+ else
+ {
+ /* Not inside a transaction, start a new batch */
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- Start BLOB restore batch\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "BEGIN;\n\n");
+
+ blobBatchCount = 1;
+ }
+ }
+ else
+ {
+ /* Not a BLOB. If we have a BLOB batch open, close it. */
+ if (blobBatchCount > 0)
+ {
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "-- End BLOB restore batch\n");
+ ahprintf(AH, "--\n");
+ ahprintf(AH, "COMMIT;\n\n");
+
+ blobBatchCount = 0;
+ }
+ }
+
/* Select owner, schema, tablespace and default AM as necessary */
_becomeOwner(AH, te);
_selectOutputSchema(AH, te->namespace);
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index d25709ad5f..17c0dd7f0c 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -196,11 +196,20 @@ static inline void dumpComment(Archive *fout, const char *type,
const char *name, const char *namespace,
const char *owner, CatalogId catalogId,
int subid, DumpId dumpId);
+static bool dumpCommentQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId,
+ const char *initdb_comment);
static int findComments(Oid classoid, Oid objoid, CommentItem **items);
static void collectComments(Archive *fout);
static void dumpSecLabel(Archive *fout, const char *type, const char *name,
const char *namespace, const char *owner,
CatalogId catalogId, int subid, DumpId dumpId);
+static bool dumpSecLabelQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId);
static int findSecLabels(Oid classoid, Oid objoid, SecLabelItem **items);
static void collectSecLabels(Archive *fout);
static void dumpDumpableObject(Archive *fout, DumpableObject *dobj);
@@ -256,6 +265,12 @@ static DumpId dumpACL(Archive *fout, DumpId objDumpId, DumpId altDumpId,
const char *type, const char *name, const char *subname,
const char *nspname, const char *owner,
const DumpableAcl *dacl);
+static bool dumpACLQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ DumpId objDumpId, DumpId altDumpId,
+ const char *type, const char *name,
+ const char *subname,
+ const char *nspname, const char *owner,
+ const DumpableAcl *dacl);
static void getDependencies(Archive *fout);
static void BuildArchiveDependencies(Archive *fout);
@@ -3477,11 +3492,43 @@ dumpBlob(Archive *fout, const BlobInfo *binfo)
{
PQExpBuffer cquery = createPQExpBuffer();
PQExpBuffer dquery = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+ teSection section = SECTION_PRE_DATA;
appendPQExpBuffer(cquery,
"SELECT pg_catalog.lo_create('%s');\n",
binfo->dobj.name);
+ /*
+ * In binary upgrade mode we put all the queries to restore
+ * one large object into a single TOC entry and emit it as
+ * SECTION_DATA so that they can be restored in parallel.
+ */
+ if (fout->dopt->binary_upgrade)
+ {
+ section = SECTION_DATA;
+
+ /* Dump comment if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_COMMENT)
+ dumpCommentQuery(fout, cquery, tag, "LARGE OBJECT",
+ binfo->dobj.name, NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId, NULL);
+
+ /* Dump security label if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
+ dumpSecLabelQuery(fout, cquery, tag, "LARGE OBJECT",
+ binfo->dobj.name,
+ NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
+
+ /* Dump ACL if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_ACL)
+ dumpACLQuery(fout, cquery, tag,
+ binfo->dobj.dumpId, InvalidDumpId, "LARGE OBJECT",
+ binfo->dobj.name, NULL,
+ NULL, binfo->rolname, &binfo->dacl);
+ }
+
appendPQExpBuffer(dquery,
"SELECT pg_catalog.lo_unlink('%s');\n",
binfo->dobj.name);
@@ -3491,27 +3538,30 @@ dumpBlob(Archive *fout, const BlobInfo *binfo)
ARCHIVE_OPTS(.tag = binfo->dobj.name,
.owner = binfo->rolname,
.description = "BLOB",
- .section = SECTION_PRE_DATA,
+ .section = section,
.createStmt = cquery->data,
.dropStmt = dquery->data));
- /* Dump comment if any */
- if (binfo->dobj.dump & DUMP_COMPONENT_COMMENT)
- dumpComment(fout, "LARGE OBJECT", binfo->dobj.name,
- NULL, binfo->rolname,
- binfo->dobj.catId, 0, binfo->dobj.dumpId);
+ if (!fout->dopt->binary_upgrade)
+ {
+ /* Dump comment if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_COMMENT)
+ dumpComment(fout, "LARGE OBJECT", binfo->dobj.name,
+ NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
- /* Dump security label if any */
- if (binfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
- dumpSecLabel(fout, "LARGE OBJECT", binfo->dobj.name,
- NULL, binfo->rolname,
- binfo->dobj.catId, 0, binfo->dobj.dumpId);
+ /* Dump security label if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
+ dumpSecLabel(fout, "LARGE OBJECT", binfo->dobj.name,
+ NULL, binfo->rolname,
+ binfo->dobj.catId, 0, binfo->dobj.dumpId);
- /* Dump ACL if any */
- if (binfo->dobj.dump & DUMP_COMPONENT_ACL)
- dumpACL(fout, binfo->dobj.dumpId, InvalidDumpId, "LARGE OBJECT",
- binfo->dobj.name, NULL,
- NULL, binfo->rolname, &binfo->dacl);
+ /* Dump ACL if any */
+ if (binfo->dobj.dump & DUMP_COMPONENT_ACL)
+ dumpACL(fout, binfo->dobj.dumpId, InvalidDumpId, "LARGE OBJECT",
+ binfo->dobj.name, NULL,
+ NULL, binfo->rolname, &binfo->dacl);
+ }
destroyPQExpBuffer(cquery);
destroyPQExpBuffer(dquery);
@@ -9442,6 +9492,38 @@ dumpCommentExtended(Archive *fout, const char *type,
const char *owner, CatalogId catalogId,
int subid, DumpId dumpId,
const char *initdb_comment)
+{
+ PQExpBuffer query = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+
+ if (dumpCommentQuery(fout, query, tag, type, name, namespace, owner,
+ catalogId, subid, dumpId, initdb_comment))
+ {
+ /*
+ * We mark comments as SECTION_NONE because they really belong in the
+ * same section as their parent, whether that is pre-data or
+ * post-data.
+ */
+ ArchiveEntry(fout, nilCatalogId, createDumpId(),
+ ARCHIVE_OPTS(.tag = tag->data,
+ .namespace = namespace,
+ .owner = owner,
+ .description = "COMMENT",
+ .section = SECTION_NONE,
+ .createStmt = query->data,
+ .deps = &dumpId,
+ .nDeps = 1));
+ }
+ destroyPQExpBuffer(query);
+ destroyPQExpBuffer(tag);
+}
+
+static bool
+dumpCommentQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId,
+ const char *initdb_comment)
{
DumpOptions *dopt = fout->dopt;
CommentItem *comments;
@@ -9449,19 +9531,19 @@ dumpCommentExtended(Archive *fout, const char *type,
/* do nothing, if --no-comments is supplied */
if (dopt->no_comments)
- return;
+ return false;
/* Comments are schema not data ... except blob comments are data */
if (strcmp(type, "LARGE OBJECT") != 0)
{
if (dopt->dataOnly)
- return;
+ return false;
}
else
{
/* We do dump blob comments in binary-upgrade mode */
if (dopt->schemaOnly && !dopt->binary_upgrade)
- return;
+ return false;
}
/* Search for comments associated with catalogId, using table */
@@ -9499,9 +9581,6 @@ dumpCommentExtended(Archive *fout, const char *type,
/* If a comment exists, build COMMENT ON statement */
if (ncomments > 0)
{
- PQExpBuffer query = createPQExpBuffer();
- PQExpBuffer tag = createPQExpBuffer();
-
appendPQExpBuffer(query, "COMMENT ON %s ", type);
if (namespace && *namespace)
appendPQExpBuffer(query, "%s.", fmtId(namespace));
@@ -9511,24 +9590,10 @@ dumpCommentExtended(Archive *fout, const char *type,
appendPQExpBuffer(tag, "%s %s", type, name);
- /*
- * We mark comments as SECTION_NONE because they really belong in the
- * same section as their parent, whether that is pre-data or
- * post-data.
- */
- ArchiveEntry(fout, nilCatalogId, createDumpId(),
- ARCHIVE_OPTS(.tag = tag->data,
- .namespace = namespace,
- .owner = owner,
- .description = "COMMENT",
- .section = SECTION_NONE,
- .createStmt = query->data,
- .deps = &dumpId,
- .nDeps = 1));
-
- destroyPQExpBuffer(query);
- destroyPQExpBuffer(tag);
+ return true;
}
+
+ return false;
}
/*
@@ -14423,23 +14488,65 @@ dumpACL(Archive *fout, DumpId objDumpId, DumpId altDumpId,
const DumpableAcl *dacl)
{
DumpId aclDumpId = InvalidDumpId;
+ PQExpBuffer query = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+
+ if (dumpACLQuery(fout, query, tag, objDumpId, altDumpId,
+ type, name, subname, nspname, owner, dacl))
+ {
+ DumpId aclDeps[2];
+ int nDeps = 0;
+
+ if (subname)
+ appendPQExpBuffer(tag, "COLUMN %s.%s", name, subname);
+ else
+ appendPQExpBuffer(tag, "%s %s", type, name);
+
+ aclDeps[nDeps++] = objDumpId;
+ if (altDumpId != InvalidDumpId)
+ aclDeps[nDeps++] = altDumpId;
+
+ aclDumpId = createDumpId();
+
+ ArchiveEntry(fout, nilCatalogId, aclDumpId,
+ ARCHIVE_OPTS(.tag = tag->data,
+ .namespace = nspname,
+ .owner = owner,
+ .description = "ACL",
+ .section = SECTION_NONE,
+ .createStmt = query->data,
+ .deps = aclDeps,
+ .nDeps = nDeps));
+
+ }
+
+ destroyPQExpBuffer(query);
+ destroyPQExpBuffer(tag);
+
+ return aclDumpId;
+}
+
+static bool
+dumpACLQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ DumpId objDumpId, DumpId altDumpId,
+ const char *type, const char *name, const char *subname,
+ const char *nspname, const char *owner,
+ const DumpableAcl *dacl)
+{
DumpOptions *dopt = fout->dopt;
const char *acls = dacl->acl;
const char *acldefault = dacl->acldefault;
char privtype = dacl->privtype;
const char *initprivs = dacl->initprivs;
const char *baseacls;
- PQExpBuffer sql;
/* Do nothing if ACL dump is not enabled */
if (dopt->aclsSkip)
- return InvalidDumpId;
+ return false;
/* --data-only skips ACLs *except* BLOB ACLs */
if (dopt->dataOnly && strcmp(type, "LARGE OBJECT") != 0)
- return InvalidDumpId;
-
- sql = createPQExpBuffer();
+ return false;
/*
* In binary upgrade mode, we don't run an extension's script but instead
@@ -14457,13 +14564,13 @@ dumpACL(Archive *fout, DumpId objDumpId, DumpId altDumpId,
if (dopt->binary_upgrade && privtype == 'e' &&
initprivs && *initprivs != '\0')
{
- appendPQExpBufferStr(sql, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(true);\n");
+ appendPQExpBufferStr(query, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(true);\n");
if (!buildACLCommands(name, subname, nspname, type,
initprivs, acldefault, owner,
- "", fout->remoteVersion, sql))
+ "", fout->remoteVersion, query))
pg_fatal("could not parse initial ACL list (%s) or default (%s) for object \"%s\" (%s)",
initprivs, acldefault, name, type);
- appendPQExpBufferStr(sql, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(false);\n");
+ appendPQExpBufferStr(query, "SELECT pg_catalog.binary_upgrade_set_record_init_privs(false);\n");
}
/*
@@ -14485,43 +14592,19 @@ dumpACL(Archive *fout, DumpId objDumpId, DumpId altDumpId,
if (!buildACLCommands(name, subname, nspname, type,
acls, baseacls, owner,
- "", fout->remoteVersion, sql))
+ "", fout->remoteVersion, query))
pg_fatal("could not parse ACL list (%s) or default (%s) for object \"%s\" (%s)",
acls, baseacls, name, type);
- if (sql->len > 0)
+ if (query->len > 0 && tag != NULL)
{
- PQExpBuffer tag = createPQExpBuffer();
- DumpId aclDeps[2];
- int nDeps = 0;
-
if (subname)
appendPQExpBuffer(tag, "COLUMN %s.%s", name, subname);
else
appendPQExpBuffer(tag, "%s %s", type, name);
-
- aclDeps[nDeps++] = objDumpId;
- if (altDumpId != InvalidDumpId)
- aclDeps[nDeps++] = altDumpId;
-
- aclDumpId = createDumpId();
-
- ArchiveEntry(fout, nilCatalogId, aclDumpId,
- ARCHIVE_OPTS(.tag = tag->data,
- .namespace = nspname,
- .owner = owner,
- .description = "ACL",
- .section = SECTION_NONE,
- .createStmt = sql->data,
- .deps = aclDeps,
- .nDeps = nDeps));
-
- destroyPQExpBuffer(tag);
}
- destroyPQExpBuffer(sql);
-
- return aclDumpId;
+ return true;
}
/*
@@ -14546,35 +14629,59 @@ static void
dumpSecLabel(Archive *fout, const char *type, const char *name,
const char *namespace, const char *owner,
CatalogId catalogId, int subid, DumpId dumpId)
+{
+ PQExpBuffer query = createPQExpBuffer();
+ PQExpBuffer tag = createPQExpBuffer();
+
+ if (dumpSecLabelQuery(fout, query, tag, type, name,
+ namespace, owner, catalogId, subid, dumpId))
+ {
+ ArchiveEntry(fout, nilCatalogId, createDumpId(),
+ ARCHIVE_OPTS(.tag = tag->data,
+ .namespace = namespace,
+ .owner = owner,
+ .description = "SECURITY LABEL",
+ .section = SECTION_NONE,
+ .createStmt = query->data,
+ .deps = &dumpId,
+ .nDeps = 1));
+ }
+
+ destroyPQExpBuffer(query);
+ destroyPQExpBuffer(tag);
+}
+
+static bool
+dumpSecLabelQuery(Archive *fout, PQExpBuffer query, PQExpBuffer tag,
+ const char *type, const char *name,
+ const char *namespace, const char *owner,
+ CatalogId catalogId, int subid, DumpId dumpId)
{
DumpOptions *dopt = fout->dopt;
SecLabelItem *labels;
int nlabels;
int i;
- PQExpBuffer query;
/* do nothing, if --no-security-labels is supplied */
if (dopt->no_security_labels)
- return;
+ return false;
/* Security labels are schema not data ... except blob labels are data */
if (strcmp(type, "LARGE OBJECT") != 0)
{
if (dopt->dataOnly)
- return;
+ return false;
}
else
{
/* We do dump blob security labels in binary-upgrade mode */
if (dopt->schemaOnly && !dopt->binary_upgrade)
- return;
+ return false;
}
/* Search for security labels associated with catalogId, using table */
nlabels = findSecLabels(catalogId.tableoid, catalogId.oid, &labels);
- query = createPQExpBuffer();
-
for (i = 0; i < nlabels; i++)
{
/*
@@ -14595,22 +14702,11 @@ dumpSecLabel(Archive *fout, const char *type, const char *name,
if (query->len > 0)
{
- PQExpBuffer tag = createPQExpBuffer();
-
appendPQExpBuffer(tag, "%s %s", type, name);
- ArchiveEntry(fout, nilCatalogId, createDumpId(),
- ARCHIVE_OPTS(.tag = tag->data,
- .namespace = namespace,
- .owner = owner,
- .description = "SECURITY LABEL",
- .section = SECTION_NONE,
- .createStmt = query->data,
- .deps = &dumpId,
- .nDeps = 1));
- destroyPQExpBuffer(tag);
+ return true;
}
- destroyPQExpBuffer(query);
+ return false;
}
/*
diff --git a/src/bin/pg_dump/pg_restore.c b/src/bin/pg_dump/pg_restore.c
index 049a100634..2159f72ffb 100644
--- a/src/bin/pg_dump/pg_restore.c
+++ b/src/bin/pg_dump/pg_restore.c
@@ -60,6 +60,7 @@ main(int argc, char **argv)
int c;
int exit_code;
int numWorkers = 1;
+ int blobBatchSize = 0;
Archive *AH;
char *inputFileSpec;
static int disable_triggers = 0;
@@ -123,6 +124,7 @@ main(int argc, char **argv)
{"no-publications", no_argument, &no_publications, 1},
{"no-security-labels", no_argument, &no_security_labels, 1},
{"no-subscriptions", no_argument, &no_subscriptions, 1},
+ {"restore-blob-batch-size", required_argument, NULL, 4},
{NULL, 0, NULL, 0}
};
@@ -286,6 +288,10 @@ main(int argc, char **argv)
set_dump_section(optarg, &(opts->dumpSections));
break;
+ case 4: /* # of blobs to restore per transaction */
+ blobBatchSize = atoi(optarg);
+ break;
+
default:
/* getopt_long already emitted a complaint */
pg_log_error_hint("Try \"%s --help\" for more information.", progname);
@@ -405,6 +411,7 @@ main(int argc, char **argv)
SortTocFromFile(AH);
AH->numWorkers = numWorkers;
+ AH->blobBatchSize = blobBatchSize;
if (opts->tocSummary)
PrintTOCSummary(AH);
@@ -478,6 +485,8 @@ usage(const char *progname)
printf(_(" --use-set-session-authorization\n"
" use SET SESSION AUTHORIZATION commands instead of\n"
" ALTER OWNER commands to set ownership\n"));
+ printf(_(" --restore-blob-batch-size=NUM\n"
+ " attempt to restore NUM large objects per transaction\n"));
printf(_("\nConnection options:\n"));
printf(_(" -h, --host=HOSTNAME database server host or socket directory\n"));
diff --git a/src/bin/pg_upgrade/dump.c b/src/bin/pg_upgrade/dump.c
index 29b9e44f78..9b838c88e5 100644
--- a/src/bin/pg_upgrade/dump.c
+++ b/src/bin/pg_upgrade/dump.c
@@ -53,8 +53,11 @@ generate_old_dump(void)
parallel_exec_prog(log_file_name, NULL,
"\"%s/pg_dump\" %s --schema-only --quote-all-identifiers "
+ "%s "
"--binary-upgrade --format=custom %s --file=\"%s/%s\" %s",
new_cluster.bindir, cluster_conn_opts(&old_cluster),
+ user_opts.pg_dump_opts ?
+ user_opts.pg_dump_opts : "",
log_opts.verbose ? "--verbose" : "",
log_opts.dumpdir,
sql_file_name, escaped_connstr.data);
diff --git a/src/bin/pg_upgrade/option.c b/src/bin/pg_upgrade/option.c
index fbab1c4fb7..4bcd925874 100644
--- a/src/bin/pg_upgrade/option.c
+++ b/src/bin/pg_upgrade/option.c
@@ -56,6 +56,8 @@ parseCommandLine(int argc, char *argv[])
{"socketdir", required_argument, NULL, 's'},
{"verbose", no_argument, NULL, 'v'},
{"clone", no_argument, NULL, 1},
+ {"dump-options", required_argument, NULL, 2},
+ {"restore-options", required_argument, NULL, 3},
{NULL, 0, NULL, 0}
};
@@ -194,6 +196,34 @@ parseCommandLine(int argc, char *argv[])
user_opts.transfer_mode = TRANSFER_MODE_CLONE;
break;
+ case 2:
+ /* append option? */
+ if (!user_opts.pg_dump_opts)
+ user_opts.pg_dump_opts = pg_strdup(optarg);
+ else
+ {
+ char *old_opts = user_opts.pg_dump_opts;
+
+ user_opts.pg_dump_opts = psprintf("%s %s",
+ old_opts, optarg);
+ free(old_opts);
+ }
+ break;
+
+ case 3:
+ /* append option? */
+ if (!user_opts.pg_restore_opts)
+ user_opts.pg_restore_opts = pg_strdup(optarg);
+ else
+ {
+ char *old_opts = user_opts.pg_restore_opts;
+
+ user_opts.pg_restore_opts = psprintf("%s %s",
+ old_opts, optarg);
+ free(old_opts);
+ }
+ break;
+
default:
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
os_info.progname);
@@ -283,6 +313,8 @@ usage(void)
printf(_(" -v, --verbose enable verbose internal logging\n"));
printf(_(" -V, --version display version information, then exit\n"));
printf(_(" --clone clone instead of copying files to new cluster\n"));
+ printf(_(" --dump-options=OPTIONS options to pass to pg_dump\n"));
+ printf(_(" --restore-options=OPTIONS options to pass to pg_restore\n"));
printf(_(" -?, --help show this help, then exit\n"));
printf(_("\n"
"Before running pg_upgrade you must:\n"
diff --git a/src/bin/pg_upgrade/pg_upgrade.c b/src/bin/pg_upgrade/pg_upgrade.c
index 115faa222e..3b98312ed2 100644
--- a/src/bin/pg_upgrade/pg_upgrade.c
+++ b/src/bin/pg_upgrade/pg_upgrade.c
@@ -457,10 +457,13 @@ create_new_objects(void)
true,
true,
"\"%s/pg_restore\" %s %s --exit-on-error --verbose "
+ "%s "
"--dbname postgres \"%s/%s\"",
new_cluster.bindir,
cluster_conn_opts(&new_cluster),
create_opts,
+ user_opts.pg_restore_opts ?
+ user_opts.pg_restore_opts : "",
log_opts.dumpdir,
sql_file_name);
@@ -495,10 +498,13 @@ create_new_objects(void)
parallel_exec_prog(log_file_name,
NULL,
"\"%s/pg_restore\" %s %s --exit-on-error --verbose "
+ "%s "
"--dbname template1 \"%s/%s\"",
new_cluster.bindir,
cluster_conn_opts(&new_cluster),
create_opts,
+ user_opts.pg_restore_opts ?
+ user_opts.pg_restore_opts : "",
log_opts.dumpdir,
sql_file_name);
}
diff --git a/src/bin/pg_upgrade/pg_upgrade.h b/src/bin/pg_upgrade/pg_upgrade.h
index 60c3c8dd68..477de6f717 100644
--- a/src/bin/pg_upgrade/pg_upgrade.h
+++ b/src/bin/pg_upgrade/pg_upgrade.h
@@ -295,6 +295,8 @@ typedef struct
transferMode transfer_mode; /* copy files or link them? */
int jobs; /* number of processes/threads to use */
char *socketdir; /* directory to use for Unix sockets */
+ char *pg_dump_opts; /* options to pass to pg_dump */
+ char *pg_restore_opts; /* options to pass to pg_dump */
} UserOpts;
typedef struct
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2022-09-07 21:42 Jacob Champion <[email protected]>
parent: Nathan Bossart <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Jacob Champion @ 2022-09-07 21:42 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; Jan Wieck <[email protected]>; +Cc: Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 8/24/22 17:32, Nathan Bossart wrote:
> I'd like to revive this thread, so I've created a commitfest entry [0] and
> attached a hastily rebased patch that compiles and passes the tests. I am
> aiming to spend some more time on this in the near future.
Just to clarify, was Justin's statement upthread (that the XID problem
is fixed) correct? And is this patch just trying to improve the
remaining memory and lock usage problems?
I took a quick look at the pg_upgrade diffs. I agree with Jan that the
escaping problem is a pretty bad smell, but even putting that aside for
a bit, is it safe to expose arbitrary options to pg_dump/restore during
upgrade? It's super flexible, but I can imagine that some of those flags
might really mess up the new cluster...
And yeah, if you choose to do that then you get to keep both pieces, I
guess, but I like that pg_upgrade tries to be (IMO) fairly bulletproof.
--Jacob
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2022-09-08 23:18 Nathan Bossart <[email protected]>
parent: Jacob Champion <[email protected]>
0 siblings, 1 reply; 49+ messages in thread
From: Nathan Bossart @ 2022-09-08 23:18 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; +Cc: Jan Wieck <[email protected]>; Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Wed, Sep 07, 2022 at 02:42:05PM -0700, Jacob Champion wrote:
> Just to clarify, was Justin's statement upthread (that the XID problem
> is fixed) correct? And is this patch just trying to improve the
> remaining memory and lock usage problems?
I think "fixed" might not be totally accurate, but that is the gist.
> I took a quick look at the pg_upgrade diffs. I agree with Jan that the
> escaping problem is a pretty bad smell, but even putting that aside for
> a bit, is it safe to expose arbitrary options to pg_dump/restore during
> upgrade? It's super flexible, but I can imagine that some of those flags
> might really mess up the new cluster...
>
> And yeah, if you choose to do that then you get to keep both pieces, I
> guess, but I like that pg_upgrade tries to be (IMO) fairly bulletproof.
IIUC the main benefit of this approach is that it isn't dependent on
binary-upgrade mode, which seems to be a goal based on the discussion
upthread [0]. I think it'd be easily possible to fix only pg_upgrade by
simply dumping and restoring pg_largeobject_metadata, as Andres suggested
in 2018 [1]. In fact, it seems like it ought to be possible to just copy
pg_largeobject_metadata's files as was done before 12a53c7. AFAICT this
would only work for clusters upgrading from v12 and newer, and it'd break
if any of the underlying data types change their storage format. This
seems unlikely for OIDs, but there is ongoing discussion about changing
aclitem.
I still think this is a problem worth fixing, but it's not yet clear how to
proceed.
[0] https://postgr.es/m/227228.1616259220%40sss.pgh.pa.us
[1] https://postgr.es/m/20181122001415.ef5bncxqin2y3esb%40alap3.anarazel.de
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2022-09-08 23:29 Jacob Champion <[email protected]>
parent: Nathan Bossart <[email protected]>
0 siblings, 2 replies; 49+ messages in thread
From: Jacob Champion @ 2022-09-08 23:29 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Jan Wieck <[email protected]>; Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Thu, Sep 8, 2022 at 4:18 PM Nathan Bossart <[email protected]> wrote:
> IIUC the main benefit of this approach is that it isn't dependent on
> binary-upgrade mode, which seems to be a goal based on the discussion
> upthread [0].
To clarify, I agree that pg_dump should contain the core fix. What I'm
questioning is the addition of --dump-options to make use of that fix
from pg_upgrade, since it also lets the user do "exciting" new things
like --exclude-schema and --include-foreign-data and so on. I don't
think we should let them do that without a good reason.
Thanks,
--Jacob
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2022-09-08 23:34 Nathan Bossart <[email protected]>
parent: Jacob Champion <[email protected]>
1 sibling, 1 reply; 49+ messages in thread
From: Nathan Bossart @ 2022-09-08 23:34 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; +Cc: Jan Wieck <[email protected]>; Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Thu, Sep 08, 2022 at 04:29:10PM -0700, Jacob Champion wrote:
> On Thu, Sep 8, 2022 at 4:18 PM Nathan Bossart <[email protected]> wrote:
>> IIUC the main benefit of this approach is that it isn't dependent on
>> binary-upgrade mode, which seems to be a goal based on the discussion
>> upthread [0].
>
> To clarify, I agree that pg_dump should contain the core fix. What I'm
> questioning is the addition of --dump-options to make use of that fix
> from pg_upgrade, since it also lets the user do "exciting" new things
> like --exclude-schema and --include-foreign-data and so on. I don't
> think we should let them do that without a good reason.
Ah, yes, I think that is a fair point.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2022-10-12 05:50 Michael Paquier <[email protected]>
parent: Nathan Bossart <[email protected]>
0 siblings, 0 replies; 49+ messages in thread
From: Michael Paquier @ 2022-10-12 05:50 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Jacob Champion <[email protected]>; Jan Wieck <[email protected]>; Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Robins Tharakan <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Thu, Sep 08, 2022 at 04:34:07PM -0700, Nathan Bossart wrote:
> On Thu, Sep 08, 2022 at 04:29:10PM -0700, Jacob Champion wrote:
>> To clarify, I agree that pg_dump should contain the core fix. What I'm
>> questioning is the addition of --dump-options to make use of that fix
>> from pg_upgrade, since it also lets the user do "exciting" new things
>> like --exclude-schema and --include-foreign-data and so on. I don't
>> think we should let them do that without a good reason.
>
> Ah, yes, I think that is a fair point.
It has been more than four weeks since the last activity of this
thread and there has been what looks like some feedback to me, so
marked as RwF for the time being.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2024-01-26 14:42 vignesh C <[email protected]>
parent: Jacob Champion <[email protected]>
1 sibling, 1 reply; 49+ messages in thread
From: vignesh C @ 2024-01-26 14:42 UTC (permalink / raw)
To: Kumar, Sachin <[email protected]>; +Cc: Tom Lane <[email protected]>; Robins Tharakan <[email protected]>; Nathan Bossart <[email protected]>; Jan Wieck <[email protected]>; Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Tue, 2 Jan 2024 at 23:03, Kumar, Sachin <[email protected]> wrote:
>
> > On 11/12/2023, 01:43, "Tom Lane" <[email protected] <mailto:[email protected]>> wrote:
>
> > I had initially supposed that in a parallel restore we could
> > have child workers also commit after every N TOC items, but was
> > soon disabused of that idea. After a worker processes a TOC
> > item, any dependent items (such as index builds) might get
> > dispatched to some other worker, which had better be able to
> > see the results of the first worker's step. So at least in
> > this implementation, we disable the multi-command-per-COMMIT
> > behavior during the parallel part of the restore. Maybe that
> > could be improved in future, but it seems like it'd add a
> > lot more complexity, and it wouldn't make life any better for
> > pg_upgrade (which doesn't use parallel pg_restore, and seems
> > unlikely to want to in future).
>
> I was not able to find email thread which details why we are not using
> parallel pg_restore for pg_upgrade. IMHO most of the customer will have single large
> database, and not using parallel restore will cause slow pg_upgrade.
>
> I am attaching a patch which enables parallel pg_restore for DATA and POST-DATA part
> of dump. It will push down --jobs value to pg_restore and will restore database sequentially.
CFBot shows that the patch does not apply anymore as in [1]:
=== Applying patches on top of PostgreSQL commit ID
46a0cd4cefb4d9b462d8cc4df5e7ecdd190bea92 ===
=== applying patch ./v9-005-parallel_pg_restore.patch
patching file src/bin/pg_upgrade/pg_upgrade.c
Hunk #3 FAILED at 650.
1 out of 3 hunks FAILED -- saving rejects to file
src/bin/pg_upgrade/pg_upgrade.c.rej
Please post an updated version for the same.
[1] - http://cfbot.cputube.org/patch_46_4713.log
Regards,
Vignesh
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2024-01-26 16:44 Tom Lane <[email protected]>
parent: vignesh C <[email protected]>
0 siblings, 0 replies; 49+ messages in thread
From: Tom Lane @ 2024-01-26 16:44 UTC (permalink / raw)
To: vignesh C <[email protected]>; +Cc: Kumar, Sachin <[email protected]>; Robins Tharakan <[email protected]>; Nathan Bossart <[email protected]>; Jan Wieck <[email protected]>; Bruce Momjian <[email protected]>; Zhihong Yu <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
vignesh C <[email protected]> writes:
> CFBot shows that the patch does not apply anymore as in [1]:
> === Applying patches on top of PostgreSQL commit ID
> 46a0cd4cefb4d9b462d8cc4df5e7ecdd190bea92 ===
> === applying patch ./v9-005-parallel_pg_restore.patch
> patching file src/bin/pg_upgrade/pg_upgrade.c
> Hunk #3 FAILED at 650.
> 1 out of 3 hunks FAILED -- saving rejects to file
> src/bin/pg_upgrade/pg_upgrade.c.rej
That's because v9-005 was posted by itself. But I don't think
we should use it anyway.
Here's 0001-0004 again, updated to current HEAD (only line numbers
changed) and with Nathan's suggestion to define some macros for
the magic constants.
regards, tom lane
Attachments:
[text/x-diff] v10-0001-Some-small-preliminaries-for-pg_dump-changes.patch (5.9K, 2-v10-0001-Some-small-preliminaries-for-pg_dump-changes.patch)
download | inline diff:
From c48b11547c6eb95ab217dddc047da5378042452c Mon Sep 17 00:00:00 2001
From: Tom Lane <[email protected]>
Date: Fri, 26 Jan 2024 11:10:00 -0500
Subject: [PATCH v10 1/4] Some small preliminaries for pg_dump changes.
Centralize management of the lo_buf used to hold data while restoring
blobs. The code previously had each format handler create lo_buf,
which seems rather pointless given that the format handlers all make
it the same way. Moreover, the format handlers never use lo_buf
directly, making this setup a failure from a separation-of-concerns
standpoint. Let's move the responsibility into pg_backup_archiver.c,
which is the only module concerned with lo_buf. The main reason to do
this now is that it allows a centralized fix for the soon-to-be-false
assumption that we never restore blobs in parallel.
Also, get rid of dead code in DropLOIfExists: it's been a long time
since we had any need to be able to restore to a pre-9.0 server.
---
src/bin/pg_dump/pg_backup_archiver.c | 9 +++++++++
src/bin/pg_dump/pg_backup_custom.c | 7 -------
src/bin/pg_dump/pg_backup_db.c | 27 +++++----------------------
src/bin/pg_dump/pg_backup_directory.c | 6 ------
src/bin/pg_dump/pg_backup_null.c | 4 ----
src/bin/pg_dump/pg_backup_tar.c | 4 ----
6 files changed, 14 insertions(+), 43 deletions(-)
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index 256d1e35a4..26c2c684c8 100644
--- a/src/bin/pg_dump/pg_backup_archiver.c
+++ b/src/bin/pg_dump/pg_backup_archiver.c
@@ -1343,6 +1343,12 @@ StartRestoreLO(ArchiveHandle *AH, Oid oid, bool drop)
AH->loCount++;
/* Initialize the LO Buffer */
+ if (AH->lo_buf == NULL)
+ {
+ /* First time through (in this process) so allocate the buffer */
+ AH->lo_buf_size = LOBBUFSIZE;
+ AH->lo_buf = (void *) pg_malloc(LOBBUFSIZE);
+ }
AH->lo_buf_used = 0;
pg_log_info("restoring large object with OID %u", oid);
@@ -4748,6 +4754,9 @@ CloneArchive(ArchiveHandle *AH)
/* clone has its own error count, too */
clone->public.n_errors = 0;
+ /* clones should not share lo_buf */
+ clone->lo_buf = NULL;
+
/*
* Connect our new clone object to the database, using the same connection
* parameters used for the original connection.
diff --git a/src/bin/pg_dump/pg_backup_custom.c b/src/bin/pg_dump/pg_backup_custom.c
index b576b29924..7c6ac89dd4 100644
--- a/src/bin/pg_dump/pg_backup_custom.c
+++ b/src/bin/pg_dump/pg_backup_custom.c
@@ -140,10 +140,6 @@ InitArchiveFmt_Custom(ArchiveHandle *AH)
ctx = (lclContext *) pg_malloc0(sizeof(lclContext));
AH->formatData = (void *) ctx;
- /* Initialize LO buffering */
- AH->lo_buf_size = LOBBUFSIZE;
- AH->lo_buf = (void *) pg_malloc(LOBBUFSIZE);
-
/*
* Now open the file
*/
@@ -902,9 +898,6 @@ _Clone(ArchiveHandle *AH)
* share knowledge about where the data blocks are across threads.
* _PrintTocData has to be careful about the order of operations on that
* state, though.
- *
- * Note: we do not make a local lo_buf because we expect at most one BLOBS
- * entry per archive, so no parallelism is possible.
*/
}
diff --git a/src/bin/pg_dump/pg_backup_db.c b/src/bin/pg_dump/pg_backup_db.c
index f766b65059..b297ca049d 100644
--- a/src/bin/pg_dump/pg_backup_db.c
+++ b/src/bin/pg_dump/pg_backup_db.c
@@ -544,26 +544,9 @@ CommitTransaction(Archive *AHX)
void
DropLOIfExists(ArchiveHandle *AH, Oid oid)
{
- /*
- * If we are not restoring to a direct database connection, we have to
- * guess about how to detect whether the LO exists. Assume new-style.
- */
- if (AH->connection == NULL ||
- PQserverVersion(AH->connection) >= 90000)
- {
- ahprintf(AH,
- "SELECT pg_catalog.lo_unlink(oid) "
- "FROM pg_catalog.pg_largeobject_metadata "
- "WHERE oid = '%u';\n",
- oid);
- }
- else
- {
- /* Restoring to pre-9.0 server, so do it the old way */
- ahprintf(AH,
- "SELECT CASE WHEN EXISTS("
- "SELECT 1 FROM pg_catalog.pg_largeobject WHERE loid = '%u'"
- ") THEN pg_catalog.lo_unlink('%u') END;\n",
- oid, oid);
- }
+ ahprintf(AH,
+ "SELECT pg_catalog.lo_unlink(oid) "
+ "FROM pg_catalog.pg_largeobject_metadata "
+ "WHERE oid = '%u';\n",
+ oid);
}
diff --git a/src/bin/pg_dump/pg_backup_directory.c b/src/bin/pg_dump/pg_backup_directory.c
index dba57443e8..de3cfea02e 100644
--- a/src/bin/pg_dump/pg_backup_directory.c
+++ b/src/bin/pg_dump/pg_backup_directory.c
@@ -143,10 +143,6 @@ InitArchiveFmt_Directory(ArchiveHandle *AH)
ctx->dataFH = NULL;
ctx->LOsTocFH = NULL;
- /* Initialize LO buffering */
- AH->lo_buf_size = LOBBUFSIZE;
- AH->lo_buf = (void *) pg_malloc(LOBBUFSIZE);
-
/*
* Now open the TOC file
*/
@@ -823,8 +819,6 @@ _Clone(ArchiveHandle *AH)
ctx = (lclContext *) AH->formatData;
/*
- * Note: we do not make a local lo_buf because we expect at most one BLOBS
- * entry per archive, so no parallelism is possible. Likewise,
* TOC-entry-local state isn't an issue because any one TOC entry is
* touched by just one worker child.
*/
diff --git a/src/bin/pg_dump/pg_backup_null.c b/src/bin/pg_dump/pg_backup_null.c
index 08f096251b..776f057770 100644
--- a/src/bin/pg_dump/pg_backup_null.c
+++ b/src/bin/pg_dump/pg_backup_null.c
@@ -63,10 +63,6 @@ InitArchiveFmt_Null(ArchiveHandle *AH)
AH->ClonePtr = NULL;
AH->DeClonePtr = NULL;
- /* Initialize LO buffering */
- AH->lo_buf_size = LOBBUFSIZE;
- AH->lo_buf = (void *) pg_malloc(LOBBUFSIZE);
-
/*
* Now prevent reading...
*/
diff --git a/src/bin/pg_dump/pg_backup_tar.c b/src/bin/pg_dump/pg_backup_tar.c
index aad88ad559..4cb9707e63 100644
--- a/src/bin/pg_dump/pg_backup_tar.c
+++ b/src/bin/pg_dump/pg_backup_tar.c
@@ -156,10 +156,6 @@ InitArchiveFmt_Tar(ArchiveHandle *AH)
ctx->filePos = 0;
ctx->isSpecialScript = 0;
- /* Initialize LO buffering */
- AH->lo_buf_size = LOBBUFSIZE;
- AH->lo_buf = (void *) pg_malloc(LOBBUFSIZE);
-
/*
* Now open the tar file, and load the TOC if we're in read mode.
*/
--
2.39.3
[text/x-diff] v10-0002-In-dumps-group-large-objects-into-matching-metad.patch (39.8K, 3-v10-0002-In-dumps-group-large-objects-into-matching-metad.patch)
download | inline diff:
From ea600dd34ebddef9e3c7d267b0e73340bb77f48a Mon Sep 17 00:00:00 2001
From: Tom Lane <[email protected]>
Date: Fri, 26 Jan 2024 11:25:26 -0500
Subject: [PATCH v10 2/4] In dumps, group large objects into matching metadata
and data entries.
Commit c0d5be5d6 caused pg_dump to create a separate BLOB metadata TOC
entry for each large object (blob), but it did not touch the ancient
decision to put all the blobs' data into a single BLOBS TOC entry.
This is bad for a few reasons: for databases with millions of blobs,
the TOC becomes unreasonably large, causing performance issues;
selective restore of just some blobs is quite impossible; and we
cannot parallelize either dump or restore of the blob data, since our
architecture for that relies on farming out whole TOC entries to
worker processes.
To improve matters, let's group multiple blobs into each blob metadata
TOC entry, and then make corresponding per-group blob data TOC entries.
Selective restore using pg_restore's -l/-L switches is then possible,
though only at the group level. (Perhaps we should provide a switch
to allow forcing one-blob-per-group for users who need precise
selective restore and don't have huge numbers of blobs. This patch
doesn't yet do that, instead just hard-wiring the maximum number of
blobs per entry at 1000.)
The blobs in a group must all have the same owner, since the TOC entry
format only allows one owner to be named. In this implementation
we also require them to all share the same ACL (grants); the archive
format wouldn't require that, but pg_dump's representation of
DumpableObjects does. It seems unlikely that either restriction
will be problematic for databases with huge numbers of blobs.
The metadata TOC entries now have a "desc" string of "BLOB METADATA",
and their "defn" string is just a newline-separated list of blob OIDs.
The restore code has to generate creation commands, ALTER OWNER
commands, and drop commands (for --clean mode) from that. We would
need special-case code for ALTER OWNER and drop in any case, so the
alternative of keeping the "defn" as directly executable SQL code
for creation wouldn't buy much, and it seems like it'd bloat the
archive to little purpose.
The data TOC entries ("BLOBS") can be exactly the same as before,
except that now there can be more than one, so we'd better give them
identifying tag strings.
We have to bump the archive file format version number, since existing
versions of pg_restore wouldn't know they need to do something special
for BLOB METADATA, plus they aren't going to work correctly with
multiple BLOBS entries.
Also, the directory and tar-file format handlers need some work
for multiple BLOBS entries: they used to hard-wire the file name
as "blobs.toc", which is replaced here with "blobs_<dumpid>.toc".
The 002_pg_dump.pl test script also knows about that and requires
minor updates. (I had to drop the test for manually-compressed
blobs.toc files with LZ4, because lz4's obtuse command line
design requires explicit specification of the output file name
which seems impractical here. I don't think we're losing any
useful test coverage thereby; that test stanza seems completely
duplicative with the gzip and zstd cases anyway.)
As this stands, we still generate a separate TOC entry for any
comment, security label, or ACL attached to a blob. I feel
comfortable in believing that comments and security labels on
blobs are rare; but we might have to do something about aggregating
blob ACLs into grouped TOC entries to avoid blowing up the TOC
size, if there are use cases with large numbers of non-default
blob ACLs. That can be done later though, as it would not create
any compatibility issues.
---
src/bin/pg_dump/common.c | 26 +++
src/bin/pg_dump/pg_backup_archiver.c | 76 +++++--
src/bin/pg_dump/pg_backup_archiver.h | 6 +-
src/bin/pg_dump/pg_backup_custom.c | 4 +-
src/bin/pg_dump/pg_backup_db.c | 27 +++
src/bin/pg_dump/pg_backup_directory.c | 38 ++--
src/bin/pg_dump/pg_backup_null.c | 4 +-
src/bin/pg_dump/pg_backup_tar.c | 39 +++-
src/bin/pg_dump/pg_dump.c | 287 +++++++++++++++-----------
src/bin/pg_dump/pg_dump.h | 11 +
src/bin/pg_dump/t/002_pg_dump.pl | 30 ++-
11 files changed, 361 insertions(+), 187 deletions(-)
diff --git a/src/bin/pg_dump/common.c b/src/bin/pg_dump/common.c
index 0ed18b72d6..c7dd0b11fd 100644
--- a/src/bin/pg_dump/common.c
+++ b/src/bin/pg_dump/common.c
@@ -47,6 +47,8 @@ static DumpId lastDumpId = 0; /* Note: 0 is InvalidDumpId */
* expects that it can move them around when resizing the table. So we
* cannot make the DumpableObjects be elements of the hash table directly;
* instead, the hash table elements contain pointers to DumpableObjects.
+ * This does have the advantage of letting us map multiple CatalogIds
+ * to one DumpableObject, which is useful for blobs.
*
* It turns out to be convenient to also use this data structure to map
* CatalogIds to owning extensions, if any. Since extension membership
@@ -700,6 +702,30 @@ AssignDumpId(DumpableObject *dobj)
}
}
+/*
+ * recordAdditionalCatalogID
+ * Record an additional catalog ID for the given DumpableObject
+ */
+void
+recordAdditionalCatalogID(CatalogId catId, DumpableObject *dobj)
+{
+ CatalogIdMapEntry *entry;
+ bool found;
+
+ /* CatalogId hash table must exist, if we have a DumpableObject */
+ Assert(catalogIdHash != NULL);
+
+ /* Add reference to CatalogId hash */
+ entry = catalogid_insert(catalogIdHash, catId, &found);
+ if (!found)
+ {
+ entry->dobj = NULL;
+ entry->ext = NULL;
+ }
+ Assert(entry->dobj == NULL);
+ entry->dobj = dobj;
+}
+
/*
* Assign a DumpId that's not tied to a DumpableObject.
*
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index 26c2c684c8..73b9972da4 100644
--- a/src/bin/pg_dump/pg_backup_archiver.c
+++ b/src/bin/pg_dump/pg_backup_archiver.c
@@ -512,7 +512,20 @@ RestoreArchive(Archive *AHX)
* don't necessarily emit it verbatim; at this point we add an
* appropriate IF EXISTS clause, if the user requested it.
*/
- if (*te->dropStmt != '\0')
+ if (strcmp(te->desc, "BLOB METADATA") == 0)
+ {
+ /* We must generate the per-blob commands */
+ if (ropt->if_exists)
+ IssueCommandPerBlob(AH, te,
+ "SELECT pg_catalog.lo_unlink(oid) "
+ "FROM pg_catalog.pg_largeobject_metadata "
+ "WHERE oid = '", "'");
+ else
+ IssueCommandPerBlob(AH, te,
+ "SELECT pg_catalog.lo_unlink('",
+ "')");
+ }
+ else if (*te->dropStmt != '\0')
{
if (!ropt->if_exists ||
strncmp(te->dropStmt, "--", 2) == 0)
@@ -528,12 +541,12 @@ RestoreArchive(Archive *AHX)
{
/*
* Inject an appropriate spelling of "if exists". For
- * large objects, we have a separate routine that
+ * old-style large objects, we have a routine that
* knows how to do it, without depending on
* te->dropStmt; use that. For other objects we need
* to parse the command.
*/
- if (strncmp(te->desc, "BLOB", 4) == 0)
+ if (strcmp(te->desc, "BLOB") == 0)
{
DropLOIfExists(AH, te->catalogId.oid);
}
@@ -1290,7 +1303,7 @@ EndLO(Archive *AHX, Oid oid)
**********/
/*
- * Called by a format handler before any LOs are restored
+ * Called by a format handler before a group of LOs is restored
*/
void
StartRestoreLOs(ArchiveHandle *AH)
@@ -1309,7 +1322,7 @@ StartRestoreLOs(ArchiveHandle *AH)
}
/*
- * Called by a format handler after all LOs are restored
+ * Called by a format handler after a group of LOs is restored
*/
void
EndRestoreLOs(ArchiveHandle *AH)
@@ -2994,13 +3007,14 @@ _tocEntryRequired(TocEntry *te, teSection curSection, ArchiveHandle *AH)
{
/*
* Special Case: If 'SEQUENCE SET' or anything to do with LOs, then it
- * is considered a data entry. We don't need to check for the BLOBS
- * entry or old-style BLOB COMMENTS, because they will have hadDumper
- * = true ... but we do need to check new-style BLOB ACLs, comments,
+ * is considered a data entry. We don't need to check for BLOBS or
+ * old-style BLOB COMMENTS entries, because they will have hadDumper =
+ * true ... but we do need to check new-style BLOB ACLs, comments,
* etc.
*/
if (strcmp(te->desc, "SEQUENCE SET") == 0 ||
strcmp(te->desc, "BLOB") == 0 ||
+ strcmp(te->desc, "BLOB METADATA") == 0 ||
(strcmp(te->desc, "ACL") == 0 &&
strncmp(te->tag, "LARGE OBJECT ", 13) == 0) ||
(strcmp(te->desc, "COMMENT") == 0 &&
@@ -3041,6 +3055,7 @@ _tocEntryRequired(TocEntry *te, teSection curSection, ArchiveHandle *AH)
if (!(ropt->sequence_data && strcmp(te->desc, "SEQUENCE SET") == 0) &&
!(ropt->binary_upgrade &&
(strcmp(te->desc, "BLOB") == 0 ||
+ strcmp(te->desc, "BLOB METADATA") == 0 ||
(strcmp(te->desc, "ACL") == 0 &&
strncmp(te->tag, "LARGE OBJECT ", 13) == 0) ||
(strcmp(te->desc, "COMMENT") == 0 &&
@@ -3612,18 +3627,26 @@ _printTocEntry(ArchiveHandle *AH, TocEntry *te, bool isData)
}
/*
- * Actually print the definition.
+ * Actually print the definition. Normally we can just print the defn
+ * string if any, but we have two special cases:
*
- * Really crude hack for suppressing AUTHORIZATION clause that old pg_dump
+ * 1. A crude hack for suppressing AUTHORIZATION clause that old pg_dump
* versions put into CREATE SCHEMA. Don't mutate the variant for schema
* "public" that is a comment. We have to do this when --no-owner mode is
* selected. This is ugly, but I see no other good way ...
+ *
+ * 2. BLOB METADATA entries need special processing since their defn
+ * strings are just lists of OIDs, not complete SQL commands.
*/
if (ropt->noOwner &&
strcmp(te->desc, "SCHEMA") == 0 && strncmp(te->defn, "--", 2) != 0)
{
ahprintf(AH, "CREATE SCHEMA %s;\n\n\n", fmtId(te->tag));
}
+ else if (strcmp(te->desc, "BLOB METADATA") == 0)
+ {
+ IssueCommandPerBlob(AH, te, "SELECT pg_catalog.lo_create('", "')");
+ }
else
{
if (te->defn && strlen(te->defn) > 0)
@@ -3644,18 +3667,31 @@ _printTocEntry(ArchiveHandle *AH, TocEntry *te, bool isData)
te->owner && strlen(te->owner) > 0 &&
te->dropStmt && strlen(te->dropStmt) > 0)
{
- PQExpBufferData temp;
+ if (strcmp(te->desc, "BLOB METADATA") == 0)
+ {
+ /* BLOB METADATA needs special code to handle multiple LOs */
+ char *cmdEnd = psprintf(" OWNER TO %s", fmtId(te->owner));
+
+ IssueCommandPerBlob(AH, te, "ALTER LARGE OBJECT ", cmdEnd);
+ pg_free(cmdEnd);
+ }
+ else
+ {
+ /* For all other cases, we can use _getObjectDescription */
+ PQExpBufferData temp;
- initPQExpBuffer(&temp);
- _getObjectDescription(&temp, te);
+ initPQExpBuffer(&temp);
+ _getObjectDescription(&temp, te);
- /*
- * If _getObjectDescription() didn't fill the buffer, then there is no
- * owner.
- */
- if (temp.data[0])
- ahprintf(AH, "ALTER %s OWNER TO %s;\n\n", temp.data, fmtId(te->owner));
- termPQExpBuffer(&temp);
+ /*
+ * If _getObjectDescription() didn't fill the buffer, then there
+ * is no owner.
+ */
+ if (temp.data[0])
+ ahprintf(AH, "ALTER %s OWNER TO %s;\n\n",
+ temp.data, fmtId(te->owner));
+ termPQExpBuffer(&temp);
+ }
}
/*
diff --git a/src/bin/pg_dump/pg_backup_archiver.h b/src/bin/pg_dump/pg_backup_archiver.h
index 917283fd34..e4dd395582 100644
--- a/src/bin/pg_dump/pg_backup_archiver.h
+++ b/src/bin/pg_dump/pg_backup_archiver.h
@@ -68,10 +68,12 @@
#define K_VERS_1_15 MAKE_ARCHIVE_VERSION(1, 15, 0) /* add
* compression_algorithm
* in header */
+#define K_VERS_1_16 MAKE_ARCHIVE_VERSION(1, 16, 0) /* BLOB METADATA entries
+ * and multiple BLOBS */
/* Current archive version number (the format we can output) */
#define K_VERS_MAJOR 1
-#define K_VERS_MINOR 15
+#define K_VERS_MINOR 16
#define K_VERS_REV 0
#define K_VERS_SELF MAKE_ARCHIVE_VERSION(K_VERS_MAJOR, K_VERS_MINOR, K_VERS_REV)
@@ -448,6 +450,8 @@ extern void InitArchiveFmt_Tar(ArchiveHandle *AH);
extern bool isValidTarHeader(char *header);
extern void ReconnectToServer(ArchiveHandle *AH, const char *dbname);
+extern void IssueCommandPerBlob(ArchiveHandle *AH, TocEntry *te,
+ const char *cmdBegin, const char *cmdEnd);
extern void DropLOIfExists(ArchiveHandle *AH, Oid oid);
void ahwrite(const void *ptr, size_t size, size_t nmemb, ArchiveHandle *AH);
diff --git a/src/bin/pg_dump/pg_backup_custom.c b/src/bin/pg_dump/pg_backup_custom.c
index 7c6ac89dd4..55107b2005 100644
--- a/src/bin/pg_dump/pg_backup_custom.c
+++ b/src/bin/pg_dump/pg_backup_custom.c
@@ -338,7 +338,7 @@ _EndData(ArchiveHandle *AH, TocEntry *te)
}
/*
- * Called by the archiver when starting to save all BLOB DATA (not schema).
+ * Called by the archiver when starting to save BLOB DATA (not schema).
* This routine should save whatever format-specific information is needed
* to read the LOs back into memory.
*
@@ -398,7 +398,7 @@ _EndLO(ArchiveHandle *AH, TocEntry *te, Oid oid)
}
/*
- * Called by the archiver when finishing saving all BLOB DATA.
+ * Called by the archiver when finishing saving BLOB DATA.
*
* Optional.
*/
diff --git a/src/bin/pg_dump/pg_backup_db.c b/src/bin/pg_dump/pg_backup_db.c
index b297ca049d..c14d813b21 100644
--- a/src/bin/pg_dump/pg_backup_db.c
+++ b/src/bin/pg_dump/pg_backup_db.c
@@ -541,6 +541,33 @@ CommitTransaction(Archive *AHX)
ExecuteSqlCommand(AH, "COMMIT", "could not commit database transaction");
}
+/*
+ * Issue per-blob commands for the large object(s) listed in the TocEntry
+ *
+ * The TocEntry's defn string is assumed to consist of large object OIDs,
+ * one per line. Wrap these in the given SQL command fragments and issue
+ * the commands. (cmdEnd need not include a semicolon.)
+ */
+void
+IssueCommandPerBlob(ArchiveHandle *AH, TocEntry *te,
+ const char *cmdBegin, const char *cmdEnd)
+{
+ /* Make a writable copy of the command string */
+ char *buf = pg_strdup(te->defn);
+ char *st;
+ char *en;
+
+ st = buf;
+ while ((en = strchr(st, '\n')) != NULL)
+ {
+ *en++ = '\0';
+ ahprintf(AH, "%s%s%s;\n", cmdBegin, st, cmdEnd);
+ st = en;
+ }
+ ahprintf(AH, "\n");
+ pg_free(buf);
+}
+
void
DropLOIfExists(ArchiveHandle *AH, Oid oid)
{
diff --git a/src/bin/pg_dump/pg_backup_directory.c b/src/bin/pg_dump/pg_backup_directory.c
index de3cfea02e..7be8d5487d 100644
--- a/src/bin/pg_dump/pg_backup_directory.c
+++ b/src/bin/pg_dump/pg_backup_directory.c
@@ -5,8 +5,10 @@
* A directory format dump is a directory, which contains a "toc.dat" file
* for the TOC, and a separate file for each data entry, named "<oid>.dat".
* Large objects are stored in separate files named "blob_<oid>.dat",
- * and there's a plain-text TOC file for them called "blobs.toc". If
- * compression is used, each data file is individually compressed and the
+ * and there's a plain-text TOC file for each BLOBS TOC entry named
+ * "blobs_<dumpID>.toc" (or just "blobs.toc" in archive versions before 16).
+ *
+ * If compression is used, each data file is individually compressed and the
* ".gz" suffix is added to the filenames. The TOC files are never
* compressed by pg_dump, however they are accepted with the .gz suffix too,
* in case the user has manually compressed them with 'gzip'.
@@ -51,7 +53,7 @@ typedef struct
char *directory;
CompressFileHandle *dataFH; /* currently open data file */
- CompressFileHandle *LOsTocFH; /* file handle for blobs.toc */
+ CompressFileHandle *LOsTocFH; /* file handle for blobs_NNN.toc */
ParallelState *pstate; /* for parallel backup / restore */
} lclContext;
@@ -81,7 +83,7 @@ static void _StartLOs(ArchiveHandle *AH, TocEntry *te);
static void _StartLO(ArchiveHandle *AH, TocEntry *te, Oid oid);
static void _EndLO(ArchiveHandle *AH, TocEntry *te, Oid oid);
static void _EndLOs(ArchiveHandle *AH, TocEntry *te);
-static void _LoadLOs(ArchiveHandle *AH);
+static void _LoadLOs(ArchiveHandle *AH, TocEntry *te);
static void _PrepParallelRestore(ArchiveHandle *AH);
static void _Clone(ArchiveHandle *AH);
@@ -232,7 +234,10 @@ _ArchiveEntry(ArchiveHandle *AH, TocEntry *te)
tctx = (lclTocEntry *) pg_malloc0(sizeof(lclTocEntry));
if (strcmp(te->desc, "BLOBS") == 0)
- tctx->filename = pg_strdup("blobs.toc");
+ {
+ snprintf(fn, MAXPGPATH, "blobs_%d.toc", te->dumpId);
+ tctx->filename = pg_strdup(fn);
+ }
else if (te->dataDumper)
{
snprintf(fn, MAXPGPATH, "%d.dat", te->dumpId);
@@ -415,7 +420,7 @@ _PrintTocData(ArchiveHandle *AH, TocEntry *te)
return;
if (strcmp(te->desc, "BLOBS") == 0)
- _LoadLOs(AH);
+ _LoadLOs(AH, te);
else
{
char fname[MAXPGPATH];
@@ -426,17 +431,23 @@ _PrintTocData(ArchiveHandle *AH, TocEntry *te)
}
static void
-_LoadLOs(ArchiveHandle *AH)
+_LoadLOs(ArchiveHandle *AH, TocEntry *te)
{
Oid oid;
lclContext *ctx = (lclContext *) AH->formatData;
+ lclTocEntry *tctx = (lclTocEntry *) te->formatData;
CompressFileHandle *CFH;
char tocfname[MAXPGPATH];
char line[MAXPGPATH];
StartRestoreLOs(AH);
- setFilePath(AH, tocfname, "blobs.toc");
+ /*
+ * Note: before archive v16, there was always only one BLOBS TOC entry,
+ * now there can be multiple. We don't need to worry what version we are
+ * reading though, because tctx->filename should be correct either way.
+ */
+ setFilePath(AH, tocfname, tctx->filename);
CFH = ctx->LOsTocFH = InitDiscoverCompressFileHandle(tocfname, PG_BINARY_R);
@@ -632,7 +643,7 @@ _ReopenArchive(ArchiveHandle *AH)
*/
/*
- * Called by the archiver when starting to save all BLOB DATA (not schema).
+ * Called by the archiver when starting to save BLOB DATA (not schema).
* It is called just prior to the dumper's DataDumper routine.
*
* We open the large object TOC file here, so that we can append a line to
@@ -642,10 +653,11 @@ static void
_StartLOs(ArchiveHandle *AH, TocEntry *te)
{
lclContext *ctx = (lclContext *) AH->formatData;
+ lclTocEntry *tctx = (lclTocEntry *) te->formatData;
pg_compress_specification compression_spec = {0};
char fname[MAXPGPATH];
- setFilePath(AH, fname, "blobs.toc");
+ setFilePath(AH, fname, tctx->filename);
/* The LO TOC file is never compressed */
compression_spec.algorithm = PG_COMPRESSION_NONE;
@@ -690,7 +702,7 @@ _EndLO(ArchiveHandle *AH, TocEntry *te, Oid oid)
pg_fatal("could not close LO data file: %m");
ctx->dataFH = NULL;
- /* register the LO in blobs.toc */
+ /* register the LO in blobs_NNN.toc */
len = snprintf(buf, sizeof(buf), "%u blob_%u.dat\n", oid, oid);
if (!CFH->write_func(buf, len, CFH))
{
@@ -703,7 +715,7 @@ _EndLO(ArchiveHandle *AH, TocEntry *te, Oid oid)
}
/*
- * Called by the archiver when finishing saving all BLOB DATA.
+ * Called by the archiver when finishing saving BLOB DATA.
*
* We close the LOs TOC file.
*/
@@ -795,7 +807,7 @@ _PrepParallelRestore(ArchiveHandle *AH)
}
/*
- * If this is the BLOBS entry, what we stat'd was blobs.toc, which
+ * If this is a BLOBS entry, what we stat'd was blobs_NNN.toc, which
* most likely is a lot smaller than the actual blob data. We don't
* have a cheap way to estimate how much smaller, but fortunately it
* doesn't matter too much as long as we get the LOs processed
diff --git a/src/bin/pg_dump/pg_backup_null.c b/src/bin/pg_dump/pg_backup_null.c
index 776f057770..a3257f4fc8 100644
--- a/src/bin/pg_dump/pg_backup_null.c
+++ b/src/bin/pg_dump/pg_backup_null.c
@@ -113,7 +113,7 @@ _EndData(ArchiveHandle *AH, TocEntry *te)
}
/*
- * Called by the archiver when starting to save all BLOB DATA (not schema).
+ * Called by the archiver when starting to save BLOB DATA (not schema).
* This routine should save whatever format-specific information is needed
* to read the LOs back into memory.
*
@@ -170,7 +170,7 @@ _EndLO(ArchiveHandle *AH, TocEntry *te, Oid oid)
}
/*
- * Called by the archiver when finishing saving all BLOB DATA.
+ * Called by the archiver when finishing saving BLOB DATA.
*
* Optional.
*/
diff --git a/src/bin/pg_dump/pg_backup_tar.c b/src/bin/pg_dump/pg_backup_tar.c
index 4cb9707e63..41ee52b1d6 100644
--- a/src/bin/pg_dump/pg_backup_tar.c
+++ b/src/bin/pg_dump/pg_backup_tar.c
@@ -94,7 +94,7 @@ typedef struct
char *filename;
} lclTocEntry;
-static void _LoadLOs(ArchiveHandle *AH);
+static void _LoadLOs(ArchiveHandle *AH, TocEntry *te);
static TAR_MEMBER *tarOpen(ArchiveHandle *AH, const char *filename, char mode);
static void tarClose(ArchiveHandle *AH, TAR_MEMBER *th);
@@ -634,13 +634,13 @@ _PrintTocData(ArchiveHandle *AH, TocEntry *te)
}
if (strcmp(te->desc, "BLOBS") == 0)
- _LoadLOs(AH);
+ _LoadLOs(AH, te);
else
_PrintFileData(AH, tctx->filename);
}
static void
-_LoadLOs(ArchiveHandle *AH)
+_LoadLOs(ArchiveHandle *AH, TocEntry *te)
{
Oid oid;
lclContext *ctx = (lclContext *) AH->formatData;
@@ -651,7 +651,26 @@ _LoadLOs(ArchiveHandle *AH)
StartRestoreLOs(AH);
- th = tarOpen(AH, NULL, 'r'); /* Open next file */
+ /*
+ * The blobs_NNN.toc or blobs.toc file is fairly useless to us because it
+ * will appear only after the associated blob_NNN.dat files. For archive
+ * versions >= 16 we can look at the BLOBS entry's te->tag to discover the
+ * OID of the first blob we want to restore, and then search forward to
+ * find the appropriate blob_<oid>.dat file. For older versions we rely
+ * on the knowledge that there was only one BLOBS entry and just search
+ * for the first blob_<oid>.dat file. Once we find the first blob file to
+ * restore, restore all blobs until we reach the blobs[_NNN].toc file.
+ */
+ if (AH->version >= K_VERS_1_16)
+ {
+ /* We rely on atooid to not complain about nnnn..nnnn tags */
+ oid = atooid(te->tag);
+ snprintf(buf, sizeof(buf), "blob_%u.dat", oid);
+ th = tarOpen(AH, buf, 'r'); /* Advance to first desired file */
+ }
+ else
+ th = tarOpen(AH, NULL, 'r'); /* Open next file */
+
while (th != NULL)
{
ctx->FH = th;
@@ -681,9 +700,9 @@ _LoadLOs(ArchiveHandle *AH)
/*
* Once we have found the first LO, stop at the first non-LO entry
- * (which will be 'blobs.toc'). This coding would eat all the
- * rest of the archive if there are no LOs ... but this function
- * shouldn't be called at all in that case.
+ * (which will be 'blobs[_NNN].toc'). This coding would eat all
+ * the rest of the archive if there are no LOs ... but this
+ * function shouldn't be called at all in that case.
*/
if (foundLO)
break;
@@ -847,7 +866,7 @@ _scriptOut(ArchiveHandle *AH, const void *buf, size_t len)
*/
/*
- * Called by the archiver when starting to save all BLOB DATA (not schema).
+ * Called by the archiver when starting to save BLOB DATA (not schema).
* This routine should save whatever format-specific information is needed
* to read the LOs back into memory.
*
@@ -862,7 +881,7 @@ _StartLOs(ArchiveHandle *AH, TocEntry *te)
lclContext *ctx = (lclContext *) AH->formatData;
char fname[K_STD_BUF_SIZE];
- sprintf(fname, "blobs.toc");
+ sprintf(fname, "blobs_%d.toc", te->dumpId);
ctx->loToc = tarOpen(AH, fname, 'w');
}
@@ -908,7 +927,7 @@ _EndLO(ArchiveHandle *AH, TocEntry *te, Oid oid)
}
/*
- * Called by the archiver when finishing saving all BLOB DATA.
+ * Called by the archiver when finishing saving BLOB DATA.
*
* Optional.
*
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index a19443becd..0245b22ef0 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -160,6 +160,13 @@ static int nseclabels = 0;
*/
#define DUMP_DEFAULT_ROWS_PER_INSERT 1
+/*
+ * Maximum number of large objects to group into a single ArchiveEntry.
+ * At some point we might want to make this user-controllable, but for now
+ * a hard-wired setting will suffice.
+ */
+#define MAX_BLOBS_PER_ARCHIVE_ENTRY 1000
+
/*
* Macro for producing quoted, schema-qualified name of a dumpable object.
*/
@@ -3581,11 +3588,10 @@ getLOs(Archive *fout)
{
DumpOptions *dopt = fout->dopt;
PQExpBuffer loQry = createPQExpBuffer();
- LoInfo *loinfo;
- DumpableObject *lodata;
PGresult *res;
int ntups;
int i;
+ int n;
int i_oid;
int i_lomowner;
int i_lomacl;
@@ -3593,11 +3599,15 @@ getLOs(Archive *fout)
pg_log_info("reading large objects");
- /* Fetch LO OIDs, and owner/ACL data */
+ /*
+ * Fetch LO OIDs and owner/ACL data. Order the data so that all the blobs
+ * with the same owner/ACL appear together.
+ */
appendPQExpBufferStr(loQry,
"SELECT oid, lomowner, lomacl, "
"acldefault('L', lomowner) AS acldefault "
- "FROM pg_largeobject_metadata");
+ "FROM pg_largeobject_metadata "
+ "ORDER BY lomowner, lomacl::pg_catalog.text, oid");
res = ExecuteSqlQuery(fout, loQry->data, PGRES_TUPLES_OK);
@@ -3609,30 +3619,72 @@ getLOs(Archive *fout)
ntups = PQntuples(res);
/*
- * Each large object has its own "BLOB" archive entry.
+ * Group the blobs into suitably-sized groups that have the same owner and
+ * ACL setting, and build a metadata and a data DumpableObject for each
+ * group. (If we supported initprivs for blobs, we'd have to insist that
+ * groups also share initprivs settings, since the DumpableObject only has
+ * room for one.) i is the index of the first tuple in the current group,
+ * and n is the number of tuples we include in the group.
*/
- loinfo = (LoInfo *) pg_malloc(ntups * sizeof(LoInfo));
+ for (i = 0; i < ntups; i += n)
+ {
+ Oid thisoid = atooid(PQgetvalue(res, i, i_oid));
+ char *thisowner = PQgetvalue(res, i, i_lomowner);
+ char *thisacl = PQgetvalue(res, i, i_lomacl);
+ LoInfo *loinfo;
+ DumpableObject *lodata;
+ char namebuf[64];
+
+ /* Scan to find first tuple not to be included in group */
+ n = 1;
+ while (n < MAX_BLOBS_PER_ARCHIVE_ENTRY && i + n < ntups)
+ {
+ if (strcmp(thisowner, PQgetvalue(res, i + n, i_lomowner)) != 0 ||
+ strcmp(thisacl, PQgetvalue(res, i + n, i_lomacl)) != 0)
+ break;
+ n++;
+ }
- for (i = 0; i < ntups; i++)
- {
- loinfo[i].dobj.objType = DO_LARGE_OBJECT;
- loinfo[i].dobj.catId.tableoid = LargeObjectRelationId;
- loinfo[i].dobj.catId.oid = atooid(PQgetvalue(res, i, i_oid));
- AssignDumpId(&loinfo[i].dobj);
+ /* Build the metadata DumpableObject */
+ loinfo = (LoInfo *) pg_malloc(offsetof(LoInfo, looids) + n * sizeof(Oid));
+
+ loinfo->dobj.objType = DO_LARGE_OBJECT;
+ loinfo->dobj.catId.tableoid = LargeObjectRelationId;
+ loinfo->dobj.catId.oid = thisoid;
+ AssignDumpId(&loinfo->dobj);
+
+ if (n > 1)
+ snprintf(namebuf, sizeof(namebuf), "%u..%u", thisoid,
+ atooid(PQgetvalue(res, i + n - 1, i_oid)));
+ else
+ snprintf(namebuf, sizeof(namebuf), "%u", thisoid);
+ loinfo->dobj.name = pg_strdup(namebuf);
+ loinfo->dacl.acl = pg_strdup(thisacl);
+ loinfo->dacl.acldefault = pg_strdup(PQgetvalue(res, i, i_acldefault));
+ loinfo->dacl.privtype = 0;
+ loinfo->dacl.initprivs = NULL;
+ loinfo->rolname = getRoleName(thisowner);
+ loinfo->numlos = n;
+ loinfo->looids[0] = thisoid;
+ /* Collect OIDs of the remaining blobs in this group */
+ for (int k = 1; k < n; k++)
+ {
+ CatalogId extraID;
+
+ loinfo->looids[k] = atooid(PQgetvalue(res, i + k, i_oid));
- loinfo[i].dobj.name = pg_strdup(PQgetvalue(res, i, i_oid));
- loinfo[i].dacl.acl = pg_strdup(PQgetvalue(res, i, i_lomacl));
- loinfo[i].dacl.acldefault = pg_strdup(PQgetvalue(res, i, i_acldefault));
- loinfo[i].dacl.privtype = 0;
- loinfo[i].dacl.initprivs = NULL;
- loinfo[i].rolname = getRoleName(PQgetvalue(res, i, i_lomowner));
+ /* Make sure we can look up loinfo by any of the blobs' OIDs */
+ extraID.tableoid = LargeObjectRelationId;
+ extraID.oid = loinfo->looids[k];
+ recordAdditionalCatalogID(extraID, &loinfo->dobj);
+ }
/* LOs have data */
- loinfo[i].dobj.components |= DUMP_COMPONENT_DATA;
+ loinfo->dobj.components |= DUMP_COMPONENT_DATA;
- /* Mark whether LO has an ACL */
+ /* Mark whether LO group has a non-empty ACL */
if (!PQgetisnull(res, i, i_lomacl))
- loinfo[i].dobj.components |= DUMP_COMPONENT_ACL;
+ loinfo->dobj.components |= DUMP_COMPONENT_ACL;
/*
* In binary-upgrade mode for LOs, we do *not* dump out the LO data,
@@ -3642,21 +3694,22 @@ getLOs(Archive *fout)
* pg_largeobject_metadata, after the dump is restored.
*/
if (dopt->binary_upgrade)
- loinfo[i].dobj.dump &= ~DUMP_COMPONENT_DATA;
- }
+ loinfo->dobj.dump &= ~DUMP_COMPONENT_DATA;
- /*
- * If we have any large objects, a "BLOBS" archive entry is needed. This
- * is just a placeholder for sorting; it carries no data now.
- */
- if (ntups > 0)
- {
+ /*
+ * Create a "BLOBS" data item for the group, too. This is just a
+ * placeholder for sorting; it carries no data now.
+ */
lodata = (DumpableObject *) pg_malloc(sizeof(DumpableObject));
lodata->objType = DO_LARGE_OBJECT_DATA;
lodata->catId = nilCatalogId;
AssignDumpId(lodata);
- lodata->name = pg_strdup("BLOBS");
+ lodata->name = pg_strdup(namebuf);
lodata->components |= DUMP_COMPONENT_DATA;
+ /* Set up explicit dependency from data to metadata */
+ lodata->dependencies = (DumpId *) pg_malloc(sizeof(DumpId));
+ lodata->dependencies[0] = loinfo->dobj.dumpId;
+ lodata->nDeps = lodata->allocDeps = 1;
}
PQclear(res);
@@ -3666,123 +3719,109 @@ getLOs(Archive *fout)
/*
* dumpLO
*
- * dump the definition (metadata) of the given large object
+ * dump the definition (metadata) of the given large object group
*/
static void
dumpLO(Archive *fout, const LoInfo *loinfo)
{
PQExpBuffer cquery = createPQExpBuffer();
- PQExpBuffer dquery = createPQExpBuffer();
- appendPQExpBuffer(cquery,
- "SELECT pg_catalog.lo_create('%s');\n",
- loinfo->dobj.name);
-
- appendPQExpBuffer(dquery,
- "SELECT pg_catalog.lo_unlink('%s');\n",
- loinfo->dobj.name);
+ /*
+ * The "definition" is just a newline-separated list of OIDs. We need to
+ * put something into the dropStmt too, but it can just be a comment.
+ */
+ for (int i = 0; i < loinfo->numlos; i++)
+ appendPQExpBuffer(cquery, "%u\n", loinfo->looids[i]);
if (loinfo->dobj.dump & DUMP_COMPONENT_DEFINITION)
ArchiveEntry(fout, loinfo->dobj.catId, loinfo->dobj.dumpId,
ARCHIVE_OPTS(.tag = loinfo->dobj.name,
.owner = loinfo->rolname,
- .description = "BLOB",
+ .description = "BLOB METADATA",
.section = SECTION_PRE_DATA,
.createStmt = cquery->data,
- .dropStmt = dquery->data));
-
- /* Dump comment if any */
- if (loinfo->dobj.dump & DUMP_COMPONENT_COMMENT)
- dumpComment(fout, "LARGE OBJECT", loinfo->dobj.name,
- NULL, loinfo->rolname,
- loinfo->dobj.catId, 0, loinfo->dobj.dumpId);
-
- /* Dump security label if any */
- if (loinfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
- dumpSecLabel(fout, "LARGE OBJECT", loinfo->dobj.name,
- NULL, loinfo->rolname,
- loinfo->dobj.catId, 0, loinfo->dobj.dumpId);
-
- /* Dump ACL if any */
- if (loinfo->dobj.dump & DUMP_COMPONENT_ACL)
- dumpACL(fout, loinfo->dobj.dumpId, InvalidDumpId, "LARGE OBJECT",
- loinfo->dobj.name, NULL,
- NULL, loinfo->rolname, &loinfo->dacl);
+ .dropStmt = "-- dummy"));
+
+ /*
+ * Dump per-blob comments, seclabels, and ACLs if any. We assume these
+ * are rare enough that it's okay to generate retail TOC entries for them.
+ */
+ if (loinfo->dobj.dump & (DUMP_COMPONENT_COMMENT |
+ DUMP_COMPONENT_SECLABEL |
+ DUMP_COMPONENT_ACL))
+ {
+ for (int i = 0; i < loinfo->numlos; i++)
+ {
+ CatalogId catId;
+ char namebuf[32];
+
+ /* Build identifying info for this blob */
+ catId.tableoid = loinfo->dobj.catId.tableoid;
+ catId.oid = loinfo->looids[i];
+ snprintf(namebuf, sizeof(namebuf), "%u", loinfo->looids[i]);
+
+ if (loinfo->dobj.dump & DUMP_COMPONENT_COMMENT)
+ dumpComment(fout, "LARGE OBJECT", namebuf,
+ NULL, loinfo->rolname,
+ catId, 0, loinfo->dobj.dumpId);
+
+ if (loinfo->dobj.dump & DUMP_COMPONENT_SECLABEL)
+ dumpSecLabel(fout, "LARGE OBJECT", namebuf,
+ NULL, loinfo->rolname,
+ catId, 0, loinfo->dobj.dumpId);
+
+ if (loinfo->dobj.dump & DUMP_COMPONENT_ACL)
+ dumpACL(fout, loinfo->dobj.dumpId, InvalidDumpId,
+ "LARGE OBJECT", namebuf, NULL,
+ NULL, loinfo->rolname, &loinfo->dacl);
+ }
+ }
destroyPQExpBuffer(cquery);
- destroyPQExpBuffer(dquery);
}
/*
* dumpLOs:
- * dump the data contents of all large objects
+ * dump the data contents of the large objects in the given group
*/
static int
dumpLOs(Archive *fout, const void *arg)
{
- const char *loQry;
- const char *loFetchQry;
+ const LoInfo *loinfo = (const LoInfo *) arg;
PGconn *conn = GetConnection(fout);
- PGresult *res;
char buf[LOBBUFSIZE];
- int ntups;
- int i;
- int cnt;
- pg_log_info("saving large objects");
-
- /*
- * Currently, we re-fetch all LO OIDs using a cursor. Consider scanning
- * the already-in-memory dumpable objects instead...
- */
- loQry =
- "DECLARE looid CURSOR FOR "
- "SELECT oid FROM pg_largeobject_metadata ORDER BY 1";
+ pg_log_info("saving large objects \"%s\"", loinfo->dobj.name);
- ExecuteSqlStatement(fout, loQry);
+ for (int i = 0; i < loinfo->numlos; i++)
+ {
+ Oid loOid = loinfo->looids[i];
+ int loFd;
+ int cnt;
- /* Command to fetch from cursor */
- loFetchQry = "FETCH 1000 IN looid";
+ /* Open the LO */
+ loFd = lo_open(conn, loOid, INV_READ);
+ if (loFd == -1)
+ pg_fatal("could not open large object %u: %s",
+ loOid, PQerrorMessage(conn));
- do
- {
- /* Do a fetch */
- res = ExecuteSqlQuery(fout, loFetchQry, PGRES_TUPLES_OK);
+ StartLO(fout, loOid);
- /* Process the tuples, if any */
- ntups = PQntuples(res);
- for (i = 0; i < ntups; i++)
+ /* Now read it in chunks, sending data to archive */
+ do
{
- Oid loOid;
- int loFd;
-
- loOid = atooid(PQgetvalue(res, i, 0));
- /* Open the LO */
- loFd = lo_open(conn, loOid, INV_READ);
- if (loFd == -1)
- pg_fatal("could not open large object %u: %s",
+ cnt = lo_read(conn, loFd, buf, LOBBUFSIZE);
+ if (cnt < 0)
+ pg_fatal("error reading large object %u: %s",
loOid, PQerrorMessage(conn));
- StartLO(fout, loOid);
-
- /* Now read it in chunks, sending data to archive */
- do
- {
- cnt = lo_read(conn, loFd, buf, LOBBUFSIZE);
- if (cnt < 0)
- pg_fatal("error reading large object %u: %s",
- loOid, PQerrorMessage(conn));
+ WriteData(fout, buf, cnt);
+ } while (cnt > 0);
- WriteData(fout, buf, cnt);
- } while (cnt > 0);
+ lo_close(conn, loFd);
- lo_close(conn, loFd);
-
- EndLO(fout, loOid);
- }
-
- PQclear(res);
- } while (ntups > 0);
+ EndLO(fout, loOid);
+ }
return 1;
}
@@ -10595,28 +10634,34 @@ dumpDumpableObject(Archive *fout, DumpableObject *dobj)
case DO_LARGE_OBJECT_DATA:
if (dobj->dump & DUMP_COMPONENT_DATA)
{
+ LoInfo *loinfo;
TocEntry *te;
+ loinfo = (LoInfo *) findObjectByDumpId(dobj->dependencies[0]);
+ if (loinfo == NULL)
+ pg_fatal("missing metadata for large objects \"%s\"",
+ dobj->name);
+
te = ArchiveEntry(fout, dobj->catId, dobj->dumpId,
ARCHIVE_OPTS(.tag = dobj->name,
+ .owner = loinfo->rolname,
.description = "BLOBS",
.section = SECTION_DATA,
- .dumpFn = dumpLOs));
+ .deps = dobj->dependencies,
+ .nDeps = dobj->nDeps,
+ .dumpFn = dumpLOs,
+ .dumpArg = loinfo));
/*
* Set the TocEntry's dataLength in case we are doing a
* parallel dump and want to order dump jobs by table size.
* (We need some size estimate for every TocEntry with a
* DataDumper function.) We don't currently have any cheap
- * way to estimate the size of LOs, but it doesn't matter;
- * let's just set the size to a large value so parallel dumps
- * will launch this job first. If there's lots of LOs, we
- * win, and if there aren't, we don't lose much. (If you want
- * to improve on this, really what you should be thinking
- * about is allowing LO dumping to be parallelized, not just
- * getting a smarter estimate for the single TOC entry.)
+ * way to estimate the size of LOs, but fortunately it doesn't
+ * matter too much as long as we get large batches of LOs
+ * processed reasonably early. Assume 8K per blob.
*/
- te->dataLength = INT_MAX;
+ te->dataLength = loinfo->numlos * (pgoff_t) 8192;
}
break;
case DO_POLICY:
diff --git a/src/bin/pg_dump/pg_dump.h b/src/bin/pg_dump/pg_dump.h
index 93d97a4090..c83e0298ca 100644
--- a/src/bin/pg_dump/pg_dump.h
+++ b/src/bin/pg_dump/pg_dump.h
@@ -583,11 +583,21 @@ typedef struct _defaultACLInfo
char defaclobjtype;
} DefaultACLInfo;
+/*
+ * LoInfo represents a group of large objects (blobs) that share the same
+ * owner and ACL setting. dobj.components has the DUMP_COMPONENT_COMMENT bit
+ * set if any blob in the group has a comment; similarly for sec labels.
+ * If there are many blobs with the same owner/ACL, we can divide them into
+ * multiple LoInfo groups, which will each spawn a BLOB METADATA and a BLOBS
+ * (data) TOC entry. This allows more parallelism during restore.
+ */
typedef struct _loInfo
{
DumpableObject dobj;
DumpableAcl dacl;
const char *rolname;
+ int numlos;
+ Oid looids[FLEXIBLE_ARRAY_MEMBER];
} LoInfo;
/*
@@ -695,6 +705,7 @@ typedef struct _SubRelInfo
extern TableInfo *getSchemaData(Archive *fout, int *numTablesPtr);
extern void AssignDumpId(DumpableObject *dobj);
+extern void recordAdditionalCatalogID(CatalogId catId, DumpableObject *dobj);
extern DumpId createDumpId(void);
extern DumpId getMaxDumpId(void);
extern DumpableObject *findObjectByDumpId(DumpId dumpId);
diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_dump.pl
index 00b5092713..df11724e93 100644
--- a/src/bin/pg_dump/t/002_pg_dump.pl
+++ b/src/bin/pg_dump/t/002_pg_dump.pl
@@ -109,11 +109,11 @@ my %pgdump_runs = (
'--format=directory', '--compress=gzip:1',
"--file=$tempdir/compression_gzip_dir", 'postgres',
],
- # Give coverage for manually compressed blob.toc files during
+ # Give coverage for manually compressed blobs.toc files during
# restore.
compress_cmd => {
program => $ENV{'GZIP_PROGRAM'},
- args => [ '-f', "$tempdir/compression_gzip_dir/blobs.toc", ],
+ args => [ '-f', "$tempdir/compression_gzip_dir/blobs_*.toc", ],
},
# Verify that only data files were compressed
glob_patterns => [
@@ -172,16 +172,6 @@ my %pgdump_runs = (
'--format=directory', '--compress=lz4:1',
"--file=$tempdir/compression_lz4_dir", 'postgres',
],
- # Give coverage for manually compressed blob.toc files during
- # restore.
- compress_cmd => {
- program => $ENV{'LZ4'},
- args => [
- '-z', '-f', '--rm',
- "$tempdir/compression_lz4_dir/blobs.toc",
- "$tempdir/compression_lz4_dir/blobs.toc.lz4",
- ],
- },
# Verify that data files were compressed
glob_patterns => [
"$tempdir/compression_lz4_dir/toc.dat",
@@ -242,14 +232,13 @@ my %pgdump_runs = (
'--format=directory', '--compress=zstd:1',
"--file=$tempdir/compression_zstd_dir", 'postgres',
],
- # Give coverage for manually compressed blob.toc files during
+ # Give coverage for manually compressed blobs.toc files during
# restore.
compress_cmd => {
program => $ENV{'ZSTD'},
args => [
'-z', '-f',
- '--rm', "$tempdir/compression_zstd_dir/blobs.toc",
- "-o", "$tempdir/compression_zstd_dir/blobs.toc.zst",
+ '--rm', "$tempdir/compression_zstd_dir/blobs_*.toc",
],
},
# Verify that data files were compressed
@@ -413,7 +402,7 @@ my %pgdump_runs = (
},
glob_patterns => [
"$tempdir/defaults_dir_format/toc.dat",
- "$tempdir/defaults_dir_format/blobs.toc",
+ "$tempdir/defaults_dir_format/blobs_*.toc",
$supports_gzip ? "$tempdir/defaults_dir_format/*.dat.gz"
: "$tempdir/defaults_dir_format/*.dat",
],
@@ -4858,8 +4847,13 @@ foreach my $run (sort keys %pgdump_runs)
# not defined.
next if (!defined($compress_program) || $compress_program eq '');
- my @full_compress_cmd =
- ($compress_cmd->{program}, @{ $compress_cmd->{args} });
+ # Arguments may require globbing.
+ my @full_compress_cmd = ($compress_program);
+ foreach my $arg (@{ $compress_cmd->{args} })
+ {
+ push @full_compress_cmd, glob($arg);
+ }
+
command_ok(\@full_compress_cmd, "$run: compression commands");
}
--
2.39.3
[text/x-diff] v10-0003-Move-BLOBS-METADATA-TOC-entries-into-SECTION_DAT.patch (3.0K, 4-v10-0003-Move-BLOBS-METADATA-TOC-entries-into-SECTION_DAT.patch)
download | inline diff:
From cc316ccc43c6e7c3b2d1631a5cdc48d57fa26344 Mon Sep 17 00:00:00 2001
From: Tom Lane <[email protected]>
Date: Fri, 26 Jan 2024 11:27:51 -0500
Subject: [PATCH v10 3/4] Move BLOBS METADATA TOC entries into SECTION_DATA.
Commit c0d5be5d6 put the new BLOB metadata TOC entries into
SECTION_PRE_DATA, which perhaps is defensible in some ways,
but it's a rather odd choice considering that we go out of our
way to treat blobs as data. Moreover, because parallel restore
handles the PRE_DATA section serially, this means we're only
getting part of the parallelism speedup we could hope for.
Moving these entries into SECTION_DATA means that we can
parallelize the lo_create calls not only the data loading
when there are many blobs. The dependencies established by
the previous patch ensure that we won't try to load data for
a blob we've not yet created.
---
src/bin/pg_dump/pg_dump.c | 4 ++--
src/bin/pg_dump/t/002_pg_dump.pl | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 0245b22ef0..77d745d55e 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -3738,7 +3738,7 @@ dumpLO(Archive *fout, const LoInfo *loinfo)
ARCHIVE_OPTS(.tag = loinfo->dobj.name,
.owner = loinfo->rolname,
.description = "BLOB METADATA",
- .section = SECTION_PRE_DATA,
+ .section = SECTION_DATA,
.createStmt = cquery->data,
.dropStmt = "-- dummy"));
@@ -18612,12 +18612,12 @@ addBoundaryDependencies(DumpableObject **dobjs, int numObjs,
case DO_FDW:
case DO_FOREIGN_SERVER:
case DO_TRANSFORM:
- case DO_LARGE_OBJECT:
/* Pre-data objects: must come before the pre-data boundary */
addObjectDependency(preDataBound, dobj->dumpId);
break;
case DO_TABLE_DATA:
case DO_SEQUENCE_SET:
+ case DO_LARGE_OBJECT:
case DO_LARGE_OBJECT_DATA:
/* Data objects: must come between the boundaries */
addObjectDependency(dobj, preDataBound->dumpId);
diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_dump.pl
index df11724e93..25b099395a 100644
--- a/src/bin/pg_dump/t/002_pg_dump.pl
+++ b/src/bin/pg_dump/t/002_pg_dump.pl
@@ -912,7 +912,7 @@ my %tests = (
column_inserts => 1,
data_only => 1,
inserts => 1,
- section_pre_data => 1,
+ section_data => 1,
test_schema_plus_large_objects => 1,
},
unlike => {
@@ -1325,7 +1325,7 @@ my %tests = (
column_inserts => 1,
data_only => 1,
inserts => 1,
- section_pre_data => 1,
+ section_data => 1,
test_schema_plus_large_objects => 1,
},
unlike => {
@@ -1533,7 +1533,7 @@ my %tests = (
column_inserts => 1,
data_only => 1,
inserts => 1,
- section_pre_data => 1,
+ section_data => 1,
test_schema_plus_large_objects => 1,
},
unlike => {
@@ -4278,7 +4278,7 @@ my %tests = (
column_inserts => 1,
data_only => 1,
inserts => 1,
- section_pre_data => 1,
+ section_data => 1,
test_schema_plus_large_objects => 1,
binary_upgrade => 1,
},
--
2.39.3
[text/x-diff] v10-0004-Invent-transaction-size-option-for-pg_restore.patch (15.4K, 5-v10-0004-Invent-transaction-size-option-for-pg_restore.patch)
download | inline diff:
From df4c150100416e1c6030221081302d7b274309da Mon Sep 17 00:00:00 2001
From: Tom Lane <[email protected]>
Date: Fri, 26 Jan 2024 11:37:37 -0500
Subject: [PATCH v10 4/4] Invent --transaction-size option for pg_restore.
This patch allows pg_restore to wrap its commands into transaction
blocks, somewhat like --single-transaction, except that we commit
and start a new block after every N objects. Using this mode
with a size limit of 1000 or so objects greatly reduces the number
of transactions consumed by the restore, while preventing any
one transaction from taking enough locks to overrun the receiving
server's shared lock table.
(A value of 1000 works well with the default lock table size of
around 6400 locks. Higher --transaction-size values can be used
if one has increased the receiving server's lock table size.)
In this patch I have just hard-wired pg_upgrade to use
--transaction-size 1000. Perhaps there would be value in adding
another pg_upgrade option to allow user control of that, but I'm
unsure that it's worth the trouble; I think few users would use it,
and any who did would see not that much benefit. However, we
might need to adjust the logic to make the size be 1000 divided
by the number of parallel restore jobs allowed.
---
doc/src/sgml/ref/pg_restore.sgml | 24 +++++
src/bin/pg_dump/pg_backup.h | 4 +-
src/bin/pg_dump/pg_backup_archiver.c | 139 +++++++++++++++++++++++++--
src/bin/pg_dump/pg_backup_archiver.h | 3 +
src/bin/pg_dump/pg_backup_db.c | 18 ++++
src/bin/pg_dump/pg_restore.c | 15 ++-
src/bin/pg_upgrade/pg_upgrade.c | 11 +++
7 files changed, 206 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/ref/pg_restore.sgml b/doc/src/sgml/ref/pg_restore.sgml
index 1a23874da6..2e3ba80258 100644
--- a/doc/src/sgml/ref/pg_restore.sgml
+++ b/doc/src/sgml/ref/pg_restore.sgml
@@ -786,6 +786,30 @@ PostgreSQL documentation
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><option>--transaction-size=<replaceable class="parameter">N</replaceable></option></term>
+ <listitem>
+ <para>
+ Execute the restore as a series of transactions, each processing
+ up to <replaceable class="parameter">N</replaceable> database
+ objects. This option implies <option>--exit-on-error</option>.
+ </para>
+ <para>
+ <option>--transaction-size</option> offers an intermediate choice
+ between the default behavior (one transaction per SQL command)
+ and <option>-1</option>/<option>--single-transaction</option>
+ (one transaction for all restored objects).
+ While <option>--single-transaction</option> has the least
+ overhead, it may be impractical for large databases because the
+ transaction will take a lock on each restored object, possibly
+ exhausting the server's lock table space.
+ Using <option>--transaction-size</option> with a size of a few
+ thousand objects offers nearly the same performance benefits while
+ capping the amount of lock table space needed.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><option>--use-set-session-authorization</option></term>
<listitem>
diff --git a/src/bin/pg_dump/pg_backup.h b/src/bin/pg_dump/pg_backup.h
index 9ef2f2017e..fbf5f1c515 100644
--- a/src/bin/pg_dump/pg_backup.h
+++ b/src/bin/pg_dump/pg_backup.h
@@ -149,7 +149,9 @@ typedef struct _restoreOptions
* compression */
int suppressDumpWarnings; /* Suppress output of WARNING entries
* to stderr */
- bool single_txn;
+
+ bool single_txn; /* restore all TOCs in one transaction */
+ int txn_size; /* restore this many TOCs per txn, if > 0 */
bool *idWanted; /* array showing which dump IDs to emit */
int enable_row_security;
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index 73b9972da4..ec74846998 100644
--- a/src/bin/pg_dump/pg_backup_archiver.c
+++ b/src/bin/pg_dump/pg_backup_archiver.c
@@ -502,7 +502,28 @@ RestoreArchive(Archive *AHX)
/* Otherwise, drop anything that's selected and has a dropStmt */
if (((te->reqs & (REQ_SCHEMA | REQ_DATA)) != 0) && te->dropStmt)
{
+ bool not_allowed_in_txn = false;
+
pg_log_info("dropping %s %s", te->desc, te->tag);
+
+ /*
+ * In --transaction-size mode, we have to temporarily exit our
+ * transaction block to drop objects that can't be dropped
+ * within a transaction.
+ */
+ if (ropt->txn_size > 0)
+ {
+ if (strcmp(te->desc, "DATABASE") == 0 ||
+ strcmp(te->desc, "DATABASE PROPERTIES") == 0)
+ {
+ not_allowed_in_txn = true;
+ if (AH->connection)
+ CommitTransaction(AHX);
+ else
+ ahprintf(AH, "COMMIT;\n");
+ }
+ }
+
/* Select owner and schema as necessary */
_becomeOwner(AH, te);
_selectOutputSchema(AH, te->namespace);
@@ -628,6 +649,33 @@ RestoreArchive(Archive *AHX)
}
}
}
+
+ /*
+ * In --transaction-size mode, re-establish the transaction
+ * block if needed; otherwise, commit after every N drops.
+ */
+ if (ropt->txn_size > 0)
+ {
+ if (not_allowed_in_txn)
+ {
+ if (AH->connection)
+ StartTransaction(AHX);
+ else
+ ahprintf(AH, "BEGIN;\n");
+ AH->txnCount = 0;
+ }
+ else if (++AH->txnCount >= ropt->txn_size)
+ {
+ if (AH->connection)
+ {
+ CommitTransaction(AHX);
+ StartTransaction(AHX);
+ }
+ else
+ ahprintf(AH, "COMMIT;\nBEGIN;\n");
+ AH->txnCount = 0;
+ }
+ }
}
}
@@ -724,7 +772,11 @@ RestoreArchive(Archive *AHX)
}
}
- if (ropt->single_txn)
+ /*
+ * Close out any persistent transaction we may have. While these two
+ * cases are started in different places, we can end both cases here.
+ */
+ if (ropt->single_txn || ropt->txn_size > 0)
{
if (AH->connection)
CommitTransaction(AHX);
@@ -785,6 +837,25 @@ restore_toc_entry(ArchiveHandle *AH, TocEntry *te, bool is_parallel)
*/
if ((reqs & REQ_SCHEMA) != 0)
{
+ bool object_is_db = false;
+
+ /*
+ * In --transaction-size mode, must exit our transaction block to
+ * create a database or set its properties.
+ */
+ if (strcmp(te->desc, "DATABASE") == 0 ||
+ strcmp(te->desc, "DATABASE PROPERTIES") == 0)
+ {
+ object_is_db = true;
+ if (ropt->txn_size > 0)
+ {
+ if (AH->connection)
+ CommitTransaction(&AH->public);
+ else
+ ahprintf(AH, "COMMIT;\n\n");
+ }
+ }
+
/* Show namespace in log message if available */
if (te->namespace)
pg_log_info("creating %s \"%s.%s\"",
@@ -835,10 +906,10 @@ restore_toc_entry(ArchiveHandle *AH, TocEntry *te, bool is_parallel)
/*
* If we created a DB, connect to it. Also, if we changed DB
* properties, reconnect to ensure that relevant GUC settings are
- * applied to our session.
+ * applied to our session. (That also restarts the transaction block
+ * in --transaction-size mode.)
*/
- if (strcmp(te->desc, "DATABASE") == 0 ||
- strcmp(te->desc, "DATABASE PROPERTIES") == 0)
+ if (object_is_db)
{
pg_log_info("connecting to new database \"%s\"", te->tag);
_reconnectToDB(AH, te->tag);
@@ -964,6 +1035,25 @@ restore_toc_entry(ArchiveHandle *AH, TocEntry *te, bool is_parallel)
}
}
+ /*
+ * If we emitted anything for this TOC entry, that counts as one action
+ * against the transaction-size limit. Commit if it's time to.
+ */
+ if ((reqs & (REQ_SCHEMA | REQ_DATA)) != 0 && ropt->txn_size > 0)
+ {
+ if (++AH->txnCount >= ropt->txn_size)
+ {
+ if (AH->connection)
+ {
+ CommitTransaction(&AH->public);
+ StartTransaction(&AH->public);
+ }
+ else
+ ahprintf(AH, "COMMIT;\nBEGIN;\n\n");
+ AH->txnCount = 0;
+ }
+ }
+
if (AH->public.n_errors > 0 && status == WORKER_OK)
status = WORKER_IGNORED_ERRORS;
@@ -1310,7 +1400,12 @@ StartRestoreLOs(ArchiveHandle *AH)
{
RestoreOptions *ropt = AH->public.ropt;
- if (!ropt->single_txn)
+ /*
+ * LOs must be restored within a transaction block, since we need the LO
+ * handle to stay open while we write it. Establish a transaction unless
+ * there's one being used globally.
+ */
+ if (!(ropt->single_txn || ropt->txn_size > 0))
{
if (AH->connection)
StartTransaction(&AH->public);
@@ -1329,7 +1424,7 @@ EndRestoreLOs(ArchiveHandle *AH)
{
RestoreOptions *ropt = AH->public.ropt;
- if (!ropt->single_txn)
+ if (!(ropt->single_txn || ropt->txn_size > 0))
{
if (AH->connection)
CommitTransaction(&AH->public);
@@ -3170,6 +3265,19 @@ _doSetFixedOutputState(ArchiveHandle *AH)
else
ahprintf(AH, "SET row_security = off;\n");
+ /*
+ * In --transaction-size mode, we should always be in a transaction when
+ * we begin to restore objects.
+ */
+ if (ropt && ropt->txn_size > 0)
+ {
+ if (AH->connection)
+ StartTransaction(&AH->public);
+ else
+ ahprintf(AH, "\nBEGIN;\n");
+ AH->txnCount = 0;
+ }
+
ahprintf(AH, "\n");
}
@@ -4033,6 +4141,14 @@ restore_toc_entries_prefork(ArchiveHandle *AH, TocEntry *pending_list)
}
}
+ /*
+ * In --transaction-size mode, we must commit the open transaction before
+ * dropping the database connection. This also ensures that child workers
+ * can see the objects we've created so far.
+ */
+ if (AH->public.ropt->txn_size > 0)
+ CommitTransaction(&AH->public);
+
/*
* Now close parent connection in prep for parallel steps. We do this
* mainly to ensure that we don't exceed the specified number of parallel
@@ -4772,6 +4888,10 @@ CloneArchive(ArchiveHandle *AH)
clone = (ArchiveHandle *) pg_malloc(sizeof(ArchiveHandle));
memcpy(clone, AH, sizeof(ArchiveHandle));
+ /* Likewise flat-copy the RestoreOptions, so we can alter them locally */
+ clone->public.ropt = (RestoreOptions *) pg_malloc(sizeof(RestoreOptions));
+ memcpy(clone->public.ropt, AH->public.ropt, sizeof(RestoreOptions));
+
/* Handle format-independent fields */
memset(&(clone->sqlparse), 0, sizeof(clone->sqlparse));
@@ -4793,6 +4913,13 @@ CloneArchive(ArchiveHandle *AH)
/* clones should not share lo_buf */
clone->lo_buf = NULL;
+ /*
+ * Clone connections disregard --transaction-size; they must commit after
+ * each command so that the results are immediately visible to other
+ * workers.
+ */
+ clone->public.ropt->txn_size = 0;
+
/*
* Connect our new clone object to the database, using the same connection
* parameters used for the original connection.
diff --git a/src/bin/pg_dump/pg_backup_archiver.h b/src/bin/pg_dump/pg_backup_archiver.h
index e4dd395582..1b9f142dea 100644
--- a/src/bin/pg_dump/pg_backup_archiver.h
+++ b/src/bin/pg_dump/pg_backup_archiver.h
@@ -324,6 +324,9 @@ struct _archiveHandle
char *currTablespace; /* current tablespace, or NULL */
char *currTableAm; /* current table access method, or NULL */
+ /* in --transaction-size mode, this counts objects emitted in cur xact */
+ int txnCount;
+
void *lo_buf;
size_t lo_buf_used;
size_t lo_buf_size;
diff --git a/src/bin/pg_dump/pg_backup_db.c b/src/bin/pg_dump/pg_backup_db.c
index c14d813b21..6b3bf174f2 100644
--- a/src/bin/pg_dump/pg_backup_db.c
+++ b/src/bin/pg_dump/pg_backup_db.c
@@ -554,6 +554,7 @@ IssueCommandPerBlob(ArchiveHandle *AH, TocEntry *te,
{
/* Make a writable copy of the command string */
char *buf = pg_strdup(te->defn);
+ RestoreOptions *ropt = AH->public.ropt;
char *st;
char *en;
@@ -562,6 +563,23 @@ IssueCommandPerBlob(ArchiveHandle *AH, TocEntry *te,
{
*en++ = '\0';
ahprintf(AH, "%s%s%s;\n", cmdBegin, st, cmdEnd);
+
+ /* In --transaction-size mode, count each command as an action */
+ if (ropt && ropt->txn_size > 0)
+ {
+ if (++AH->txnCount >= ropt->txn_size)
+ {
+ if (AH->connection)
+ {
+ CommitTransaction(&AH->public);
+ StartTransaction(&AH->public);
+ }
+ else
+ ahprintf(AH, "COMMIT;\nBEGIN;\n\n");
+ AH->txnCount = 0;
+ }
+ }
+
st = en;
}
ahprintf(AH, "\n");
diff --git a/src/bin/pg_dump/pg_restore.c b/src/bin/pg_dump/pg_restore.c
index c3beacdec1..5ea78cf7cc 100644
--- a/src/bin/pg_dump/pg_restore.c
+++ b/src/bin/pg_dump/pg_restore.c
@@ -120,6 +120,7 @@ main(int argc, char **argv)
{"role", required_argument, NULL, 2},
{"section", required_argument, NULL, 3},
{"strict-names", no_argument, &strict_names, 1},
+ {"transaction-size", required_argument, NULL, 5},
{"use-set-session-authorization", no_argument, &use_setsessauth, 1},
{"no-comments", no_argument, &no_comments, 1},
{"no-publications", no_argument, &no_publications, 1},
@@ -289,10 +290,18 @@ main(int argc, char **argv)
set_dump_section(optarg, &(opts->dumpSections));
break;
- case 4:
+ case 4: /* filter */
read_restore_filters(optarg, opts);
break;
+ case 5: /* transaction-size */
+ if (!option_parse_int(optarg, "--transaction-size",
+ 1, INT_MAX,
+ &opts->txn_size))
+ exit(1);
+ opts->exit_on_error = true;
+ break;
+
default:
/* getopt_long already emitted a complaint */
pg_log_error_hint("Try \"%s --help\" for more information.", progname);
@@ -337,6 +346,9 @@ main(int argc, char **argv)
if (opts->dataOnly && opts->dropSchema)
pg_fatal("options -c/--clean and -a/--data-only cannot be used together");
+ if (opts->single_txn && opts->txn_size > 0)
+ pg_fatal("options -1/--single-transaction and --transaction-size cannot be used together");
+
/*
* -C is not compatible with -1, because we can't create a database inside
* a transaction block.
@@ -484,6 +496,7 @@ usage(const char *progname)
printf(_(" --section=SECTION restore named section (pre-data, data, or post-data)\n"));
printf(_(" --strict-names require table and/or schema include patterns to\n"
" match at least one entity each\n"));
+ printf(_(" --transaction-size=N commit after every N objects\n"));
printf(_(" --use-set-session-authorization\n"
" use SET SESSION AUTHORIZATION commands instead of\n"
" ALTER OWNER commands to set ownership\n"));
diff --git a/src/bin/pg_upgrade/pg_upgrade.c b/src/bin/pg_upgrade/pg_upgrade.c
index 10c94a6c1f..6a698e0c87 100644
--- a/src/bin/pg_upgrade/pg_upgrade.c
+++ b/src/bin/pg_upgrade/pg_upgrade.c
@@ -51,6 +51,13 @@
#include "fe_utils/string_utils.h"
#include "pg_upgrade.h"
+/*
+ * Maximum number of pg_restore actions (TOC entries) to process within one
+ * transaction. At some point we might want to make this user-controllable,
+ * but for now a hard-wired setting will suffice.
+ */
+#define RESTORE_TRANSACTION_SIZE 1000
+
static void set_locale_and_encoding(void);
static void prepare_new_cluster(void);
static void prepare_new_globals(void);
@@ -548,10 +555,12 @@ create_new_objects(void)
true,
true,
"\"%s/pg_restore\" %s %s --exit-on-error --verbose "
+ "--transaction-size=%d "
"--dbname postgres \"%s/%s\"",
new_cluster.bindir,
cluster_conn_opts(&new_cluster),
create_opts,
+ RESTORE_TRANSACTION_SIZE,
log_opts.dumpdir,
sql_file_name);
@@ -586,10 +595,12 @@ create_new_objects(void)
parallel_exec_prog(log_file_name,
NULL,
"\"%s/pg_restore\" %s %s --exit-on-error --verbose "
+ "--transaction-size=%d "
"--dbname template1 \"%s/%s\"",
new_cluster.bindir,
cluster_conn_opts(&new_cluster),
create_opts,
+ RESTORE_TRANSACTION_SIZE,
log_opts.dumpdir,
sql_file_name);
}
--
2.39.3
^ permalink raw reply [nested|flat] 49+ messages in thread
* Re: pg_upgrade failing for 200+ million Large Objects
@ 2026-03-23 19:47 PP L <[email protected]>
0 siblings, 0 replies; 49+ messages in thread
From: PP L @ 2026-03-23 19:47 UTC (permalink / raw)
To: Alexander Korotkov <[email protected]>; Tom Lane <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Nathan Bossart <[email protected]>; Michael Banck <[email protected]>; Laurenz Albe <[email protected]>; vignesh C <[email protected]>; Kumar, Sachin <[email protected]>; Robins Tharakan <[email protected]>; Jan Wieck <[email protected]>; Bruce Momjian <[email protected]>; Andrew Dunstan <[email protected]>; Magnus Hagander <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
Hello hackers,
I wanted to revive this thread specifically around the attislocal
optimization discussion. As part of
https://github.com/postgres/postgres/commit/b3f0e0503f3, we now batch all
the attislocal UPDATEs together, hence making it more performant.
I think we might be able to go one step further and completely skip the
attislocal UPDATE for partition tables. This is because the attislocal
UPDATE is done immediately after 'CREATE TABLE', during the 'ATTACH
PARTITION' step(see attislocal being set to false in
MergeAttributesIntoExisting). The UPDATEs emitted by pg_dump are therefore
redundant. Even with batching, the single UPDATE still modifies N(no of
columns) rows causing N relcache invalidations. This same workflow is then
repeated by ATTACH PARTITION causing another N relcache invalidations.
Skipping the attislocal UPDATE definitely speeds up the runtime if there
are a lot of partition tables because we will avoid quite a lot of relcache
invalidations and rebuild calls. Since this optimization removes the
attislocal UPDATE completely, the effect will be even more pronounced for
wider partition tables.
There's already precedent for this:
* attinhcount is never explicitly set by pg_dump. It is only modified by
MergeAttributesIntoExisting during ATTACH PARTITION
* conislocal for CHECK constraints is explicitly not fixed for partitions.
See comment "No need to fix conislocal: ATTACH PARTITION does that" in
dumpTableSchema
The only risk I can foresee is the window between CREATE TABLE and ATTACH
PARTITION where attislocal will be incorrectly set to true. But I think
this window is small enough to not worry about since ATTACH PARTITION
immediately succeeds CREATE TABLE(maybe barring some other minor updates)
Here is a simple patch
```
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 137161aa5e0..d3d7403228a 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -17734,7 +17734,8 @@ dumpTableSchema(Archive *fout, const TableInfo
*tbinfo)
for (j = 0; j < tbinfo->numatts; j++)
{
if (!tbinfo->attisdropped[j] &&
- !tbinfo->attislocal[j])
+ !tbinfo->attislocal[j] &&
+ !tbinfo->ispartition)
{
if (firstitem)
{
```
I tried a few experiments on my local macbook and noticed an improvement of
around ~33-36% (% can vary mostly depending on the number of columns)
Setup(master branch): 300 partitioned root tables with 200 leaves each =
60000 partition tables
300 columns per partition:
baseline : ~30 mins
with patch : ~20 mins (~33% faster)
700 columns per partition:
baseline : ~66 mins
with patch : ~42 mins (~36% faster)
Thanks
Nikhil
Broadcom Inc.
On Mon, 23 Mar 2026 at 11:50, Alexander Korotkov <[email protected]>
wrote:
> On Mon, Jul 29, 2024 at 12:24 AM Tom Lane <[email protected]> wrote:
> > So I'm forced to the conclusion that we'd better make the transaction
> > size adaptive as per Alexander's suggestion.
> >
> > In addition to the patches attached, I experimented with making
> > dumpTableSchema fold all the ALTER TABLE commands for a single table
> > into one command. That's do-able without too much effort, but I'm now
> > convinced that we shouldn't. It would break the semicolon-counting
> > hack for detecting that tables like these involve extra work.
> > I'm also not very confident that the backend won't have trouble with
> > ALTER TABLE commands containing hundreds of subcommands. That's
> > something we ought to work on probably, but it's not a project that
> > I want to condition v17 pg_upgrade's stability on.
> >
> > Anyway, proposed patches attached. 0001 is some trivial cleanup
> > that I noticed while working on the failed single-ALTER-TABLE idea.
> > 0002 merges the catalog-UPDATE commands that dumpTableSchema issues,
> > and 0003 is Alexander's suggestion.
>
> Nice to see you picked up my idea. I took a look over the patchset.
> Looks good to me.
>
> ------
> Regards,
> Alexander Korotkov
> Supabase
>
>
>
>
>
^ permalink raw reply [nested|flat] 49+ messages in thread
end of thread, other threads:[~2026-03-23 19:47 UTC | newest]
Thread overview: 49+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-03-03 11:36 pg_upgrade failing for 200+ million Large Objects Tharakan, Robins <[email protected]>
2021-03-09 20:08 ` Justin Pryzby <[email protected]>
2021-03-07 08:43 RE: pg_upgrade failing for 200+ million Large Objects Tharakan, Robins <[email protected]>
2021-03-07 22:41 ` Daniel Gustafsson <[email protected]>
2021-03-08 10:25 ` Peter Eisentraut <[email protected]>
2021-03-08 11:00 RE: pg_upgrade failing for 200+ million Large Objects Tharakan, Robins <[email protected]>
2021-03-08 11:02 Re: pg_upgrade failing for 200+ million Large Objects Tharakan, Robins <[email protected]>
2021-03-08 12:33 ` Magnus Hagander <[email protected]>
2021-03-08 14:13 ` Robins Tharakan <[email protected]>
2021-03-08 16:33 ` Tom Lane <[email protected]>
2021-03-08 16:35 ` Magnus Hagander <[email protected]>
2021-03-08 16:58 ` Tom Lane <[email protected]>
2021-03-08 17:18 ` Magnus Hagander <[email protected]>
2021-03-20 04:39 ` Jan Wieck <[email protected]>
2021-03-20 15:17 ` Andrew Dunstan <[email protected]>
2021-03-20 15:23 ` Tom Lane <[email protected]>
2021-03-20 16:45 ` Bruce Momjian <[email protected]>
2021-03-20 16:53 ` Tom Lane <[email protected]>
2021-03-20 16:55 ` Jan Wieck <[email protected]>
2021-03-21 11:47 ` Andrew Dunstan <[email protected]>
2021-03-21 16:56 ` Jan Wieck <[email protected]>
2021-03-21 18:18 ` Andrew Dunstan <[email protected]>
2021-03-22 21:36 ` Zhihong Yu <[email protected]>
2021-03-22 23:18 ` Jan Wieck <[email protected]>
2021-03-23 12:51 ` Jan Wieck <[email protected]>
2021-03-23 14:56 ` Bruce Momjian <[email protected]>
2021-03-23 17:25 ` Jan Wieck <[email protected]>
2021-03-23 18:06 ` Bruce Momjian <[email protected]>
2021-03-23 18:23 ` Jan Wieck <[email protected]>
2021-03-23 18:25 ` Bruce Momjian <[email protected]>
2021-03-23 18:35 ` Tom Lane <[email protected]>
2021-03-23 18:54 ` Jan Wieck <[email protected]>
2021-03-23 18:59 ` Tom Lane <[email protected]>
2021-03-23 19:22 ` Jan Wieck <[email protected]>
2021-03-23 19:35 ` Tom Lane <[email protected]>
2021-03-23 19:59 ` Jan Wieck <[email protected]>
2021-03-23 20:55 ` Tom Lane <[email protected]>
2021-03-24 16:04 ` Jan Wieck <[email protected]>
2021-03-24 16:05 ` Jan Wieck <[email protected]>
2021-12-11 22:43 ` Justin Pryzby <[email protected]>
2022-08-25 00:32 ` Nathan Bossart <[email protected]>
2022-09-07 21:42 ` Jacob Champion <[email protected]>
2022-09-08 23:18 ` Nathan Bossart <[email protected]>
2022-09-08 23:29 ` Jacob Champion <[email protected]>
2022-09-08 23:34 ` Nathan Bossart <[email protected]>
2022-10-12 05:50 ` Michael Paquier <[email protected]>
2024-01-26 14:42 ` vignesh C <[email protected]>
2024-01-26 16:44 ` Tom Lane <[email protected]>
2026-03-23 19:47 Re: pg_upgrade failing for 200+ million Large Objects PP L <[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