public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 6/7] pg_restore: "must be specified" and --list 2+ messages / 2 participants [nested] [flat]
* [PATCH 6/7] pg_restore: "must be specified" and --list @ 2020-12-06 04:43 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Justin Pryzby @ 2020-12-06 04:43 UTC (permalink / raw) This was discussed here, but the idea got lost. https://www.postgresql.org/message-id/flat/20190612170201.GA11881%40alvherre.pgsql#2984347ab074e6f19... --- src/bin/pg_dump/pg_restore.c | 2 +- src/bin/pg_dump/t/001_basic.pl | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/bin/pg_dump/pg_restore.c b/src/bin/pg_dump/pg_restore.c index 589b4aed53..f6e6e41329 100644 --- a/src/bin/pg_dump/pg_restore.c +++ b/src/bin/pg_dump/pg_restore.c @@ -305,7 +305,7 @@ main(int argc, char **argv) /* Complain if neither -f nor -d was specified (except if dumping TOC) */ if (!opts->cparams.dbname && !opts->filename && !opts->tocSummary) { - pg_log_error("one of -d/--dbname and -f/--file must be specified"); + pg_log_error("one of -d/--dbname, -f/--file, or -l/--list must be specified"); exit_nicely(1); } diff --git a/src/bin/pg_dump/t/001_basic.pl b/src/bin/pg_dump/t/001_basic.pl index 083fb3ad08..8280914c2a 100644 --- a/src/bin/pg_dump/t/001_basic.pl +++ b/src/bin/pg_dump/t/001_basic.pl @@ -63,8 +63,8 @@ command_fails_like( command_fails_like( ['pg_restore'], - qr{\Qpg_restore: error: one of -d/--dbname and -f/--file must be specified\E}, - 'pg_restore: error: one of -d/--dbname and -f/--file must be specified'); + qr{\Qpg_restore: error: one of -d/--dbname, -f/--file, or -l/--list must be specified\E}, + 'pg_restore: error: one of -d/--dbname, -f/--file, or -l/--list must be specified'); command_fails_like( [ 'pg_restore', '-s', '-a', '-f -' ], -- 2.17.0 --Pk6IbRAofICFmK5e Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0007-Remove-ZSTD_COMPRESSION-accidentially-included-at-90.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [DOC] Add detail regarding resource consumption wrt max_connections @ 2024-03-22 17:57 Robert Haas <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Robert Haas @ 2024-03-22 17:57 UTC (permalink / raw) To: Robert Treat <[email protected]>; +Cc: [email protected]; Roberto Mello <[email protected]>; Cary Huang <[email protected]>; [email protected] On Fri, Mar 8, 2024 at 9:52 AM Robert Treat <[email protected]> wrote: > I'm of the opinion that advice suggestingDBA's set things to DEBUG 3 > is unfriendly at best. If you really want to add more, there is an > existing unfriendly section of the docs at > https://www.postgresql.org/docs/devel/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT > that mentions this problem, specifically: > > "If PostgreSQL itself is the cause of the system running out of > memory, you can avoid the problem by changing your configuration. In > some cases, it may help to lower memory-related configuration > parameters, particularly shared_buffers, work_mem, and > hash_mem_multiplier. In other cases, the problem may be caused by > allowing too many connections to the database server itself. In many > cases, it may be better to reduce max_connections and instead make use > of external connection-pooling software." > > I couldn't really find a spot to add in your additional info, but > maybe you can find a spot that fits? Or maybe a well written > walk-through of this would make for a good wiki page in case people > really want to dig in. > > In any case, I think Roberto's original language is an improvement > over what we have now, so I'd probably recommend just going with that, > along with a similar note to max_prepared_xacts, and optionally a > pointer to the shared mem section of the docs. I agree with this. I don't agree with Cary's statement that if you increase max_connections you should increase shared_buffers as well. That seems situation-dependent to me, and it's also missing Roberto's point, which is that JUST increasing max_connections without doing anything else uses more shared memory. Similarly, I don't think we need to document a detailed testing procedure, as proposed by Reid. If users want to know exactly how many additional resources are used, they can test; either using the DEBUG3 approach, or perhaps more simply via the pg_shmem_allocations view. But I think it's overkill for us to recommend any specific testing procedure here. Rather, I think that it's entirely appropriate to do what Roberto suggested, which is to say, let users know that they're going to use some extra resources if they increase the setting, and then let them figure out what if anything they want to do about that. -- Robert Haas EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-03-22 17:57 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-12-06 04:43 [PATCH 6/7] pg_restore: "must be specified" and --list Justin Pryzby <[email protected]> 2024-03-22 17:57 Re: [DOC] Add detail regarding resource consumption wrt max_connections Robert Haas <[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