pgsql: Add AioUringCompletion in wait_event_names.txt

Add AioUringCompletion in wait_event_names.txt Oversight in c325a7633fcb, where the LWLock tranche AioUringCompletion has been added. Author: Bertrand Drouvot Discussion: https://postgr.es/m/adt5sboxjtdul...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitd

pgsql: doc PG 18 relnotes: split apart log_connections item

doc PG 18 relnotes: split apart log_connections item Also add details to asynchronous I/O item. Reported-by: Melanie Plageman Discussion: https://postgr.es/m/CAAKRu_YsVvyantS0X0Y_-vp_97=ygaoyjmxxycekr7pumah...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/c

pgsql: pg_stat_statements: Fix parameter number gaps in normalized quer

pg_stat_statements: Fix parameter number gaps in normalized queries pg_stat_statements anticipates that certain constant locations may be recorded multiple times and attempts to avoid calculating a length for these locations in fill_in_constant_lengths(). However, during generate_normalized_query

pgsql: pg_stat_statements: Fix parameter number gaps in normalized quer

pg_stat_statements: Fix parameter number gaps in normalized queries pg_stat_statements anticipates that certain constant locations may be recorded multiple times and attempts to avoid calculating a length for these locations in fill_in_constant_lengths(). However, during generate_normalized_query

pgsql: pg_stat_statements: Fix parameter number gaps in normalized quer

pg_stat_statements: Fix parameter number gaps in normalized queries pg_stat_statements anticipates that certain constant locations may be recorded multiple times and attempts to avoid calculating a length for these locations in fill_in_constant_lengths(). However, during generate_normalized_query

pgsql: pg_stat_statements: Fix parameter number gaps in normalized quer

pg_stat_statements: Fix parameter number gaps in normalized queries pg_stat_statements anticipates that certain constant locations may be recorded multiple times and attempts to avoid calculating a length for these locations in fill_in_constant_lengths(). However, during generate_normalized_query

pgsql: pg_stat_statements: Fix parameter number gaps in normalized quer

pg_stat_statements: Fix parameter number gaps in normalized queries pg_stat_statements anticipates that certain constant locations may be recorded multiple times and attempts to avoid calculating a length for these locations in fill_in_constant_lengths(). However, during generate_normalized_query

pgsql: pg_stat_statements: Fix parameter number gaps in normalized quer

pg_stat_statements: Fix parameter number gaps in normalized queries pg_stat_statements anticipates that certain constant locations may be recorded multiple times and attempts to avoid calculating a length for these locations in fill_in_constant_lengths(). However, during generate_normalized_query

pgsql: doc: clarify log_connections new "setup_durations" output

doc: clarify log_connections new "setup_durations" output Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/089f27cf8aa4716acc5601abce4b14a372c8569e Modified Files -- doc/src/sgml/config.sgml | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(

pgsql: doc PG 18 relnotes: move ANALYZE item,split ANALYZE/EXPLAIN item

doc PG 18 relnotes: move ANALYZE item,split ANALYZE/EXPLAIN item Reported-by: Yugo Nagata Author: Yugo Nagata Discussion: https://postgr.es/m/20250528232503.7db770f651c2c821c0e3c...@sraoss.co.jp Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bf6034d00dd4c7e82fe2

pgsql: Tighten parsing of datetime input.

Tighten parsing of datetime input. ParseFraction only expects to deal with fields that contain a decimal point and digit(s). However it's possible in some edge cases for it to be passed input that doesn't look like that. In particular the input could look like a valid floating-point number, such

pgsql: Fix memory leakage when function compilation fails.

Fix memory leakage when function compilation fails. In pl_comp.c, initially create the plpgsql function's cache context under the assumed-short-lived caller's context, and reparent it under CacheMemoryContext only upon success. This avoids a process-lifespan leak of 8kB or more if the function co

pgsql: doc PG 18 relnotes: clarify multiplication item

doc PG 18 relnotes: clarify multiplication item Reported-by: Dean Rasheed Author: Dean Rasheed Discussion: https://postgr.es/m/caezatcxzgu3llmzhobyys1mlpynmaus7+uupweefywsapnc...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c861092b0e0fe2393bc5

pgsql: Fix assertion when decrementing eager scanning success and failu

Fix assertion when decrementing eager scanning success and failure counters. Previously, we asserted that the eager scan's success and failure counters were positive before decrementing them. However, this assumption was incorrect, as it's possible that some blocks have already been eagerly scanne