Add meson.build to version_stamp.pl
Author: Dagfinn Ilmari Mannsåker
Reviewed-by: Andres Freund
Discussion:
https://www.postgresql.org/message-id/flat/7567dd2d-5e28-c135-79ff-270d7ed83490%40enterprisedb.com
Branch
--
master
Details
---
Remove Abs()
All callers have been replaced by standard C library functions.
Reviewed-by: Zhang Mingli
Reviewed-by: Tom Lane
Discussion:
https://www.postgresql.org/message-id/flat/4beb42b5-216b-bce8-d452-d924d5794c63%40enterprisedb.com
Branch
--
master
Details
---
Fix shadow variable in postgres.c
-Wshadow=compatible-local is added by default since 0fe954c, and this
warning was detected under -DWRITE_READ_PARSE_PLAN_TREES.
Reviewed-by: David Rowley
Discussion: https://postgr.es/m/y0ya5sh0qiao9...@paquier.xyz
Branch
--
master
Details
---
Simplify some maths in xlogreader.c
An LSN was calculated from a segment number, a segment size and a
position offset, matching exactly the LSN given by the caller of
XLogReaderValidatePageHeader(). This change removes the extra LSN
calculation, relying only on the LSN given by the function
On Tue, Oct 11, 2022 at 03:42:21PM -0700, Andres Freund wrote:
> Looks quite justified. Passing NULL to bool is_program isn't right.
Justified it is. Thanks!
--
Michael
signature.asc
Description: PGP signature
Fix compilation warning in test_copy_callbacks
A passed-in parameter value was incorrect, for a warning coming from
MSVC.
Oversight in 9fcdf2c.
Reported-by: Andres Freund
Discussion:
https://postgr.es/m/20221011224221.dvg5q7e7vhjdt...@awork3.anarazel.de
Branch
--
master
Details
---
Harden pmsignal.c against clobbered shared memory.
The postmaster is not supposed to do anything that depends
fundamentally on shared memory contents, because that creates
the risk that a backend crash that trashes shared memory will
take the postmaster down with it, preventing automatic
Harden pmsignal.c against clobbered shared memory.
The postmaster is not supposed to do anything that depends
fundamentally on shared memory contents, because that creates
the risk that a backend crash that trashes shared memory will
take the postmaster down with it, preventing automatic
Harden pmsignal.c against clobbered shared memory.
The postmaster is not supposed to do anything that depends
fundamentally on shared memory contents, because that creates
the risk that a backend crash that trashes shared memory will
take the postmaster down with it, preventing automatic
Harden pmsignal.c against clobbered shared memory.
The postmaster is not supposed to do anything that depends
fundamentally on shared memory contents, because that creates
the risk that a backend crash that trashes shared memory will
take the postmaster down with it, preventing automatic
Harden pmsignal.c against clobbered shared memory.
The postmaster is not supposed to do anything that depends
fundamentally on shared memory contents, because that creates
the risk that a backend crash that trashes shared memory will
take the postmaster down with it, preventing automatic
Harden pmsignal.c against clobbered shared memory.
The postmaster is not supposed to do anything that depends
fundamentally on shared memory contents, because that creates
the risk that a backend crash that trashes shared memory will
take the postmaster down with it, preventing automatic
Harden pmsignal.c against clobbered shared memory.
The postmaster is not supposed to do anything that depends
fundamentally on shared memory contents, because that creates
the risk that a backend crash that trashes shared memory will
take the postmaster down with it, preventing automatic
Hi,
On 2022-10-11 02:47:56 +, Michael Paquier wrote:
> Add support for COPY TO callback functions
>
> This is useful as a way for extensions to process COPY TO rows in the
> way they see fit (say auditing, analytics, backend, etc.) without the
> need to invoke an external process running as
Yet further fixes for multi-row VALUES lists for updatable views.
DEFAULT markers appearing in an INSERT on an updatable view
could be mis-processed if they were in a multi-row VALUES clause.
This would lead to strange errors such as "cache lookup failed
for type ", or in older branches even
Yet further fixes for multi-row VALUES lists for updatable views.
DEFAULT markers appearing in an INSERT on an updatable view
could be mis-processed if they were in a multi-row VALUES clause.
This would lead to strange errors such as "cache lookup failed
for type ", or in older branches even
Yet further fixes for multi-row VALUES lists for updatable views.
DEFAULT markers appearing in an INSERT on an updatable view
could be mis-processed if they were in a multi-row VALUES clause.
This would lead to strange errors such as "cache lookup failed
for type ", or in older branches even
Yet further fixes for multi-row VALUES lists for updatable views.
DEFAULT markers appearing in an INSERT on an updatable view
could be mis-processed if they were in a multi-row VALUES clause.
This would lead to strange errors such as "cache lookup failed
for type ", or in older branches even
Yet further fixes for multi-row VALUES lists for updatable views.
DEFAULT markers appearing in an INSERT on an updatable view
could be mis-processed if they were in a multi-row VALUES clause.
This would lead to strange errors such as "cache lookup failed
for type ", or in older branches even
Yet further fixes for multi-row VALUES lists for updatable views.
DEFAULT markers appearing in an INSERT on an updatable view
could be mis-processed if they were in a multi-row VALUES clause.
This would lead to strange errors such as "cache lookup failed
for type ", or in older branches even
Yet further fixes for multi-row VALUES lists for updatable views.
DEFAULT markers appearing in an INSERT on an updatable view
could be mis-processed if they were in a multi-row VALUES clause.
This would lead to strange errors such as "cache lookup failed
for type ", or in older branches even
Tag refs/tags/REL_15_0 was created.
Doc: add entry for pg_get_partkeydef().
Other pg_get_XXXdef() functions are documented, so it seems reasonable
to include this as well.
Ian Barwick
Discussion:
https://postgr.es/m/CAB8KJ=hb2QZXdgyrrRjPCw++DsrRcui4fKArWabQ+oij+2x=_...@mail.gmail.com
Branch
--
master
Details
---
C comment: explain procArray->pgprocnos[]
Reported-by: Aleksander Alekseev
Discussion:
https://postgr.es/m/CAJ7c6TOs9Dh3KNR2kiQJ3Ow0=tbucl_57dabm--2p8w5x_8...@mail.gmail.com
Author: Aleksander Alekseev
Backpatch-through: master
Branch
--
master
Details
---
Ensure all perl test modules are installed
PostgreSQL::Test::Cluster and ::Utils were not being installed. This is
very hard to notice, as it only seems to affect external modules that
want to run tests from 15 back in earlier versions. Oversight in
b235d41d9646.
This applies only to branches
Ensure all perl test modules are installed
PostgreSQL::Test::Cluster and ::Utils were not being installed. This is
very hard to notice, as it only seems to affect external modules that
want to run tests from 15 back in earlier versions. Oversight in
b235d41d9646.
This applies only to branches
Ensure all perl test modules are installed
PostgreSQL::Test::Cluster and ::Utils were not being installed. This is
very hard to notice, as it only seems to affect external modules that
want to run tests from 15 back in earlier versions. Oversight in
b235d41d9646.
This applies only to branches
Ensure all perl test modules are installed
PostgreSQL::Test::Cluster and ::Utils were not being installed. This is
very hard to notice, as it only seems to affect external modules that
want to run tests from 15 back in earlier versions. Oversight in
b235d41d9646.
This applies only to branches
Ensure all perl test modules are installed
PostgreSQL::Test::Cluster and ::Utils were not being installed. This is
very hard to notice, as it only seems to affect external modules that
want to run tests from 15 back in earlier versions. Oversight in
b235d41d9646.
This applies only to branches
29 matches
Mail list logo
