pgsql: Change last_inactive_time to inactive_since in pg_replication_sl
Change last_inactive_time to inactive_since in pg_replication_slots. Commit a11f330b55 added last_inactive_time to show the last time the slot was inactive. But, it tells the last time that a currently-inactive slot previously *WAS* active. This could be unclear, so we changed the name to inactive_since. Reported-by: Robert Haas Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Shveta Malik, Amit Kapila Discussion: https://postgr.es/m/ca+tgmob_ta-t2ty8qrkhbgnnlrf4zycwhghgfsuuofraedw...@mail.gmail.com Discussion: https://postgr.es/m/calj2acuxs0sfbhzsx8bqo+7czhocsv52kiu7owgb5hvpamj...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6d49c8d4b4f4a20eb5b4c501d78cf894fa13c0ea Modified Files -- doc/src/sgml/system-views.sgml| 4 +- src/backend/catalog/system_views.sql | 2 +- src/backend/replication/slot.c| 17 + src/backend/replication/slotfuncs.c | 4 +- src/include/catalog/catversion.h | 2 +- src/include/catalog/pg_proc.dat | 2 +- src/include/replication/slot.h| 4 +- src/test/recovery/t/019_replslot_limit.pl | 62 +++ src/test/regress/expected/rules.out | 4 +- 9 files changed, 52 insertions(+), 49 deletions(-)
pgsql: Allow specifying initial and maximum segment sizes for DSA.
Allow specifying initial and maximum segment sizes for DSA. Previously, the DSA segment size always started with 1MB and grew up to DSA_MAX_SEGMENT_SIZE. It was inconvenient in certain scenarios, such as when the caller desired a soft constraint on the total DSA segment size, limiting it to less than 1MB. This commit introduces the capability to specify the initial and maximum DSA segment sizes when creating a DSA area, providing more flexibility and control over memory usage. Reviewed-by: John Naylor, Tomas Vondra Discussion: https://postgr.es/m/CAD21AoAYGGC1ePjVX0H%2Bpp9rH%3D9vuPK19nNOiu12NprdV5TVJA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bb952c8c8b13279eca039499249cb5dc60991603 Modified Files -- src/backend/utils/mmgr/dsa.c | 63 src/include/utils/dsa.h | 46 +--- 2 files changed, 71 insertions(+), 38 deletions(-)
pgsql: Fix compiler warning for pg_lfind32().
Fix compiler warning for pg_lfind32(). The newly-introduced "one_by_one" label produces -Wunused-label warnings when building without SIMD support. To fix, move the label into the SIMD section of this function. Oversight in commit 7644a7340c. Reported-by: Tom Lane Discussion: https://postgr.es/m/3189995.1711495704%40sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1f42337be535243e665f85916ce21b2d85d9f2b3 Modified Files -- src/include/port/pg_lfind.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Add commit 64e401b62b to .git-blame-ignore-revs.
Add commit 64e401b62b to .git-blame-ignore-revs. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ffa9bb53ecb1cec14039d0c78e6f941565e8f986 Modified Files -- .git-blame-ignore-revs | 3 +++ 1 file changed, 3 insertions(+)
pgsql: Remove some redundant set_cheapest() calls.
Remove some redundant set_cheapest() calls. Commit e2fa76d80 centralized the responsibility for doing set_cheapest() for a baserel, but these functions added later seemingly didn't get the memo. There's no apparent reason why we need the cheapest path for these relation types to be available any sooner than it is for other base relation types, so delete the duplicate calls. Doesn't save much since there's only one path in these cases, but it might improve clarity. Richard Guo Discussion: https://postgr.es/m/cambws4-kfeu_fdujpncokuu3rwvzvkbeytkd9vrm4kh4-2h...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9d00cf47722a5d2876fc5c7727a395c0348dd304 Modified Files -- src/backend/optimizer/path/allpaths.c | 6 -- 1 file changed, 6 deletions(-)
pgsql: Optimize roles_is_member_of() with a Bloom filter.
Optimize roles_is_member_of() with a Bloom filter. When the list of roles gathered by roles_is_member_of() grows very large, a Bloom filter is created to help avoid some linear searches through the list. The threshold for creating the Bloom filter is set arbitrarily high and may require future adjustment. Suggested-by: Tom Lane Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAGvXd3OSMbJQwOSc-Tq-Ro1CAz%3DvggErdSG7pv2s6vmmTOLJSg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d365ae705409f5d9c81da4b668f59c3598feb512 Modified Files -- src/backend/utils/adt/acl.c | 68 +++-- 1 file changed, 65 insertions(+), 3 deletions(-)
pgsql: Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences.
Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences. Ordinary ALTER TABLE SET SCHEMA will also move any owned sequences into the new schema. We failed to do likewise for foreign tables, because AlterTableNamespaceInternal believed that only certain relkinds could have indexes, owned sequences, or constraints. We could simply add foreign tables to that relkind list, but it seems likely that the same oversight could be made again in future. Instead let's remove the relkind filter altogether. These functions shouldn't cost much when there are no objects that they need to process, and surely this isn't an especially performance-critical case anyway. Per bug #18407 from Vidushi Gupta. Back-patch to all supported branches. Discussion: https://postgr.es/m/18407-4fd07373d252c...@postgresql.org Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/97de2a15992f997b3461a4a6a6172f43e60308f0 Modified Files -- src/backend/commands/tablecmds.c | 15 +-- src/test/regress/expected/foreign_data.out | 29 + src/test/regress/sql/foreign_data.sql | 2 ++ 3 files changed, 24 insertions(+), 22 deletions(-)
pgsql: Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences.
Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences. Ordinary ALTER TABLE SET SCHEMA will also move any owned sequences into the new schema. We failed to do likewise for foreign tables, because AlterTableNamespaceInternal believed that only certain relkinds could have indexes, owned sequences, or constraints. We could simply add foreign tables to that relkind list, but it seems likely that the same oversight could be made again in future. Instead let's remove the relkind filter altogether. These functions shouldn't cost much when there are no objects that they need to process, and surely this isn't an especially performance-critical case anyway. Per bug #18407 from Vidushi Gupta. Back-patch to all supported branches. Discussion: https://postgr.es/m/18407-4fd07373d252c...@postgresql.org Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/66bbad581ce289fab8a55152987a223fe8795fee Modified Files -- src/backend/commands/tablecmds.c | 15 +-- src/test/regress/expected/foreign_data.out | 29 + src/test/regress/sql/foreign_data.sql | 2 ++ 3 files changed, 24 insertions(+), 22 deletions(-)
pgsql: Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences.
Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences. Ordinary ALTER TABLE SET SCHEMA will also move any owned sequences into the new schema. We failed to do likewise for foreign tables, because AlterTableNamespaceInternal believed that only certain relkinds could have indexes, owned sequences, or constraints. We could simply add foreign tables to that relkind list, but it seems likely that the same oversight could be made again in future. Instead let's remove the relkind filter altogether. These functions shouldn't cost much when there are no objects that they need to process, and surely this isn't an especially performance-critical case anyway. Per bug #18407 from Vidushi Gupta. Back-patch to all supported branches. Discussion: https://postgr.es/m/18407-4fd07373d252c...@postgresql.org Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7445f092814dbb8ac3061524fc341a209f805d80 Modified Files -- src/backend/commands/tablecmds.c | 15 +-- src/test/regress/expected/foreign_data.out | 29 + src/test/regress/sql/foreign_data.sql | 2 ++ 3 files changed, 24 insertions(+), 22 deletions(-)
pgsql: Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences.
Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences. Ordinary ALTER TABLE SET SCHEMA will also move any owned sequences into the new schema. We failed to do likewise for foreign tables, because AlterTableNamespaceInternal believed that only certain relkinds could have indexes, owned sequences, or constraints. We could simply add foreign tables to that relkind list, but it seems likely that the same oversight could be made again in future. Instead let's remove the relkind filter altogether. These functions shouldn't cost much when there are no objects that they need to process, and surely this isn't an especially performance-critical case anyway. Per bug #18407 from Vidushi Gupta. Back-patch to all supported branches. Discussion: https://postgr.es/m/18407-4fd07373d252c...@postgresql.org Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b48eda4e54810aa1d8dd2af7c6763fd414d8e0a1 Modified Files -- src/backend/commands/tablecmds.c | 15 +-- src/test/regress/expected/foreign_data.out | 29 + src/test/regress/sql/foreign_data.sql | 2 ++ 3 files changed, 24 insertions(+), 22 deletions(-)
pgsql: Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences.
Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences. Ordinary ALTER TABLE SET SCHEMA will also move any owned sequences into the new schema. We failed to do likewise for foreign tables, because AlterTableNamespaceInternal believed that only certain relkinds could have indexes, owned sequences, or constraints. We could simply add foreign tables to that relkind list, but it seems likely that the same oversight could be made again in future. Instead let's remove the relkind filter altogether. These functions shouldn't cost much when there are no objects that they need to process, and surely this isn't an especially performance-critical case anyway. Per bug #18407 from Vidushi Gupta. Back-patch to all supported branches. Discussion: https://postgr.es/m/18407-4fd07373d252c...@postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fad3b5b5acb154725b0265010642ee95fa37c5d7 Modified Files -- src/backend/commands/tablecmds.c | 15 +-- src/test/regress/expected/foreign_data.out | 29 + src/test/regress/sql/foreign_data.sql | 2 ++ 3 files changed, 24 insertions(+), 22 deletions(-)
pgsql: Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences.
Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences. Ordinary ALTER TABLE SET SCHEMA will also move any owned sequences into the new schema. We failed to do likewise for foreign tables, because AlterTableNamespaceInternal believed that only certain relkinds could have indexes, owned sequences, or constraints. We could simply add foreign tables to that relkind list, but it seems likely that the same oversight could be made again in future. Instead let's remove the relkind filter altogether. These functions shouldn't cost much when there are no objects that they need to process, and surely this isn't an especially performance-critical case anyway. Per bug #18407 from Vidushi Gupta. Back-patch to all supported branches. Discussion: https://postgr.es/m/18407-4fd07373d252c...@postgresql.org Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a8b7408686a5576cf3b102dcbec61d37dde04b02 Modified Files -- src/backend/commands/tablecmds.c | 15 +-- src/test/regress/expected/foreign_data.out | 29 + src/test/regress/sql/foreign_data.sql | 2 ++ 3 files changed, 24 insertions(+), 22 deletions(-)
pgsql: Micro-optimize pg_lfind32().
Micro-optimize pg_lfind32(). This commit improves the performance of pg_lfind32() in many cases by modifying it to process the remaining "tail" of elements with SIMD instructions instead of processing them one-by-one. Since the SIMD code processes a large block of elements, this means that we will process a subset of elements more than once, but that won't affect the correctness of the result, and testing has shown that this helps more cases than it regresses. With this change, the standard one-by-one linear search code is only used for small arrays and for platforms without SIMD support. Suggested-by: John Naylor Reviewed-by: John Naylor Discussion: https://postgr.es/m/20231129171526.GA857928%40nathanxps13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7644a7340c8a7764f1b20b34e1273b41347cbfcb Modified Files -- src/include/port/pg_lfind.h | 114 +--- 1 file changed, 76 insertions(+), 38 deletions(-)
pgsql: Propagate pathkeys from CTEs up to the outer query.
Propagate pathkeys from CTEs up to the outer query. If we know the sort order of a CTE's output, and it is relevant to the outer query, label the CTE's outer-query access path using those pathkeys. This may enable optimizations such as avoiding a sort in the outer query. The code for hoisting pathkeys into the outer query already exists for regular RTE_SUBQUERY subqueries, but it wasn't getting used for CTEs, possibly out of concern for maintaining an optimization fence between the CTE and the outer query. However, on the same arguments used for commit f7816aec2, there seems no harm in letting the outer query know what the inner query decided to do. In support of this, we now remember the best Path as well as Plan for each subquery for the rest of the planner run. There may be future applications for having that at hand, and it surely costs little to build one more List. Richard Guo (minor mods by me) Discussion: https://postgr.es/m/cambws49xyd3f8cre8-ww3--dv1zh_sdsdn-vs2dzhj81wcn...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a65724dfa73db8b451d0c874a9161935a34a914e Modified Files -- src/backend/optimizer/path/allpaths.c | 16 ++-- src/backend/optimizer/plan/planner.c | 1 + src/backend/optimizer/plan/subselect.c | 28 ++-- src/backend/optimizer/util/pathnode.c | 5 +++-- src/include/nodes/pathnodes.h | 3 +++ src/include/optimizer/pathnode.h | 2 +- src/test/regress/expected/with.out | 17 + src/test/regress/sql/with.sql | 7 +++ 8 files changed, 64 insertions(+), 15 deletions(-)
pgsql: C comment: mention no doc for negative start of substring(text)
C comment: mention no doc for negative start of substring(text) Also add URL to hackers discussion. Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e648e77e25708874196326b6e4da30e7717156ab Modified Files -- src/backend/utils/adt/varlena.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Allow "make check"-style testing to work with musl C library.
Allow "make check"-style testing to work with musl C library. The musl dynamic linker saves a pointer to the process' environment value of LD_LIBRARY_PATH very early in startup. When we move/clobber the environment to make more room for ps status strings, we clobber that value and thereby prevent libraries from being found via LD_LIBRARY_PATH, which breaks the use of a temporary installation for testing purposes. To fix, stop collecting usable space for ps status if we notice that the variable we are about to clobber is LD_LIBRARY_PATH. This will result in some reduction in how long the ps status can be, but it's only likely to occur in temporary test contexts, so it doesn't seem like a big problem. In any case, we don't have to do it if we see we are on glibc, which surely is where the majority of our Linux testing is done. Thomas Munro, Bruce Momjian, and Tom Lane, per report from Wolfgang Walther. Back-patch to all supported branches, with the hope that we'll set up a buildfarm animal to test on this platform. Discussion: https://postgr.es/m/fddd1cd6-dc16-40a2-9eb5-d7fef2101...@technowledgy.de Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3c3f4fd741d0c795470a61d12c285af9acdcea0e Modified Files -- src/backend/utils/misc/ps_status.c | 35 +++ 1 file changed, 31 insertions(+), 4 deletions(-)
pgsql: Allow "make check"-style testing to work with musl C library.
Allow "make check"-style testing to work with musl C library. The musl dynamic linker saves a pointer to the process' environment value of LD_LIBRARY_PATH very early in startup. When we move/clobber the environment to make more room for ps status strings, we clobber that value and thereby prevent libraries from being found via LD_LIBRARY_PATH, which breaks the use of a temporary installation for testing purposes. To fix, stop collecting usable space for ps status if we notice that the variable we are about to clobber is LD_LIBRARY_PATH. This will result in some reduction in how long the ps status can be, but it's only likely to occur in temporary test contexts, so it doesn't seem like a big problem. In any case, we don't have to do it if we see we are on glibc, which surely is where the majority of our Linux testing is done. Thomas Munro, Bruce Momjian, and Tom Lane, per report from Wolfgang Walther. Back-patch to all supported branches, with the hope that we'll set up a buildfarm animal to test on this platform. Discussion: https://postgr.es/m/fddd1cd6-dc16-40a2-9eb5-d7fef2101...@technowledgy.de Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7124e7d528a89b6fa4cbe803cf85ecf6ddff29c3 Modified Files -- src/backend/utils/misc/ps_status.c | 35 +++ 1 file changed, 31 insertions(+), 4 deletions(-)
pgsql: Allow "make check"-style testing to work with musl C library.
Allow "make check"-style testing to work with musl C library. The musl dynamic linker saves a pointer to the process' environment value of LD_LIBRARY_PATH very early in startup. When we move/clobber the environment to make more room for ps status strings, we clobber that value and thereby prevent libraries from being found via LD_LIBRARY_PATH, which breaks the use of a temporary installation for testing purposes. To fix, stop collecting usable space for ps status if we notice that the variable we are about to clobber is LD_LIBRARY_PATH. This will result in some reduction in how long the ps status can be, but it's only likely to occur in temporary test contexts, so it doesn't seem like a big problem. In any case, we don't have to do it if we see we are on glibc, which surely is where the majority of our Linux testing is done. Thomas Munro, Bruce Momjian, and Tom Lane, per report from Wolfgang Walther. Back-patch to all supported branches, with the hope that we'll set up a buildfarm animal to test on this platform. Discussion: https://postgr.es/m/fddd1cd6-dc16-40a2-9eb5-d7fef2101...@technowledgy.de Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d82605bcd6663cb7dc506fc9c0c5c9c7d80e144b Modified Files -- src/backend/utils/misc/ps_status.c | 35 +++ 1 file changed, 31 insertions(+), 4 deletions(-)
pgsql: Allow "make check"-style testing to work with musl C library.
Allow "make check"-style testing to work with musl C library. The musl dynamic linker saves a pointer to the process' environment value of LD_LIBRARY_PATH very early in startup. When we move/clobber the environment to make more room for ps status strings, we clobber that value and thereby prevent libraries from being found via LD_LIBRARY_PATH, which breaks the use of a temporary installation for testing purposes. To fix, stop collecting usable space for ps status if we notice that the variable we are about to clobber is LD_LIBRARY_PATH. This will result in some reduction in how long the ps status can be, but it's only likely to occur in temporary test contexts, so it doesn't seem like a big problem. In any case, we don't have to do it if we see we are on glibc, which surely is where the majority of our Linux testing is done. Thomas Munro, Bruce Momjian, and Tom Lane, per report from Wolfgang Walther. Back-patch to all supported branches, with the hope that we'll set up a buildfarm animal to test on this platform. Discussion: https://postgr.es/m/fddd1cd6-dc16-40a2-9eb5-d7fef2101...@technowledgy.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8a92b70c11ba2b5f0d2b2611d9453dd90f618629 Modified Files -- src/backend/utils/misc/ps_status.c | 35 +++ 1 file changed, 31 insertions(+), 4 deletions(-)
pgsql: Allow "make check"-style testing to work with musl C library.
Allow "make check"-style testing to work with musl C library. The musl dynamic linker saves a pointer to the process' environment value of LD_LIBRARY_PATH very early in startup. When we move/clobber the environment to make more room for ps status strings, we clobber that value and thereby prevent libraries from being found via LD_LIBRARY_PATH, which breaks the use of a temporary installation for testing purposes. To fix, stop collecting usable space for ps status if we notice that the variable we are about to clobber is LD_LIBRARY_PATH. This will result in some reduction in how long the ps status can be, but it's only likely to occur in temporary test contexts, so it doesn't seem like a big problem. In any case, we don't have to do it if we see we are on glibc, which surely is where the majority of our Linux testing is done. Thomas Munro, Bruce Momjian, and Tom Lane, per report from Wolfgang Walther. Back-patch to all supported branches, with the hope that we'll set up a buildfarm animal to test on this platform. Discussion: https://postgr.es/m/fddd1cd6-dc16-40a2-9eb5-d7fef2101...@technowledgy.de Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/243e9953281f680037eb65ee638b030424b84947 Modified Files -- src/backend/utils/misc/ps_status.c | 35 +++ 1 file changed, 31 insertions(+), 4 deletions(-)
pgsql: Allow "make check"-style testing to work with musl C library.
Allow "make check"-style testing to work with musl C library. The musl dynamic linker saves a pointer to the process' environment value of LD_LIBRARY_PATH very early in startup. When we move/clobber the environment to make more room for ps status strings, we clobber that value and thereby prevent libraries from being found via LD_LIBRARY_PATH, which breaks the use of a temporary installation for testing purposes. To fix, stop collecting usable space for ps status if we notice that the variable we are about to clobber is LD_LIBRARY_PATH. This will result in some reduction in how long the ps status can be, but it's only likely to occur in temporary test contexts, so it doesn't seem like a big problem. In any case, we don't have to do it if we see we are on glibc, which surely is where the majority of our Linux testing is done. Thomas Munro, Bruce Momjian, and Tom Lane, per report from Wolfgang Walther. Back-patch to all supported branches, with the hope that we'll set up a buildfarm animal to test on this platform. Discussion: https://postgr.es/m/fddd1cd6-dc16-40a2-9eb5-d7fef2101...@technowledgy.de Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7651fd387697a8872d0e11ba2fcecfaf6cbaa39f Modified Files -- src/backend/utils/misc/ps_status.c | 35 +++ 1 file changed, 31 insertions(+), 4 deletions(-)
Re: pgsql: make dist uses git archive
On Tue, Mar 26, 2024 at 12:09 PM Andrew Dunstan wrote:
>
>
> On Tue, Mar 26, 2024 at 6:10 AM Andrew Dunstan
> wrote:
>
>>
>>
>> On Tue, Mar 26, 2024 at 5:15 AM Magnus Hagander
>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 26, 2024 at 9:13 AM Andrew Dunstan
>>> wrote:
>>>
On Tue, Mar 26, 2024 at 3:20 AM Peter Eisentraut
wrote:
> On 25.03.24 23:20, Andrew Dunstan wrote:
> > The problem occurs because except in vpath mode the buildfarm
> operates
> > on a copy of the code, and for efficiency reasons we don't copy the
> ,git
> > directory.
> >
> > The simplest fix is probably to change the machine's config to use a
> > vpath build.
> >
> > In the config file change the undef here to a 1:
> >
> > 'use_vpath' => undef,
> >
> > That worked for me in a quick test.
>
> Note that "make dist" doesn't work with vpath in backbranches. :-/
>
Ugh.
OK, plan B :
In the Module's setup code, right after the "die", put
symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>>> If I understand you right, you meant:
>>>
>>> die "can't run this module with vpath builds"
>>> if $conf->{vpath};
>>> + symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>>>
>>> my $self = {buildroot => $buildroot, pgbranch=> $branch, bfconf
>>> => $conf, pgsql => $pgsql};
>>> bless ($self, $class);
>>>
>>> If so, I tried that, but it didn't work. That's this run here:
>>> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus=2024-03-26%2009%3A02%3A51=make-dist
>>>
>>>
>>>
>> *sigh*
>>
>> OK, instead of speculating I'll experiment and come up with an answer.
>>
>
>
> OK, this should work. Put these lines after the first print statement of
> the module's build() routine - the setup() routine runs too early:
>
> my $src = "$self->{buildroot}/$self->{pgbranch}/pgsql";
> symlink("$src/.git", "$self->{pgsql}/.git");
>
>
>
That seems to have sorted it.
I did a manual force run and that made it recovered. Let's see if it's also
happy after the first regular run, but it definitely look right.
Thanks!
//Magnus
Re: pgsql: make dist uses git archive
On Tue, Mar 26, 2024 at 6:10 AM Andrew Dunstan wrote:
>
>
> On Tue, Mar 26, 2024 at 5:15 AM Magnus Hagander
> wrote:
>
>>
>>
>> On Tue, Mar 26, 2024 at 9:13 AM Andrew Dunstan
>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 26, 2024 at 3:20 AM Peter Eisentraut
>>> wrote:
>>>
On 25.03.24 23:20, Andrew Dunstan wrote:
> The problem occurs because except in vpath mode the buildfarm
operates
> on a copy of the code, and for efficiency reasons we don't copy the
,git
> directory.
>
> The simplest fix is probably to change the machine's config to use a
> vpath build.
>
> In the config file change the undef here to a 1:
>
> 'use_vpath' => undef,
>
> That worked for me in a quick test.
Note that "make dist" doesn't work with vpath in backbranches. :-/
>>>
>>>
>>> Ugh.
>>>
>>> OK, plan B :
>>>
>>> In the Module's setup code, right after the "die", put
>>>
>>> symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>>>
>>>
>> If I understand you right, you meant:
>>
>> die "can't run this module with vpath builds"
>> if $conf->{vpath};
>> + symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>>
>> my $self = {buildroot => $buildroot, pgbranch=> $branch, bfconf
>> => $conf, pgsql => $pgsql};
>> bless ($self, $class);
>>
>> If so, I tried that, but it didn't work. That's this run here:
>> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus=2024-03-26%2009%3A02%3A51=make-dist
>>
>>
>>
> *sigh*
>
> OK, instead of speculating I'll experiment and come up with an answer.
>
OK, this should work. Put these lines after the first print statement of
the module's build() routine - the setup() routine runs too early:
my $src = "$self->{buildroot}/$self->{pgbranch}/pgsql";
symlink("$src/.git", "$self->{pgsql}/.git");
cheers
andrew
Re: pgsql: make dist uses git archive
On Tue, Mar 26, 2024 at 5:15 AM Magnus Hagander wrote:
>
>
> On Tue, Mar 26, 2024 at 9:13 AM Andrew Dunstan
> wrote:
>
>>
>>
>> On Tue, Mar 26, 2024 at 3:20 AM Peter Eisentraut
>> wrote:
>>
>>> On 25.03.24 23:20, Andrew Dunstan wrote:
>>> > The problem occurs because except in vpath mode the buildfarm operates
>>> > on a copy of the code, and for efficiency reasons we don't copy the
>>> ,git
>>> > directory.
>>> >
>>> > The simplest fix is probably to change the machine's config to use a
>>> > vpath build.
>>> >
>>> > In the config file change the undef here to a 1:
>>> >
>>> > 'use_vpath' => undef,
>>> >
>>> > That worked for me in a quick test.
>>>
>>> Note that "make dist" doesn't work with vpath in backbranches. :-/
>>>
>>
>>
>> Ugh.
>>
>> OK, plan B :
>>
>> In the Module's setup code, right after the "die", put
>>
>> symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>>
>>
> If I understand you right, you meant:
>
> die "can't run this module with vpath builds"
> if $conf->{vpath};
> + symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>
> my $self = {buildroot => $buildroot, pgbranch=> $branch, bfconf
> => $conf, pgsql => $pgsql};
> bless ($self, $class);
>
> If so, I tried that, but it didn't work. That's this run here:
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus=2024-03-26%2009%3A02%3A51=make-dist
>
>
>
*sigh*
OK, instead of speculating I'll experiment and come up with an answer.
cheers
andrew
pgsql: Remove ObjectClass type
Remove ObjectClass type ObjectClass is an enum whose values correspond to catalog OIDs. But the extra layer of redirection, which is used only in small parts of the code, and the similarity to ObjectType, are confusing and cumbersome. One advantage has been that some switches processing the OCLASS enum don't have "default:" cases. This is so that the compiler tells us when we fail to add support for some new object class. But you can also handle that with some assertions and proper test coverage. It's not even clear how strong this benefit is. For example, in AlterObjectNamespace_oid(), you could still put a new OCLASS into the "ignore object types that don't have schema-qualified names" case, and it might or might not be wrong. Also, there are already various OCLASS switches that do have a default case, so it's not even clear what the preferred coding style should be. Reviewed-by: jian he Reviewed-by: Michael Paquier Discussion: https://www.postgresql.org/message-id/flat/CAGECzQT3caUbcCcszNewCCmMbCuyP7XNAm60J3ybd6PN5kH2Dw%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/89e5ef7e21812916c9cf9fcf56e45f0f74034656 Modified Files -- src/backend/catalog/dependency.c | 239 +- src/backend/catalog/objectaddress.c | 316 +++ src/backend/commands/alter.c | 73 ++-- src/backend/commands/event_trigger.c | 130 +++--- src/backend/commands/tablecmds.c | 62 ++- src/include/catalog/dependency.h | 51 -- src/include/commands/event_trigger.h | 2 +- src/tools/pgindent/typedefs.list | 1 - 8 files changed, 233 insertions(+), 641 deletions(-)
Re: pgsql: make dist uses git archive
On Tue, Mar 26, 2024 at 9:13 AM Andrew Dunstan wrote:
>
>
> On Tue, Mar 26, 2024 at 3:20 AM Peter Eisentraut
> wrote:
>
>> On 25.03.24 23:20, Andrew Dunstan wrote:
>> > The problem occurs because except in vpath mode the buildfarm operates
>> > on a copy of the code, and for efficiency reasons we don't copy the
>> ,git
>> > directory.
>> >
>> > The simplest fix is probably to change the machine's config to use a
>> > vpath build.
>> >
>> > In the config file change the undef here to a 1:
>> >
>> > 'use_vpath' => undef,
>> >
>> > That worked for me in a quick test.
>>
>> Note that "make dist" doesn't work with vpath in backbranches. :-/
>>
>
>
> Ugh.
>
> OK, plan B :
>
> In the Module's setup code, right after the "die", put
>
> symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>
>
If I understand you right, you meant:
die "can't run this module with vpath builds"
if $conf->{vpath};
+ symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
my $self = {buildroot => $buildroot, pgbranch=> $branch, bfconf =>
$conf, pgsql => $pgsql};
bless ($self, $class);
If so, I tried that, but it didn't work. That's this run here:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus=2024-03-26%2009%3A02%3A51=make-dist
//Magnus
Re: pgsql: make dist uses git archive
On Tue, Mar 26, 2024 at 3:20 AM Peter Eisentraut
wrote:
> On 25.03.24 23:20, Andrew Dunstan wrote:
> > The problem occurs because except in vpath mode the buildfarm operates
> > on a copy of the code, and for efficiency reasons we don't copy the ,git
> > directory.
> >
> > The simplest fix is probably to change the machine's config to use a
> > vpath build.
> >
> > In the config file change the undef here to a 1:
> >
> > 'use_vpath' => undef,
> >
> > That worked for me in a quick test.
>
> Note that "make dist" doesn't work with vpath in backbranches. :-/
>
Ugh.
OK, plan B :
In the Module's setup code, right after the "die", put
symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
cheers
andrew
Re: pgsql: pg_createsubscriber: creates a new logical replica from a standb
I have committed your patch to tidy this up. Thanks.
On 26.03.24 06:01, Kyotaro Horiguchi wrote:
Hello.
This commit added the following error message:
pg_createsubscriber.c: 375
pg_fatal("could not access directory \"%s\": %s",
datadir,
strerror(errno));
Although other messages use %s with PQresultErrorMessage(), regarding
this specific message, shouldn't we use %m instead of %s + strerror()?
I'm not sure if that would be better.
pg_createsubscriber.c: 687
pg_log_error("could not obtain database OID: got %d rows, expected
%d rows",
PQntuples(res), 1);
pg_createsubscriber.c: 1652
pg_log_error("could not obtain subscription OID: got %d rows,
expected %d rows",
In these messages, the second %d is always written as "1 rows",
whereas a similar message correctly uses "1 row".
pg_createsubscriber.c: 561
pg_log_error("could not get system identifier: got %d rows, expected
%d row",
PQntuples(res), 1);
I think it would be better to change the former instances to "%d row",
or to change both to "1 row". I'd like to go the second way but maybe
we should take the first way following our convention.
pg_createsubscriber.c: 923
pg_log_error("publisher requires wal_level >= logical");
We discussed this message in relation to commit 801792e528, and
decided to quote "logical" to clarify that it is a string literal. I'd
like to follow the conclusion here, too.
regards.
pgsql: Message fixes for pg_createsubscriber
Message fixes for pg_createsubscriber Author: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/20240326.140116.1116279856046587865.horikyota@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8c4f2d5475b9f0411baf38590c054ba1fb566780 Modified Files -- src/bin/pg_basebackup/pg_createsubscriber.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-)
Re: pgsql: make dist uses git archive
On 25.03.24 23:20, Andrew Dunstan wrote: The problem occurs because except in vpath mode the buildfarm operates on a copy of the code, and for efficiency reasons we don't copy the ,git directory. The simplest fix is probably to change the machine's config to use a vpath build. In the config file change the undef here to a 1: 'use_vpath' => undef, That worked for me in a quick test. Note that "make dist" doesn't work with vpath in backbranches. :-/
