Обсуждение: pgsql: Further cleanup of autoconf output files for GSSAPI changes.
Further cleanup of autoconf output files for GSSAPI changes. Running autoheader was missed in f7431bca8. This is cosmetic since we aren't using these HAVE_ symbols, but let's get everything in sync while we're looking at this. Discussion: https://postgr.es/m/2422362.1681741814@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d48ac0070cff197125088959e5644ed051322f5e Modified Files -------------- src/include/pg_config.h.in | 6 ++++++ 1 file changed, 6 insertions(+)
Further cleanup of autoconf output files for GSSAPI changes. Running autoheader was missed in f7431bca8. This is cosmetic since we aren't using these HAVE_ symbols, but let's get everything in sync while we're looking at this. Discussion: https://postgr.es/m/2422362.1681741814@sss.pgh.pa.us
I think this also needs a fix in src/tools/msvc/Solution.pm, see <https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2023-04-17%2016%3A30%3A03>
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes: > I think this also needs a fix in src/tools/msvc/Solution.pm, see > <https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2023-04-17%2016%3A30%3A03> Argh, forgot about that. Will fix. (This three-build-system business can't go away soon enough.) regards, tom lane
Andrew Dunstan <andrew@dunslane.net> writes:I think this also needs a fix in src/tools/msvc/Solution.pm, see <https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2023-04-17%2016%3A30%3A03>Argh, forgot about that. Will fix. (This three-build-system business can't go away soon enough.)
From my POV we can remove it any time - I am still having Windows issues with meson, but only with MSYS2. The MSVC meson build on drongo is perfectly well behaved.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
> On 2023-04-17 Mo 15:53, Tom Lane wrote:
>> (This three-build-system business can't go away soon enough.)
> From my POV we can remove it any time - I am still having Windows
> issues with meson, but only with MSYS2. The MSVC meson build on drongo
> is perfectly well behaved.
I think the outcome of the discussion a week or so ago was that
we want the MSVC scripts in v16, but we can nuke them from HEAD
as soon as the branch is made.
autoconf unfortunately will have to live a good bit longer ...
I don't think we're anywhere near the point where the meson
system is mature enough to drop that.
regards, tom lane
On 2023-04-17 16:22:30 -0400, Andrew Dunstan wrote: > I am still having Windows issues with meson, but only with MSYS2. Any more details on that? I might be able to help out / improve things.
On 2023-04-17 16:22:30 -0400, Andrew Dunstan wrote:I am still having Windows issues with meson, but only with MSYS2.Any more details on that? I might be able to help out / improve things.
For some reason which makes no sense to me the buildfarm animal fails at the first Stop-Db step. The DB is actually stopped, but pg_ctl returns a non-zero status. The thing that's really odd is that meson isn't at all involved in this step. But it's happened enough that I've had to back off using meson builds on fairywren - I'm going to do more testing on a new Windows instance.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
[redirecting to -hackers]
On 2023-04-20 Th 11:06, Andres Freund wrote:On 2023-04-17 16:22:30 -0400, Andrew Dunstan wrote:I am still having Windows issues with meson, but only with MSYS2.Any more details on that? I might be able to help out / improve things.
For some reason which makes no sense to me the buildfarm animal fails at the first Stop-Db step. The DB is actually stopped, but pg_ctl returns a non-zero status. The thing that's really odd is that meson isn't at all involved in this step. But it's happened enough that I've had to back off using meson builds on fairywren - I'm going to do more testing on a new Windows instance.
Still running into this, and I am rather stumped. This is a blocker for buildfarm support for meson:
Here's a simple illustration of the problem. If I do the identical test with a non-meson build there is no problem:
pgrunner@EC2AMAZ-GCB871B UCRT64 ~/bf
$ export PGCTLTIMEOUT=300
pgrunner@EC2AMAZ-GCB871B UCRT64 ~/bf
$ /usr/bin/perl -e 'chdir "root/HEAD/instkeep.2023-04-25_11-09-41"; system("bin/pg_ctl -D data-C -l logfile start") ; print "fail\n" if $?; '
waiting for server to start.... done
server started
pgrunner@EC2AMAZ-GCB871B UCRT64 ~/bf
$ /usr/bin/perl -e 'chdir "root/HEAD/instkeep.2023-04-25_11-09-41"; system("bin/pg_ctl -D data-C -l logfile stop") ; print "fail\n" if $?; '
waiting for server to shut down....fail
pgrunner@EC2AMAZ-GCB871B UCRT64 ~/bf
$ tail root/HEAD/instkeep.2023-04-25_11-09-41/logfile
2023-04-26 12:44:50.188 UTC [5132:2] LOG: listening on Unix socket "C:/tools/msys64/tmp/buildfarm-jaWBkm/.s.PGSQL.5678"
2023-04-26 12:44:50.249 UTC [5388:1] LOG: database system was shut down at 2023-04-26 12:43:02 UTC
2023-04-26 12:44:50.260 UTC [5132:3] LOG: database system is ready to accept connections
2023-04-26 12:45:01.542 UTC [5132:4] LOG: received fast shutdown request
2023-04-26 12:45:01.542 UTC [5132:5] LOG: aborting any active transactions
2023-04-26 12:45:01.547 UTC [5132:6] LOG: background worker "logical replication launcher" (PID 3876) exited with exit code 1
2023-04-26 12:45:01.550 UTC [6032:1] LOG: shutting down
2023-04-26 12:45:01.551 UTC [6032:2] LOG: checkpoint starting: shutdown immediate
2023-04-26 12:45:01.557 UTC [6032:3] LOG: checkpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.003 s, sync=0.001 s, total=0.007 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=0 kB; lsn=0/1034E7F8, redo lsn=0/1034E7F8
2023-04-26 12:45:01.568 UTC [5132:7] LOG: database system is shut down
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com