pgsql: Fix rare deadlock failure in create_am regression test.
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacuum might chance to be processing that table when the DROP runs, resulting in a deadlock failure. This is pretty rare but we see it in the buildfarm from time to time. To fix, acquire a lock on fast_emp4000 before issuing the DROP. Since the point of the exercise is mostly to prevent buildfarm failures, back-patch to 9.6 where this test was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b2fcaed66a4aa88331b375409ef208b12f97c144 Modified Files -- src/test/regress/expected/create_am.out | 5 + src/test/regress/sql/create_am.sql | 5 + 2 files changed, 10 insertions(+)
pgsql: Fix rare deadlock failure in create_am regression test.
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacuum might chance to be processing that table when the DROP runs, resulting in a deadlock failure. This is pretty rare but we see it in the buildfarm from time to time. To fix, acquire a lock on fast_emp4000 before issuing the DROP. Since the point of the exercise is mostly to prevent buildfarm failures, back-patch to 9.6 where this test was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/44f4986dd96bca9d847ccde9ee9428bd9901810b Modified Files -- src/test/regress/expected/create_am.out | 5 + src/test/regress/sql/create_am.sql | 5 + 2 files changed, 10 insertions(+)
pgsql: Fix rare deadlock failure in create_am regression test.
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacuum might chance to be processing that table when the DROP runs, resulting in a deadlock failure. This is pretty rare but we see it in the buildfarm from time to time. To fix, acquire a lock on fast_emp4000 before issuing the DROP. Since the point of the exercise is mostly to prevent buildfarm failures, back-patch to 9.6 where this test was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/afec6ba0bae0258835b81fcc0eeed3ff9c455427 Modified Files -- src/test/regress/expected/create_am.out | 5 + src/test/regress/sql/create_am.sql | 5 + 2 files changed, 10 insertions(+)
pgsql: Fix rare deadlock failure in create_am regression test.
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacuum might chance to be processing that table when the DROP runs, resulting in a deadlock failure. This is pretty rare but we see it in the buildfarm from time to time. To fix, acquire a lock on fast_emp4000 before issuing the DROP. Since the point of the exercise is mostly to prevent buildfarm failures, back-patch to 9.6 where this test was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/43b6f3ed8b135d8452e820e6489d90bd86c4ef4e Modified Files -- src/test/regress/expected/create_am.out | 5 + src/test/regress/sql/create_am.sql | 5 + 2 files changed, 10 insertions(+)
pgsql: Fix rare deadlock failure in create_am regression test.
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacuum might chance to be processing that table when the DROP runs, resulting in a deadlock failure. This is pretty rare but we see it in the buildfarm from time to time. To fix, acquire a lock on fast_emp4000 before issuing the DROP. Since the point of the exercise is mostly to prevent buildfarm failures, back-patch to 9.6 where this test was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d54f99e41541de848a6ca53b3ec060f461e9ab71 Modified Files -- src/test/regress/expected/create_am.out | 5 + src/test/regress/sql/create_am.sql | 5 + 2 files changed, 10 insertions(+)
pgsql: Fix rare deadlock failure in create_am regression test.
Fix rare deadlock failure in create_am regression test. The "DROP ACCESS METHOD gist2" test will require locking the index to be dropped and then its table; while most ordinary operations lock a table first then its index. While no concurrent test scripts should be touching fast_emp4000, autovacuum might chance to be processing that table when the DROP runs, resulting in a deadlock failure. This is pretty rare but we see it in the buildfarm from time to time. To fix, acquire a lock on fast_emp4000 before issuing the DROP. Since the point of the exercise is mostly to prevent buildfarm failures, back-patch to 9.6 where this test was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/aa4eeb38f3aa3e4ebde4abb6edc79dd530ecda79 Modified Files -- src/test/regress/expected/create_am.out | 5 + src/test/regress/sql/create_am.sql | 5 + 2 files changed, 10 insertions(+)
pgsql: C comment: correct use of 64-"byte" cache line size
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cb9d1faa4a7dca9b28f4a21cc9b2c25287eb74d5 Modified Files -- src/include/storage/buf_internals.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: C comment: correct use of 64-"byte" cache line size
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3b5af0e95ad5a3d9b478826336a11ad1d201c378 Modified Files -- src/include/storage/buf_internals.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: C comment: correct use of 64-"byte" cache line size
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/226fd0c518bb17e0433422a161b948feef5601d1 Modified Files -- src/include/storage/buf_internals.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: C comment: correct use of 64-"byte" cache line size
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7f79f9582185eb7086ac3c59fa79b47a37cd7d7a Modified Files -- src/include/storage/buf_internals.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: C comment: correct use of 64-"byte" cache line size
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/56f42cf9063d3ddf89962857d30a15d7ac49ce97 Modified Files -- src/include/storage/buf_internals.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: C comment: correct use of 64-"byte" cache line size
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/63abf9ad9b41f91a96d6eb9bc1c0c49877f1d854 Modified Files -- src/include/storage/buf_internals.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: C comment: correct use of 64-"byte" cache line size
C comment: correct use of 64-"byte" cache line size Reported-by: Kelly Min Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=dqf...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7574af1e1b94a4de7a6f63f3a7854a508ab7b0e0 Modified Files -- src/include/storage/buf_internals.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Collect attribute data on extension owned tables being dumped
Collect attribute data on extension owned tables being dumped If this data is not collected, pg_dump segfaults if asked for column inserts. Fix by Fabrízio de Royes Mello Backpatch to release 12 where the bug was introduced. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/72857482c135677703111855f33550c442108eaa Modified Files -- src/bin/pg_dump/pg_dump.c | 4 src/test/modules/test_pg_dump/t/001_base.pl| 24 -- .../modules/test_pg_dump/test_pg_dump--1.0.sql | 5 + 3 files changed, 31 insertions(+), 2 deletions(-)
pgsql: Collect attribute data on extension owned tables being dumped
Collect attribute data on extension owned tables being dumped If this data is not collected, pg_dump segfaults if asked for column inserts. Fix by Fabrízio de Royes Mello Backpatch to release 12 where the bug was introduced. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3eb3d3e7822d5eecfcaba871a90263c6025c5216 Modified Files -- src/bin/pg_dump/pg_dump.c | 4 src/test/modules/test_pg_dump/t/001_base.pl| 24 -- .../modules/test_pg_dump/test_pg_dump--1.0.sql | 5 + 3 files changed, 31 insertions(+), 2 deletions(-)
pgsql: Collect attribute data on extension owned tables being dumped
Collect attribute data on extension owned tables being dumped If this data is not collected, pg_dump segfaults if asked for column inserts. Fix by Fabrízio de Royes Mello Backpatch to release 12 where the bug was introduced. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/616110eac3b5d939954391c5e9330ce9432502e4 Modified Files -- src/bin/pg_dump/pg_dump.c | 4 src/test/modules/test_pg_dump/t/001_base.pl| 24 -- .../modules/test_pg_dump/test_pg_dump--1.0.sql | 5 + 3 files changed, 31 insertions(+), 2 deletions(-)
pgsql: Remove some more useless assignments.
Remove some more useless assignments. Found with clang's scan-build tool. It also whines about a lot of other dead stores that we should *not* change IMO, either as a matter of style or future-proofing. But these places seem like clear oversights. Discussion: https://postgr.es/m/CAEudQAo1+AcGppxDSg8k+zF4+Kv+eJyqzEDdbpDg58-=mqc...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/38a2d703298c9a891dc9c24c0c087f417f555c70 Modified Files -- src/backend/access/brin/brin_tuple.c| 1 - src/backend/access/gin/ginbtree.c | 1 - src/backend/catalog/pg_depend.c | 6 +++--- src/backend/optimizer/plan/planner.c| 2 +- src/backend/parser/parse_utilcmd.c | 1 - src/backend/partitioning/partbounds.c | 4 src/backend/statistics/extended_stats.c | 2 +- src/backend/tsearch/spell.c | 4 ++-- 8 files changed, 7 insertions(+), 14 deletions(-)
pgsql: Report expected contrecord length on mismatch
Report expected contrecord length on mismatch When reading a WAL record fails to find continuation record(s) of the proper length, report what it expects, for clarity. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f43e295f68c3e04ef891627f62016a5b3d8ed4a8 Modified Files -- src/backend/access/transam/xlogreader.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix bogus MaxAllocSize check in logtape.c.
Fix bogus MaxAllocSize check in logtape.c. Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=NZPZc3-fkdmvu=w2itx0pib-g6qpxhxzojuvfazp...@mail.gmail.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0852006a946aa9795b4913bccebb88d623942ca6 Modified Files -- src/backend/utils/sort/logtape.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix bogus MaxAllocSize check in logtape.c.
Fix bogus MaxAllocSize check in logtape.c. Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=NZPZc3-fkdmvu=w2itx0pib-g6qpxhxzojuvfazp...@mail.gmail.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4a4f3bf983b4abd908585a8d752eee0e47627034 Modified Files -- src/backend/utils/sort/logtape.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix over-eager ping'ing in logical replication receiver.
Fix over-eager ping'ing in logical replication receiver. Commit 3f60f690f only partially fixed the broken-status-tracking issue in LogicalRepApplyLoop: we need ping_sent to have the same lifetime as last_recv_timestamp. The effects are much less serious than what that commit fixed, though. AFAICS this would just lead to extra ping requests being sent, once per second until the sender responds. Still, it's a bug, so backpatch to v10 as before. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7156a0eac3aff743cf0e0972db58c8fffe55cbfc Modified Files -- src/backend/replication/logical/worker.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)
pgsql: Fix over-eager ping'ing in logical replication receiver.
Fix over-eager ping'ing in logical replication receiver. Commit 3f60f690f only partially fixed the broken-status-tracking issue in LogicalRepApplyLoop: we need ping_sent to have the same lifetime as last_recv_timestamp. The effects are much less serious than what that commit fixed, though. AFAICS this would just lead to extra ping requests being sent, once per second until the sender responds. Still, it's a bug, so backpatch to v10 as before. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9b8a8516ed2e4268026a826c5e9b768f88aa67aa Modified Files -- src/backend/replication/logical/worker.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)
pgsql: Fix over-eager ping'ing in logical replication receiver.
Fix over-eager ping'ing in logical replication receiver. Commit 3f60f690f only partially fixed the broken-status-tracking issue in LogicalRepApplyLoop: we need ping_sent to have the same lifetime as last_recv_timestamp. The effects are much less serious than what that commit fixed, though. AFAICS this would just lead to extra ping requests being sent, once per second until the sender responds. Still, it's a bug, so backpatch to v10 as before. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9b81a30f924cf30e6bf3abb3366706440351e163 Modified Files -- src/backend/replication/logical/worker.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)
pgsql: Fix over-eager ping'ing in logical replication receiver.
Fix over-eager ping'ing in logical replication receiver. Commit 3f60f690f only partially fixed the broken-status-tracking issue in LogicalRepApplyLoop: we need ping_sent to have the same lifetime as last_recv_timestamp. The effects are much less serious than what that commit fixed, though. AFAICS this would just lead to extra ping requests being sent, once per second until the sender responds. Still, it's a bug, so backpatch to v10 as before. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9b47ee6e7cba30701b4e11b872455461460650c4 Modified Files -- src/backend/replication/logical/worker.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)
pgsql: Fix over-eager ping'ing in logical replication receiver.
Fix over-eager ping'ing in logical replication receiver. Commit 3f60f690f only partially fixed the broken-status-tracking issue in LogicalRepApplyLoop: we need ping_sent to have the same lifetime as last_recv_timestamp. The effects are much less serious than what that commit fixed, though. AFAICS this would just lead to extra ping requests being sent, once per second until the sender responds. Still, it's a bug, so backpatch to v10 as before. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c8746f999ea2feba22832b485fba37b5301b54a3 Modified Files -- src/backend/replication/logical/worker.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)
pgsql: Remove still more useless assignments.
Remove still more useless assignments. Fix some more things scan-build pointed to as dead stores. In some of these cases, rearranging the code a little leads to more readable code IMO. It's all cosmetic, though. Discussion: https://postgr.es/m/CAEudQAo1+AcGppxDSg8k+zF4+Kv+eJyqzEDdbpDg58-=mqc...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9a851039aac6fc7b78a80e60699e7bd8924b6f12 Modified Files -- src/backend/replication/slotfuncs.c | 3 --- src/backend/utils/adt/formatting.c | 27 --- src/backend/utils/adt/jsonfuncs.c | 14 ++ src/bin/scripts/vacuumdb.c | 19 ++- 4 files changed, 24 insertions(+), 39 deletions(-)
pgsql: Make new authentication test case more robust.
Make new authentication test case more robust. I happened to notice that the new test case I added in b55b4dad9 falls over if one runs "make check" repeatedly; though not in branches after v10. That's because it was assuming that tmp_check/pgpass wouldn't exist already. However, it's only been since v11 that the Makefiles forcibly remove all of tmp_check/ before starting a TAP run. This fix to unlink the file is therefore strictly necessary only in v10 ... but it seems wisest to do it across the board, rather than let the test rely on external logic to get the conditions right. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d7ae549e31ccf19a28375b1f72ec898eeace3c58 Modified Files -- src/test/authentication/t/001_password.pl | 1 + 1 file changed, 1 insertion(+)
pgsql: Make new authentication test case more robust.
Make new authentication test case more robust. I happened to notice that the new test case I added in b55b4dad9 falls over if one runs "make check" repeatedly; though not in branches after v10. That's because it was assuming that tmp_check/pgpass wouldn't exist already. However, it's only been since v11 that the Makefiles forcibly remove all of tmp_check/ before starting a TAP run. This fix to unlink the file is therefore strictly necessary only in v10 ... but it seems wisest to do it across the board, rather than let the test rely on external logic to get the conditions right. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4d41823c5267184fb021ac456caf95ef734cc8b0 Modified Files -- src/test/authentication/t/001_password.pl | 1 + 1 file changed, 1 insertion(+)
pgsql: Make new authentication test case more robust.
Make new authentication test case more robust. I happened to notice that the new test case I added in b55b4dad9 falls over if one runs "make check" repeatedly; though not in branches after v10. That's because it was assuming that tmp_check/pgpass wouldn't exist already. However, it's only been since v11 that the Makefiles forcibly remove all of tmp_check/ before starting a TAP run. This fix to unlink the file is therefore strictly necessary only in v10 ... but it seems wisest to do it across the board, rather than let the test rely on external logic to get the conditions right. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8df601bd4067ecdf373ebe43bdf03159a12e2e9d Modified Files -- src/test/authentication/t/001_password.pl | 1 + 1 file changed, 1 insertion(+)
pgsql: Make new authentication test case more robust.
Make new authentication test case more robust. I happened to notice that the new test case I added in b55b4dad9 falls over if one runs "make check" repeatedly; though not in branches after v10. That's because it was assuming that tmp_check/pgpass wouldn't exist already. However, it's only been since v11 that the Makefiles forcibly remove all of tmp_check/ before starting a TAP run. This fix to unlink the file is therefore strictly necessary only in v10 ... but it seems wisest to do it across the board, rather than let the test rely on external logic to get the conditions right. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fc37c6f6105a594467eb8922eb6d47e0d156ab21 Modified Files -- src/test/authentication/t/001_password.pl | 1 + 1 file changed, 1 insertion(+)
pgsql: Make new authentication test case more robust.
Make new authentication test case more robust. I happened to notice that the new test case I added in b55b4dad9 falls over if one runs "make check" repeatedly; though not in branches after v10. That's because it was assuming that tmp_check/pgpass wouldn't exist already. However, it's only been since v11 that the Makefiles forcibly remove all of tmp_check/ before starting a TAP run. This fix to unlink the file is therefore strictly necessary only in v10 ... but it seems wisest to do it across the board, rather than let the test rely on external logic to get the conditions right. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/546479f34f5c960494687f5808eb7b3d054478a1 Modified Files -- src/test/authentication/t/001_password.pl | 1 + 1 file changed, 1 insertion(+)
pgsql: Use multi-inserts for pg_depend
Use multi-inserts for pg_depend This is a follow-up of the work done in e3931d01. This case is a bit different than pg_attribute and pg_shdepend: the maximum number of items to insert is known in advance, but there is no need to handle pinned dependencies. Hence, the base allocation for slots is done based on the number of items and the maximum allowed with a cap at 64kB. Slots are initialized once used to minimize the overhead of the operation. The insertions can be done for dependencies of the same type. More could be done by grouping the insertion of multiple dependency types in a single batch. This is left as future work. Some of the multi-insert logic is also simplified for pg_shdepend, as per the feedback discussed for this specific patch. This also moves to indexing.h the variable capping the maximum amount of data that can be used at once for a multi-insert, instead of having separate definitions for pg_attribute, pg_depend and pg_shdepend. Author: Daniel Gustafsson, Michael Paquier Reviewed-by: Andres Freund, Álvaro Herrera Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/63110c6264a5363863209c8fbdd0498c03535507 Modified Files -- src/backend/catalog/heap.c| 8 +--- src/backend/catalog/pg_depend.c | 90 --- src/backend/catalog/pg_shdepend.c | 66 ++-- src/include/catalog/indexing.h| 6 +++ 4 files changed, 105 insertions(+), 65 deletions(-)
