Re: pgsql: Build all Flex files standalone
The second failure is on drongo (MSVC):
"c:\\prog\\bf\\root\\HEAD\\pgsql.build\\pgsql.sln" (default target) (1) ->
"c:\\prog\\bf\\root\\HEAD\\pgsql.build\\isolationtester.vcxproj"
(default target) (13) ->
(Link target) ->
specparse.obj : error LNK2019: unresolved external symbol spec_yylex
referenced in function spec_yyparse
[c:\\prog\\bf\\root\\HEAD\\pgsql.build\\isolationtester.vcxproj]
specparse.obj : error LNK2019: unresolved external symbol
spec_yyerror referenced in function spec_yyparse
[c:\\prog\\bf\\root\\HEAD\\pgsql.build\\isolationtester.vcxproj]
.\\Release\\isolationtester\\isolationtester.exe : fatal error
LNK1120: 2 unresolved externals
[c:\\prog\\bf\\root\\HEAD\\pgsql.build\\isolationtester.vcxproj]
For this, Mkvcbuild.pm specifies specparse.c explicitly, so maybe
something like the following is needed:
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -362,6 +362,7 @@ sub mkvcbuild
$isolation_tester->AddFile('src/test/isolation/specparse.y');
$isolation_tester->AddFile('src/test/isolation/specscanner.l');
$isolation_tester->AddFile('src/test/isolation/specparse.c');
+ $isolation_tester->AddFile('src/test/isolation/specscanner.c');
$isolation_tester->AddIncludeDir('src/test/isolation');
--
John Naylor
EDB: http://www.enterprisedb.com
pgsql: Fix MSVC linker error for specparse.obj
Fix MSVC linker error for specparse.obj Per buildfarm animals drongo Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/92e7b7722da98eb4d54df7d4f850eee6a5fe9eef Modified Files -- src/tools/msvc/Mkvcbuild.pm | 1 + 1 file changed, 1 insertion(+)
Re: pgsql: Build all Flex files standalone
On Sun, Sep 4, 2022 at 4:36 PM John Naylor wrote:
>
> For this, Mkvcbuild.pm specifies specparse.c explicitly, so maybe
> something like the following is needed:
>
> --- a/src/tools/msvc/Mkvcbuild.pm
> +++ b/src/tools/msvc/Mkvcbuild.pm
> @@ -362,6 +362,7 @@ sub mkvcbuild
> $isolation_tester->AddFile('src/test/isolation/specparse.y');
> $isolation_tester->AddFile('src/test/isolation/specscanner.l');
> $isolation_tester->AddFile('src/test/isolation/specparse.c');
> + $isolation_tester->AddFile('src/test/isolation/specscanner.c');
> $isolation_tester->AddIncludeDir('src/test/isolation');
This gets CI green (tip o' the hat to Thomas Munro for off-list advice
on getting that working), so pushed.
--
John Naylor
EDB: http://www.enterprisedb.com
Re: pgsql: Build all Flex files standalone
On 2022-09-04 Su 02:19, John Naylor wrote: > Crake fails with > > headerscheck: > Sep 04 01:56:01 In file included from /tmp/headerscheck.UNgmKy/test.c:2: > Sep 04 01:56:01 > /home/andrew/bf/root/HEAD/pgsql.build/../pgsql/src/backend/utils/adt/jsonpath_internal.h:26:10: > fatal error: jsonpath_gram.h: No such file or directory > Sep 04 01:56:0126 | #include "jsonpath_gram.h" > Sep 04 01:56:01 | ^ > Sep 04 01:56:01 compilation terminated. > Sep 04 01:56:14 make: *** [GNUmakefile:138: headerscheck] Error 1 > cpluspluscheck: > Sep 04 01:57:19 In file included from /tmp/cpluspluscheck.HhRV5k/test.cpp:3: > Sep 04 01:57:19 > /home/andrew/bf/root/HEAD/pgsql.build/../pgsql/src/backend/utils/adt/jsonpath_internal.h:26:10: > fatal error: jsonpath_gram.h: No such file or directory > Sep 04 01:57:1926 | #include "jsonpath_gram.h" > Sep 04 01:57:19 | ^ > > I don't get the same in an already-built tree. I also don't see an > exception for gramparse.h, which I imagine would have the same issue? Probably happens because crake does vpath builds. I think you're going to have to set up EXTRAINCLUDES for it - see near the bottom of the headerscheck script. Possibly something like src/backend/utils/adt/*) EXTRAINCLUDES="-I $builddir/src/backend/utils/adt" ;; cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Re: pgsql: Build all Flex files standalone
Hi,
On 2022-09-04 18:04:13 +0700, John Naylor wrote:
> On Sun, Sep 4, 2022 at 4:36 PM John Naylor
> wrote:
> >
> > For this, Mkvcbuild.pm specifies specparse.c explicitly, so maybe
> > something like the following is needed:
> >
> > --- a/src/tools/msvc/Mkvcbuild.pm
> > +++ b/src/tools/msvc/Mkvcbuild.pm
> > @@ -362,6 +362,7 @@ sub mkvcbuild
> > $isolation_tester->AddFile('src/test/isolation/specparse.y');
> > $isolation_tester->AddFile('src/test/isolation/specscanner.l');
> > $isolation_tester->AddFile('src/test/isolation/specparse.c');
> > + $isolation_tester->AddFile('src/test/isolation/specscanner.c');
> > $isolation_tester->AddIncludeDir('src/test/isolation');
>
> This gets CI green (tip o' the hat to Thomas Munro for off-list advice
> on getting that working), so pushed.
It doesn't seem to have gotten all of CI green, cpluspluscheck fails:
https://cirrus-ci.com/task/6561938334285824
I think this just needs a copy the logic you added to headerscheck also to
cpluspluscheck (and yes, we should merge these files one of these days).
Greetings,
Andres Freund
Re: pgsql: Build all Flex files standalone
Hi, On 2022-09-04 13:19:56 +0700, John Naylor wrote: > Crake fails with > > headerscheck: > Sep 04 01:56:01 In file included from /tmp/headerscheck.UNgmKy/test.c:2: > Sep 04 01:56:01 > /home/andrew/bf/root/HEAD/pgsql.build/../pgsql/src/backend/utils/adt/jsonpath_internal.h:26:10: > fatal error: jsonpath_gram.h: No such file or directory > Sep 04 01:56:0126 | #include "jsonpath_gram.h" > Sep 04 01:56:01 | ^ > Sep 04 01:56:01 compilation terminated. > Sep 04 01:56:14 make: *** [GNUmakefile:138: headerscheck] Error 1 > cpluspluscheck: > Sep 04 01:57:19 In file included from /tmp/cpluspluscheck.HhRV5k/test.cpp:3: > Sep 04 01:57:19 > /home/andrew/bf/root/HEAD/pgsql.build/../pgsql/src/backend/utils/adt/jsonpath_internal.h:26:10: > fatal error: jsonpath_gram.h: No such file or directory > Sep 04 01:57:1926 | #include "jsonpath_gram.h" > Sep 04 01:57:19 | ^ > > I don't get the same in an already-built tree. I also don't see an > exception for gramparse.h, which I imagine would have the same issue? It doesn't happen for gramparse.h because gram.h is copied to src/include/parser (see src/backend/Makefile), and included as parser/gram.h. I think this could be addressed by always adding something like -iquote $builddir/$(dirname "$f") -iquote $srcdir/$(dirname "$f") \ to cpluspluscheck/headerscheck. Greetings, Andres Freund
pgsql: Force parallelism in partition_aggregate
Force parallelism in partition_aggregate Commit db0d67db2 tweaked sort costing, which however resulted in a couple plan changes in our regression tests. Most of the new plans were fine, but partition_aggregate were meant to test parallel plans and the new plans were serial. Fix that by lowering parallel_setup_cost to 0, which is enough to switch to the parallel plan again. Report and patch by David Rowley. Author: David Rowley Reviewed-by: Tomas Vondra Discussion: https://postgr.es/m/CAApHDvpVFgWzXdtUQkjyOPhNrNvumRi_=ftgs79keaz92tn...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/01474f56981a4b27fe5e304a61b0fce2ac025c69 Modified Files -- src/test/regress/expected/partition_aggregate.out | 114 -- src/test/regress/sql/partition_aggregate.sql | 3 + 2 files changed, 63 insertions(+), 54 deletions(-)
pgsql: Reinstate tests accidentally removed by e3fcca0d0d
Reinstate tests accidentally removed by e3fcca0d0d Commit e3fcca0d0d24 reverted modifications to HOT for BRIN, but it also removed a couple unrelated tests from stats.sql. Reinstate those tests. Reported-by: Peter Eisentraut Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/46b588afcdc6891bb0972bdeb6bc36bad5c01033 Modified Files -- src/test/regress/expected/stats.out | 242 src/test/regress/sql/stats.sql | 111 + 2 files changed, 353 insertions(+)
pgsql: Force parallelism in partition_aggregate
Force parallelism in partition_aggregate Commit db0d67db2 tweaked sort costing, which however resulted in a couple plan changes in our regression tests. Most of the new plans were fine, but partition_aggregate were meant to test parallel plans and the new plans were serial. Fix that by lowering parallel_setup_cost to 0, which is enough to switch to the parallel plan again. Commit 1349d2790 already made the plans parallel again, but do this anyway to keep the tests in sync with 15, to make backpatching simpler. Report and patch by David Rowley. Author: David Rowley Reviewed-by: Tomas Vondra Discussion: https://postgr.es/m/CAApHDvpVFgWzXdtUQkjyOPhNrNvumRi_=ftgs79keaz92tn...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2fe6b2a806f20f2dbf02c6e79783dbc2777a1840 Modified Files -- src/test/regress/expected/partition_aggregate.out | 2 ++ src/test/regress/sql/partition_aggregate.sql | 3 +++ 2 files changed, 5 insertions(+)
Re: pgsql: Build all Flex files standalone
On Sun, Sep 4, 2022 at 8:34 PM Andrew Dunstan wrote: > Probably happens because crake does vpath builds. I think you're going > to have to set up EXTRAINCLUDES for it - see near the bottom of the > headerscheck script. Possibly something like > > > src/backend/utils/adt/*) > > EXTRAINCLUDES="-I $builddir/src/backend/utils/adt" ;; Okay, I'll look at this and the cpp header check within 24 hours. -- John Naylor EDB: http://www.enterprisedb.com
pgsql: Doc: clarify partitioned table limitations
Doc: clarify partitioned table limitations Improve documentation regarding the limitations of unique and primary key constraints on partitioned tables. The existing documentation didn't make it clear that the constraint columns had to be present in the partition key as bare columns. The reader could be led to believe that it was ok to include the constraint columns as part of a function call's parameters or as part of an expression. Additionally, the documentation didn't mention anything about the fact that we disallow unique and primary key constraints if the partition keys contain *any* function calls or expressions, regardless of if the constraint columns appear as columns elsewhere in the partition key. The confusion here was highlighted by a report on the general mailing list by James Vanns. Discussion: https://postgr.es/m/cah7vdhnf0edyzz3glpge3rsjlwwlhek7a_fiks9dpbt3dz_...@mail.gmail.com Discussion: https://postgr.es/m/CAApHDvoU-u9iTqKjteYRFfi+UNEk7dbSAcyxEQD==vzt9b1...@mail.gmail.com Reviewed-by: Erik Rijkers Backpatch-through: 11 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/519be095f2bf7150fe7a36c4f5cd0c1825126427 Modified Files -- doc/src/sgml/ddl.sgml | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)
pgsql: Doc: clarify partitioned table limitations
Doc: clarify partitioned table limitations Improve documentation regarding the limitations of unique and primary key constraints on partitioned tables. The existing documentation didn't make it clear that the constraint columns had to be present in the partition key as bare columns. The reader could be led to believe that it was ok to include the constraint columns as part of a function call's parameters or as part of an expression. Additionally, the documentation didn't mention anything about the fact that we disallow unique and primary key constraints if the partition keys contain *any* function calls or expressions, regardless of if the constraint columns appear as columns elsewhere in the partition key. The confusion here was highlighted by a report on the general mailing list by James Vanns. Discussion: https://postgr.es/m/cah7vdhnf0edyzz3glpge3rsjlwwlhek7a_fiks9dpbt3dz_...@mail.gmail.com Discussion: https://postgr.es/m/CAApHDvoU-u9iTqKjteYRFfi+UNEk7dbSAcyxEQD==vzt9b1...@mail.gmail.com Reviewed-by: Erik Rijkers Backpatch-through: 11 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6ce4c4d83101886e0a9fea026faa3480a572bc84 Modified Files -- doc/src/sgml/ddl.sgml | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)
pgsql: Doc: clarify partitioned table limitations
Doc: clarify partitioned table limitations Improve documentation regarding the limitations of unique and primary key constraints on partitioned tables. The existing documentation didn't make it clear that the constraint columns had to be present in the partition key as bare columns. The reader could be led to believe that it was ok to include the constraint columns as part of a function call's parameters or as part of an expression. Additionally, the documentation didn't mention anything about the fact that we disallow unique and primary key constraints if the partition keys contain *any* function calls or expressions, regardless of if the constraint columns appear as columns elsewhere in the partition key. The confusion here was highlighted by a report on the general mailing list by James Vanns. Discussion: https://postgr.es/m/cah7vdhnf0edyzz3glpge3rsjlwwlhek7a_fiks9dpbt3dz_...@mail.gmail.com Discussion: https://postgr.es/m/CAApHDvoU-u9iTqKjteYRFfi+UNEk7dbSAcyxEQD==vzt9b1...@mail.gmail.com Reviewed-by: Erik Rijkers Backpatch-through: 11 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a254545a54a2e14ec6f41b8190d6c6713a85a18a Modified Files -- doc/src/sgml/ddl.sgml | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)
pgsql: Doc: clarify partitioned table limitations
Doc: clarify partitioned table limitations Improve documentation regarding the limitations of unique and primary key constraints on partitioned tables. The existing documentation didn't make it clear that the constraint columns had to be present in the partition key as bare columns. The reader could be led to believe that it was ok to include the constraint columns as part of a function call's parameters or as part of an expression. Additionally, the documentation didn't mention anything about the fact that we disallow unique and primary key constraints if the partition keys contain *any* function calls or expressions, regardless of if the constraint columns appear as columns elsewhere in the partition key. The confusion here was highlighted by a report on the general mailing list by James Vanns. Discussion: https://postgr.es/m/cah7vdhnf0edyzz3glpge3rsjlwwlhek7a_fiks9dpbt3dz_...@mail.gmail.com Discussion: https://postgr.es/m/CAApHDvoU-u9iTqKjteYRFfi+UNEk7dbSAcyxEQD==vzt9b1...@mail.gmail.com Reviewed-by: Erik Rijkers Backpatch-through: 11 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b70db6c83073b562a92aaba917aa787c46ea1b39 Modified Files -- doc/src/sgml/ddl.sgml | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)
pgsql: Doc: clarify partitioned table limitations
Doc: clarify partitioned table limitations Improve documentation regarding the limitations of unique and primary key constraints on partitioned tables. The existing documentation didn't make it clear that the constraint columns had to be present in the partition key as bare columns. The reader could be led to believe that it was ok to include the constraint columns as part of a function call's parameters or as part of an expression. Additionally, the documentation didn't mention anything about the fact that we disallow unique and primary key constraints if the partition keys contain *any* function calls or expressions, regardless of if the constraint columns appear as columns elsewhere in the partition key. The confusion here was highlighted by a report on the general mailing list by James Vanns. Discussion: https://postgr.es/m/cah7vdhnf0edyzz3glpge3rsjlwwlhek7a_fiks9dpbt3dz_...@mail.gmail.com Discussion: https://postgr.es/m/CAApHDvoU-u9iTqKjteYRFfi+UNEk7dbSAcyxEQD==vzt9b1...@mail.gmail.com Reviewed-by: Erik Rijkers Backpatch-through: 11 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/844ac0967e390583f589832d084f102e0791d0d6 Modified Files -- doc/src/sgml/ddl.sgml | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)
pgsql: Doc: clarify partitioned table limitations
Doc: clarify partitioned table limitations Improve documentation regarding the limitations of unique and primary key constraints on partitioned tables. The existing documentation didn't make it clear that the constraint columns had to be present in the partition key as bare columns. The reader could be led to believe that it was ok to include the constraint columns as part of a function call's parameters or as part of an expression. Additionally, the documentation didn't mention anything about the fact that we disallow unique and primary key constraints if the partition keys contain *any* function calls or expressions, regardless of if the constraint columns appear as columns elsewhere in the partition key. The confusion here was highlighted by a report on the general mailing list by James Vanns. Discussion: https://postgr.es/m/cah7vdhnf0edyzz3glpge3rsjlwwlhek7a_fiks9dpbt3dz_...@mail.gmail.com Discussion: https://postgr.es/m/CAApHDvoU-u9iTqKjteYRFfi+UNEk7dbSAcyxEQD==vzt9b1...@mail.gmail.com Reviewed-by: Erik Rijkers Backpatch-through: 11 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1630cad74092bf7af277762a22cc2605bd0bd5b6 Modified Files -- doc/src/sgml/ddl.sgml | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)
