Re: pgsql: Fix cross-version upgrade test breakage from commit fe07100e82.
On 2025-07-02 We 2:27 PM, Nathan Bossart wrote: Fix cross-version upgrade test breakage from commit fe07100e82. In commit fe07100e82, I renamed a couple of functions in test_dsm_registry to make it clear what they are testing. However, the buildfarm's cross-version upgrade tests run pg_upgrade with the test modules installed, so this caused errors like: ERROR: could not find function "get_val_in_shmem" in file ".../test_dsm_registry.so" To fix, revert those renames. I could probably get away with only un-renaming the C symbols, but I figured I'd avoid introducing function name mismatches. Also, AFAICT the buildfarm's cross-version upgrade tests do not run the test module tests post-upgrade, else we'll need to properly version the extension. It doesn't really run any sanity checks at all other than amchecks.. It just compares the pre- and post- upgrade dumps (with suitable modifications). So far that seems to have been enough. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
pgsql: Avoid uninitialized value error in TAP tests' Cluster->psql
Avoid uninitialized value error in TAP tests' Cluster->psql If the method is called in scalar context and we didn't pass in a stderr handle, one won't be created. However, some error paths assume that it exists, so in this case create a dummy stderr to avoid the resulting perl error. Per gripe from Oleg Tselebrovskiy and adapted from his patch. Discussion: https://postgr.es/m/378eac5de4b8ecb5be7bcdf2db9d2...@postgrespro.ru Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c3e28e9fd936b83dbb6dfb5003b6221d98f8469c Modified Files -- src/test/perl/PostgreSQL/Test/Cluster.pm | 8 1 file changed, 8 insertions(+)
pgsql: pg_restore cleanups
pg_restore cleanups . remove unnecessary oid_string list stuff . use pg_get_line_buf() instead of open-coding it . cleaner parsing of map.dat lines Reverts 2b69afbe50d add new list type simple_oid_string_list to fe-utils/simple_list Author: Álvaro Herrera Author: Andrew Dunstan Discussion: https://postgr.es/m/202504141220.343fmoxfsbj4@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/40b9c27014d90d77c61e8f5c77ddeb84fa9a6b69 Modified Files -- src/bin/pg_dump/pg_restore.c | 105 ++--- src/fe_utils/simple_list.c | 41 --- src/include/fe_utils/simple_list.h | 16 -- src/tools/pgindent/typedefs.list | 3 +- 4 files changed, 65 insertions(+), 100 deletions(-)
pgsql: Make AIO error test more portable
Make AIO error test more portable Alpine Linux's C library (musl) spells one error message differently. Reported-by: Wolfgang Walther Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/64e193f5dda2075ecc6356625992e190a4347df6 Modified Files -- src/test/modules/test_aio/t/001_aio.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Free memory properly in pg_restore.c
Free memory properly in pg_restore.c Thinko in commit 39729ec01d2. Mea maxima culpa. Per Mahendra Singh Thalor Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f09088a01d3372fdfe5da12dd0b2e24989f0caa6 Modified Files -- src/bin/pg_dump/pg_restore.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: pgsql: Fix fat fingering in 22cb6d28950
On 2025-04-11 Fr 3:24 PM, Mahendra Singh Thalor wrote: On Fri, 11 Apr 2025 at 04:38, Andrew Dunstan wrote: > > Fix fat fingering in 22cb6d28950 > > Per Rainier Vilela > > Branch > -- > master > > Details > --- > https://git.postgresql.org/pg/commitdiff/39729ec01d25dbe12e0dd8322c68f242650235c9 > > Modified Files > -- > src/bin/pg_dump/pg_restore.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Hi, This seems not a proper fix, rather this is adding a segfault. [...] Here, we are passing &q, but we can't free this by destroyStringInfo(&q); *Fix*: pg_free(q.data) Quite right. Clearly I was not having a good day on Thursday. Will fix. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com
pgsql: Fix fat fingering in 22cb6d28950
Fix fat fingering in 22cb6d28950 Per Rainier Vilela Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/39729ec01d25dbe12e0dd8322c68f242650235c9 Modified Files -- src/bin/pg_dump/pg_restore.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix memory leak in pg_restore.c
Fix memory leak in pg_restore.c Oversight in 1495eff7bdb Author: Ranier Vilela Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/22cb6d289500ef22163a9d7cf2afa496f41b4d4c Modified Files -- src/bin/pg_dump/pg_restore.c | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Further cleanup for directory creation on pg_dump/pg_dumpall
Further cleanup for directory creation on pg_dump/pg_dumpall Instead of two separate (and different) implementations, refactor to use a single common routine. Along the way, remove use of a hardcoded file permissions constant in favor of the common project setting for directory creation. Author: Mahendra Singh Thalor Discussion: https://postgr.es/m/cakytnapihl8x1h7xo-zojznc8ca66aevgvhc9zoth6dbh2i...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4170298b6ecff7ce697b81e13d9a81e3b825798c Modified Files -- src/bin/pg_dump/dumputils.c | 36 src/bin/pg_dump/dumputils.h | 1 + src/bin/pg_dump/pg_backup_directory.c | 36 ++-- src/bin/pg_dump/pg_dumpall.c | 39 +-- 4 files changed, 40 insertions(+), 72 deletions(-)
pgsql: Clean up error messages from 1495eff7bdb
Clean up error messages from 1495eff7bdb Quote file names, and mostly avoid hard coded file names. Along the way make a few other minor improvements. Discussion: https://postgr.es/m/20250407.152721.1397761902317499205.horikyota@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b52a4a5f285df49399fe6deefa1bf63dc88cd3d1 Modified Files -- src/bin/pg_dump/pg_dumpall.c | 2 +- src/bin/pg_dump/pg_restore.c | 16 +--- 2 files changed, 10 insertions(+), 8 deletions(-)
pgsql: Revert "Use workaround of __builtin_setjmp only on MINGW on MSVC
Revert "Use workaround of __builtin_setjmp only on MINGW on MSVCRT" This reverts commit c313fa4602defe1be947370ab5b217ca163a1e3c. This is found to cause issues on x86_64 Windows even when using UCRT. Discussion: https://postgr.es/m/3312149.1744001...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8f5e419484c3efb613d971ec25b9bf344db3d0b0 Modified Files -- src/include/c.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)
pgsql: Clean up checking for pg_dumpall output directory
Clean up checking for pg_dumpall output directory Coverity objected to the original code, and in any case this is much cleaner, using the existing routine pg_check_dir() instead of rolling its own test. Per suggestion from Tom Lane. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/643a1a61985bef25904965053020057200d4ae48 Modified Files -- src/bin/pg_dump/pg_dumpall.c | 58 +++- 1 file changed, 20 insertions(+), 38 deletions(-)
pgsql: Avoid unnecessary copying of a string in pg_restore.c
Avoid unnecessary copying of a string in pg_restore.c Coverity complained about a possible overrun in the copy, but there is no actual need to copy the string at all. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5e1915439085014140314979c4dd5e23bd677cac Modified Files -- src/bin/pg_dump/pg_restore.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Fix a couple of memory leaks in pg_restore.c
Fix a couple of memory leaks in pg_restore.c per complaint from Coverity. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6d5417e634b3841dcc44bdb43f5586bcde33ddb4 Modified Files -- src/bin/pg_dump/pg_restore.c | 4 1 file changed, 4 insertions(+)
pgsql: Show plperl version in the meson setup summary.
Show plperl version in the meson setup summary. Also, use perl 'version' instead of 'api_versionstring' to sync with the configure script. Author: Roman Zharkov Discussion: https://postgr.es/m/93e7f77bf4e1ef4640e4ee733f9e2...@postgrespro.ru Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/12604593e9f3b3460f7359a39d25731aff6beb88 Modified Files -- meson.build | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: Clean up from commit 1495eff7bdb
Clean up from commit 1495eff7bdb Fix some comments, and remove the hacky way of quoting database names in favor of appendStringLiteralConn. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5db3bf7391d77ae86bc9b5f580141e022803b744 Modified Files -- src/bin/pg_dump/pg_restore.c | 107 ++- 1 file changed, 24 insertions(+), 83 deletions(-)
pgsql: Fix a couple of error messages and tests for them
Fix a couple of error messages and tests for them oversights in 1495eff7bdb and 289f74d0cb2. Mea culpa. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2ef57908067ab29c22ae13f7775fe2afc330e8f6 Modified Files -- src/bin/pg_dump/pg_restore.c| 6 +++--- src/bin/pg_dump/t/001_basic.pl | 4 ++-- src/bin/pg_dump/t/006_pg_dumpall.pl | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-)
Re: pgsql: Add more TAP tests for pg_dumpall
On 2025-04-04 Fr 4:09 PM, Andrew Dunstan wrote: Add more TAP tests for pg_dumpall I changed an error message at the last moment and forgot to fix the test ... will fix cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
pgsql: Non text modes for pg_dumpall, correspondingly change pg_restore
Non text modes for pg_dumpall, correspondingly change pg_restore pg_dumpall acquires a new -F/--format option, with the same meanings as pg_dump. The default is p, meaning plain text. For any other value, a directory is created containing two files, globals.data and map.dat. The first contains SQL for restoring the global data, and the second contains a map from oids to database names. It will also contain a subdirectory called databases, inside which it will create archives in the specified format, named using the database oids. In these casess the -f argument is required. If pg_restore encounters a directory containing globals.dat, and no toc.dat, it restores the global settings and then restores each database. pg_restore acquires two new options: -g/--globals-only which suppresses restoration of any databases, and --exclude-database which inhibits restoration of particualr database(s) in the same way the same option works in pg_dumpall. Author: Mahendra Singh Thalor Co-authored-by: Andrew Dunstan Reviewed-by: jian he Reviewed-by: Srinath Reddy Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/cb103623-8ee6-4ba5-a2c9-f32e3a493...@dunslane.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1495eff7bdb0779cc54ca04f3bd768f647240df2 Modified Files -- doc/src/sgml/ref/pg_dumpall.sgml | 86 +++- doc/src/sgml/ref/pg_restore.sgml | 66 ++- src/bin/pg_dump/parallel.c | 10 + src/bin/pg_dump/pg_backup.h | 2 +- src/bin/pg_dump/pg_backup_archiver.c | 20 +- src/bin/pg_dump/pg_backup_archiver.h | 1 + src/bin/pg_dump/pg_backup_tar.c | 2 +- src/bin/pg_dump/pg_dump.c| 2 +- src/bin/pg_dump/pg_dumpall.c | 294 +++-- src/bin/pg_dump/pg_restore.c | 794 ++- src/bin/pg_dump/t/001_basic.pl | 9 + 11 files changed, 1201 insertions(+), 85 deletions(-)
pgsql: Add more TAP tests for pg_dumpall
Add more TAP tests for pg_dumpall Author: Matheus Alcantara Author: Mahendra Singh Thalor Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/289f74d0cb247ebdb443fec65fb2500531c961b4 Modified Files -- src/bin/pg_dump/meson.build | 1 + src/bin/pg_dump/t/001_basic.pl | 10 + src/bin/pg_dump/t/006_pg_dumpall.pl | 391 3 files changed, 402 insertions(+)
pgsql: add new list type simple_oid_string_list to fe-utils/simple_list
add new list type simple_oid_string_list to fe-utils/simple_list This type contains both an oid and a string. This will be used in forthcoming changes to pg_restore. Author: Andrew Dunstan Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2b69afbe50d5e39cc7d9703b3ab7acc4495a54ea Modified Files -- src/fe_utils/simple_list.c | 41 ++ src/include/fe_utils/simple_list.h | 16 +++ src/tools/pgindent/typedefs.list | 2 ++ 3 files changed, 59 insertions(+)
pgsql: Move common pg_dump code related to connections to a new file
Move common pg_dump code related to connections to a new file ConnectDatabase is used by pg_dumpall, pg_restore and pg_dump so move common code to new file. new file name: connectdb.c Author:Mahendra Singh Thalor Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c1da7281060d646f863e920a1aac3b9dbc997672 Modified Files -- src/bin/pg_dump/Makefile | 5 +- src/bin/pg_dump/connectdb.c | 294 +++ src/bin/pg_dump/connectdb.h | 26 src/bin/pg_dump/meson.build | 1 + src/bin/pg_dump/pg_backup.h | 6 +- src/bin/pg_dump/pg_backup_archiver.c | 6 +- src/bin/pg_dump/pg_backup_db.c | 79 ++ src/bin/pg_dump/pg_dump.c| 2 +- src/bin/pg_dump/pg_dumpall.c | 278 ++--- 9 files changed, 352 insertions(+), 345 deletions(-)
pgsql: Use workaround of __builtin_setjmp only on MINGW on MSVCRT
Use workaround of __builtin_setjmp only on MINGW on MSVCRT MSVCRT is not present Windows/ARM64 and the workaround is not necessary on any UCRT based toolchain. Author: Lars Kanis Discussion: https://postgr.es/m/cahxcyb2ojnhtogvkyxtxmw4b3buxwjx6m-lcp1kcmcrumlo...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c313fa4602defe1be947370ab5b217ca163a1e3c Modified Files -- src/include/c.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)
pgsql: Silence perl critic
Silence perl critic Commit 27bdec06841 uses a loop variable that is not strictly local to the loop. Perlcritic disapproves, and there's really no reason as the variable is not used outside the loop. Per buildfarm animals koel and crake. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5eabd91a83adae75f53b61857343660919fef4c7 Modified Files -- src/common/unicode/generate-unicode_case_table.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Re: pgsql: tests: Fix race condition in postmaster/002_connection_limits
On 2025-03-07 Fr 1:22 PM, Andres Freund wrote: tests: Fix race condition in postmaster/002_connection_limits The test occasionally failed due to unexpected connection limit errors being encountered after having waited for FATAL errors on another connection. These spurious failures were caused by the the backend reporting FATAL errors to the client before detaching from the PGPROC entry. Adding a sleep(1) before proc_exit() makes it easy to reproduce that problem. To fix the issue, add a helper function that waits for postmaster to notice the process having exited. For now this is implemented by waiting for the DEBUG2 message that postmaster logs in that case. That's not the prettiest fix, but simple. If we notice this problem elsewhere, it might be worthwhile to make this more general, e.g. by adding an injection point. New test breaks when log_error_verbosity=verbose. It's adding an SQL ERRCODE to the DEBUG string. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
pgsql: Further fix for json_strip_nulls documentation
Further fix for json_strip_nulls documentation Oversight in commit 4603903d294. Author: Shinoda, Noriyoshi (SXD Japan FSI) Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e33969abc1934cc7fd92d539e51a2b8ae46d6a33 Modified Files -- doc/src/sgml/func.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Remove extraneous commas in json{b}_strip_nulls documentation
Remove extraneous commas in json{b}_strip_nulls documentation
Oversight in commit 4603903d294.
Author: Ian Lawrence Barwick
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/0e76f253f4f0bf3d8a85e88dbea62a09be1f3ff8
Modified Files
--
doc/src/sgml/func.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Allow json{b}_strip_nulls to remove null array elements
Allow json{b}_strip_nulls to remove null array elements
An additional paramater ("strip_in_arrays") is added to these functions.
It defaults to false. If true, then null array elements are removed as
well as null valued object fields. JSON that just consists of a single
null is not affected.
Author: Florents Tselai
Discussion: https://postgr.es/m/4bceccd5-4f40-4313-9e98-9e16beb0b...@gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4603903d294bbdd644afecf9b5970827db6d1ff5
Modified Files
--
doc/src/sgml/func.sgml | 17 +++
src/backend/catalog/system_functions.sql | 14 +
src/backend/utils/adt/jsonfuncs.c| 27 +++--
src/include/catalog/pg_proc.dat | 4 +--
src/test/regress/expected/json.out | 50
src/test/regress/expected/jsonb.out | 50
src/test/regress/sql/json.sql| 19
src/test/regress/sql/jsonb.sql | 18
8 files changed, 190 insertions(+), 9 deletions(-)
Re: pgsql: Refactor COPY FROM to use format callback functions.
On 2025-02-28 Fr 5:39 PM, Masahiko Sawada wrote:
On Fri, Feb 28, 2025 at 2:16 PM Sutou Kouhei wrote:
Hi,
Thanks for following up the patch!
In
"Re: pgsql: Refactor COPY FROM to use format callback functions." on Fri, 28
Feb 2025 12:56:19 -0800,
Masahiko Sawada wrote:
Right. I've attached the updated patch.
In general, this approach will work but could you keep
the same signature for backward compatibility?
--- a/src/backend/commands/copyfromparse.c
+++ b/src/backend/commands/copyfromparse.c
+bool
+NextCopyFromRawFields(CopyFromState cstate, char ***fields, int *nfields, bool
is_csv)
+{
+ return NextCopyFromRawFieldsInternal(cstate, fields, nfields, is_csv);
+}
NextCopyFromRawFields() uses
NextCopyFromRawFields(CopyFromState cstate, char ***fields,
int *nfields) (no "bool is_csv") before we remove it. So
could you use the no "bool is_csv" signature for backward
compatibility?
bool
NextCopyFromRawFields(CopyFromState cstate, char ***fields, int *nfields)
{
return NextCopyFromRawFieldsInternal(cstate, fields, nfields,
cstate->opts.csv_mode);
}
I like this idea.
@@ -738,6 +742,15 @@ CopyReadBinaryData(CopyFromState cstate, char *dest, int
nbytes)
/*
* Read raw fields in the next line for COPY FROM in text or csv mode.
* Return false if no more lines.
+ */
+bool
+NextCopyFromRawFields(CopyFromState cstate, char ***fields, int *nfields, bool
is_csv)
+{
+ return NextCopyFromRawFieldsInternal(cstate, fields, nfields, is_csv);
+}
+
+/*
+ * Workhorse for NextCopyFromRawFields().
It may be better that we don't split docs for
NextCopyFromRawFields() and
NextCopyFromRawFieldsInternal(). How about referring the
NextCopyFromRawFieldsInternal() doc from the
NextCopyFromRawFields() doc something like the following?
/*
* See NextCopyFromRawFieldsInternal() for details.
*/
bool
NextCopyFromRawFields(...)
{
...
}
/*
* Workhorse for NextCopyFromRawFields().
*
* Read raw fields ...
*
* ...
*/
static pg_attribute_always_inline bool
NextCopyFromRawFieldsInternal()
{
...
}
Agreed.
I've updated the patch. I'm going to push it, barring any objections
and further comments.
I'm OK either way - I have made changes to adapt to the API change, and
tested them.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Re: pgsql: Refactor COPY FROM to use format callback functions.
On 2025-02-28 Fr 2:55 PM, Masahiko Sawada wrote: On Fri, Feb 28, 2025 at 11:47 AM Andrew Dunstan wrote: On 2025-02-28 Fr 1:31 PM, Masahiko Sawada wrote: Refactor COPY FROM to use format callback functions. This commit introduces a new CopyFromRoutine struct, which is a set of callback routines to read tuples in a specific format. It also makes COPY FROM with the existing formats (text, CSV, and binary) utilize these format callbacks. This change is a preliminary step towards making the COPY FROM command extensible in terms of input formats. Similar to 2e4127b6d2d, this refactoring contributes to a performance improvement by reducing the number of "if" branches that need to be checked on a per-row basis when sending field representations in text or CSV mode. The performance benchmark results showed ~5% performance gain in text or CSV mode. Author: Sutou Kouhei Reviewed-by: Masahiko Sawada Reviewed-by: Michael Paquier Reviewed-by: Andres Freund Reviewed-by: Tomas Vondra Reviewed-by: Junwang Zhao Discussion: https://postgr.es/m/20231204.153548.2126325458835528809@clear-code.com This patch has completely broken the file_textarray fdw, which uses NextCopyFromRawFields(). Removing that from API is not a good thing. Thank you for pointing it out. I've just posted my analysis[1] and am planning to revive that API (Sutou-san already proposed an idea). Could you please check if the idea would work for file_text_array_fdw? Looks OK, I think. You could even use the Internal function further down in the file and avoid a function call. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Re: pgsql: Trial fix for old cross-version upgrades.
On 2025-02-28 Fr 2:29 PM, Sami Imseih wrote:
My perl expertise is bit shallow, but I could not find much
regarding bugs related to such behavior, or maybe I did not
look enough.
Playing around with this, "s+", "s{1,}", s{2,}" all of these combinations
where we are searching for more than 1 space result in the hanging command,
but we really only need to look for a single space before the 'version',
so maybe we can just do the below, which works?
- $dump =~ s {(^\s+'version',) '\d+'::integer,$}
+ $dump =~ s {(^\s{1}'version',) '\d+'::integer,$}
Just noting here that \s{1} is simply the same as \s
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Re: pgsql: Refactor COPY FROM to use format callback functions.
On 2025-02-28 Fr 1:31 PM, Masahiko Sawada wrote: Refactor COPY FROM to use format callback functions. This commit introduces a new CopyFromRoutine struct, which is a set of callback routines to read tuples in a specific format. It also makes COPY FROM with the existing formats (text, CSV, and binary) utilize these format callbacks. This change is a preliminary step towards making the COPY FROM command extensible in terms of input formats. Similar to 2e4127b6d2d, this refactoring contributes to a performance improvement by reducing the number of "if" branches that need to be checked on a per-row basis when sending field representations in text or CSV mode. The performance benchmark results showed ~5% performance gain in text or CSV mode. Author: Sutou Kouhei Reviewed-by: Masahiko Sawada Reviewed-by: Michael Paquier Reviewed-by: Andres Freund Reviewed-by: Tomas Vondra Reviewed-by: Junwang Zhao Discussion:https://postgr.es/m/20231204.153548.2126325458835528809@clear-code.com This patch has completely broken the file_textarray fdw, which uses NextCopyFromRawFields(). Removing that from API is not a good thing. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com
Re: pgsql: Trial fix for old cross-version upgrades.
On 2025-02-22 Sa 9:20 PM, Tom Lane wrote: I wrote: Furthermore, it can't be a coincidence that the four tables we are seeing relallvisible diffs for are exactly the four tables in the regression database that have hash indexes. Oh! If the source version is <= 9.6, old_9_6_invalidate_hash_indexes() generates a script "reindex_hash.sql" to reindex all hash indexes. And TestUpgradeXversion faithfully executes that, *before* making the new-database comparison dump. I added some instrumentation and confirmed that these tables' relallvisible values match between the pre-dump state on the old database and the immediately-post-upgrade state on the new database. It's definitely reindex_hash.sql that's changing them. This doesn't in itself explain why 9.3-9.5 don't show the problem, but I noticed something interesting: it's the pre-dump state that is out of line in 9.2 and 9.6. All the other cases show relallvisible that's a couple pages less than relpages, but in those two branches we start from a state that claims these rels are fully all-visible, and then seemingly REINDEX discovers that that's not so. What I'm guessing is that the variance is due to changes in vacuum/analyze's heuristics for updating pg_class.relallvisible after a partial scan of the table. Anyway, we know where the culprit is, and I'm not sure that explaining the differences in behavior of long-dead branches is an exciting use of time. Question is, what to do about this? We probably want to continue to test that reindex_hash.sql does something sane, so just deleting that step won't do. I experimented with moving it from immediately before the pg_dumpall of the new installation to immediately after, but that didn't work at all: the indexes are marked invalid and so pg_dump just doesn't dump them, so we still end up with a diff in the dump output. I'm not really seeing a better answer than hacking the comparison rules to ignore the relallvisible difference for these tables. That's darn ugly, and I suspect the implementation will be messy, but do we have another way? Having slept on it I can't see anything better. It's only for very old branches, and nothing is really going wrong here, so ignoring the difference seems quite reasonable. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com
Re: pgsql: Trial fix for old cross-version upgrades.
On 2025-02-22 Sa 1:34 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 2025-02-21 Fr 10:11 PM, Tom Lane wrote:
... It seems there is
something different between what TestUpgradeXversion.pm is doing
and what 002_pg_upgrade.pl is doing. No clue what, although it
does look like an additional round of analyze'ing has added more
stats than were there before.
Hah! Looking at the script with less bleary eyes, I see it does
this after pg_upgrade:
if (-e "$installdir/analyze_new_cluster.sh")
{
system( "cd $installdir && sh ./analyze_new_cluster.sh "
. qq{> "$upgrade_loc/$oversion-analyse.log" 2>&1 });
return if $?;
}
else
{
system( qq{"$installdir/bin/vacuumdb" --all --analyze-only }
. qq{> "$upgrade_loc/$oversion-analyse.log" 2>&1 });
return if $?;
}
So there's our extra round of ANALYZE right there. I diked out the
vacuumdb call and things are working much better. It seems to pass
for branches back through 9.3, and upgrade from 9.2 has only some
diffs for relallvisible (see attached). We still need to figure out
why that is, but a quick-n-dirty patch could just be to make the dump
comparison logic ignore relallvisible diffs.
We might want to make this vacuumdb invocation dependent on version,
but I could also see just removing it entirely.
Here's what I have so far:
. for HEAD/18 disable running the analyze script / vacuumdb --analyze.
. turn off autovacuum on the old and upgraded database.
. reverse the order of testing so we do newest first
Check.
What I'm thinking of doing is running all the eligible upgrades rather
than stopping on the first failure.
Seems like possibly wasted work --- I'd be content with
newest-to-oldest.
OK, went with that. crake is getting a failure at 9.6 like you saw with
9.2, but things are a whole lot better than they were.
I have updated drongo and fairywren with the new code too, so they
should also improve before long.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Re: pgsql: Trial fix for old cross-version upgrades.
On 2025-02-21 Fr 10:11 PM, Tom Lane wrote: Jeff Davis writes: In 002_pg_upgrade.pl, I disabled autovacuum and restarted after the regression run. In other words, in the old cluster, autovacuum did have a chance to run, just not after the first dumpall. The hack I posted should prevent autovacuum from running either before or after dumping, in either cluster. However, it occurred to me to try forcing a HEAD-to-HEAD upgrade, a case the buildfarm animals have not been able to reach. And *it failed*!? (Diffs attached.) So that eliminates the theory that this is a cross-version compatibility problem, or at least that is not our only problem. It seems there is something different between what TestUpgradeXversion.pm is doing and what 002_pg_upgrade.pl is doing. No clue what, although it does look like an additional round of analyze'ing has added more stats than were there before. Yeah, I don't know. Here's what I have so far: . for HEAD/18 disable running the analyze script / vacuumdb --analyze. . turn off autovacuum on the old and upgraded database. . reverse the order of testing so we do newest first What I'm thinking of doing is running all the eligible upgrades rather than stopping on the first failure. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Re: pgsql: Transfer statistics during pg_upgrade.
On 2025-02-20 Th 4:29 AM, Jeff Davis wrote: Transfer statistics during pg_upgrade. Small nit. I notice this commit has introduced a couple of dubious uses of "mututally exclusive": doc/src/sgml/ref/pg_dump.sgml: This option is mutually exclusive to --data-only doc/src/sgml/ref/pg_dump.sgml- and --statistics-only. -- doc/src/sgml/ref/pg_restore.sgml: This option is mutually exclusive of --data-only doc/src/sgml/ref/pg_restore.sgml- and --statistics-only. I don't think this is idiomatic usage, and it's possibly not correct usage. At best it is jarring. One does not normally follow "mutually exclusive" with a preposition. I would replace the these with something like "This option cannot be used with ...". If you want to use the phrase, it should be something like "This option and ... are mutually exclusive." cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
pgsql: Ignore blank lines in pgindent exclude files
Ignore blank lines in pgindent exclude files Currently a blank line matches everything, which is almost never what someone would want. If they really want that they can use a wildcard regex to do it. Author: Zsolt Parragi Discussion: https://postgr.es/m/CAN4CZFNka+2q3=-dithr4w65rjfwpav92t62spezln+t4mg...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8e4d72573cc8b8bdc081661c0a3a76d6573eaa38 Modified Files -- src/tools/pgindent/pgindent | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Be clearer about when jsonapi's need_escapes is needed
Be clearer about when jsonapi's need_escapes is needed Most operations beyond pure json parsing need to set need_escapes to true to get access to field names and string scalars. Document this fact more explicitly. Slightly tweaked patch from: Author: Corey Huinker Discussion: https://postgr.es/m/CADkLM=c49vkfg2+a8ubsuetagejuakzxca6srxa8kdwhjx3...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ea5ff5833c7d4ae727a5acfc590c848b520775d0 Modified Files -- src/common/jsonapi.c | 6 +- src/include/common/jsonapi.h | 15 +-- 2 files changed, 18 insertions(+), 3 deletions(-)
pgsql: Fix readlink() for non-PostgreSQL junction points on Windows.
Fix readlink() for non-PostgreSQL junction points on Windows. Since commit c5cb8f3b taught stat() to follow symlinks, and since initdb uses pg_mkdir_p(), and that examines parent directories, our humble readlink() implementation can now be exposed to junction points not of PostgreSQL origin. Those might be corrupted by our naive path mangling, which doesn't really understand NT paths in general. Simply decline to transform paths that don't look like a drive absolute path. That means that readlink() returns the NT path directly when checking a parent directory of PGDATA that happen to point to a drive using "rooted" format. That works for the purposes of our stat() emulation. Reported-by: Roman Zharkov Reviewed-by: Roman Zharkov Discussion: https://postgr.es/m/4590c37927d7b8ee84f9855d83229018%40postgrespro.ru Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com Backpatched commit f71007fb as above by Thomas Munro into releases 13 thru 15 Discussion: https://postgr.es/m/ca+hukglbnv+pe3q1fyovkld3pmra7guihfmxun-1831yh9r...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9b136b0f2e531e41d1949fba3f618405adfcef02 Author: Thomas Munro Modified Files -- src/port/dirmod.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-)
pgsql: Fix stat() for recursive junction points on Windows.
Fix stat() for recursive junction points on Windows. Commit c5cb8f3b supposed that we'd only ever have to follow one junction point in stat(), because we don't construct longer chains of them ourselves. When examining a parent directory supplied by the user, we should really be able to cope with longer chains, just in case someone has their system set up that way. Choose an arbitrary cap of 8, to match the minimum acceptable value of SYMLOOP_MAX in POSIX. Previously I'd avoided reporting ELOOP thinking Windows didn't have it, but it turns out that it does, so we can use the proper error number. Reviewed-by: Roman Zharkov Discussion: https://postgr.es/m/CA%2BhUKGJ7JDGWYFt9%3D-TyJiRRy5q9TtPfqeKkneWDr1XPU1%2Biqw%40mail.gmail.com Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com Backpatched commit 4517358e as above by Thomas Munro into releases 13 thru 15 Discussion: https://postgr.es/m/ca+hukglbnv+pe3q1fyovkld3pmra7guihfmxun-1831yh9r...@mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fbf8efbda88ce3cac6b135cbba93d4ee7c80dde8 Author: Thomas Munro Modified Files -- src/port/win32stat.c | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-)
pgsql: Fix stat() for recursive junction points on Windows.
Fix stat() for recursive junction points on Windows. Commit c5cb8f3b supposed that we'd only ever have to follow one junction point in stat(), because we don't construct longer chains of them ourselves. When examining a parent directory supplied by the user, we should really be able to cope with longer chains, just in case someone has their system set up that way. Choose an arbitrary cap of 8, to match the minimum acceptable value of SYMLOOP_MAX in POSIX. Previously I'd avoided reporting ELOOP thinking Windows didn't have it, but it turns out that it does, so we can use the proper error number. Reviewed-by: Roman Zharkov Discussion: https://postgr.es/m/CA%2BhUKGJ7JDGWYFt9%3D-TyJiRRy5q9TtPfqeKkneWDr1XPU1%2Biqw%40mail.gmail.com Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com Backpatched commit 4517358e as above by Thomas Munro into releases 13 thru 15 Discussion: https://postgr.es/m/ca+hukglbnv+pe3q1fyovkld3pmra7guihfmxun-1831yh9r...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9f1c67488e59b9b8a1791e75783f7a817216259d Author: Thomas Munro Modified Files -- src/port/win32stat.c | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-)
pgsql: Fix readlink() for non-PostgreSQL junction points on Windows.
Fix readlink() for non-PostgreSQL junction points on Windows. Since commit c5cb8f3b taught stat() to follow symlinks, and since initdb uses pg_mkdir_p(), and that examines parent directories, our humble readlink() implementation can now be exposed to junction points not of PostgreSQL origin. Those might be corrupted by our naive path mangling, which doesn't really understand NT paths in general. Simply decline to transform paths that don't look like a drive absolute path. That means that readlink() returns the NT path directly when checking a parent directory of PGDATA that happen to point to a drive using "rooted" format. That works for the purposes of our stat() emulation. Reported-by: Roman Zharkov Reviewed-by: Roman Zharkov Discussion: https://postgr.es/m/4590c37927d7b8ee84f9855d83229018%40postgrespro.ru Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com Backpatched commit f71007fb as above by Thomas Munro into releases 13 thru 15 Discussion: https://postgr.es/m/ca+hukglbnv+pe3q1fyovkld3pmra7guihfmxun-1831yh9r...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f4fd5325cc870cc7563703ed2dc3661139cf5d13 Author: Thomas Munro Modified Files -- src/port/dirmod.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-)
pgsql: Fix stat() for recursive junction points on Windows.
Fix stat() for recursive junction points on Windows. Commit c5cb8f3b supposed that we'd only ever have to follow one junction point in stat(), because we don't construct longer chains of them ourselves. When examining a parent directory supplied by the user, we should really be able to cope with longer chains, just in case someone has their system set up that way. Choose an arbitrary cap of 8, to match the minimum acceptable value of SYMLOOP_MAX in POSIX. Previously I'd avoided reporting ELOOP thinking Windows didn't have it, but it turns out that it does, so we can use the proper error number. Reviewed-by: Roman Zharkov Discussion: https://postgr.es/m/CA%2BhUKGJ7JDGWYFt9%3D-TyJiRRy5q9TtPfqeKkneWDr1XPU1%2Biqw%40mail.gmail.com Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com Backpatched commit 4517358e as above by Thomas Munro into releases 13 thru 15 Discussion: https://postgr.es/m/ca+hukglbnv+pe3q1fyovkld3pmra7guihfmxun-1831yh9r...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e708f31881fd767af6d665968f6124ab82a08962 Author: Thomas Munro Modified Files -- src/port/win32stat.c | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-)
pgsql: Fix readlink() for non-PostgreSQL junction points on Windows.
Fix readlink() for non-PostgreSQL junction points on Windows. Since commit c5cb8f3b taught stat() to follow symlinks, and since initdb uses pg_mkdir_p(), and that examines parent directories, our humble readlink() implementation can now be exposed to junction points not of PostgreSQL origin. Those might be corrupted by our naive path mangling, which doesn't really understand NT paths in general. Simply decline to transform paths that don't look like a drive absolute path. That means that readlink() returns the NT path directly when checking a parent directory of PGDATA that happen to point to a drive using "rooted" format. That works for the purposes of our stat() emulation. Reported-by: Roman Zharkov Reviewed-by: Roman Zharkov Discussion: https://postgr.es/m/4590c37927d7b8ee84f9855d83229018%40postgrespro.ru Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com Backpatched commit f71007fb as above by Thomas Munro into releases 13 thru 15 Discussion: https://postgr.es/m/ca+hukglbnv+pe3q1fyovkld3pmra7guihfmxun-1831yh9r...@mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2c4a532c96a948e26b25e3260d155c1ec245c2ae Author: Thomas Munro Modified Files -- src/port/dirmod.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-)
pgsql: Set exit status for pgindent if pg_bsd_indent fails
Set exit status for pgindent if pg_bsd_indent fails Also document the exit codes in the script. The new exit code is 3, and is not overridden by the exit code set in --check mode. Author: Ashutosh Bapat Discussion: https://postgr.es/m/caexhw5sprsifeldp-u1fa5ba7ys2f0gvljmkoobopkadjwq...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b20fe54c9c2194fec65db73b2778a014e7823ae0 Modified Files -- src/tools/pgindent/pgindent | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: Document strange jsonb sort order for empty top level arrays
Document strange jsonb sort order for empty top level arrays Slightly faulty logic in the original jsonb code (commit d9134d0a355) results in an empty top level array sorting less than a json null. We can't change the sort order now since it would affect btree indexes over jsonb, so document the anomaly. Backpatch to all live branches (13 .. 17) In master, also add a code comment noting the anomaly. Reported-by: Yan Chengpen Reviewed-by: Jian He Discussion: https://postgr.es/m/osbpr01mb45199dd8da2d1cecd50518188e...@osbpr01mb4519.jpnprd01.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/30f017626308a06cf0c0c82a706a1ba1b07df34a Modified Files -- doc/src/sgml/json.sgml | 3 ++- src/backend/utils/adt/jsonb_util.c | 7 +++ 2 files changed, 9 insertions(+), 1 deletion(-)
pgsql: Document strange jsonb sort order for empty top level arrays
Document strange jsonb sort order for empty top level arrays Slightly faulty logic in the original jsonb code (commit d9134d0a355) results in an empty top level array sorting less than a json null. We can't change the sort order now since it would affect btree indexes over jsonb, so document the anomaly. Backpatch to all live branches (13 .. 17) In master, also add a code comment noting the anomaly. Reported-by: Yan Chengpen Reviewed-by: Jian He Discussion: https://postgr.es/m/osbpr01mb45199dd8da2d1cecd50518188e...@osbpr01mb4519.jpnprd01.prod.outlook.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/591128f9c9c0e0b9c511c5eba6f889bd1daf3c4c Modified Files -- doc/src/sgml/json.sgml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Document strange jsonb sort order for empty top level arrays
Document strange jsonb sort order for empty top level arrays Slightly faulty logic in the original jsonb code (commit d9134d0a355) results in an empty top level array sorting less than a json null. We can't change the sort order now since it would affect btree indexes over jsonb, so document the anomaly. Backpatch to all live branches (13 .. 17) In master, also add a code comment noting the anomaly. Reported-by: Yan Chengpen Reviewed-by: Jian He Discussion: https://postgr.es/m/osbpr01mb45199dd8da2d1cecd50518188e...@osbpr01mb4519.jpnprd01.prod.outlook.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/653729ce0ec1c38b444740637896d6ec706ef13a Modified Files -- doc/src/sgml/json.sgml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Document strange jsonb sort order for empty top level arrays
Document strange jsonb sort order for empty top level arrays Slightly faulty logic in the original jsonb code (commit d9134d0a355) results in an empty top level array sorting less than a json null. We can't change the sort order now since it would affect btree indexes over jsonb, so document the anomaly. Backpatch to all live branches (13 .. 17) In master, also add a code comment noting the anomaly. Reported-by: Yan Chengpen Reviewed-by: Jian He Discussion: https://postgr.es/m/osbpr01mb45199dd8da2d1cecd50518188e...@osbpr01mb4519.jpnprd01.prod.outlook.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9577dd523b3e3bb7fba66e708dfb9ca76e299b7e Modified Files -- doc/src/sgml/json.sgml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Document strange jsonb sort order for empty top level arrays
Document strange jsonb sort order for empty top level arrays Slightly faulty logic in the original jsonb code (commit d9134d0a355) results in an empty top level array sorting less than a json null. We can't change the sort order now since it would affect btree indexes over jsonb, so document the anomaly. Backpatch to all live branches (13 .. 17) In master, also add a code comment noting the anomaly. Reported-by: Yan Chengpen Reviewed-by: Jian He Discussion: https://postgr.es/m/osbpr01mb45199dd8da2d1cecd50518188e...@osbpr01mb4519.jpnprd01.prod.outlook.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/20a344bce8949f542eb25360fe69f14aa9a05b1b Modified Files -- doc/src/sgml/json.sgml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Document strange jsonb sort order for empty top level arrays
Document strange jsonb sort order for empty top level arrays Slightly faulty logic in the original jsonb code (commit d9134d0a355) results in an empty top level array sorting less than a json null. We can't change the sort order now since it would affect btree indexes over jsonb, so document the anomaly. Backpatch to all live branches (13 .. 17) In master, also add a code comment noting the anomaly. Reported-by: Yan Chengpen Reviewed-by: Jian He Discussion: https://postgr.es/m/osbpr01mb45199dd8da2d1cecd50518188e...@osbpr01mb4519.jpnprd01.prod.outlook.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bd606ed8ec65f7ad388c3dead9ba200bf0b4fa6a Modified Files -- doc/src/sgml/json.sgml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: jsonapi: add lexer option to keep token ownership
jsonapi: add lexer option to keep token ownership Commit 0785d1b8b adds support for libpq as a JSON client, but allocations for string tokens can still be leaked during parsing failures. This is tricky to fix for the object_field semantic callbacks: the field name must remain valid until the end of the object, but if a parsing error is encountered partway through, object_field_end() won't be invoked and the client won't get a chance to free the field name. This patch adds a flag to switch the ownership of parsed tokens to the lexer. When this is enabled, the client must make a copy of any tokens it wants to persist past the callback lifetime, but the lexer will handle necessary cleanup on failure. Backend uses of the JSON parser don't need to use this flag, since the parser's allocations will occur in a short lived memory context. A -o option has been added to test_json_parser_incremental to exercise the new setJsonLexContextOwnsTokens() API, and the test_json_parser TAP tests make use of it. (The test program now cleans up allocated memory, so that tests can be usefully run under leak sanitizers.) Author: Jacob Champion Discussion: https://postgr.es/m/caoymi+kb38eciwybqof9peapkgwrahqa7pgzbkvounw5brf...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5c32c21afe6449a19b6dfafa17f29b71c9595e03 Modified Files -- src/common/jsonapi.c | 102 +++-- src/include/common/jsonapi.h | 28 +- .../t/001_test_json_parser_incremental.pl | 13 ++- src/test/modules/test_json_parser/t/002_inline.pl | 15 +-- .../test_json_parser/t/003_test_semantic.pl| 11 ++- .../test_json_parser_incremental.c | 37 ++-- 6 files changed, 173 insertions(+), 33 deletions(-)
pgsql: Fix meson uuid header check so it works with MSVC
Fix meson uuid header check so it works with MSVC The OSSP uuid.h file includes unistd.h, so to use it with MSVC we need to include the postgres include directories so it picks up our version of that in src/include/port/win32_msvc. Adjust the meson test accordingly. Backported from commit 7c655a04a2, so we can build release 16 with UUID per request from Marina Polyakova Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1250adfdf07da7eb6e1f629d7ffafd8372e0ad6d Modified Files -- meson.build | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
Re: pgsql: Release notes for 17.1, 16.5, 15.9, 14.14, 13.17, 12.21.
On Mon, Nov 11, 2024 at 10:25 AM Andrew Dunstan wrote: > > > On Mon, Nov 11, 2024 at 5:11 AM Tom Lane wrote: > >> Release notes for 17.1, 16.5, 15.9, 14.14, 13.17, 12.21. >> >> Branch >> -- >> REL_17_STABLE >> >> Details >> --- >> >> https://git.postgresql.org/pg/commitdiff/ca19f881b071fa57ee469fbc27b520fbb0c67280 >> >> Modified Files >> -- >> doc/src/sgml/release-17.sgml | 707 >> ++- >> 1 file changed, 28 insertions(+), 679 deletions(-) >> > > > Unless I'm reading it wrong, there seems to be something odd about the > release 17 notes. The draft changes appear to have been wiped out. > > > Never mind, I see what's going on. Sorry for the noise. cheers andrew
Re: pgsql: Release notes for 17.1, 16.5, 15.9, 14.14, 13.17, 12.21.
On Mon, Nov 11, 2024 at 5:11 AM Tom Lane wrote: > Release notes for 17.1, 16.5, 15.9, 14.14, 13.17, 12.21. > > Branch > -- > REL_17_STABLE > > Details > --- > > https://git.postgresql.org/pg/commitdiff/ca19f881b071fa57ee469fbc27b520fbb0c67280 > > Modified Files > -- > doc/src/sgml/release-17.sgml | 707 > ++- > 1 file changed, 28 insertions(+), 679 deletions(-) > Unless I'm reading it wrong, there seems to be something odd about the release 17 notes. The draft changes appear to have been wiped out. cheers andrew
Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.
On Sat, Nov 9, 2024 at 11:20 AM Thomas Munro wrote: > On Sat, Nov 9, 2024 at 9:30 AM Andrew Dunstan wrote: > > My impression was that this was something we just didn't get around to. > I wouldn't have pushed these so close to release if this hadn't been code > already tested for a long time in release 16+. Maybe we missed something, > but I doubt it. > > c5cb8f3b did have a couple more follow-ups: 4517358e and f71007fb. > These fixed initdb when run under a junction point: > > > https://www.postgresql.org/message-id/4590c37927d7b8ee84f9855d83229018%40postgrespro.ru Oh, ouch. I guess it's too late to add those for this release. Still, an initdb failure is not as bad as a pg_rewind failure, IMNSHO. cheers andrew
Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.
On Sat, Nov 9, 2024 at 2:33 AM Tom Lane wrote: > Robert Haas writes: > > On Thu, Nov 7, 2024 at 6:19 PM Andrew Dunstan > wrote: > >> Juan José Santamaría Flecha, reviewed by Emil Iggland; > >> based on prior work by Michael Paquier, Sergey Zubkovsky, and others > >> > >> Author: Alexandra Wang > > > This authorship information is confusing. > > Yes. Worse, there is no link to what prompted this sudden burst > of back-patches of years-old commits. After digging around I guess > it was this thread: > > > https://www.postgresql.org/message-id/flat/CA%2BpA0kLc5VxOaO4WfLjmh7W0V%2BquVvVtT5CaRVRAZMuh0zft4Q%40mail.gmail.com Right. I meant to add that link to the commit messages. Mea culpa. Alexandra isn't the original author of these patches, but she did the work to determine exactly what needed to be backpatched, and tested it. I figured that was worth an Author credit. There didn't seem to be some other appropriate tag. > > > I'm nervous about pushing these in mere hours before a release freeze, > primarily because there's no way to be sure whether any necessary > follow-up fixes got missed. If we were unwilling to back-patch at > the time, is reversing that decision such a good idea? > My impression was that this was something we just didn't get around to. I wouldn't have pushed these so close to release if this hadn't been code already tested for a long time in release 16+. Maybe we missed something, but I doubt it. cheers andrew
Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.
On Sat, Nov 9, 2024 at 6:11 AM Tom Lane wrote: > I wrote: > > I'm also confused about how to document them in the release notes. > > Alexandra should get some credit I guess for collecting and testing > > the patches, but she's not the original author(s). > > After thinking for awhile, I'm going to fold all of these into one > release-note entry: > > > Fix misbehavior with junction points on Windows, particularly > in pg_rewind (Alexandra Wang) > > > > This entailed back-patching previous fixes by Thomas Munro, Peter > Eisentraut, Alexander Lakhin, and Juan José Santamaría Flecha. > Those changes were originally not back-patched out of caution, but > they have been in use in later branches for long enough to deem > them safe. > > > If anyone's really unhappy with that plan, let me know. > > WFM, Thanks. cheers andrew
pgsql: Provide lstat() for Windows.
Provide lstat() for Windows. Junction points will be reported with S_ISLNK(x.st_mode), simulating POSIX lstat(). stat() will follow pseudo-symlinks, like in POSIX (but only one level before giving up, unlike in POSIX). This completes a TODO left by commit bed90759fcb. Tested-by: Andrew Dunstan (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com (cherry picked from commit c5cb8f3b770c043509b61528664bcd805e1777e6) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b73c1496dc7aba7748eb3d55b29c4eb0dc788296 Author: Thomas Munro Modified Files -- src/include/port/win32_port.h | 18 ++- src/port/win32stat.c | 110 -- 2 files changed, 123 insertions(+), 5 deletions(-)
pgsql: Fix lstat() for broken junction points on Windows.
Fix lstat() for broken junction points on Windows. When using junction points to emulate symlinks on Windows, one edge case was not handled correctly by commit c5cb8f3b: if a junction point is broken (pointing to a non-existent path), we'd report ENOENT. This doesn't break any known use case, but was noticed while developing a test suite for these functions and is fixed here for completeness. Also add translation ERROR_CANT_RESOLVE_FILENAME -> ENOENT, as that is one of the errors Windows can report for some kinds of broken paths. Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com (cherry picked from commit 387803d81d6256fcb60b9192bb5b00042442b4e3) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8a5e4982f9c536fafa4ae9b7c331ee656ded2fe5 Author: Thomas Munro Modified Files -- src/port/win32error.c | 6 ++ src/port/win32stat.c | 27 ++- 2 files changed, 28 insertions(+), 5 deletions(-)
pgsql: Provide lstat() for Windows.
Provide lstat() for Windows. Junction points will be reported with S_ISLNK(x.st_mode), simulating POSIX lstat(). stat() will follow pseudo-symlinks, like in POSIX (but only one level before giving up, unlike in POSIX). This completes a TODO left by commit bed90759fcb. Tested-by: Andrew Dunstan (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com (cherry picked from commit c5cb8f3b770c043509b61528664bcd805e1777e6) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/895f23d9e174897a9c1a71a2c6cdb439fe5a3101 Author: Thomas Munro Modified Files -- src/include/port/win32_port.h | 18 ++- src/port/win32stat.c | 110 -- 2 files changed, 123 insertions(+), 5 deletions(-)
pgsql: Check for STATUS_DELETE_PENDING on Windows.
Check for STATUS_DELETE_PENDING on Windows. 1. Update our open() wrapper to check for NT's STATUS_DELETE_PENDING and translate it to Unix-like errors. This is done with RtlGetLastNtStatus(), which is dynamically loaded from ntdll. A new file win32ntdll.c centralizes lookup of NT functions, in case we decide to add more in the future. 2. Remove non-working code that was trying to do something similar for stat(), and just reuse the open() wrapper code. As a side effect, stat() also gains resilience against "sharing violation" errors. 3. Since stat() is used very early in process startup, remove the requirement that the Win32 signal event has been created before pgwin32_open_handle() is reached. Instead, teach pg_usleep() to fall back to a non-interruptible sleep if reached before the signal event is available. This could be back-patched, but for now it's in master only. The problem has apparently been with us for a long time and generated only a few complaints. Proposed patches trigger it more often, which led to this investigation and fix. Reviewed-by: Andres Freund Reviewed-by: Alexander Lakhin Reviewed-by: Juan José Santamaría Flecha Discussion: https://postgr.es/m/CA%2BhUKGJz_pZTF9mckn6XgSv69%2BjGwdgLkxZ6b3NWGLBCVjqUZA%40mail.gmail.com (cherry picked from commit e2f0f8ed251d02c1eda79e1ca3cb3db2681e7a86) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/56b39cce778f93cd95a01df0da083e937424662d Author: Thomas Munro Modified Files -- configure | 6 +++ configure.in| 1 + src/backend/port/win32/signal.c | 12 - src/include/port.h | 1 + src/include/port/win32ntdll.h | 27 +++ src/port/open.c | 104 +--- src/port/win32ntdll.c | 69 ++ src/port/win32stat.c| 78 +++--- src/tools/msvc/Mkvcbuild.pm | 3 +- 9 files changed, 179 insertions(+), 122 deletions(-)
pgsql: Fix issues with Windows' stat() for files pending on deletion
Fix issues with Windows' stat() for files pending on deletion The code introduced by bed9075 to enhance the stat() implementation on Windows for file sizes larger than 4GB fails to properly detect files pending for deletion with its method based on NtQueryInformationFile() or GetFileInformationByHandleEx(), as proved by Alexander Lakhin in a custom TAP test of his own. The method used in the implementation of open() to sleep and loop when when failing on ERROR_ACCESS_DENIED (EACCES) is showing much more stability, so switch to this method. This could still lead to issues if the permission problem stays around for much longer than the timeout of 1 second used, but that should (hopefully) never happen in performance-critical paths. Still, there could be a point in increasing the timeouts for the sake of machines that handle heavy loads. Note that WIN32's open() now uses microsoft_native_stat() as it should be similar to stat() when working around issues with concurrent file deletions. I have spent some time testing this patch with pgbench in combination of the SQL functions from genfile.c, as well as running the TAP test provided on the thread with MSVC builds, and this looks much more stable than the previous method. Author: Alexander Lakhin Reviewed-by: Tom Lane, Michael Paquier, Justin Pryzby Discussion: https://postgr.es/m/c3427edf-d7c0-ff57-90f6-b5de3bb62...@gmail.com Backpatch-through: 14 (cherry picked from commit 54fb8c7ddf152629021cab3ac3596354217b7d81) Author: Alexandra Wang Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f1cf64167fc9a09f54f69ec1d82865ba6aca5fe6 Author: Michael Paquier Modified Files -- src/port/open.c | 4 +- src/port/win32stat.c | 173 +++ 2 files changed, 51 insertions(+), 126 deletions(-)
pgsql: Replace pgwin32_is_junction() with lstat().
Replace pgwin32_is_junction() with lstat(). Now that lstat() reports junction points with S_IFLNK/S_ISLINK(), and unlink() can unlink them, there is no need for conditional code for Windows in a few places. That was expressed by testing for WIN32 or S_ISLNK, which we can now constant-fold. The coding around pgwin32_is_junction() was a bit suspect anyway, as we never checked for errors, and we also know that errors can be spuriously reported because of transient sharing violations on this OS. The lstat()-based code has handling for that. This also reverts 4fc6b6ee on master only. That was done because lstat() didn't previously work for symlinks (junction points), but now it does. Tested-by: Andrew Dunstan Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com (cherry picked from commit 5fc88c5d53e43fa7dcea93499d230a0bf70f4f77) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f95ad555de5623588bcc6e48fe8a3fd50d721216 Author: Thomas Munro Modified Files -- src/backend/backup/basebackup.c | 12 +--- src/backend/commands/tablespace.c | 7 +-- src/backend/storage/file/fd.c | 5 - src/backend/utils/adt/misc.c| 7 --- src/bin/pg_checksums/pg_checksums.c | 4 src/bin/pg_rewind/file_ops.c| 4 src/common/file_utils.c | 23 --- src/include/port.h | 1 - src/include/port/win32_port.h | 1 - src/port/dirmod.c | 16 10 files changed, 2 insertions(+), 78 deletions(-)
pgsql: Make unlink() work for junction points on Windows.
Make unlink() work for junction points on Windows. To support harmonization of Windows and Unix code, teach our unlink() wrapper that junction points need to be unlinked with rmdir() on Windows. Tested-by: Andrew Dunstan Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com (cherry picked from commit f357233c9db8be2a015163da8e1ab0630f444340) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fa56aa23fad3c27f4553025206afa8ba2500347f Author: Thomas Munro Modified Files -- src/port/dirmod.c | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-)
pgsql: Make unlink() work for junction points on Windows.
Make unlink() work for junction points on Windows. To support harmonization of Windows and Unix code, teach our unlink() wrapper that junction points need to be unlinked with rmdir() on Windows. Tested-by: Andrew Dunstan Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com (cherry picked from commit f357233c9db8be2a015163da8e1ab0630f444340) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b9d4a927d627bf5802e7e8e797ffc60d21bbac8b Author: Thomas Munro Modified Files -- src/port/dirmod.c | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-)
pgsql: Add missing include guard to win32ntdll.h.
Add missing include guard to win32ntdll.h. Oversight in commit e2f0f8ed. Also add this file to the exclusion lists in headerscheck and cpluscpluscheck, because Unix systems don't have a header it includes. Reported-by: Tom Lane Discussion: https://postgr.es/m/2760528.1641929756%40sss.pgh.pa.us (cherry picked from commit af9e6331aeba149c93052c3549140082a85a3cf9) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5c0b7581ba12bb01ebebce60583e3db6c0511057 Author: Thomas Munro Modified Files -- src/include/port/win32ntdll.h | 5 + src/tools/pginclude/cpluspluscheck | 1 + src/tools/pginclude/headerscheck | 1 + 3 files changed, 7 insertions(+)
pgsql: Fix lstat() for broken junction points on Windows.
Fix lstat() for broken junction points on Windows. When using junction points to emulate symlinks on Windows, one edge case was not handled correctly by commit c5cb8f3b: if a junction point is broken (pointing to a non-existent path), we'd report ENOENT. This doesn't break any known use case, but was noticed while developing a test suite for these functions and is fixed here for completeness. Also add translation ERROR_CANT_RESOLVE_FILENAME -> ENOENT, as that is one of the errors Windows can report for some kinds of broken paths. Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com (cherry picked from commit 387803d81d6256fcb60b9192bb5b00042442b4e3) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f2a4a137bb93922a925255665f5a47094ed8c9df Author: Thomas Munro Modified Files -- src/port/win32error.c | 6 ++ src/port/win32stat.c | 27 ++- 2 files changed, 28 insertions(+), 5 deletions(-)
pgsql: Provide lstat() for Windows.
Provide lstat() for Windows. Junction points will be reported with S_ISLNK(x.st_mode), simulating POSIX lstat(). stat() will follow pseudo-symlinks, like in POSIX (but only one level before giving up, unlike in POSIX). This completes a TODO left by commit bed90759fcb. Tested-by: Andrew Dunstan (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com (cherry picked from commit c5cb8f3b770c043509b61528664bcd805e1777e6) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ee219102d2e76d3e7277ac1a7ddda7757737b31b Author: Thomas Munro Modified Files -- src/include/port/win32_port.h | 18 ++- src/port/win32stat.c | 110 -- 2 files changed, 123 insertions(+), 5 deletions(-)
pgsql: Add missing include guard to win32ntdll.h.
Add missing include guard to win32ntdll.h. Oversight in commit e2f0f8ed. Also add this file to the exclusion lists in headerscheck and cpluscpluscheck, because Unix systems don't have a header it includes. Reported-by: Tom Lane Discussion: https://postgr.es/m/2760528.1641929756%40sss.pgh.pa.us (cherry picked from commit af9e6331aeba149c93052c3549140082a85a3cf9) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ce14dbbcafde5a629d4dbcabdadecea440e7955d Author: Thomas Munro Modified Files -- src/include/port/win32ntdll.h | 5 + src/tools/pginclude/cpluspluscheck | 1 + src/tools/pginclude/headerscheck | 1 + 3 files changed, 7 insertions(+)
pgsql: Fix -Wcast-function-type warnings
Fix -Wcast-function-type warnings Three groups of issues needed to be addressed: load_external_function() and related functions returned PGFunction, even though not necessarily all callers are looking for a function of type PGFunction. Since these functions are really just wrappers around dlsym(), change to return void * just like dlsym(). In dynahash.c, we are using strlcpy() where a function with a signature like memcpy() is expected. This should be safe, as the new comment there explains, but the cast needs to be augmented to avoid the warning. In PL/Python, methods all need to be cast to PyCFunction, per Python API, but this now runs afoul of these warnings. (This issue also exists in core CPython.) To fix the second and third case, we add a new type pg_funcptr_t that is defined specifically so that gcc accepts it as a special function pointer that can be cast to any other function pointer without the warning. Also add -Wcast-function-type to the standard warning flags, subject to configure check. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/1e97628e-6447-b4fd-e230-d109cec2d584%402ndquadrant.com (cherry picked from commit de8feb1f3a23465b5737e8a8c160e8ca62f61339) Author: Peter Eisentraut Author: Alexandra Wang Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a5abacecb46358a7b771841e2ee0acbb1c353b79 Author: Peter Eisentraut Modified Files -- configure | 91 +++ configure.in | 2 + src/backend/utils/fmgr/dfmgr.c| 14 +++--- src/backend/utils/hash/dynahash.c | 11 - src/include/c.h | 7 +++ src/include/fmgr.h| 6 +-- src/pl/plpython/plpy_plpymodule.c | 14 +++--- 7 files changed, 127 insertions(+), 18 deletions(-)
pgsql: Disable clang 16's -Wcast-function-type-strict.
Disable clang 16's -Wcast-function-type-strict. Clang 16 is still in development, but seawasp reveals that it has started warning about many of our casts of function pointers (those introduced by commit 1c27d16e, and some older ones). Disable the new warning for now, since otherwise buildfarm animal seawasp fails, and we have no current plans to change our strategy for these callback function types. May be back-patched with other Clang/LLVM 16 changes around release time. Discussion: https://postgr.es/m/CA%2BhUKGJvX%2BL3aMN84ksT-cGy08VHErRNip3nV-WmTx7f6Pqhyw%40mail.gmail.com (cherry picked from commit 101c37cd342a3ae134bb3e5e0abb14ae46692b56) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b4363fc66e642b70f88455004e5bc6d67c65cf71 Author: Thomas Munro Modified Files -- configure| 44 configure.in | 6 ++ meson.build | 0 3 files changed, 50 insertions(+)
pgsql: Check for STATUS_DELETE_PENDING on Windows.
Check for STATUS_DELETE_PENDING on Windows. 1. Update our open() wrapper to check for NT's STATUS_DELETE_PENDING and translate it to Unix-like errors. This is done with RtlGetLastNtStatus(), which is dynamically loaded from ntdll. A new file win32ntdll.c centralizes lookup of NT functions, in case we decide to add more in the future. 2. Remove non-working code that was trying to do something similar for stat(), and just reuse the open() wrapper code. As a side effect, stat() also gains resilience against "sharing violation" errors. 3. Since stat() is used very early in process startup, remove the requirement that the Win32 signal event has been created before pgwin32_open_handle() is reached. Instead, teach pg_usleep() to fall back to a non-interruptible sleep if reached before the signal event is available. This could be back-patched, but for now it's in master only. The problem has apparently been with us for a long time and generated only a few complaints. Proposed patches trigger it more often, which led to this investigation and fix. Reviewed-by: Andres Freund Reviewed-by: Alexander Lakhin Reviewed-by: Juan José Santamaría Flecha Discussion: https://postgr.es/m/CA%2BhUKGJz_pZTF9mckn6XgSv69%2BjGwdgLkxZ6b3NWGLBCVjqUZA%40mail.gmail.com (cherry picked from commit e2f0f8ed251d02c1eda79e1ca3cb3db2681e7a86) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1bf47d89776c2647d896f308687fa13d6c2877e2 Author: Thomas Munro Modified Files -- configure | 6 ++ configure.ac| 1 + src/backend/port/win32/signal.c | 12 ++- src/include/port.h | 1 + src/include/port/win32ntdll.h | 27 +++ src/port/open.c | 104 ++ src/port/win32ntdll.c | 69 + src/port/win32stat.c| 159 ++-- src/tools/msvc/Mkvcbuild.pm | 2 +- 9 files changed, 177 insertions(+), 204 deletions(-)
pgsql: Replace pgwin32_is_junction() with lstat().
Replace pgwin32_is_junction() with lstat(). Now that lstat() reports junction points with S_IFLNK/S_ISLINK(), and unlink() can unlink them, there is no need for conditional code for Windows in a few places. That was expressed by testing for WIN32 or S_ISLNK, which we can now constant-fold. The coding around pgwin32_is_junction() was a bit suspect anyway, as we never checked for errors, and we also know that errors can be spuriously reported because of transient sharing violations on this OS. The lstat()-based code has handling for that. This also reverts 4fc6b6ee on master only. That was done because lstat() didn't previously work for symlinks (junction points), but now it does. Tested-by: Andrew Dunstan Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com (cherry picked from commit 5fc88c5d53e43fa7dcea93499d230a0bf70f4f77) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ca9921936ea352df30db2955fb2662695d8377be Author: Thomas Munro Modified Files -- src/backend/commands/tablespace.c| 7 +-- src/backend/replication/basebackup.c | 12 +--- src/backend/storage/file/fd.c| 5 - src/backend/utils/adt/misc.c | 7 --- src/bin/pg_checksums/pg_checksums.c | 4 src/bin/pg_rewind/file_ops.c | 4 src/common/file_utils.c | 23 --- src/include/port.h | 1 - src/include/port/win32_port.h| 1 - src/port/dirmod.c| 16 10 files changed, 2 insertions(+), 78 deletions(-)
pgsql: Make unlink() work for junction points on Windows.
Make unlink() work for junction points on Windows. To support harmonization of Windows and Unix code, teach our unlink() wrapper that junction points need to be unlinked with rmdir() on Windows. Tested-by: Andrew Dunstan Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com (cherry picked from commit f357233c9db8be2a015163da8e1ab0630f444340) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/02a4ec478df8a4724b84d76f84e49248da204f95 Author: Thomas Munro Modified Files -- src/port/dirmod.c | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-)
pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.
Fix our Windows stat() emulation to handle file sizes > 4GB. Hack things so that our idea of "struct stat" is equivalent to Windows' struct __stat64, allowing it to have a wide enough st_size field. Instead of relying on native stat(), use GetFileInformationByHandle(). This avoids a number of issues with Microsoft's multiple and rather slipshod emulations of stat(). We still need to jump through hoops to deal with ERROR_DELETE_PENDING, though :-( Pull the relevant support code out of dirmod.c and put it into its own file, win32stat.c. Still TODO: do we need to do something different with lstat(), rather than treating it identically to stat()? Juan José Santamaría Flecha, reviewed by Emil Iggland; based on prior work by Michael Paquier, Sergey Zubkovsky, and others Discussion: https://postgr.es/m/1803D792815FC24D871C00D17AE95905CF5099@g01jpexmbkw24 Discussion: https://postgr.es/m/15858-9572469fd3b73...@postgresql.org (cherry picked from commit bed90759fcbcd72d4d06969eebab81e47326f9a2) Author: Alexandra Wang Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a9beed67670e680edeadd2a3cf7557a3c9808adf Author: Tom Lane Modified Files -- configure | 6 + configure.in | 1 + src/include/port/win32_port.h | 44 +-- src/port/dirmod.c | 52 src/port/win32stat.c | 299 ++ src/tools/msvc/Mkvcbuild.pm | 2 +- 6 files changed, 339 insertions(+), 65 deletions(-)
pgsql: Fix lstat() for broken junction points on Windows.
Fix lstat() for broken junction points on Windows. When using junction points to emulate symlinks on Windows, one edge case was not handled correctly by commit c5cb8f3b: if a junction point is broken (pointing to a non-existent path), we'd report ENOENT. This doesn't break any known use case, but was noticed while developing a test suite for these functions and is fixed here for completeness. Also add translation ERROR_CANT_RESOLVE_FILENAME -> ENOENT, as that is one of the errors Windows can report for some kinds of broken paths. Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com (cherry picked from commit 387803d81d6256fcb60b9192bb5b00042442b4e3) Author: Thomas Munro Author: Alexandra Wang Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bb509a464e3e59e13b8869665fe5eccc98f83b39 Author: Thomas Munro Modified Files -- src/port/win32error.c | 6 ++ src/port/win32stat.c | 27 ++- 2 files changed, 28 insertions(+), 5 deletions(-)
Re: pgsql: Update time zone data files to tzdata release 2024b.
On Wed, Oct 30, 2024 at 7:20 PM Tom Lane wrote: > I wrote: > > So the problem is precisely that *our* interpretation of EST5EDT > > changed when we adopted tzdata 2024b, and that is affecting how > > we dump these old timestamps. Or at least, that seems like what > > should be happening, but then why is only crake showing a failure? > > Oh, got it: of the machines in question, only crake is selecting > EST5EDT as default timezone. I can see from the buildfarm logs > that drongo and fairywren are using UTC, and as said, my test > instance is selecting America/New_York. Both UTC and America/New_York > would have rendered these old timestamps the same way all along, > but EST5EDT just changed its interpretation of them. > > That means that simply forcing a re-run of the old branches on > crake won't fix it, because pre-v12 branches will still think > that EST5EDT means what it used to. We need to make sure that > the dumps are taken in a completely stable zone, i.e. UTC. > > > Yep, I rebuilt all those old branches using 'America/New_York" and we're back to green. Thanks for the diagnosis. cheers andrew
Re: pgsql: Update time zone data files to tzdata release 2024b.
On Wed, Oct 30, 2024 at 4:53 PM Andrew Dunstan wrote: > > > On Wed, Oct 30, 2024 at 4:33 PM Tom Lane wrote: > >> Andrew Dunstan writes: >> > On Wed, Oct 30, 2024 at 11:00 AM Tom Lane wrote: >> >> I went to try to test this locally, and got nowhere, because: >> >> old cluster does not use data checksums but the new one does >> >> Failure, exiting >> >> What have you done to get around that on crake? >> >> > I did this: >> > >> https://github.com/PGBuildFarm/client-code/commit/2ef5acefe5e6eee761ea2ee010c3d14e2d8fab60 >> >> Ah, thanks. I installed that locally, and got >> >> ... >> tester:HEAD [16:25:31] saving files for cross-version upgrade >> check >> tester:HEAD [16:25:33] checking upgrade from REL9_2_STABLE to >> HEAD ... >> tester:HEAD [16:25:53] checking upgrade from REL_11_STABLE to >> HEAD ... >> tester:HEAD [16:26:31] checking upgrade from REL_12_STABLE to >> HEAD ... >> tester:HEAD [16:27:08] checking upgrade from REL_13_STABLE to >> HEAD ... >> tester:HEAD [16:27:46] checking upgrade from REL_14_STABLE to >> HEAD ... >> tester:HEAD [16:28:26] checking upgrade from REL_15_STABLE to >> HEAD ... >> tester:HEAD [16:29:05] checking upgrade from REL_16_STABLE to >> HEAD ... >> tester:HEAD [16:29:47] checking upgrade from HEAD to HEAD ... >> tester:HEAD [16:30:32] running make ecpg check ... >> tester:HEAD [16:30:40] OK >> >> (This client instance doesn't have back-branch runs for v9.3--v10.) >> >> So now I'm even more confused. Why does it work here and not there? >> I can't think of any buildfarm options that would affect this. >> >> > > My 9.2 saved instance is quite old ... Nov 2018. > > But I don't see why that should affect it, so I'm confused too. > > Further data point - drongo and fairywren are not showing this issue. cheers andrew
Re: pgsql: Update time zone data files to tzdata release 2024b.
On Wed, Oct 30, 2024 at 11:00 AM Tom Lane wrote: > Andrew Dunstan writes: > > On Oct 29, 2024, at 5:41 PM, Tom Lane wrote: > >> I would expect that the upgrade tests would pass now for upgrades > >> from v12 or later, thanks to b8ea0f675 et al, but I'm not real > >> sure what to do about testing the out-of-support branches. Should > >> we back-patch b8ea0f675 as far down as 9.2? > > > Or fix/remove the problem rows in AdjustUpgrade.pm I guess > > I went to try to test this locally, and got nowhere, because: > > old cluster does not use data checksums but the new one does > Failure, exiting > > What have you done to get around that on crake? > > > I did this: https://github.com/PGBuildFarm/client-code/commit/2ef5acefe5e6eee761ea2ee010c3d14e2d8fab60 I was intending to push a new client release with it but things got kinda screwy the last 10 days. I will try to push it out later this week. Meanwhile I think you should see the same result without this issue if you test using v17 or earlier instead of master. cheers andrew
Re: pgsql: Update time zone data files to tzdata release 2024b.
> On Oct 29, 2024, at 5:41 PM, Tom Lane wrote: > > Andrew Dunstan writes: >> Crake doesn't seem to like this for cross version upgrade, and the diff >> looks rather odd: > > Oh, that's annoying. I forgot to mention the side-effects that 2024b > had on PST8PDT and other SysV-derived timezones (probably because Paul > Eggert avoided mentioning that in his release notes ... thanks for > nothing Paul). What we've got there is that sufficiently old > timestamps (pre 1890 or so) are now interpreted as local mean solar > time for Los Angeles rather than exactly UTC-8. > > I would expect that the upgrade tests would pass now for upgrades > from v12 or later, thanks to b8ea0f675 et al, but I'm not real > sure what to do about testing the out-of-support branches. Should > we back-patch b8ea0f675 as far down as 9.2? > > Or fix/remove the problem rows in AdjustUpgrade.pm I guess Cheers Andrew
Re: pgsql: Update time zone data files to tzdata release 2024b.
On Tue, Oct 29, 2024 at 11:50 AM Tom Lane wrote: > Update time zone data files to tzdata release 2024b. > > Historical corrections for Mexico, Mongolia, and Portugal. > Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar > rather than being a separate zone, mainly because the differences > between those zones were found to be based on untrustworthy data. > > Branch > -- > master > > Details > --- > > https://git.postgresql.org/pg/commitdiff/502e7bf7f09c458ce66ce043b94864b535c5d5d0 > > Modified Files > -- > src/timezone/data/tzdata.zi | 1653 > +++ > src/timezone/known_abbrevs.txt |2 - > src/timezone/tznames/Default|6 +- > src/timezone/tznames/Europe.txt |6 +- > 4 files changed, 824 insertions(+), 843 deletions(-) > > Crake doesn't seem to like this for cross version upgrade, and the diff looks rather odd: --- /home/andrew/bf/root/upgrade.crake/HEAD/origin-REL9_2_STABLE.sql.fixed 2024-10-29 13:40:01.778445456 -0400 +++ /home/andrew/bf/root/upgrade.crake/HEAD/converted-REL9_2_STABLE-to-HEAD.sql.fixed 2024-10-29 13:40:01.780445460 -0400 @@ -206462,12 +206462,12 @@ 1997-02-14 20:32:01-05 1997-02-15 20:32:01-05 1997-02-16 20:32:01-05 -0097-02-16 20:32:01-05 BC -0097-02-16 20:32:01-05 -0597-02-16 20:32:01-05 -1097-02-16 20:32:01-05 -1697-02-16 20:32:01-05 -1797-02-16 20:32:01-05 +0097-02-16 20:35:59-04:56:02 BC +0097-02-16 20:35:59-04:56:02 +0597-02-16 20:35:59-04:56:02 +1097-02-16 20:35:59-04:56:02 +1697-02-16 20:35:59-04:56:02 +1797-02-16 20:35:59-04:56:02 1897-02-16 20:32:01-05 1997-02-16 20:32:01-05 2097-02-16 20:32:01-05 cheers andrew
pgsql: Move Cluster.pm initialization code to a more obvious place
Move Cluster.pm initialization code to a more obvious place Commit 460c0076e8 added some module intialization code to set signal handlers. However, that code has now become somewhat buried, as later commits added new subroutines. Therefore, move the initialization code to the module's INIT block where it won't become obscured. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/70fea390cfa71c438998993bebfb584effd3e7df Modified Files -- src/test/perl/PostgreSQL/Test/Cluster.pm | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-)
pgsql: Bump MIN_WINNT for MINGW to clear a build error
Bump MIN_WINNT for MINGW to clear a build error Because we have been setting this too low, there has been a long-standing warning about a missing declaration for inet_pton(). Modern gcc now considers this an error, so we have been getting failures on the buildfarm animal fairywren. Fix suggested by Thomas Munro. This isn't needed in later branches, as they already set MIN_WINNT higher, nor on earlier branches because they don't use inet_pton(). Discussion: https://postgr.es/m/574fae43-c993-4a25-b0e5-04c3e9c36...@dunslane.net Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d700e8d75bc3844d866bf15c8cadbd72d759422d Modified Files -- src/include/port/win32.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
Re: pgsql: scripts: add Perl script to add links to release notes
On 2024-09-16 Mo 1:27 PM, Bruce Momjian wrote:
scripts: add Perl script to add links to release notes
Reported-by: jian he
Discussion:https://postgr.es/m/zuyss5xda7hvc...@momjian.us
I realize I'm late to the party on this, but here's a review patch for
this script. It's mostly stylistic changes (simpler use of print, use of
POSIX xdigit class for hex digits), but it does correct one actual
error: AFAIK "die" doesn't do printf style substitutions.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
diff --git a/src/tools/add_commit_links.pl b/src/tools/add_commit_links.pl
index ebfc97ea32..64a5783297 100755
--- a/src/tools/add_commit_links.pl
+++ b/src/tools/add_commit_links.pl
@@ -51,9 +51,8 @@ sub process_file
$file =~ m/-(\d+)\./;
my $major_version = $1;
- open(my $fh, '<', $file) || die "could not open file %s: $!\n", $file;
- open(my $tfh, '>', $tmpfile) || die "could not open file %s: $!\n",
- $tmpfile;
+ open(my $fh, '<', $file) || die "could not open file $file: $!\n";
+ open(my $tfh, '>', $tmpfile) || die "could not open file $tmpfile: $!\n";
while (<$fh>)
{
@@ -64,9 +63,9 @@ sub process_file
# skip over commit links because we will add them below
next
if (!$in_comment &&
- m{^\s*§\s*$});
+ m{^\s*§\s*$});
- if ($in_comment && m/\[([\da-f]+)\]/)
+ if ($in_comment && m/\[([[:xdigit:]]+)\]/)
{
my $hash = $1;
@@ -88,23 +87,21 @@ sub process_file
{
for my $hash (@hashes)
{
- print({$tfh}
- "$prev_leading_space§\n"
- );
+ print $tfh
+ "$prev_leading_space§\n";
}
@hashes = ();
}
else
{
- printf(
- "hashes found but no matching text found for placement on line %s\n",
- $lineno);
+ print
+ "hashes found but no matching text found for placement on line $lineno\n";
exit(1);
}
}
}
- print({$tfh} $_);
+ print $tfh $_;
$prev_line_ended_with_paren = m/\)\s*$/;
Re: pgsql: Perl scripts: eliminate "Useless interpolation" warnings
On 2024-09-15 Su 9:28 PM, Bruce Momjian wrote:
On Sun, Sep 15, 2024 at 06:07:21PM -0400, Andrew Dunstan wrote:
On 2024-09-15 Su 4:36 PM, Bruce Momjian wrote:
On Sun, Sep 15, 2024 at 04:33:49PM -0400, Andrew Dunstan wrote:
I understand perfectly what the warning is about.
But the project's perlcritic policy is expressed at src/tools/perlcheck/
perlcriticrc. It's basically severity 5 plus some additions and one exception.
We shouldn't be imposing our personal perlcritic policies on the project.
The change isn't bad in itself, but there shouldn't be any expectation that we
will keep to this policy, as it's not required by project policy.
There is a huge mass of perlcritic issues in our perl code at severity 1 (over
13000 by my count). If we're going to clean them up (which I would oppose) we
should do it in a systematic way. It's hard to see why this one is special.
I guess it is special only because my policy is more strict so I wanted
my new code to match. Should I revert it?
Yes I think so.
Okay, done.
Is the very tiny improvement
not worth the churn in the code?
Yeah, I don't think it is.
FYI, the line that got me started was:
my ($tmpfilename) = $filename . ".tmp";
while I would write that with single quotes. Because mine uses single
quotes and version_stamp.pl uses double-quotes, I started to try to
unify the style.
I would normally write this as
my $tempfile = "$filename.tmp";
or possibly
my $tempfile = "${filename}.tmp";
There's a perl mantra that says There Is More Than One Way To Do It,
usually abbreviated to TIMTOWTDI, which perlcritic fights against to
some extent. I think the idea of unifying style beyond the official
project policy is an effort doomed to failure. Nobody is going to
maintain that consistency, and the project has rejected attempts to have
a stricter set of rules in the past.
I agree severity=1 generates many false warnings, and changing code
based on them can actually produce errors, but I do think there are some
safe ones like the single/double quote item we can improve.
Attached is my Perl critic file, where I do use severity=1, but turn off
various warnings.
Sure, or for something in between, there's the buildfarm policy at
<https://github.com/PGBuildFarm/client-code/blob/main/.perlcriticrc>
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Re: pgsql: Perl scripts: eliminate "Useless interpolation" warnings
On 2024-09-15 Su 4:36 PM, Bruce Momjian wrote: On Sun, Sep 15, 2024 at 04:33:49PM -0400, Andrew Dunstan wrote: I understand perfectly what the warning is about. But the project's perlcritic policy is expressed at src/tools/perlcheck/ perlcriticrc. It's basically severity 5 plus some additions and one exception. We shouldn't be imposing our personal perlcritic policies on the project. The change isn't bad in itself, but there shouldn't be any expectation that we will keep to this policy, as it's not required by project policy. There is a huge mass of perlcritic issues in our perl code at severity 1 (over 13000 by my count). If we're going to clean them up (which I would oppose) we should do it in a systematic way. It's hard to see why this one is special. I guess it is special only because my policy is more strict so I wanted my new code to match. Should I revert it? Yes I think so. Is the very tiny improvement not worth the churn in the code? Yeah, I don't think it is. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Re: pgsql: Perl scripts: eliminate "Useless interpolation" warnings
On 2024-09-15 Su 4:16 PM, Bruce Momjian wrote: On Sun, Sep 15, 2024 at 02:30:47PM -0400, Andrew Dunstan wrote: On 2024-09-15 Su 10:56 AM, Bruce Momjian wrote: Perl scripts: eliminate "Useless interpolation" warnings Eliminate warnings of Perl Critic from src/tools. Backpatch-through: master I don't understand this commit. The buildfarm members crake and koel regularly run the perl critic checks and have not complained. See for example from before this change:<https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm= koel&dt=2024-09-15%2003%3A34%3A02&stg=perl-check> The change doesn't seem to have had any discussion either. This particular warning is surely a very low level (i.e. fairly unimportant) one, of the type we normally ignore. If some version of perlcritic has raised it to severity 5 then the correct action IMNSHO would be to add an exception for it to the perlcriticrc, like we do for ProhibitLeadingZeros. If not, then perhaps you can explain how you got the warnings. So, the warning is about the use of double-quotes when single-quotes will work just fine. I wrote a new script and changed it to single quotes, so for consistency, I looked at other Perl scripts that might have the issue. The message I got was: /root/add_commit_links.pl: Useless interpolation of literal string at line 51 near 'my $tmpfile = $file . ".tmp";'. (Severity: 1) My $HOME/.perlcritic has: severity = 1 and that is why I saw it. Is it a bad change? I understand perfectly what the warning is about. But the project's perlcritic policy is expressed at src/tools/perlcheck/perlcriticrc. It's basically severity 5 plus some additions and one exception. We shouldn't be imposing our personal perlcritic policies on the project. The change isn't bad in itself, but there shouldn't be any expectation that we will keep to this policy, as it's not required by project policy. There is a huge mass of perlcritic issues in our perl code at severity 1 (over 13000 by my count). If we're going to clean them up (which I would oppose) we should do it in a systematic way. It's hard to see why this one is special. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com
Re: pgsql: Perl scripts: eliminate "Useless interpolation" warnings
On 2024-09-15 Su 10:56 AM, Bruce Momjian wrote: Perl scripts: eliminate "Useless interpolation" warnings Eliminate warnings of Perl Critic from src/tools. Backpatch-through: master I don't understand this commit. The buildfarm members crake and koel regularly run the perl critic checks and have not complained. See for example from before this change: <https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=koel&dt=2024-09-15%2003%3A34%3A02&stg=perl-check> The change doesn't seem to have had any discussion either. This particular warning is surely a very low level (i.e. fairly unimportant) one, of the type we normally ignore. If some version of perlcritic has raised it to severity 5 then the correct action IMNSHO would be to add an exception for it to the perlcriticrc, like we do for ProhibitLeadingZeros. If not, then perhaps you can explain how you got the warnings. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com
pgsql: Improve meson's detection of perl build flags
Improve meson's detection of perl build flags The current method of detecting perl build flags breaks if the path to perl contains a space. This change makes two improvements. First, instead of getting a list of ldflags and ccdlflags and then trying to filter those out of the reported ldopts, we tell perl to suppress reporting those in the first instance. Second, it tells perl to parse those and output them, one per line. Thus any space on the option in a file name, for example, is preserved. Issue reported off-list by Muralikrishna Bandaru Discussion: https://postgr.es/01117f88-f465-bf6c-9362-083bd72ca...@dunslane.net Backpatch to release 16. Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dc2a660bd983f2675f357d279253256a2aef9836 Modified Files -- meson.build | 25 - 1 file changed, 12 insertions(+), 13 deletions(-)
pgsql: Improve meson's detection of perl build flags
Improve meson's detection of perl build flags The current method of detecting perl build flags breaks if the path to perl contains a space. This change makes two improvements. First, instead of getting a list of ldflags and ccdlflags and then trying to filter those out of the reported ldopts, we tell perl to suppress reporting those in the first instance. Second, it tells perl to parse those and output them, one per line. Thus any space on the option in a file name, for example, is preserved. Issue reported off-list by Muralikrishna Bandaru Discussion: https://postgr.es/01117f88-f465-bf6c-9362-083bd72ca...@dunslane.net Backpatch to release 16. Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cb52d1cdd1031d3b0d66a001b7b153990a0497c8 Modified Files -- meson.build | 25 - 1 file changed, 12 insertions(+), 13 deletions(-)
pgsql: Improve meson's detection of perl build flags
Improve meson's detection of perl build flags The current method of detecting perl build flags breaks if the path to perl contains a space. This change makes two improvements. First, instead of getting a list of ldflags and ccdlflags and then trying to filter those out of the reported ldopts, we tell perl to suppress reporting those in the first instance. Second, it tells perl to parse those and output them, one per line. Thus any space on the option in a file name, for example, is preserved. Issue reported off-list by Muralikrishna Bandaru Discussion: https://postgr.es/01117f88-f465-bf6c-9362-083bd72ca...@dunslane.net Backpatch to release 16. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/76f2a0e5479618d48161549a148a37251b4b3d4b Modified Files -- meson.build | 25 - 1 file changed, 12 insertions(+), 13 deletions(-)
pgsql: Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required
Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we therefore get a handshake error when building against such instances. The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is defined and only define NO_THREAD_SAFE_LOCALE if it isn't. Backpatch the meson.build fix back to release 16 and apply the same logic to Mkvcbuild.pm in releases 12 through 16. Original report of the issue from Muralikrishna Bandaru. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9f77494647ded10c5ffd67cea92abcfdaea7 Modified Files -- src/tools/msvc/Mkvcbuild.pm | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
pgsql: Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required
Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we therefore get a handshake error when building against such instances. The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is defined and only define NO_THREAD_SAFE_LOCALE if it isn't. Backpatch the meson.build fix back to release 16 and apply the same logic to Mkvcbuild.pm in releases 12 through 16. Original report of the issue from Muralikrishna Bandaru. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d94e3b33eaf6c57109a21115572ac78124da5939 Modified Files -- src/tools/msvc/Mkvcbuild.pm | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
pgsql: Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required
Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we therefore get a handshake error when building against such instances. The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is defined and only define NO_THREAD_SAFE_LOCALE if it isn't. Backpatch the meson.build fix back to release 16 and apply the same logic to Mkvcbuild.pm in releases 12 through 16. Original report of the issue from Muralikrishna Bandaru. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/17c35ab236980fce2989f7fac7cee42ca4d5ca04 Modified Files -- src/tools/msvc/Mkvcbuild.pm | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
pgsql: Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required
Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we therefore get a handshake error when building against such instances. The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is defined and only define NO_THREAD_SAFE_LOCALE if it isn't. Backpatch the meson.build fix back to release 16 and apply the same logic to Mkvcbuild.pm in releases 12 through 16. Original report of the issue from Muralikrishna Bandaru. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f40d9e9f1b5892a340d5ed5d650c9dc3cf72e6e9 Modified Files -- src/tools/msvc/Mkvcbuild.pm | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
pgsql: Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required
Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we therefore get a handshake error when building against such instances. The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is defined and only define NO_THREAD_SAFE_LOCALE if it isn't. Backpatch the meson.build fix back to release 16 and apply the same logic to Mkvcbuild.pm in releases 12 through 16. Original report of the issue from Muralikrishna Bandaru. Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0a0db46313749bb379db65eb987af6bf29470300 Modified Files -- meson.build | 5 - src/tools/msvc/Mkvcbuild.pm | 4 +++- 2 files changed, 7 insertions(+), 2 deletions(-)
pgsql: Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required
Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we therefore get a handshake error when building against such instances. The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is defined and only define NO_THREAD_SAFE_LOCALE if it isn't. Backpatch the meson.build fix back to release 16 and apply the same logic to Mkvcbuild.pm in releases 12 through 16. Original report of the issue from Muralikrishna Bandaru. Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/648397b1d409f15612b5bb6f95c5527f94e69807 Modified Files -- meson.build | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required
Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we therefore get a handshake error when building against such instances. The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is defined and only define NO_THREAD_SAFE_LOCALE if it isn't. Backpatch the meson.build fix back to release 16 and apply the same logic to Mkvcbuild.pm in releases 12 through 16. Original report of the issue from Muralikrishna Bandaru. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bc46104fc9aa5254f98250cf2756552f92095ae9 Modified Files -- meson.build | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Preserve tz when converting to jsonb timestamptz
Preserve tz when converting to jsonb timestamptz This removes an inconsistency in the treatment of different datatypes by the jsonpath timestamp_tz() function. Conversions from data types that are not timestamp-aware, such as date and timestamp, are now treated consistently with conversion from those that are such as timestamptz. Author: David Wheeler Reviewed-by: Junwang Zhao and Jeevan Chalke Discussion: https://postgr.es/m/7DE080CE-6D8C-4794-9BD1-7D9699172FAB%40justatheory.com Backpatch to release 17. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/524d490a9f4ab81d86bbedc6e429fbc27776351c Modified Files -- src/backend/utils/adt/jsonpath_exec.c| 25 + src/test/regress/expected/jsonb_jsonpath.out | 4 ++-- 2 files changed, 27 insertions(+), 2 deletions(-)
