Doc: Improve the description of confirmed_flush_lsn in pg_replication_slots.
Make it clear that the data corresponding to the transactions committed
before confirmed_flush_lsn is not available anymore.
Author: Ashutosh Sharma
Reviewd by: Ashutosh Bapat
Discussion:
Remove outdated include
In the wake of bfb9dfd93, there are no longer any stat() calls in
guc-file.l, but the work leading to dac048f71 did not get the memo.
Noted by Michael Paquier
Discussion: https://www.postgresql.org/message-id/Y2OosGi1Xh9x/lEn%40paquier.xyz
Branch
--
master
Details
docs: Improve pg_settings_get_flags docs.
In the docs, the GUC flags that pg_settings_get_flags() reported were
listed using . But the list was treated as separate lines
in the existing function table and didn't look good. For better view,
this commit separates the list from the table entry for
Create FKs properly when attaching table as partition
Commit f56f8f8da6af added some code in CloneFkReferencing that's way too
lax about a Constraint node it manufactures, not initializing enough
struct members -- initially_valid in particular was forgotten. This
causes some FKs in partitions
Create FKs properly when attaching table as partition
Commit f56f8f8da6af added some code in CloneFkReferencing that's way too
lax about a Constraint node it manufactures, not initializing enough
struct members -- initially_valid in particular was forgotten. This
causes some FKs in partitions
Create FKs properly when attaching table as partition
Commit f56f8f8da6af added some code in CloneFkReferencing that's way too
lax about a Constraint node it manufactures, not initializing enough
struct members -- initially_valid in particular was forgotten. This
causes some FKs in partitions
Create FKs properly when attaching table as partition
Commit f56f8f8da6af added some code in CloneFkReferencing that's way too
lax about a Constraint node it manufactures, not initializing enough
struct members -- initially_valid in particular was forgotten. This
causes some FKs in partitions
Create FKs properly when attaching table as partition
Commit f56f8f8da6af added some code in CloneFkReferencing that's way too
lax about a Constraint node it manufactures, not initializing enough
struct members -- initially_valid in particular was forgotten. This
causes some FKs in partitions
Make AssertPointerAlignment available to frontend code
We don't need separate definitions for frontend and backend, since the
contained Assert() will take care of the difference. So this also
makes it simpler overall.
Reviewed-by: Tom Lane
Reviewed-by: Michael Paquier
Discussion:
Avoid crash after function syntax error in a replication worker.
If a syntax error occurred in a SQL-language or PL/pgSQL-language
CREATE FUNCTION or DO command executed in a logical replication worker,
we'd suffer a null pointer dereference or assertion failure. That
seems like a rather
Avoid crash after function syntax error in a replication worker.
If a syntax error occurred in a SQL-language or PL/pgSQL-language
CREATE FUNCTION or DO command executed in a logical replication worker,
we'd suffer a null pointer dereference or assertion failure. That
seems like a rather
Avoid crash after function syntax error in a replication worker.
If a syntax error occurred in a SQL-language or PL/pgSQL-language
CREATE FUNCTION or DO command executed in a logical replication worker,
we'd suffer a null pointer dereference or assertion failure. That
seems like a rather
Avoid crash after function syntax error in a replication worker.
If a syntax error occurred in a SQL-language or PL/pgSQL-language
CREATE FUNCTION or DO command executed in a logical replication worker,
we'd suffer a null pointer dereference or assertion failure. That
seems like a rather
Avoid crash after function syntax error in a replication worker.
If a syntax error occurred in a SQL-language or PL/pgSQL-language
CREATE FUNCTION or DO command executed in a logical replication worker,
we'd suffer a null pointer dereference or assertion failure. That
seems like a rather
Avoid crash after function syntax error in a replication worker.
If a syntax error occurred in a SQL-language or PL/pgSQL-language
CREATE FUNCTION or DO command executed in a logical replication worker,
we'd suffer a null pointer dereference or assertion failure. That
seems like a rather
Avoid crash after function syntax error in a replication worker.
If a syntax error occurred in a SQL-language or PL/pgSQL-language
CREATE FUNCTION or DO command executed in a logical replication worker,
we'd suffer a null pointer dereference or assertion failure. That
seems like a rather
Resolve partition strategy during early parsing
This has little practical value, but there's no reason to let the
partition strategy names travel through DDL as strings.
Reviewed-by: Japin Li
Discussion: https://postgr.es/m/20221021093216.ffupd7epy2mytkux@alvherre.pgsql
Branch
--
master
Add casts to simplehash.h to silence C++ warnings.
Casting the result of palloc etc. to the intended type is more per
project style anyway.
(The fact that cpluspluscheck doesn't notice these problems is
because it doesn't expand any macros, which seems like a troubling
shortcoming. Don't have a
Add casts to simplehash.h to silence C++ warnings.
Casting the result of palloc etc. to the intended type is more per
project style anyway.
(The fact that cpluspluscheck doesn't notice these problems is
because it doesn't expand any macros, which seems like a troubling
shortcoming. Don't have a
Add casts to simplehash.h to silence C++ warnings.
Casting the result of palloc etc. to the intended type is more per
project style anyway.
(The fact that cpluspluscheck doesn't notice these problems is
because it doesn't expand any macros, which seems like a troubling
shortcoming. Don't have a
Add casts to simplehash.h to silence C++ warnings.
Casting the result of palloc etc. to the intended type is more per
project style anyway.
(The fact that cpluspluscheck doesn't notice these problems is
because it doesn't expand any macros, which seems like a troubling
shortcoming. Don't have a
John Naylor writes:
> flaviventris fails on the pg_resetwal test with "initdb: error: invalid
> locale settings; check LANG and LC_* environment variables", and
> idiacanthus fails to start the server in another tap test. But if this
> commit were at fault, surely they would fail more
On Thu, Nov 3, 2022 at 12:39 PM John Naylor
wrote:
>
https://git.postgresql.org/pg/commitdiff/062eef3a9bbd5da9c26c93127ee6272193cb06e6
flaviventris fails on the pg_resetwal test with "initdb: error: invalid
locale settings; check LANG and LC_* environment variables", and
idiacanthus fails to
23 matches
Mail list logo
