Suppress maybe-uninitialized warning.
Following commit e035863c9a0, building with -O0 began triggering
warnings about potentially uninitialized 'workbuf' usage. While
theoretically the initialization isn't necessary since VARDATA()
doesn't access the contents of the pointed-to object, this commit
Fix incorrect return value in brin_minmax_multi_distance_numeric().
The result of "DirectFunctionCall1(numeric_float8, d)" is already in
Datum form, but the code was incorrectly applying PG_RETURN_FLOAT8()
to it. On machines where float8 is pass-by-reference, this would
result in complete garbage
Fix incorrect return value in brin_minmax_multi_distance_numeric().
The result of "DirectFunctionCall1(numeric_float8, d)" is already in
Datum form, but the code was incorrectly applying PG_RETURN_FLOAT8()
to it. On machines where float8 is pass-by-reference, this would
result in complete garbage
Fix incorrect return value in brin_minmax_multi_distance_numeric().
The result of "DirectFunctionCall1(numeric_float8, d)" is already in
Datum form, but the code was incorrectly applying PG_RETURN_FLOAT8()
to it. On machines where float8 is pass-by-reference, this would
result in complete garbage
Fix incorrect return value in brin_minmax_multi_distance_numeric().
The result of "DirectFunctionCall1(numeric_float8, d)" is already in
Datum form, but the code was incorrectly applying PG_RETURN_FLOAT8()
to it. On machines where float8 is pass-by-reference, this would
result in complete garbage
Fix incorrect return value in brin_minmax_multi_distance_numeric().
The result of "DirectFunctionCall1(numeric_float8, d)" is already in
Datum form, but the code was incorrectly applying PG_RETURN_FLOAT8()
to it. On machines where float8 is pass-by-reference, this would
result in complete garbage
Fix incorrect return value in brin_minmax_multi_distance_numeric().
The result of "DirectFunctionCall1(numeric_float8, d)" is already in
Datum form, but the code was incorrectly applying PG_RETURN_FLOAT8()
to it. On machines where float8 is pass-by-reference, this would
result in complete garbage
Put PG_TEST_EXTRA doc items back in alphabetical order
A few items appears to have added in random order over the years.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/455a040d966897edd3901f044945398450da338a
Modified Files
--
doc/src/sgml/regress.sgml
Put PG_TEST_EXTRA doc items back in alphabetical order
A few items appears to have added in random order over the years.
Branch
--
REL_18_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/f71ad5b082f3c714af6f3c43b0df1fe8e68f91e6
Modified Files
--
doc/src/sgml/regre
Hide expensive pg_upgrade test behind PG_TEST_EXTRA
This new test is very expensive. Make it opt-in.
Discussion: https://postgr.es/m/202508051433.ebznuqrxt4b2@alvherre.pgsql
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/37fc1803cc12120f19184cd952865cc35e0f1755
Hide expensive pg_upgrade test behind PG_TEST_EXTRA
This new test is very expensive. Make it opt-in.
Discussion: https://postgr.es/m/202508051433.ebznuqrxt4b2@alvherre.pgsql
Branch
--
REL_18_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/d185161e4739282de72083374e32451b10c
Add backup_type column to pg_stat_progress_basebackup.
This commit introduces a new column backup_type that indicates the
type of backup being performed: either 'full' or 'incremental'.
Bump catalog version.
Author: Shinya Kato
Reviewed-by: Yugo Nagata
Discussion:
https://postgr.es/m/caozeurq
Don't copy datlocale from template unless provider matches.
During CREATE DATABASE, if changing the locale provider, require that
a new locale is specified rather than trying to reinterpret the
template's locale using the new provider.
This only affects the behavior when the template uses the bui
Don't copy datlocale from template unless provider matches.
During CREATE DATABASE, if changing the locale provider, require that
a new locale is specified rather than trying to reinterpret the
template's locale using the new provider.
This only affects the behavior when the template uses the bui
Mop-up for commit e035863c9.
Neither Peter nor I had tried this with USE_VALGRIND ...
Per buildfarm member skink.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/f291751ef86ec407b3e67a951f55e79fb160ae10
Modified Files
--
src/backend/access/common/print
Convert varatt.h access macros to static inline functions.
We've only bothered converting the external interfaces, not the
endian-dependent internal macros (which should not be used by any
callers other than the interface functions in this header, anyway).
The VARTAG_1B_E() changes are required f
Fix varatt versus Datum type confusions
Macros like VARDATA() and VARSIZE() should be thought of as taking
values of type pointer to struct varlena or some other related struct.
The way they are implemented, you can pass anything to it and it will
cast it right. But this is in principle incorrect
Fix various hash function uses
These instances were using Datum-returning functions where a
lower-level function returning uint32 would be more appropriate.
Reviewed-by: Tom Lane
Discussion:
https://www.postgresql.org/message-id/flat/8246d7ff-f4b7-4363-913e-827dadfeb145%40eisentraut.org
Branch
Throw ERROR when publish_generated_columns is specified without a value.
Previously, specifying the publication option 'publish_generated_columns'
without an explicit value would incorrectly default to 'stored', which is
not the intended behavior.
This patch fixes the issue by raising an ERROR wh
Throw ERROR when publish_generated_columns is specified without a value.
Previously, specifying the publication option 'publish_generated_columns'
without an explicit value would incorrectly default to 'stored', which is
not the intended behavior.
This patch fixes the issue by raising an ERROR wh
Fix mixups of FooGetDatum() vs. DatumGetFoo()
Some of these were accidentally reversed, but there was no ill effect.
Reviewed-by: Tom Lane
Discussion:
https://www.postgresql.org/message-id/flat/8246d7ff-f4b7-4363-913e-827dadfeb145%40eisentraut.org
Branch
--
master
Details
---
https://
21 matches
Mail list logo
