pgsql: Fix handling of default option values in createuser
Fix handling of default option values in createuser Add description of which one is the default between two complementary options of --bypassrls and --replication in the help text and docs. In correspondence let the command always include the tokens corresponding to every options of that kind in the SQL command sent to server. Tests are updated accordingly. Also fix the checks of some trivalue vars which were using literal zero for checking default value instead of the enum label TRI_DEFAULT. While not a bug, since TRI_DEFAULT is defined as zero, fixing improves read- ability improved readability (and avoid bugs if the enum is changed). Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d3406d80360776bbcafa05d8b966806012f9594e Modified Files -- doc/src/sgml/ref/createuser.sgml| 2 +- src/bin/scripts/createuser.c| 21 ++--- src/bin/scripts/t/040_createuser.pl | 18 +- 3 files changed, 24 insertions(+), 17 deletions(-)
pgsql: In basebackup.c, perform end-of-file test after checksum validat
In basebackup.c, perform end-of-file test after checksum validation. We read blocks of data from files that we're backing up in chunks, some multiple of BLCKSZ for each read. If checksum verification fails, we then try rereading just the one block for which validation failed. If that block happened to be the first block of the chunk, and if the file was concurrently truncated to remove that block, then we'd reach a call to bbsink_archive_contents() with a buffer length of 0. That causes an assertion failure. As far as I can see, there are no particularly bad consequences if this happens in a non-assert build, and it's pretty unlikely to happen in the first place because it requires a series of somewhat unlikely things to happen in very quick succession. However, assertion failures are bad, so rearrange the code to avoid that possibility. Patch by me, reviewed by Michael Paquier. Discussion: http://postgr.es/m/ca+tgmoz_ffaou6mrht9qbs+dcyhn6yxengttmrebznhtwpw...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/33352b9279f5e109aae74d61531d33d8fb12253e Modified Files -- src/backend/backup/basebackup.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-)
pgsql: In basebackup.c, perform end-of-file test after checksum validat
In basebackup.c, perform end-of-file test after checksum validation. We read blocks of data from files that we're backing up in chunks, some multiple of BLCKSZ for each read. If checksum verification fails, we then try rereading just the one block for which validation failed. If that block happened to be the first block of the chunk, and if the file was concurrently truncated to remove that block, then we'd reach a call to bbsink_archive_contents() with a buffer length of 0. That causes an assertion failure. As far as I can see, there are no particularly bad consequences if this happens in a non-assert build, and it's pretty unlikely to happen in the first place because it requires a series of somewhat unlikely things to happen in very quick succession. However, assertion failures are bad, so rearrange the code to avoid that possibility. Patch by me, reviewed by Michael Paquier. Discussion: http://postgr.es/m/ca+tgmoz_ffaou6mrht9qbs+dcyhn6yxengttmrebznhtwpw...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/349803b18fee2476c7c9c84039d04c900ce8d499 Modified Files -- src/backend/backup/basebackup.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-)
pgsql: Remove an old comment that doesn't seem especially useful.
Remove an old comment that doesn't seem especially useful. The functions that follow are concerned with various things, of which the tar format is only one, so this comment doesn't really seem helpful. The file isn't really divided into sections in the way that this comment seems to contemplate -- or at least, not any more. Patch by me, reviewed by Michael Paquier. Discussion: http://postgr.es/m/ca+tgmoz_ffaou6mrht9qbs+dcyhn6yxengttmrebznhtwpw...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f3948b5c9152e4beb33c0a4ff4ee193d264a5535 Modified Files -- src/backend/backup/basebackup.c | 7 --- 1 file changed, 7 deletions(-)
pgsql: Reword overly-optimistic comment about backup checksum verificat
Reword overly-optimistic comment about backup checksum verification. The comment implies that a single retry is sufficient to avoid spurious checksum failures, but in fact no number of retries is sufficient for that purpose. Update the comment accordingly. Patch by me, reviewed by Michael Paquier. Discussion: http://postgr.es/m/ca+tgmoz_ffaou6mrht9qbs+dcyhn6yxengttmrebznhtwpw...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e76cbb6cd64d9c9cdf76a56318ba5249bf694b69 Modified Files -- src/backend/backup/basebackup.c | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-)
pgsql: Fill EState.es_rteperminfos more systematically.
Fill EState.es_rteperminfos more systematically. While testing a fix for bug #17823, I discovered that EvalPlanQualStart failed to copy es_rteperminfos from the parent EState, resulting in failure if anything in EPQ execution wanted to consult that information. This led me to conclude that commit a61b1f748 had been too haphazard about where to fill es_rteperminfos, and that we need to be sure that that happens exactly where es_range_table gets filled. So I changed the signature of ExecInitRangeTable to help ensure that this new requirement doesn't get missed. (Indeed, pgoutput.c was also failing to fill it. Maybe we don't ever need it there, but I wouldn't bet on that.) No test case yet; one will arrive with the fix for #17823. But that needs to be back-patched, while this fix is HEAD-only. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b803b7d132e3505ab77c29acf91f3d1caa298f95 Modified Files -- src/backend/commands/copyfrom.c | 8 +--- src/backend/executor/execMain.c | 8 src/backend/executor/execUtils.c| 6 +- src/backend/replication/logical/worker.c| 6 -- src/backend/replication/pgoutput/pgoutput.c | 7 ++- src/include/executor/executor.h | 2 +- 6 files changed, 21 insertions(+), 16 deletions(-)
pgsql: Silence -Wmissing-braces complaints in file_utils.c
Silence -Wmissing-braces complaints in file_utils.c Per buildfarm member lapwing, coupled with an offline poke from Julien Rouhaud. 6392f2a was a similar case. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d937904cce6a3d82e4f9c2127de7b59105a134b3 Modified Files -- src/common/file_utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix some more cases of missed GENERATED-column updates.
Fix some more cases of missed GENERATED-column updates. If UPDATE is forced to retry after an EvalPlanQual check, it neglected to repeat GENERATED-column computations, even though those might well have changed since we're dealing with a different tuple than before. Fixing this is mostly a matter of looping back a bit further when we retry. In v15 and HEAD that's most easily done by altering the API of ExecUpdateAct so that it includes computing GENERATED expressions. Also, if an UPDATE in a partitioned table turns into a cross-partition INSERT operation, we failed to recompute GENERATED columns. That's a bug since 8bf6ec3ba allowed partitions to have different generation expressions; although it seems to have no ill effects before that. Fixing this is messier because we can now have situations where the same query needs both the UPDATE-aligned set of GENERATED columns and the INSERT-aligned set, and it's unclear which set will be generated first (else we could hack things by forcing the INSERT-aligned set to be generated, which is indeed how fe9e658f4 made it work for MERGE). The best fix seems to be to build and store separate sets of expressions for the INSERT and UPDATE cases. That would create ABI issues in the back branches, but so far it seems we can leave this alone in the back branches. Per bug #17823 from Hisahiro Kauchi. The first part of this affects all branches back to v12 where GENERATED columns were added. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7fee7871b4302e916577df130344060d0f9b8004 Modified Files -- src/backend/executor/execMain.c| 3 +- src/backend/executor/execUtils.c | 4 +- src/backend/executor/nodeModifyTable.c | 125 ++ src/include/nodes/execnodes.h | 10 +- src/test/isolation/expected/eval-plan-qual.out | 304 + src/test/isolation/specs/eval-plan-qual.spec | 25 +- src/test/regress/expected/generated.out| 13 ++ src/test/regress/sql/generated.sql | 3 + 8 files changed, 280 insertions(+), 207 deletions(-)
pgsql: Fix some more cases of missed GENERATED-column updates.
Fix some more cases of missed GENERATED-column updates. If UPDATE is forced to retry after an EvalPlanQual check, it neglected to repeat GENERATED-column computations, even though those might well have changed since we're dealing with a different tuple than before. Fixing this is mostly a matter of looping back a bit further when we retry. In v15 and HEAD that's most easily done by altering the API of ExecUpdateAct so that it includes computing GENERATED expressions. Also, if an UPDATE in a partitioned table turns into a cross-partition INSERT operation, we failed to recompute GENERATED columns. That's a bug since 8bf6ec3ba allowed partitions to have different generation expressions; although it seems to have no ill effects before that. Fixing this is messier because we can now have situations where the same query needs both the UPDATE-aligned set of GENERATED columns and the INSERT-aligned set, and it's unclear which set will be generated first (else we could hack things by forcing the INSERT-aligned set to be generated, which is indeed how fe9e658f4 made it work for MERGE). The best fix seems to be to build and store separate sets of expressions for the INSERT and UPDATE cases. That would create ABI issues in the back branches, but so far it seems we can leave this alone in the back branches. Per bug #17823 from Hisahiro Kauchi. The first part of this affects all branches back to v12 where GENERATED columns were added. Discussion: https://postgr.es/m/[email protected] Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1e05ea51d327635ce56caab56cc47e70716e081f Modified Files -- src/backend/executor/execUtils.c | 2 +- src/backend/executor/nodeModifyTable.c | 26 +-- src/test/isolation/expected/eval-plan-qual.out | 304 + src/test/isolation/specs/eval-plan-qual.spec | 21 +- src/test/regress/expected/generated.out| 14 ++ src/test/regress/sql/generated.sql | 4 + 6 files changed, 207 insertions(+), 164 deletions(-)
pgsql: Fix some more cases of missed GENERATED-column updates.
Fix some more cases of missed GENERATED-column updates. If UPDATE is forced to retry after an EvalPlanQual check, it neglected to repeat GENERATED-column computations, even though those might well have changed since we're dealing with a different tuple than before. Fixing this is mostly a matter of looping back a bit further when we retry. In v15 and HEAD that's most easily done by altering the API of ExecUpdateAct so that it includes computing GENERATED expressions. Also, if an UPDATE in a partitioned table turns into a cross-partition INSERT operation, we failed to recompute GENERATED columns. That's a bug since 8bf6ec3ba allowed partitions to have different generation expressions; although it seems to have no ill effects before that. Fixing this is messier because we can now have situations where the same query needs both the UPDATE-aligned set of GENERATED columns and the INSERT-aligned set, and it's unclear which set will be generated first (else we could hack things by forcing the INSERT-aligned set to be generated, which is indeed how fe9e658f4 made it work for MERGE). The best fix seems to be to build and store separate sets of expressions for the INSERT and UPDATE cases. That would create ABI issues in the back branches, but so far it seems we can leave this alone in the back branches. Per bug #17823 from Hisahiro Kauchi. The first part of this affects all branches back to v12 where GENERATED columns were added. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/23b75dd03da1a4a6db080b27bb3c8efcf7dbc9ae Modified Files -- src/backend/executor/nodeModifyTable.c | 21 +- src/test/isolation/expected/eval-plan-qual.out | 304 + src/test/isolation/specs/eval-plan-qual.spec | 21 +- src/test/regress/expected/generated.out| 14 ++ src/test/regress/sql/generated.sql | 4 + 5 files changed, 204 insertions(+), 160 deletions(-)
pgsql: Fix some more cases of missed GENERATED-column updates.
Fix some more cases of missed GENERATED-column updates. If UPDATE is forced to retry after an EvalPlanQual check, it neglected to repeat GENERATED-column computations, even though those might well have changed since we're dealing with a different tuple than before. Fixing this is mostly a matter of looping back a bit further when we retry. In v15 and HEAD that's most easily done by altering the API of ExecUpdateAct so that it includes computing GENERATED expressions. Also, if an UPDATE in a partitioned table turns into a cross-partition INSERT operation, we failed to recompute GENERATED columns. That's a bug since 8bf6ec3ba allowed partitions to have different generation expressions; although it seems to have no ill effects before that. Fixing this is messier because we can now have situations where the same query needs both the UPDATE-aligned set of GENERATED columns and the INSERT-aligned set, and it's unclear which set will be generated first (else we could hack things by forcing the INSERT-aligned set to be generated, which is indeed how fe9e658f4 made it work for MERGE). The best fix seems to be to build and store separate sets of expressions for the INSERT and UPDATE cases. That would create ABI issues in the back branches, but so far it seems we can leave this alone in the back branches. Per bug #17823 from Hisahiro Kauchi. The first part of this affects all branches back to v12 where GENERATED columns were added. Discussion: https://postgr.es/m/[email protected] Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/70ef509543fab4c35f79e73dd2b309cc75ceed51 Modified Files -- src/backend/executor/execUtils.c | 2 +- src/backend/executor/nodeModifyTable.c | 42 ++-- src/test/isolation/expected/eval-plan-qual.out | 304 + src/test/isolation/specs/eval-plan-qual.spec | 21 +- src/test/regress/expected/generated.out| 14 ++ src/test/regress/sql/generated.sql | 4 + 6 files changed, 221 insertions(+), 166 deletions(-)
pgsql: Fix some more cases of missed GENERATED-column updates.
Fix some more cases of missed GENERATED-column updates. If UPDATE is forced to retry after an EvalPlanQual check, it neglected to repeat GENERATED-column computations, even though those might well have changed since we're dealing with a different tuple than before. Fixing this is mostly a matter of looping back a bit further when we retry. In v15 and HEAD that's most easily done by altering the API of ExecUpdateAct so that it includes computing GENERATED expressions. Also, if an UPDATE in a partitioned table turns into a cross-partition INSERT operation, we failed to recompute GENERATED columns. That's a bug since 8bf6ec3ba allowed partitions to have different generation expressions; although it seems to have no ill effects before that. Fixing this is messier because we can now have situations where the same query needs both the UPDATE-aligned set of GENERATED columns and the INSERT-aligned set, and it's unclear which set will be generated first (else we could hack things by forcing the INSERT-aligned set to be generated, which is indeed how fe9e658f4 made it work for MERGE). The best fix seems to be to build and store separate sets of expressions for the INSERT and UPDATE cases. That would create ABI issues in the back branches, but so far it seems we can leave this alone in the back branches. Per bug #17823 from Hisahiro Kauchi. The first part of this affects all branches back to v12 where GENERATED columns were added. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4a94cbd02b2cc637c4a7636a1e7fefee43bff8f6 Modified Files -- src/backend/executor/execUtils.c | 2 +- src/backend/executor/nodeModifyTable.c | 30 +-- src/test/isolation/expected/eval-plan-qual.out | 304 + src/test/isolation/specs/eval-plan-qual.spec | 21 +- src/test/regress/expected/generated.out| 14 ++ src/test/regress/sql/generated.sql | 4 + 6 files changed, 210 insertions(+), 165 deletions(-)
pgsql: Improve cleanup phases in regression tests of pg_stat_statements
Improve cleanup phases in regression tests of pg_stat_statements As shaped, two DROP ROLE queries included in "user_activity" were showing in the reports for "wal". The intention is to keep each test isolated and independent, so this is incorrect. This commit adds some calls to pg_stat_statements_reset() to clean up the statistics once each test finishes, so as there are no risks of overlap in the reports for individial scenarios. The addition in "user_activity" fixes the output of "wal". The new resets done in "level_tracking" and "utility" are added for consistency with the rest, though they do not affect the stats generated in the other tests. Oversight in d0028e3. Reported-by: Andrei Zubkov Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9a714b9d6ec0a562bc9242ec17122321cd174588 Modified Files -- .../pg_stat_statements/expected/level_tracking.out| 6 ++ contrib/pg_stat_statements/expected/user_activity.out | 6 ++ contrib/pg_stat_statements/expected/utility.out | 6 ++ contrib/pg_stat_statements/expected/wal.out | 19 --- contrib/pg_stat_statements/sql/level_tracking.sql | 1 + contrib/pg_stat_statements/sql/user_activity.sql | 1 + contrib/pg_stat_statements/sql/utility.sql| 1 + 7 files changed, 29 insertions(+), 11 deletions(-)
pgsql: Fix incorrect comment in pg_get_partkeydef()
Fix incorrect comment in pg_get_partkeydef() The comment claimed the output of the function was prefixed by "PARTITION BY". This is incorrect. Author: Japin Li Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/meyp282mb166923b446ff5fe55b9dacb7b6...@meyp282mb1669.ausp282.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cf96907aadca454c4094819c2ecddee07eafe203 Modified Files -- src/backend/utils/adt/ruleutils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Make get_extension_schema() available
Make get_extension_schema() available This routine is able to retrieve the OID of the schema used with an extension (pg_extension.extnamespace), or InvalidOid if this information is not available. plpgsql_check embeds a copy of this code when performing checks on functions, as one out-of-core example. Author: Pavel Stehule Reviewed-by: Julien Rouhaud Discussion: https://postgr.es/m/cafj8prd+9x55hjdoi285jccjpc8uuy_d+fln5rpxggdz+4o...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e20b1ea1575cb523821d51e9934d8d6dab835335 Modified Files -- src/backend/commands/extension.c | 2 +- src/include/commands/extension.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-)
