Not able to compile PG16 with custom flags in freebsd 14.1 - Please Help

Hi I am trying to install Postgresql 16 on my freebsd 14.1 by compiling it hosted in an ec2 machine on AWS. I am using GCC13 to compile the binaries and I keep on running into *gcc13: fatal error: cannot read spec file './specs': Is a directory *Please Help here is the code of my bas

Re: Role Granting Issues in PostgreSQL: Need Help

"David G. Johnston" writes: > On Wednesday, September 4, 2024, Muhammad Imtiaz > wrote: >> replication_expert | Cannot login > Those are not permissions, they are attributes, and attributes are not > inherited. Specifically: the NOLOGIN attribute on a role is a hard block on logging in with tha

Re: Role Granting Issues in PostgreSQL: Need Help

On Wednesday, September 4, 2024, Muhammad Imtiaz wrote: > > 1. Create a role with specific permissions > > CREATE ROLE rep_admin WITH LOGIN CREATEDB CREATEROLE REPLICATION; > > List of roles > Role name | Attributes >

Role Granting Issues in PostgreSQL: Need Help

Hi, I need to assign role permissions from one role to another. However, after granting the role, I see that the permission list for the target role has not been updated. For this process, I followed the PostgreSQL documentation available at PostgreSQL Role Membership

Re: Help Needed with Including External SQL Script in Extension Script

On Friday, July 26, 2024, Ayush Vatsa wrote: > > I wanted to modify the SQL script of an extension by creating multiple > objects within it. > My aim is to make minimal changes to the existing script. To achieve this, > I have created an > external script and am attempting to run it within the ext

Help Needed with Including External SQL Script in Extension Script

Hi PostgreSQL community, I wanted to modify the SQL script of an extension by creating multiple objects within it. My aim is to make minimal changes to the existing script. To achieve this, I have created an external script and am attempting to run it within the extension script using the \i comma

Re: Adding comments to help understand psql hidden queries

t; > -label = psprintf("QUERY (\\%s)", curcmd); > +label = psprintf(_("QUERY (\\%s)"), curcmd); Any further concerns/issues with this patch that I can address to help move it forward? David

Re: Help update PostgreSQL 13.12 to 13.14

not finding V13.14. Please follow the link > below. > > https://www.postgresql.org/download/linux/redhat/ > > There is another way to avoid it by downloading the V13.14 on your > system and then install this version on your system which will upgrad

Re: Help update PostgreSQL 13.12 to 13.14

son that it's not finding V13.14. Please follow the link below. >> >> https://www.postgresql.org/download/linux/redhat/ >> >> There is another way to avoid it by downloading the V13.14 on your system >> and then install this version on your system which will u

Help regarding figuring out routes in pgAdmin4

Dear PostgreSQL Hackers, I hope this email finds you well. As I delve into the codebase, I've encountered some challenges understanding how routes are implemented within the application. As I navigate through the codebase, I've encountered some challenges understanding how routes are implemented

Re: Help update PostgreSQL 13.12 to 13.14

upgrade your existing installation. Regards Kashif Zeeshan Bitnine Global > > El sáb, 27 abr 2024 a las 9:29, Kashif Zeeshan () > escribió: > >> Glad to be of help. >> pg_uprade is used with major version upgrade e.g. from PG13 to 14 etc >> >> Regards >> Kashif

Re: Help update PostgreSQL 13.12 to 13.14

Glad to be of help. pg_uprade is used with major version upgrade e.g. from PG13 to 14 etc Regards Kashif Zeeshan Bitnine Global On Fri, Apr 26, 2024 at 10:47 PM •Isaac Rv wrote: > Hola, lo acabo de hacer, quedó bien luego detuve el servidor, aplique otra > vez el sudo yum update postgr

Re: Help update PostgreSQL 13.12 to 13.14

estart the server. The data >>>> directory remains unchanged — minor upgrades are that simple.* >>>> >>>> >>>> Please follow the links below for more information. >>>> https://www.postgresql.org/docs/13/upgrading.html >>>> https://www.

Re: Help update PostgreSQL 13.12 to 13.14

have a guide or >>> know how to perform an upgrade from PostgreSQL 13.12 to 13.14 on Linux? >>> I've searched in various places but haven't found any solid guides, and >>> truth be told, I'm a bit of a novice with PostgreSQL. Any help would be >>> appreciated. >>> >>

Re: Help update PostgreSQL 13.12 to 13.14

t; Hello everyone, I hope you're doing well. Does anyone have a guide or know > how to perform an upgrade from PostgreSQL 13.12 to 13.14 on Linux? I've > searched in various places but haven't found any solid guides, and truth be > told, I'm a bit of a novice with PostgreSQL. Any help would be appreciated. >

Help update PostgreSQL 13.12 to 13.14

Hello everyone, I hope you're doing well. Does anyone have a guide or know how to perform an upgrade from PostgreSQL 13.12 to 13.14 on Linux? I've searched in various places but haven't found any solid guides, and truth be told, I'm a bit of a novice with PostgreSQL. Any help would be appreciated.

Re: Adding comments to help understand psql hidden queries

On Thu, Apr 4, 2024 at 9:32 AM Peter Eisentraut wrote: > > On 03.04.24 19:16, David Christensen wrote: > > I removed _() in the output of the query/stars since there'd be no > > sensible existing translations for the constructed string, which > > included the query string itself. If we need it fo

Re: Adding comments to help understand psql hidden queries

On 03.04.24 19:16, David Christensen wrote: I removed _() in the output of the query/stars since there'd be no sensible existing translations for the constructed string, which included the query string itself. If we need it for the "QUERY" string, this could be added fairly easily, but the exist

Re: Adding comments to help understand psql hidden queries

I got Greg's blessing on squashing the commits down, and now including a v4 with additional improvements on the output formatting front. Main changes: - all generated comments are the same width - width has been bumped to 80 - removed _() functions for consumers of the new output functions This p

Re: Adding comments to help understand psql hidden queries

On Fri, Mar 22, 2024 at 11:39 AM David Christensen wrote: > I think it's easier to keep the widths balanced than constant (patch > version included here) Yeah, I'm fine with that, especially because nobody is translating it, nor are they likely to, to be honest. Cheers, Greg

Re: Adding comments to help understand psql hidden queries

On Fri, Mar 22, 2024 at 9:47 AM Greg Sabino Mullane wrote: > > On Thu, Mar 21, 2024 at 6:20 PM Peter Eisentraut wrote: >> >> lines are supposed to align vertically. With your patch, the first line >> would have variable length depending on the command. > > > Yes, that is a good point. Aligning t

Re: Adding comments to help understand psql hidden queries

On Thu, Mar 21, 2024 at 6:20 PM Peter Eisentraut wrote: > lines are supposed to align vertically. With your patch, the first line > would have variable length depending on the command. > Yes, that is a good point. Aligning those would be quite tricky, what if we just kept a standard width for t

Re: Adding comments to help understand psql hidden queries

On 21.03.24 18:31, David Christensen wrote: Thanks for the feedback. Enclosed is a v2 of this series(?) rebased and with that warning fixed; @Greg Sabino Mullane I just created a commit on your behalf with the message to hackers. I'm also creating a commit-fest entry for this thread. I don't

Re: Adding comments to help understand psql hidden queries

Created the CF entry in commitfest 48 but didn't see it was already in 47; closing the CFEntry in 48. (Doesn't appear to be a different status than "Withdrawn"...)

Re: Adding comments to help understand psql hidden queries

Hi Jim, Thanks for the feedback. Enclosed is a v2 of this series(?) rebased and with that warning fixed; @Greg Sabino Mullane I just created a commit on your behalf with the message to hackers. I'm also creating a commit-fest entry for this thread. Best, David v2-0002-Add-output-of-the-comma

Re: Adding comments to help understand psql hidden queries

Hi Greg, hi David On 01.02.24 23:39, David Christensen wrote: > On Thu, Feb 1, 2024 at 4:34 PM Greg Sabino Mullane wrote: >> The use of the --echo-hidden flag in psql is used to show people the way >> psql performs its magic for its backslash commands. None of them has more >> magic than "\d re

Re: Adding comments to help understand psql hidden queries

On Thu, Feb 1, 2024 at 4:34 PM Greg Sabino Mullane wrote: > > The use of the --echo-hidden flag in psql is used to show people the way psql > performs its magic for its backslash commands. None of them has more magic > than "\d relation", but it suffers from needing a lot of separate queries to

Re: [patch] pg_basebackup: mention that spread checkpoints are the default in --help

com/task/4648506929971200?logs=build#L1217): > > Oops, sorry. Attached is a working third version of this patch. While I think Peters argument about one reading better than the other one, that does also increase the "help message bloat" mentioned by Michael. So I think we're

Re: pg_basebackup has an accidentaly separated help message

At Tue, 26 Dec 2023 19:04:53 +0900, Michael Paquier wrote in > On Mon, Dec 25, 2023 at 05:07:28PM +0900, Kyotaro Horiguchi wrote: > > Yes. So, it turns out that they're found after they have been > > committed. > > No problem. I've just applied what you had. I hope this makes your > life a bi

Re: pg_basebackup has an accidentaly separated help message

On Mon, Dec 25, 2023 at 05:07:28PM +0900, Kyotaro Horiguchi wrote: > Yes. So, it turns out that they're found after they have been > committed. No problem. I've just applied what you had. I hope this makes your life a bit easier ;) -- Michael signature.asc Description: PGP signature

Re: pg_basebackup has an accidentaly separated help message

At Mon, 25 Dec 2023 15:42:41 +0900, Michael Paquier wrote in > On Mon, Dec 25, 2023 at 02:39:16PM +0900, Kyotaro Horiguchi wrote: > > The attached patch contains both of the above fixes. > > Good catches, let's fix them. You have noticed that while translating > these new messages, I guess? Y

Re: pg_basebackup has an accidentaly separated help message

On Mon, Dec 25, 2023 at 02:39:16PM +0900, Kyotaro Horiguchi wrote: > The attached patch contains both of the above fixes. Good catches, let's fix them. You have noticed that while translating these new messages, I guess? -- Michael signature.asc Description: PGP signature

Re: pg_basebackup has an accidentaly separated help message

a/src/bin/pg_combinebackup/pg_combinebackup.c b/src/bin/pg_combinebackup/pg_combinebackup.c index b6ae6f2aef..49e97fcca8 100644 --- a/src/bin/pg_combinebackup/pg_combinebackup.c +++ b/src/bin/pg_combinebackup/pg_combinebackup.c @@ -669,8 +669,8 @@ help(const char *progname) printf(_(" -n, -

pg_basebackup has an accidentaly separated help message

Hello. pg_basebackup.c: got the following message lines: > printf(_(" -i, --incremental=OLDMANIFEST\n")); > printf(_(" take incremental backup\n")); I'd suggest merging these lines as follows (and the attached patch). > + printf(_(" -i, --incremental=OL

Adding comments to help understand psql hidden queries

The use of the --echo-hidden flag in psql is used to show people the way psql performs its magic for its backslash commands. None of them has more magic than "\d relation", but it suffers from needing a lot of separate queries to gather all of the information it needs. Unfortunately, those queries

Re: about help message for new pg_dump's --filter option

> On 2 Dec 2023, at 17:02, Alvaro Herrera wrote: > > On 2023-Nov-30, Kyotaro Horiguchi wrote: > >> Hello. >> >> Recently, a new --filter option was added to pg_dump. I might be >> wrong, but the syntax of the help message for this feels off. Is the >

Re: about help message for new pg_dump's --filter option

On 2023-Nov-30, Kyotaro Horiguchi wrote: > Hello. > > Recently, a new --filter option was added to pg_dump. I might be > wrong, but the syntax of the help message for this feels off. Is the > word 'on' not necessary after 'based'? > > > --filter=FI

Re: about help message for new pg_dump's --filter option

> On 30 Nov 2023, at 02:52, Kyotaro Horiguchi wrote: > > At Thu, 30 Nov 2023 10:20:40 +0900 (JST), Kyotaro Horiguchi > wrote in >> Hello. >> >> Recently, a new --filter option was added to pg_dump. I might be >> wrong, but the syntax of the help message fo

Re: about help message for new pg_dump's --filter option

At Thu, 30 Nov 2023 10:20:40 +0900 (JST), Kyotaro Horiguchi wrote in > Hello. > > Recently, a new --filter option was added to pg_dump. I might be > wrong, but the syntax of the help message for this feels off. Is the > word 'on' not necessary after 'bas

about help message for new pg_dump's --filter option

Hello. Recently, a new --filter option was added to pg_dump. I might be wrong, but the syntax of the help message for this feels off. Is the word 'on' not necessary after 'based'? > --filter=FILENAMEinclude or exclude objects and data from dump >

Re: [patch] pg_basebackup: mention that spread checkpoints are the default in --help

ersion of this patch. Michael >From bc9eb46a49ee514236aabe42d9689a7c35b5bcd7 Mon Sep 17 00:00:00 2001 From: Michael Banck Date: Thu, 19 Oct 2023 11:37:11 +0200 Subject: [PATCH v3] pg_basebackup: Mention that spread checkpoints are the default in --help --- src/bin/pg_basebackup/pg_base

Re: [patch] pg_basebackup: mention that spread checkpoints are the default in --help

e default in > > > pg_basebackup, but noticed that --help does not specify which is which - > > > contrary to the reference documentation. > > > > > > So I propose the small attached patch to clarify that. > > > > > printf(_(" -c, --c

Re: [patch] pg_basebackup: mention that spread checkpoints are the default in --help

Hi, On Wed, Oct 25, 2023 at 04:36:41PM +0200, Peter Eisentraut wrote: > On 19.10.23 11:39, Michael Banck wrote: > > Hi, > > > > I believed that spread (not fast) checkpoints are the default in > > pg_basebackup, but noticed that --help does not specify which is

Re: [patch] pg_basebackup: mention that spread checkpoints are the default in --help

On 19.10.23 11:39, Michael Banck wrote: Hi, I believed that spread (not fast) checkpoints are the default in pg_basebackup, but noticed that --help does not specify which is which - contrary to the reference documentation. So I propose the small attached patch to clarify that. > pri

Re: [patch] pg_basebackup: mention that spread checkpoints are the default in --help

Hi, > On Thu, Oct 19, 2023 at 10:30:04PM +0200, Michael Banck wrote: > > Hrm right, but those have multiple options and they do not enumerate > > them in the help string as do -F and -c - not sure what general project > > policy here is for mentioning defaults in --help,

Re: [patch] pg_basebackup: mention that spread checkpoints are the default in --help

On Thu, Oct 19, 2023 at 10:30:04PM +0200, Michael Banck wrote: > Hrm right, but those have multiple options and they do not enumerate > them in the help string as do -F and -c - not sure what general project > policy here is for mentioning defaults in --help, I will check some of &g

Re: [patch] pg_basebackup: mention that spread checkpoints are the default in --help

Hi, On Thu, Oct 19, 2023 at 04:21:19PM +0300, Aleksander Alekseev wrote: > > I believed that spread (not fast) checkpoints are the default in > > pg_basebackup, but noticed that --help does not specify which is which - > > contrary to the reference documentation. > > &g

Re: [patch] pg_basebackup: mention that spread checkpoints are the default in --help

Hi, > I believed that spread (not fast) checkpoints are the default in > pg_basebackup, but noticed that --help does not specify which is which - > contrary to the reference documentation. > > So I propose the small attached patch to clarify that. You are right and I believe

[patch] pg_basebackup: mention that spread checkpoints are the default in --help

Hi, I believed that spread (not fast) checkpoints are the default in pg_basebackup, but noticed that --help does not specify which is which - contrary to the reference documentation. So I propose the small attached patch to clarify that. Michael >From 2fc49eae5ccc82e144c3f683689757e014e33

Re: Make --help output fit within 80 columns per line

02 removed environment-variable-based defaults in psql --help. I have committed 0002 and a different implementation of 0001. I set the maximum line length to 95, which is the current maximum in use. Thanks! BTW as far as I investigated, the original 0002 patch failed because current meson doesn't

Re: Make --help output fit within 80 columns per line

like patch 0001? Agreed. It seems inconsistent with other commands. Patch 0002 removed environment-variable-based defaults in psql --help. I have committed 0002 and a different implementation of 0001. I set the maximum line length to 95, which is the current maximum in use. I'm open to

Re: Better help output for pgbench -I init_steps

On 22.09.23 22:01, Tristen Raab wrote: The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Hello, I've reviewed all 4 of y

Re: Make --help output fit within 80 columns per line

more sensible defaults: $ wget --help | wc -L 110 $ gcloud --help | wc -L 122 $ yum --help | wc -L 122 git is an interesting one, as they force things through a pager for their help, but if you look at their raw help text files, they have plenty of times they go past 80 when needed: $ wc -L gi

Re: Make --help output fit within 80 columns per line

se 80 characters for all commands? Well, that's the question du jour, isn't it? The 80 character limit is based on punch cards, and really has no place in modern systems. While gnu systems are stuck in the past, many other ones have moved on to more sensible defaults: $ wget --help | wc -

Re: Better help output for pgbench -I init_steps

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Hello, I've reviewed all 4 of your patches, each one applies and builds

Re: Make --help output fit within 80 columns per line

On 31.08.23 09:47, torikoshia wrote: BTW, psql --help outputs the content of PGHOST, which caused a failure in the test: ``` -h, --host=HOSTNAME  database server host or socket directory (default: "/var/folders/m7/9snkd5b54cx_b4lxkl9ljlccgn/T/Lobrm

Re: Better help output for pgbench -I init_steps

On 12.07.23 15:41, Alvaro Herrera wrote: On 2023-Jul-12, Gurjeet Singh wrote: The init-steps are severely under-documented in pgbench --help output. I think at least a pointer to the the pgbench docs should be mentioned in the pgbench --help output; an average user may not rush to read the

Re: Make --help output fit within 80 columns per line

#x27;t it? The 80 character limit is based on punch cards, and really has no place in modern systems. While gnu systems are stuck in the past, many other ones have moved on to more sensible defaults: $ wget --help | wc -L 110 $ gcloud --help | wc -L 122 $ yum --help | wc -L 122 git is an int

Re: psql help message contains excessive indentations

On 2023-Sep-07, Yugo NAGATA wrote: > Thank you for your explanation. I understood it. I thought of just > imitating other places, and I didn't know each is a single translatable > unit. Thanks for reviewing, and Kyotaro for reporting. Pushed now. -- Álvaro HerreraBreisgau, Deutschland

Re: Make --help output fit within 80 columns per line

Looks like you failed 1 test of 21. # Failed test 'vacuumlo --help outputs fit within 80 columns per line' # at t/001_basic.pl line 10. # Looks like you failed 1 test of 9. t/001_basic.pl .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/9 subtests Test Summary Report -

Re: Make --help output fit within 80 columns per line

On Tue, Jul 4, 2023 at 9:47 PM torikoshia wrote: > Since it seems preferable to have consistent line break policy and some > people use 80-column terminal, wouldn't it be better to make all commands > in 80 > columns per line? > All this seems an awful lot of work to support this mythical 80-col

Re: Make --help output fit within 80 columns per line

On 2023-09-12 15:27, Peter Eisentraut wrote: I like this work a lot. It's good to give developers easy to verify guidance about formatting the --help messages. However, I think instead of just adding a bunch of line breaks to satisfy the test, we should really try to make the lines short

Re: Make --help output fit within 80 columns per line

I like this work a lot. It's good to give developers easy to verify guidance about formatting the --help messages. However, I think instead of just adding a bunch of line breaks to satisfy the test, we should really try to make the lines shorter by rewording. Otherwise, chances are w

Re: psql help message contains excessive indentations

t; + " stop if less than MIN rows are > > returned\n"); > > Yeah, this looks right to me -- the whole help entry as a single > translatable unit, instead of three separately translatable lines. +1 regards. -- Kyotaro Horiguchi NTT Open Source Software Center

Re: psql help message contains excessive indentations

y every SEC seconds, up to > > N times\n"); > > - HELP0(" stop if less than MIN rows are > > returned\n"); > > + HELP0(" \\watch [[i=]SEC] [c=N] [m=MIN]\n" > > + " execute query every

Re: psql help message contains excessive indentations

stop if less than MIN rows are > returned\n"); > + HELP0(" \\watch [[i=]SEC] [c=N] [m=MIN]\n" > + " execute query every SEC seconds, up > to N times\n" > + " stop if less than MIN rows are > returned\n

Re: psql help message contains excessive indentations

At Thu, 7 Sep 2023 16:08:10 +0900, Yugo NAGATA wrote in > On Thu, 07 Sep 2023 15:36:10 +0900 (JST) > Kyotaro Horiguchi wrote: > > > At Thu, 7 Sep 2023 15:02:49 +0900, Yugo NAGATA wrote > > in > > > I wonder this better to fix this in similar way to other places where the > > > description ha

Re: psql help message contains excessive indentations

than MIN rows are returned\n"); + HELP0(" \\watch [[i=]SEC] [c=N] [m=MIN]\n" + " execute query every SEC seconds, up to N times\n" + " stop if less than MIN rows are returned\n"); HELP0("\n"); HELP0("Help\n");

Re: psql help message contains excessive indentations

At Thu, 7 Sep 2023 15:02:49 +0900, Yugo NAGATA wrote in > On Thu, 07 Sep 2023 14:29:56 +0900 (JST) > Kyotaro Horiguchi wrote: > > > \q quit psql > > > \watch [[i=]SEC] [c=N] [m=MIN] > > !> execute query every SEC seconds, up to N times > > !>

Re: psql help message contains excessive indentations

On Thu, 07 Sep 2023 14:29:56 +0900 (JST) Kyotaro Horiguchi wrote: > This topic is extracted from [1]. > > As mentioned there, in psql, running \? displays the following lines. > > > \gdesc describe result of query, without executing it > > \gexec execute quer

psql help message contains excessive indentations

ned\n"); + HELP0(" execute query every SEC seconds, up to N times\n"); + HELP0(" stop if less than MIN rows are returned\n"); HELP0("\n"); HELP0("Help\n");

Re: Make --help output fit within 80 columns per line

On Mon, Aug 21, 2023 at 1:09 PM Masahiro Ikeda wrote: (1) Why don't you add test for the purpose? It could be overkill... I though the following function is the best place. Added the test. BTW, psql --help outputs the content of PGHOST, which caused a failure in the test: ``` -h, -

A propose to revise \watch help message

Recently \watch got the following help message. > \watch [[i=]SEC] [c=N] [m=MIN] > execute query every SEC seconds, up to N times > stop if less than MIN rows are returned The "m=MIN" can be a bit misleading. It may l

Re: A propose to revise \watch help message

At Wed, 30 Aug 2023 10:21:26 +0900 (JST), Kyotaro Horiguchi wrote in > Recently \watch got the following help message. > > > \watch [[i=]SEC] [c=N] [m=MIN] > > execute query every SEC seconds, up to N times > > st

Re: Make --help output fit within 80 columns per line

$ vacuumlo --help | while IFS='' read line; do echo $((`echo $line | wc -m` - 1)) $line; done | sort -n -r | head -n 2 84 -n, --dry-run don't remove large objects, just show what would be done 74 -l, --limit=LIMIT commit after removing each LIMIT large objects

Re: Make --help output fit within 80 columns per line

index 617caa022f..1bdb81ac56 100644 --- a/src/test/perl/PostgreSQL/Test/Utils.pm +++ b/src/test/perl/PostgreSQL/Test/Utils.pm @@ -843,6 +843,10 @@ sub program_help_ok ok($result, "$cmd --help exit code 0"); isnt($stdout, '', "$cmd --help goes to stdout");

Re: Make --help output fit within 80 columns per line

On 2023-07-05 10:47, torikoshia wrote: Hi, As discussed in [1], outputs of --help for some commands fits into 80 columns per line, while others do not. Since it seems preferable to have consistent line break policy and some people use 80-column terminal, wouldn't it be better to mak

Re: Better help output for pgbench -I init_steps

On 12.07.23 19:47, Gurjeet Singh wrote: If you end up with variant 3 or 4, please use double quotes instead of single quotes. Will do. I believe you're suggesting this because in the neighboring help text the string literals use double quotes. I see that other utilities, such as psql

Re: Better help output for pgbench -I init_steps

;sufficient, but not too much" variant. I have attempted > > that in variants 3 and 4; also attached. > > If you end up with variant 3 or 4, please use double quotes instead of > single quotes. Will do. I believe you're suggesting this because in the neighboring help

Re: Better help output for pgbench -I init_steps

On 2023-Jul-12, Gurjeet Singh wrote: > The init-steps are severely under-documented in pgbench --help output. > I think at least a pointer to the the pgbench docs should be mentioned > in the pgbench --help output; an average user may not rush to read the > code to find the explan

Re: Better help output for pgbench -I init_steps

On 12.07.23 09:42, Gurjeet Singh wrote: These two variants show the two extremes; bare minimum vs. everything but the kitchen sink. So one may feel the need to find a middle ground and provide a "sufficient, but not too much" variant. I have attempted that in variants 3 and 4; also attached. If

Better help output for pgbench -I init_steps

These patches were created during an unrelated discussion about pgbench. Please see emails [1] - [6] linked below, for the past discussion. In brief: > $ pgbench -i -I dtGvp -s 500 The init-steps are severely under-documented in pgbench --help output. I think at least a pointer to the

Make --help output fit within 80 columns per line

Hi, As discussed in [1], outputs of --help for some commands fits into 80 columns per line, while others do not. Since it seems preferable to have consistent line break policy and some people use 80-column terminal, wouldn't it be better to make all commands in 80 columns per

Re: Inquiry/Help with pg_adviser (problem in index_create function for creating indexes)

On 25/06/2023 17:30, Ahmed Ibrahim wrote: The full current code (PR is still draft) can be found at https://github.com/DrPostgres/pg_adviser/pull/4 The idea behind what is being done is creating virtual indexes, and measuring the query cost af

Re: Inquiry/Help with pg_adviser (problem in index_create function for creating indexes)

Hi, Since some people prefer plain text over screenshots/pdfs (but I think the pdf is more readable), I will post the problem here, in case anyone can help. I will appreciate that :) The full current code (PR is still draft) can be found at https://github.com/DrPostgres/pg_adviser/pull/4 The

Inquiry/Help with pg_adviser (problem in index_create function for creating indexes)

cost. The problem I am facing is in creating those indexes in Postgres 16 (while calling *index_create*), and you can find here a detail description about the problem along with the code/PR https://drive.google.com/file/d/1x2PnDEfEo094vgNiBd1-BfJtB5Fovrih/view I would appreciate any help. Thanks :)

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On Wed, 12 Apr 2023 at 09:53, Tom Lane wrote: > I don't see a reason to wait longer once the buildfarm is on board. I did a final sweep of the latest runs for each animal this morning. Everything has been switched over to debug_parallel_query, so I've gone and pushed the patch to remove the mappi

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On Wed, 12 Apr 2023 at 09:53, Tom Lane wrote: > > David Rowley writes: > > In preparation for when that's ticked off, I'd like to gather people's > > thoughts about if we should remove force_parallel_mode from v16? > > To clarify, you just mean removing that alias, right? +1. > I don't see a rea

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

David Rowley writes: > In preparation for when that's ticked off, I'd like to gather people's > thoughts about if we should remove force_parallel_mode from v16? To clarify, you just mean removing that alias, right? +1. I don't see a reason to wait longer once the buildfarm is on board.

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On Thu, 16 Feb 2023 at 00:05, David Rowley wrote: > I pushed the rename patch earlier. > > How should we go about making contact with the owners? After a quick round of making direct contact with the few remaining buildfarm machine owners which are still using force_parallel_mode, we're now down

Re: Marking options deprecated in help output

> On 24 Feb 2023, at 21:31, Heikki Linnakangas wrote: > On 05/12/2022 11:42, Daniel Gustafsson wrote: > How about putting the deprecated option on a separate line like this: > >> -h, --host=HOSTNAMEdatabase server host or socket directory >> -H (same as -h, depr

Re: Marking options deprecated in help output

On 05/12/2022 11:42, Daniel Gustafsson wrote: In the pg_dump blob terminology thread it was briefly discussed [0] to mark parameters as deprecated in the --help output. The attached is a quick diff to show that that would look like. Personally I think it makes sense, not everyone will read the

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On 2023-02-15 We 06:05, David Rowley wrote: On Wed, 15 Feb 2023 at 14:10, Andrew Dunstan wrote: We'll email them once this is in. Most people are fairly reponsive. I pushed the rename patch earlier. How should we go about making contact with the owners? I'm thinking it may be better coming

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On Wed, 15 Feb 2023 at 14:10, Andrew Dunstan wrote: > We'll email them once this is in. Most people are fairly reponsive. I pushed the rename patch earlier. How should we go about making contact with the owners? I'm thinking it may be better coming from you, especially if you think technical de

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On 2023-02-14 Tu 17:32, David Rowley wrote: On Wed, 15 Feb 2023 at 11:27, Andrew Dunstan wrote: It's just occurred to me that this could break the buildfarm fairly comprehensively. I just took a count and we have 74 members using force_parallel_mode. Maybe we need to keep force_parallel_mode

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On Wed, 15 Feb 2023 at 11:27, Andrew Dunstan wrote: > It's just occurred to me that this could break the buildfarm fairly > comprehensively. I just took a count and we have 74 members using > force_parallel_mode. Maybe we need to keep force_parallel_mode as an > alternative spelling for debug_p

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On 2023-02-13 Mo 06:16, David Rowley wrote: On Sat, 11 Feb 2023 at 04:34, Andrew Dunstan wrote: On 2023-02-09 Th 15:25, David Rowley wrote: Likely the hardest part to get right here is the new name. Can anyone think of anything better than debug_parallel_query? WFM Thanks for chipping in.

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On Sat, 11 Feb 2023 at 04:34, Andrew Dunstan wrote: > > On 2023-02-09 Th 15:25, David Rowley wrote: > Likely the hardest part to get right here is the new name. Can anyone > think of anything better than debug_parallel_query? > > > WFM Thanks for chipping in. I've attached a patch which fixes t

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On 2023-02-09 Th 15:25, David Rowley wrote: On Thu, 9 Feb 2023 at 21:20, John Naylor wrote: Looks good at a glance, just found a spurious word: + "by forcing the planner into to generate plans which contains nodes " Thanks for looking. I'll fix that. Likely the hardest part to get right her

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On Thu, 9 Feb 2023 at 21:20, John Naylor wrote: > Looks good at a glance, just found a spurious word: > > + "by forcing the planner into to generate plans which contains nodes " Thanks for looking. I'll fix that. Likely the hardest part to get right here is the new name. Can anyone think of any

  1   2   3   4   >