pgsql: Block ALTER INDEX/TABLE index_name ALTER COLUMN colname SET (opt

Block ALTER INDEX/TABLE index_name ALTER COLUMN colname SET (options) The grammar of this command run on indexes with column names has always been authorized by the parser, and it has never been documented. Since 911e702, it is possible to define opclass parameters as of CREATE INDEX, which actua

pgsql: Block ALTER INDEX/TABLE index_name ALTER COLUMN colname SET (opt

Block ALTER INDEX/TABLE index_name ALTER COLUMN colname SET (options) The grammar of this command run on indexes with column names has always been authorized by the parser, and it has never been documented. Since 911e702, it is possible to define opclass parameters as of CREATE INDEX, which actua

pgsql: Block ALTER INDEX/TABLE index_name ALTER COLUMN colname SET (opt

Block ALTER INDEX/TABLE index_name ALTER COLUMN colname SET (options) The grammar of this command run on indexes with column names has always been authorized by the parser, and it has never been documented. Since 911e702, it is possible to define opclass parameters as of CREATE INDEX, which actua

pgsql: Invalidate partitions of table being attached/detached

Invalidate partitions of table being attached/detached Failing to do that, any direct inserts/updates of those partitions would fail to enforce the correct constraint, that is, one that considers the new partition constraint of their parent table. Backpatch to 10. Reported by: Hou Zhijie Author

pgsql: Invalidate partitions of table being attached/detached

Invalidate partitions of table being attached/detached Failing to do that, any direct inserts/updates of those partitions would fail to enforce the correct constraint, that is, one that considers the new partition constraint of their parent table. Backpatch to 10. Reported by: Hou Zhijie Author

pgsql: Invalidate partitions of table being attached/detached

Invalidate partitions of table being attached/detached Failing to do that, any direct inserts/updates of those partitions would fail to enforce the correct constraint, that is, one that considers the new partition constraint of their parent table. Backpatch to 10. Reported by: Hou Zhijie Author

pgsql: Invalidate partitions of table being attached/detached

Invalidate partitions of table being attached/detached Failing to do that, any direct inserts/updates of those partitions would fail to enforce the correct constraint, that is, one that considers the new partition constraint of their parent table. Backpatch to 10. Reported by: Hou Zhijie Author

pgsql: Invalidate partitions of table being attached/detached

Invalidate partitions of table being attached/detached Failing to do that, any direct inserts/updates of those partitions would fail to enforce the correct constraint, that is, one that considers the new partition constraint of their parent table. Backpatch to 10. Reported by: Hou Zhijie Author

pgsql: Invalidate partitions of table being attached/detached

Invalidate partitions of table being attached/detached Failing to do that, any direct inserts/updates of those partitions would fail to enforce the correct constraint, that is, one that considers the new partition constraint of their parent table. Backpatch to 10. Reported by: Hou Zhijie Author

pgsql: Fix parallel sort, broken by the balanced merge patch.

Fix parallel sort, broken by the balanced merge patch. The code for initializing the tapes on each merge iteration was skipped in a parallel worker. I put the !WORKER(state) check in wrong place while rebasing the patch. That caused failures in the index build in 'multiple-row-versions' isolation

Re: pgsql: Reference test binary using TESTDIR in 001_libpq_pipeline.pl.

On 10/18/21 10:23 AM, Alvaro Herrera wrote: > On 2021-Oct-17, Andrew Dunstan wrote: > >> +sub find_built_program >> +{ >> +my $program = shift; >> +my $path; >> + >> +if (defined $ENV{MSBUILDDIR}) >> +{ >> +# vcregress.pl sets MSBUILDDIR which is the root of all the >

Re: pgsql: Reference test binary using TESTDIR in 001_libpq_pipeline.pl.

On 2021-Oct-17, Andrew Dunstan wrote: > +sub find_built_program > +{ > + my $program = shift; > + my $path; > + > + if (defined $ENV{MSBUILDDIR}) > + { > + # vcregress.pl sets MSBUILDDIR which is the root of all the > build dirs > + my $wanted = sub { $_ eq

pgsql: Fix duplicate typedef LogicalTape.

Fix duplicate typedef LogicalTape. To make buildfarm member locust happy. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aa3ac6453b28049b3198433b75228271b7612d4a Modified Files -- src/backend/utils/sort/logtape.c | 4 ++-- 1 file changed, 2 insertions(+

Re: pgsql: Replace polyphase merge algorithm with a simple balanced k-way m

On 18/10/2021 15:15, Heikki Linnakangas wrote: Replace polyphase merge algorithm with a simple balanced k-way merge. This patch made some buildfarm animals fail in the isolation tests. 'eelpout' seems to have ran out of disk space: +setup failed: ERROR: could not write to file "base/pgsql_

pgsql: Fix format modifier used in elog.

Fix format modifier used in elog. The previous commit 65014000b3 changed the variable passed to elog from an int64 to a size_t variable, but neglected to change the modifier in the format string accordingly. Per failure on buildfarm member lapwing. Branch -- master Details --- https://g

pgsql: Refactor LogicalTapeSet/LogicalTape interface.

Refactor LogicalTapeSet/LogicalTape interface. All the tape functions, like LogicalTapeRead and LogicalTapeWrite, now take a LogicalTape as argument, instead of LogicalTapeSet+tape number. You can create any number of LogicalTapes in a single LogicalTapeSet, and you don't need to decide the number

pgsql: Replace polyphase merge algorithm with a simple balanced k-way m

Replace polyphase merge algorithm with a simple balanced k-way merge. The advantage of polyphase merge is that it can reuse the input tapes as output tapes efficiently, but that is irrelevant on modern hardware, when we can easily emulate any number of tape drives. The number of input tapes we can