pgsql: Make the order of the header file includes consistent.

Make the order of the header file includes consistent. Similar to commits 14aec03502, 7e735035f2 and dddf4cdc33, this commit makes the order of header file inclusion consistent in more places. Author: Vignesh C Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsx

pgsql: Fix inconsistent variable name in static function of mac8.c

Fix inconsistent variable name in static function of mac8.c Both argument names were reversed in the declaration of the function. Author: Ranier Vilela Discussion: https://postgr.es/m/mn2pr18mb292755aeff9a9144b220abeee3...@mn2pr18mb2927.namprd18.prod.outlook.com Branch -- master Details --

pgsql: Refactor reloption handling for index AMs in-core

Refactor reloption handling for index AMs in-core This reworks the reloption parsing and build of a couple of index AMs by creating new structures for each index AM's options. This split was already done for BRIN, GIN and GiST (which actually has a fillfactor parameter), but not for hash, B-tree

pgsql: Use native methods to open input in TestLib::slurp_file on Windo

Use native methods to open input in TestLib::slurp_file on Windows. It is hoped that this will avoid some errors that we have seen before, but lately with greater frequency, in buildfarm animals. For now apply only to master. If this proves effective it can be backpatched. Discussion: https://po

pgsql: Doc: improve discussion of race conditions involved in LISTEN.

Doc: improve discussion of race conditions involved in LISTEN. The user docs didn't really explain how to use LISTEN safely, so clarify that. Also clean up some fuzzy-headed explanations in comments. No code changes. Discussion: https://postgr.es/m/[email protected]

pgsql: Avoid assertion failure with LISTEN in a serializable transactio

Avoid assertion failure with LISTEN in a serializable transaction. If LISTEN is the only action in a serializable-mode transaction, and the session was not previously listening, and the notify queue is not empty, predicate.c reported an assertion failure. That happened because we'd acquire the tr

pgsql: Avoid assertion failure with LISTEN in a serializable transactio

Avoid assertion failure with LISTEN in a serializable transaction. If LISTEN is the only action in a serializable-mode transaction, and the session was not previously listening, and the notify queue is not empty, predicate.c reported an assertion failure. That happened because we'd acquire the tr

pgsql: Avoid assertion failure with LISTEN in a serializable transactio

Avoid assertion failure with LISTEN in a serializable transaction. If LISTEN is the only action in a serializable-mode transaction, and the session was not previously listening, and the notify queue is not empty, predicate.c reported an assertion failure. That happened because we'd acquire the tr

pgsql: Avoid assertion failure with LISTEN in a serializable transactio

Avoid assertion failure with LISTEN in a serializable transaction. If LISTEN is the only action in a serializable-mode transaction, and the session was not previously listening, and the notify queue is not empty, predicate.c reported an assertion failure. That happened because we'd acquire the tr

pgsql: Avoid assertion failure with LISTEN in a serializable transactio

Avoid assertion failure with LISTEN in a serializable transaction. If LISTEN is the only action in a serializable-mode transaction, and the session was not previously listening, and the notify queue is not empty, predicate.c reported an assertion failure. That happened because we'd acquire the tr

pgsql: Avoid assertion failure with LISTEN in a serializable transactio

Avoid assertion failure with LISTEN in a serializable transaction. If LISTEN is the only action in a serializable-mode transaction, and the session was not previously listening, and the notify queue is not empty, predicate.c reported an assertion failure. That happened because we'd acquire the tr

pgsql: Avoid assertion failure with LISTEN in a serializable transactio

Avoid assertion failure with LISTEN in a serializable transaction. If LISTEN is the only action in a serializable-mode transaction, and the session was not previously listening, and the notify queue is not empty, predicate.c reported an assertion failure. That happened because we'd acquire the tr

pgsql: doc: Fix whitespace in syntax.

doc: Fix whitespace in syntax. Back-patch to 10. Author: Andreas Karlsson Discussion: https://postgr.es/m/043acae2-a369-b7fa-be48-1933aa2e82d1%40proxel.se Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c08ac67f47a3e3e8ca7889178f1f12fe993ca7d2 Modified File

pgsql: doc: Fix whitespace in syntax.

doc: Fix whitespace in syntax. Back-patch to 10. Author: Andreas Karlsson Discussion: https://postgr.es/m/043acae2-a369-b7fa-be48-1933aa2e82d1%40proxel.se Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/14512879364144e6c6b4762902e6a551d709280d Modified File

pgsql: doc: Fix whitespace in syntax.

doc: Fix whitespace in syntax. Back-patch to 10. Author: Andreas Karlsson Discussion: https://postgr.es/m/043acae2-a369-b7fa-be48-1933aa2e82d1%40proxel.se Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ec9f6be3b9a935864f28b9ef183a9a4d08662cc3 Modified File

pgsql: doc: Fix whitespace in syntax.

doc: Fix whitespace in syntax. Back-patch to 10. Author: Andreas Karlsson Discussion: https://postgr.es/m/043acae2-a369-b7fa-be48-1933aa2e82d1%40proxel.se Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1974853d899db69a72361a9052fd699c9dcd028e Modified Files -

pgsql: Stabilize NOTIFY behavior by transmitting notifies before ReadyF

Stabilize NOTIFY behavior by transmitting notifies before ReadyForQuery. This patch ensures that, if any notify messages were received during a just-finished transaction, they get sent to the frontend just before not just after the ReadyForQuery message. With libpq and other client libraries that

pgsql: Stabilize NOTIFY behavior by transmitting notifies before ReadyF

Stabilize NOTIFY behavior by transmitting notifies before ReadyForQuery. This patch ensures that, if any notify messages were received during a just-finished transaction, they get sent to the frontend just before not just after the ReadyForQuery message. With libpq and other client libraries that

pgsql: Stabilize NOTIFY behavior by transmitting notifies before ReadyF

Stabilize NOTIFY behavior by transmitting notifies before ReadyForQuery. This patch ensures that, if any notify messages were received during a just-finished transaction, they get sent to the frontend just before not just after the ReadyForQuery message. With libpq and other client libraries that

pgsql: Stabilize NOTIFY behavior by transmitting notifies before ReadyF

Stabilize NOTIFY behavior by transmitting notifies before ReadyForQuery. This patch ensures that, if any notify messages were received during a just-finished transaction, they get sent to the frontend just before not just after the ReadyForQuery message. With libpq and other client libraries that

pgsql: Stabilize NOTIFY behavior by transmitting notifies before ReadyF

Stabilize NOTIFY behavior by transmitting notifies before ReadyForQuery. This patch ensures that, if any notify messages were received during a just-finished transaction, they get sent to the frontend just before not just after the ReadyForQuery message. With libpq and other client libraries that

pgsql: Stabilize the results of pg_notification_queue_usage().

Stabilize the results of pg_notification_queue_usage(). This function wasn't touched in commit 51004c717, but that turns out to be a bad idea, because its results now include any dead space that exists in the NOTIFY queue on account of our being lazy about advancing the queue tail. Notably, the i

pgsql: Remove a couple of unnecessary if-tests.

Remove a couple of unnecessary if-tests. Commit abd9ca377 replaced a couple of while-loops in fmtfloat() with calls to dopr_outchmulti, but I (tgl) failed to notice that the new if-tests guarding those calls were really unnecessary, because they're inside a larger if-block checking the same thing.