psql crash while executing core regression tests
hi During installation from source code, there are many crashes for psql while executing core regression tests, all the crashes are similar, the backtrace info as follows: Core was generated by 'psql'. Program terminated with signal 11, Segmentation fault. # 0 0x0043f140 in slash_yylex() (gdb) bt #0 0x0043f140 in slash_yylex() #1 0x004430fc in psql_scan_slash_command() #2 0x0043f140 in HandleSlashCmds() #3 0x0043f140 in MainLoop() #4 0x0043f140 in main() I did more compared testing about this scenario, as follows: 1. install from local source code(xxx.tar.gz) 1) switch to source tree directory, and build there no crash generated 2) create a build directory, and build there no crash generated 2. install from git source code 1) switch to source tree directory, and build there no crash generated 2) create a build directory, and build there many crashes generated, but if install newer version of flex, e.g. 2.6.4, the problem doesn't exist. Any suggestions about this behavior? NOTES: test commands are same, as follows: configure --enable-coverage --enable-tap-tests make make check testing environment: PostgreSQL: 13.2 redhat 7.4, 3.10.0-693.e17.x86_64 flex: 2.5.37 thanks walker
make coverage-html would fail within build directory separate from source tree
Hi, hackers During installation from source code, I created a build directory separate from the source tree, and execute the following command in the build directory: /home/postgres/postgresql-13.2/configure -- enable-coverage make make check make coverage-html However, while executing make coverage-html, it failed with the following error messages: /bin/lcov --gcov-tool /bin/gcov -q --no-external -c -i -d . -d /home/postgres/postgresql-13.2/ -o lcve_base.info ... geninfo: ERROR: no .gcno files found in /home/postgres/postgresql-13.2/! make: *** [lcov_base.info] Error 255 make: *** Deleting file 'lcov_base.info' if I repeat the above steps within the source tree directory, make coverage-html works fine. From the official documentation, I didn't find any limitations for "make coverage-html", not sure if I miss something. thanks walker
Re: make coverage-html would fail within build directory separate from source tree
thanks for your reply. it indeed that there are no .gcon files in source tree directory, they're in build tree directory, which results in failures. That's a bit wired. Add more detailed testing steps: mkdir build_dir cd build_dir /home/postgres/postgresql-13.2/configure -- enable-coverage make make check make coverage-html thanks walker -- Original -- From: "Alvaro Herrera"
Re: make coverage-html would fail within build directory separate from source tree
The same, the build directory is outside the source tree. the version of lcov is 1.10 thanks walker -- Original -- From: "Alvaro Herrera"
011_crash_recovery.pl failes using wal_block_size=16K
Hi, hackers
cd source_dir
./configure --enable-tap-tests --with-wal-blocksize=16
make world
make install-world
cd source_dir/src/test/recovery
make check PROVE_TESTS='t/011_crash_recovery.pl' PROVE_FLAGS='--verbose'
the output of the last command is:
011_crash_recovery.pl ..
1..3
ok 1 - own xid is in-progress
not ok 2 - new xid after restart is greater
# Failed test 'new xid after restart is greater'
# at t/011_crash_recovery.pl line 61
# '485'
# >
# '485'
not ok 3 - xid is aborted after crash
# Failed test 'xid is aborted after crash'
# at t/011_crash_recovery.pl line 65.
# got: 'committed'
# expected: 'aborted'
# Looks like you failed 2 tests of 3.
Dubious test returned 2(stat 512, 0x200)
Failed 2/3 subtests
..
But if I modified something in t/011_crash_recovery.pl, this perl script works
fine, as follows:
is($node->safe_psql('postgres'), qq[SELECT pg_xact_status('$xid');]),
'in progress', 'own xid is
in-progress');
sleep(1); # here new added, just make sure the CREATE TABLE XLOG can
be flushed into WAL segment file on disk.
# Crash and restart the postmaster
$node->stop('immediate');
$node->start;
I think the problem is that before crash(simulated by stop with immediate
mode), the XLOG of "create table mine" didn't get flushed into wal file on
disk. Instead, if delay some time, e.g. 200ms, or more after issue create
table, in theory, the data in wal buffer should be written to disk by wal
writer.
However, I'm not sure the root cause. what's the difference between
wal_blocksize=8k and wal_blocksize=16k while flushing wal buffer data to disk?
thanks
walker
Re: make coverage-html would fail within build directory separate from source tree
install a newer version of lcov 1.13, it works fine with WARNING just same as yours. much appreciated thanks walker -- Original -- From: "Alvaro Herrera" http://archives.postgresql.org/pgsql-sql/2006-03/msg00378.php
Re: make coverage-html would fail within build directory separate from source tree
Thanks for your reminder, Tom. Before I understand VPATH well, I always thought "outside the source tree" means the build tree is not under source tree. Here because of VPATH build, which means build tree should be a subdirectory of source tree. according to this rule, I retry this scenario with old version of lcov(1.10). tar -zxf source_dir.tar.gz cd source_dir mkdir build_dir && cd build_dir ../configure --enable-coverage make make check make coverage-html And "make coverage-html" works fine, no any error, or warning, output is like this: /bin/lcov --gcov-tool /bin/gcov -q --no-external -c -i -d . -d source_dir/build_dir/../ -o lcov_base.info /bin/lcov --gcov-tool /bin/gcov -q --no-external -c -d . -d source_dir/build_dir/../ -o lcov_test.info rm -rf coverage /bin/genhtml -q --legend -o coverage --title='PostgreSQL 13.2' --num-spaces=4 lcov_base.info lcov_test.info touch coverage-html-stamp thanks walker -- Original -- From: "Tom Lane"
unrecognized configuration parameter "plpgsql.check_asserts"
Hi, hackers Due to configure with parameter --enable-cassert, the debug_assertions is on by default, as follows: postgres=# show debug_assertions; debug_assertions --- on Because of pgbench performance testing, I need to disable the assert function. Following the doc below, I tried to set plpgsql.check_asserts to off to disable assert function. https://www.postgresql.org/docs/13/plpgsql-errors-and-messages.html However, it prompts the following error, not sure if I missed something, any thoughts about it? postgres=# alter system set plpgsql.check_asserts = off; EORROR: unrecognized configuration parameter "plpgsql.check_asserts" env: PG: 13.2 OS: redhat 7.4 3.10.0-693.17.1.e17.x86_64 configure parameter: --enable-coverage --enable-tap-tests --enable-cassert --enable-debug --enable-nls --with-perl --with-python --with-tcl --with-openssl --with-ldap --with-libxml --with-libxslt --with-uuid=e2fs --with-segsize=10 --with-wal-blocksize=16 --with-llvm LLVM_CONFIG=xxx CLANG=xxx thanks walker
?????? unrecognized configuration parameter "plpgsql.check_asserts"
Hi, Pavel Thanks for your comments. To get rid of --enable-cassert while configuring, debug_assertions is shown as off. In this case, ASSERT statement also can't be used, right? when enable --enable-cassert, can we use plpgsql.check_asserts to control ASSERT statement, and how? thanks walker -- -- ??: "Pavel Stehule" https://www.postgresql.org/docs/13/plpgsql-errors-and-messages.html However, it prompts the following error, not sure if I missed something, any thoughts about it? postgres=# alter system set plpgsql.check_asserts = off; EORROR: unrecognized configuration parameter "plpgsql.check_asserts" you cannot disable debug_assertions. It is possible just by configure, and make plpgsql.check_asserts controls evaluation of plpgsql statement ASSERT Pavel env: PG: 13.2 OS: redhat 7.4 3.10.0-693.17.1.e17.x86_64 configure parameter: --enable-coverage --enable-tap-tests --enable-cassert --enable-debug --enable-nls --with-perl --with-python --with-tcl --with-openssl --with-ldap --with-libxml --with-libxslt --with-uuid=e2fs --with-segsize=10 --with-wal-blocksize=16 --with-llvm LLVM_CONFIG=xxx CLANG=xxx thanks walker
Re: ?????? unrecognized configuration parameter "plpgsql.check_asserts"
thanks Julien & Pavel it's crystal clear now. thanks again for your kindly help thanks walker -- Original -- From: "Julien Rouhaud"
pg_toast.pg_toast_relfilenode not exist due to vacuum full tablename
hi,
this morning i met an issue, that after vacuum full tablename, the associated
toast table shows not exist.
here is the operation steps:
drop table if exists reymont;
create table reymont ( id bigint primary key, data bytea not null);
alter table reymont alter column data set compression pglz;
insert into reymont values(1, pg_read_binary_file('filename'));
vacuum full reymont;
select relname, relfilenode, reltoastrelid from pg_class where
relname='reymont';
\d+ pg_toast.pg_toast_relfilenode
Did not find any relation named "pg_toast.pg_toast_relfilenode".
however, if display toast table before vacuum full operation, no problem.
drop table if exists reymont;
create table reymont ( id bigint primary key, data bytea not null);
alter table reymont alter column data set compression pglz;
insert into reymont values(1, pg_read_binary_file('filename'));
\d+ pg_toast.pg_toast_relfilenode --- it's ok, the toast table exists
vacuum full reymont;
\d+ pg_toast.pg_toast_relfilenode --- it's ok, the toast table exists
it looks a little strange, any ideas? appreciate your help.
env:
pg14.4
linux 3.10.0-693.17.1.e17
thanks
walker
