pgsql: Compare only major versions in AdjustUpgrade.pm

2023-07-24 Thread Alvaro Herrera
Compare only major versions in AdjustUpgrade.pm Because PostgreSQL::Version is very nuanced about development version numbers, the comparison to 16beta2 makes it think that that release is older than 16, therefore applying a database tweak that doesn't work there (the comparison is only supposed t

pgsql: Compare only major versions in AdjustUpgrade.pm

2023-07-24 Thread Alvaro Herrera
Compare only major versions in AdjustUpgrade.pm Because PostgreSQL::Version is very nuanced about development version numbers, the comparison to 16beta2 makes it think that that release is older than 16, therefore applying a database tweak that doesn't work there (the comparison is only supposed t

pgsql: Make test_decoding ddl.out shorter

2023-07-24 Thread Alvaro Herrera
Make test_decoding ddl.out shorter Some of the test_decoding test output was extremely wide, because it deals with massive toasted values, and the aligned mode causes psql to produce 200kB of whitespace and dashes. Change to unaligned mode temporarily to avoid that behavior. Backpatch to 14, wher

pgsql: Make test_decoding ddl.out shorter

2023-07-24 Thread Alvaro Herrera
Make test_decoding ddl.out shorter Some of the test_decoding test output was extremely wide, because it deals with massive toasted values, and the aligned mode causes psql to produce 200kB of whitespace and dashes. Change to unaligned mode temporarily to avoid that behavior. Backpatch to 14, wher

pgsql: Make test_decoding ddl.out shorter

2023-07-24 Thread Alvaro Herrera
Make test_decoding ddl.out shorter Some of the test_decoding test output was extremely wide, because it deals with massive toasted values, and the aligned mode causes psql to produce 200kB of whitespace and dashes. Change to unaligned mode temporarily to avoid that behavior. Backpatch to 14, wher

pgsql: Make test_decoding ddl.out shorter

2023-07-24 Thread Alvaro Herrera
Make test_decoding ddl.out shorter Some of the test_decoding test output was extremely wide, because it deals with massive toasted values, and the aligned mode causes psql to produce 200kB of whitespace and dashes. Change to unaligned mode temporarily to avoid that behavior. Backpatch to 14, wher

pgsql: Fix off-by-one in LimitAdditionalPins()

2023-07-24 Thread Andres Freund
Fix off-by-one in LimitAdditionalPins() Due to the bug LimitAdditionalPins() could return 0, violating LimitAdditionalPins()'s API ("One additional pin is always allowed"). This could be hit when setting shared_buffers very low and using a fair amount of concurrency. This bug was introduced in 31

pgsql: Fix off-by-one in LimitAdditionalPins()

2023-07-24 Thread Andres Freund
Fix off-by-one in LimitAdditionalPins() Due to the bug LimitAdditionalPins() could return 0, violating LimitAdditionalPins()'s API ("One additional pin is always allowed"). This could be hit when setting shared_buffers very low and using a fair amount of concurrency. This bug was introduced in 31

pgsql: Fix the display of UNKNOWN message type in apply worker.

2023-07-24 Thread Amit Kapila
Fix the display of UNKNOWN message type in apply worker. We include the message type while displaying an error context in the apply worker. Now, while retrieving the message type string if the message type is unknown we throw an error that will hide the original error. So, instead, we need to simp

pgsql: Fix the display of UNKNOWN message type in apply worker.

2023-07-24 Thread Amit Kapila
Fix the display of UNKNOWN message type in apply worker. We include the message type while displaying an error context in the apply worker. Now, while retrieving the message type string if the message type is unknown we throw an error that will hide the original error. So, instead, we need to simp

pgsql: Fix the display of UNKNOWN message type in apply worker.

2023-07-24 Thread Amit Kapila
Fix the display of UNKNOWN message type in apply worker. We include the message type while displaying an error context in the apply worker. Now, while retrieving the message type string if the message type is unknown we throw an error that will hide the original error. So, instead, we need to simp

pgsql: Optimize WAL insertion lock acquisition and release with some at

2023-07-24 Thread Michael Paquier
Optimize WAL insertion lock acquisition and release with some atomics The WAL insertion lock variable insertingAt is currently being read and written with the help of the LWLock wait list lock to avoid any read of torn values. This wait list lock can become a point of contention on a highly concu

Re: pgsql: Fix the display of UNKNOWN message type in apply worker.

2023-07-24 Thread Michael Paquier
On Tue, Jul 25, 2023 at 03:52:32AM +, Amit Kapila wrote: > Fix the display of UNKNOWN message type in apply worker. > > We include the message type while displaying an error context in the > apply worker. Now, while retrieving the message type string if the > message type is unknown we throw a

pgsql: Remove unnecessary checks for indexes for REPLICA IDENTITY FULL

2023-07-24 Thread Masahiko Sawada
Remove unnecessary checks for indexes for REPLICA IDENTITY FULL tables. Previously, when selecting an usable index for update/delete for the REPLICA IDENTITY FULL table, in IsIndexOnlyExpression(), we used to check if all index fields are not expressions. However, it was not necessary, because it

pgsql: Remove unnecessary checks for indexes for REPLICA IDENTITY FULL

2023-07-24 Thread Masahiko Sawada
Remove unnecessary checks for indexes for REPLICA IDENTITY FULL tables. Previously, when selecting an usable index for update/delete for the REPLICA IDENTITY FULL table, in IsIndexOnlyExpression(), we used to check if all index fields are not expressions. However, it was not necessary, because it