Fix pgbench TAP test.
Bildfarm member prairiedog reported a pgbench TAP test failure after
commit: 4a39f87acd6e681e5ded1239391d8a92645b43d6. This commit attempts
to fix some copy&paste errors introduced in the previous commit.
Author: Yugo Nagata
Reported-by: Tom Lane
Discussion: https://postgr.e
Refactor code related to pg_hba_file_rules() into new file
hba.c is growing big, and more contents are planned for it. In order to
prepare for this future work, this commit moves all the code related to
the system function processing the contents of pg_hba.conf,
pg_hba_file_rules() to a new file
Add some basic regression tests for pg_freespacemap
The number of relation pages is tricky to get right in a portable way,
particularly across 32b and 64b builds, but checking after the existence
of the FSM and if there is any space available space should be stable
enough with a minimal number of
Don't call fwrite() with len == 0 when writing out relcache init file.
Noticed via -fsanitize=undefined.
Backpatch to all branches, for the same reasons as 46ab07ffda9.
Discussion:
https://postgr.es/m/20220323173537.ll7klrglnp4gn...@alap3.anarazel.de
Backpatch: 10-
Branch
--
REL_14_STABLE
Don't try to translate NULL in GetConfigOptionByNum().
Noticed via -fsanitize=undefined. Introduced when a few columns in
GetConfigOptionByNum() / pg_settings started to be translated in 72be8c29a /
PG 12.
Backpatch to all affected branches, for the same reasons as 46ab07ffda9.
Discussion:
http
Don't try to translate NULL in GetConfigOptionByNum().
Noticed via -fsanitize=undefined. Introduced when a few columns in
GetConfigOptionByNum() / pg_settings started to be translated in 72be8c29a /
PG 12.
Backpatch to all affected branches, for the same reasons as 46ab07ffda9.
Discussion:
http
Don't call fwrite() with len == 0 when writing out relcache init file.
Noticed via -fsanitize=undefined.
Backpatch to all branches, for the same reasons as 46ab07ffda9.
Discussion:
https://postgr.es/m/20220323173537.ll7klrglnp4gn...@alap3.anarazel.de
Backpatch: 10-
Branch
--
REL_11_STABLE
Don't call fwrite() with len == 0 when writing out relcache init file.
Noticed via -fsanitize=undefined.
Backpatch to all branches, for the same reasons as 46ab07ffda9.
Discussion:
https://postgr.es/m/20220323173537.ll7klrglnp4gn...@alap3.anarazel.de
Backpatch: 10-
Branch
--
REL_10_STABLE
Don't call fwrite() with len == 0 when writing out relcache init file.
Noticed via -fsanitize=undefined.
Backpatch to all branches, for the same reasons as 46ab07ffda9.
Discussion:
https://postgr.es/m/20220323173537.ll7klrglnp4gn...@alap3.anarazel.de
Backpatch: 10-
Branch
--
REL_12_STABLE
Don't call fwrite() with len == 0 when writing out relcache init file.
Noticed via -fsanitize=undefined.
Backpatch to all branches, for the same reasons as 46ab07ffda9.
Discussion:
https://postgr.es/m/20220323173537.ll7klrglnp4gn...@alap3.anarazel.de
Backpatch: 10-
Branch
--
REL_13_STABLE
Don't try to translate NULL in GetConfigOptionByNum().
Noticed via -fsanitize=undefined. Introduced when a few columns in
GetConfigOptionByNum() / pg_settings started to be translated in 72be8c29a /
PG 12.
Backpatch to all affected branches, for the same reasons as 46ab07ffda9.
Discussion:
http
Don't try to translate NULL in GetConfigOptionByNum().
Noticed via -fsanitize=undefined. Introduced when a few columns in
GetConfigOptionByNum() / pg_settings started to be translated in 72be8c29a /
PG 12.
Backpatch to all affected branches, for the same reasons as 46ab07ffda9.
Discussion:
http
Don't call fwrite() with len == 0 when writing out relcache init file.
Noticed via -fsanitize=undefined.
Backpatch to all branches, for the same reasons as 46ab07ffda9.
Discussion:
https://postgr.es/m/20220323173537.ll7klrglnp4gn...@alap3.anarazel.de
Backpatch: 10-
Branch
--
master
Detail
configure: check for dlsym instead of dlopen.
When building with sanitizers the sanitizer library provides dlopen, but not
dlsym(), making configure think that -ldl isn't needed. Just checking for
dlsym() ought to suffice, hard to see dlsym() being provided without dlopen()
also being provided.
B
configure: check for dlsym instead of dlopen.
When building with sanitizers the sanitizer library provides dlopen, but not
dlsym(), making configure think that -ldl isn't needed. Just checking for
dlsym() ought to suffice, hard to see dlsym() being provided without dlopen()
also being provided.
B
configure: check for dlsym instead of dlopen.
When building with sanitizers the sanitizer library provides dlopen, but not
dlsym(), making configure think that -ldl isn't needed. Just checking for
dlsym() ought to suffice, hard to see dlsym() being provided without dlopen()
also being provided.
B
configure: check for dlsym instead of dlopen.
When building with sanitizers the sanitizer library provides dlopen, but not
dlsym(), making configure think that -ldl isn't needed. Just checking for
dlsym() ought to suffice, hard to see dlsym() being provided without dlopen()
also being provided.
B
configure: check for dlsym instead of dlopen.
When building with sanitizers the sanitizer library provides dlopen, but not
dlsym(), making configure think that -ldl isn't needed. Just checking for
dlsym() ought to suffice, hard to see dlsym() being provided without dlopen()
also being provided.
B
configure: check for dlsym instead of dlopen.
When building with sanitizers the sanitizer library provides dlopen, but not
dlsym(), making configure think that -ldl isn't needed. Just checking for
dlsym() ought to suffice, hard to see dlsym() being provided without dlopen()
also being provided.
B
Clean test_rls_hooks module
This module isn't an extension and doesn't need to be preloaded.
Adjust the Makefile and remove the extraneous .control and .conf
files accordingly.
Discussion:
https://postgr.es/m/43bcaaab-077e-cebe-35be-3cd7f2633...@dunslane.net
Branch
--
master
Details
--
ci: test headerscheck, cpluspluscheck as part of CompilerWarnings task.
Discussion:
https://postgr.es/m/20220323002024.f2g6tivduzrkt...@alap3.anarazel.de
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/81b9f23c9c83813f14d20cf6993d94fdd44c0991
Modified Files
--
On 2022-Mar-23, Alvaro Herrera wrote:
> Discussion: https://postgr.es/m//202109040001.zky3wgv2qeqg@alvherre.pgsql
Hmm, apparently the double slash here makes the link invalid. I had
never realized that that URL-handling thingy was so brittle. Anyway,
the correct URL of course is
https://postgr.
pg_upgrade: Upgrade an Assert to a real 'if' test
It seems possible for the condition being tested to be true in
production, and nobody would never know (except when some data
eventually becomes corrupt?).
Author: Álvaro Herrera
Discussion: https://postgr.es/m//202109040001.zky3wgv2qeqg@alvherre
pg_upgrade: Upgrade an Assert to a real 'if' test
It seems possible for the condition being tested to be true in
production, and nobody would never know (except when some data
eventually becomes corrupt?).
Author: Álvaro Herrera
Discussion: https://postgr.es/m//202109040001.zky3wgv2qeqg@alvherre
pg_upgrade: Upgrade an Assert to a real 'if' test
It seems possible for the condition being tested to be true in
production, and nobody would never know (except when some data
eventually becomes corrupt?).
Author: Álvaro Herrera
Discussion: https://postgr.es/m//202109040001.zky3wgv2qeqg@alvherre
pg_upgrade: Upgrade an Assert to a real 'if' test
It seems possible for the condition being tested to be true in
production, and nobody would never know (except when some data
eventually becomes corrupt?).
Author: Álvaro Herrera
Discussion: https://postgr.es/m//202109040001.zky3wgv2qeqg@alvherre
pg_upgrade: Upgrade an Assert to a real 'if' test
It seems possible for the condition being tested to be true in
production, and nobody would never know (except when some data
eventually becomes corrupt?).
Author: Álvaro Herrera
Discussion: https://postgr.es/m//202109040001.zky3wgv2qeqg@alvherre
pg_upgrade: Upgrade an Assert to a real 'if' test
It seems possible for the condition being tested to be true in
production, and nobody would never know (except when some data
eventually becomes corrupt?).
Author: Álvaro Herrera
Discussion: https://postgr.es/m//202109040001.zky3wgv2qeqg@alvherre
pg_basebackup: Try to fix some failures on Windows.
Commit ffd53659c46a54a6978bcb8c4424c1e157a2c0f1 messed up the
mechanism that was being used to pass parameters to LogStreamerMain()
on Windows. It worked on Linux because only Windows was using threads.
Repair by moving the additional parameters
Fix "missing continuation record" after standby promotion
Invalidate abortedRecPtr and missingContrecPtr after a missing
continuation record is successfully skipped on a standby. This fixes a
PANIC caused when a recently promoted standby attempts to write an
OVERWRITE_RECORD with an LSN of the pre
Fix "missing continuation record" after standby promotion
Invalidate abortedRecPtr and missingContrecPtr after a missing
continuation record is successfully skipped on a standby. This fixes a
PANIC caused when a recently promoted standby attempts to write an
OVERWRITE_RECORD with an LSN of the pre
Fix "missing continuation record" after standby promotion
Invalidate abortedRecPtr and missingContrecPtr after a missing
continuation record is successfully skipped on a standby. This fixes a
PANIC caused when a recently promoted standby attempts to write an
OVERWRITE_RECORD with an LSN of the pre
Fix "missing continuation record" after standby promotion
Invalidate abortedRecPtr and missingContrecPtr after a missing
continuation record is successfully skipped on a standby. This fixes a
PANIC caused when a recently promoted standby attempts to write an
OVERWRITE_RECORD with an LSN of the pre
Fix "missing continuation record" after standby promotion
Invalidate abortedRecPtr and missingContrecPtr after a missing
continuation record is successfully skipped on a standby. This fixes a
PANIC caused when a recently promoted standby attempts to write an
OVERWRITE_RECORD with an LSN of the pre
Fix "missing continuation record" after standby promotion
Invalidate abortedRecPtr and missingContrecPtr after a missing
continuation record is successfully skipped on a standby. This fixes a
PANIC caused when a recently promoted standby attempts to write an
OVERWRITE_RECORD with an LSN of the pre
On Wed, Mar 23, 2022 at 11:55 AM Tom Lane wrote:
> Andres Freund writes:
> > And windows still fails tests after this commit:
> > https://cirrus-ci.com/task/6424123323711488?logs=test_bin#L22
>
> Yeah. drongo is reporting
>
> # Running: pg_basebackup --no-sync -cfast -D
> C:\\prog\\bf\\root\\H
Andres Freund writes:
> And windows still fails tests after this commit:
> https://cirrus-ci.com/task/6424123323711488?logs=test_bin#L22
Yeah. drongo is reporting
# Running: pg_basebackup --no-sync -cfast -D
C:\\prog\\bf\\root\\HEAD\\pgsql.build\\src\\bin\\pg_basebackup\\tmp_check\\tmp_test_v
Hi,
On 2022-03-23 11:38:39 -0400, Robert Haas wrote:
> On Wed, Mar 23, 2022 at 10:46 AM Andres Freund wrote:
> > There's new warnings that sound reasonable introduced in the prior commit
> > that didn't get removed in this one:
> >
> > https://cirrus-ci.com/task/5259487073271808?logs=mingw_cross
On 2022-Feb-14, Tomas Vondra wrote:
> On 2/14/22 14:36, Alvaro Herrera wrote:
> > I propose the attached comment additions instead.
>
> The comments seem fine to me (although not really related to these commits
> about sequence decoding).
Thanks, pushed.
--
Álvaro HerreraBreisgau, Deu
test_decoding: Add comments about delaying BEGIN/PREPARE
It is not immediately obvious why we return early in these functions;
these comments should make it so.
Reviewed-by: Tomas Vondra
Discussion: https://postgr.es/m/202202141336.xv35beswc6ec@alvherre.pgsql
Branch
--
master
Details
-
On Wed, Mar 23, 2022 at 10:46 AM Andres Freund wrote:
> There's new warnings that sound reasonable introduced in the prior commit
> that didn't get removed in this one:
>
> https://cirrus-ci.com/task/5259487073271808?logs=mingw_cross_warning#L392
That link takes me to a screen that shows no warn
In get_bc_algorithm_name, add a dummy return statement.
This code shouldn't be reached, but having it here might avoid a
compiler warning.
Per CI complaint from Andres Freund.
Discussion: http://postgr.es/m/c6a7643a-582b-47f7-a03d-01736bc03...@anarazel.de
Branch
--
master
Details
---
h
Force NO_LOCALE / UTF8 for test_oat_hooks tests
This will fix cases like fairywren that have been having issues.
Discussion: https://postgr.es/m/2630561.1647994...@sss.pgh.pa.us
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/7c51b7f7cc0860ab9a5784fce7a44142e4eb546
Hi,
On March 23, 2022 7:46:10 AM PDT, Andres Freund wrote:
>Hi,
>
>On March 23, 2022 7:24:13 AM PDT, Robert Haas wrote:
>>Unbreak the build.
>>
>>Commit ffd53659c46a54a6978bcb8c4424c1e157a2c0f1 broke the build for
>>anyone not compiling with LZ4 and ZSTD enabled. Woops.
>
>There's new warnings
Hi,
On March 23, 2022 7:24:13 AM PDT, Robert Haas wrote:
>Unbreak the build.
>
>Commit ffd53659c46a54a6978bcb8c4424c1e157a2c0f1 broke the build for
>anyone not compiling with LZ4 and ZSTD enabled. Woops.
There's new warnings that sound reasonable introduced in the prior commit that
didn't get
Use approved style for listing OBJS in test_oat_hooks Makefile
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/fc15396dc6821e15c883b8101be45ee6298a4d77
Modified Files
--
src/test/modules/test_oat_hooks/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1
Unbreak the build.
Commit ffd53659c46a54a6978bcb8c4424c1e157a2c0f1 broke the build for
anyone not compiling with LZ4 and ZSTD enabled. Woops.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/607e75e8f0f84544feb879b747da1d40fed71499
Modified Files
--
src/
Replace BASE_BACKUP COMPRESSION_LEVEL option with COMPRESSION_DETAIL.
There are more compression parameters that can be specified than just
an integer compression level, so rename the new COMPRESSION_LEVEL
option to COMPRESSION_DETAIL before it gets released. Introduce a
flexible syntax for that o
On 3/22/22 20:08, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/22/22 18:33, Andres Freund wrote:
>>> This currently triggers a number of warnings. I assume that's because of the
>>> following patches not being there yet? How far out are those?
>> Tomorrow, with the SQL/JSON constructors patc
Allow pgbench to retry in some cases.
When serialization or deadlock errors are reported by backend, allow
to retry and continue the benchmarking. For this purpose new options
"--max-tries", "--failures-detailed" and "--verbose-errors" are added.
Transactions with serialization errors or deadlock
On 2022-Mar-22, Andrew Dunstan wrote:
> Tomorrow, with the SQL/JSON constructors patch should resolve it. So
> roughly 24 hours. It's not his fault but this happened because Alvaro
> asked me to stagger the commits.
Ouch, yeah. This kind of problem can be observed by using something
like
git re
51 matches
Mail list logo
