Re: [PATCH] Logical decoding of TRUNCATE

On Sat, Apr 07, 2018 at 07:40:11PM -0400, Peter Eisentraut wrote:
> Committed with those changes.

Since commit 039eb6e added logical replication support for TRUNCATE, logical
apply of the TRUNCATE fails if it chooses a parallel index build:

cat >/tmp/most_parallel.conf <<EOCONF; make -C src/test/subscription check TEMP_CONFIG=/tmp/most_parallel.conf
# like noah(at)leadboat(dot)com buildfarm members
log_line_prefix = '%m [%p:%l] %q%a '
log_connections = 'true'
log_disconnections = 'true'
log_statement = 'all'
fsync = off
authentication_timeout = '600s'
wal_sender_timeout = '18000s'
# not on v12
backtrace_functions = 'quickdie, GetTransactionSnapshot'
# as much parallelism as we can get
log_statement = all
wal_level = minimal
max_wal_senders = 0
force_parallel_mode = regress
min_parallel_index_scan_size = 0
min_parallel_table_scan_size = 0
parallel_setup_cost = 0
parallel_tuple_cost = 0
EOCONF

Symptom in src/test/subscription/tmp_check/log/010_truncate_subscriber.log:

2020-12-19 17:54:04.669 PST [3629509:1] LOG: logical replication apply worker for subscription "sub1" has started
2020-12-19 17:54:04.682 PST [3629509:2] ERROR: cannot take query snapshot during a parallel operation
2020-12-19 17:54:04.682 PST [3629509:3] BACKTRACE:
postgres: subscriber: logical replication worker for subscription 16411 (GetTransactionSnapshot+0x168) [0x951ce8]
postgres: subscriber: logical replication worker for subscription 16411 (InitializeParallelDSM+0x16) [0x52cf86]
postgres: subscriber: logical replication worker for subscription 16411 (btbuild+0x26a) [0x50905a]
postgres: subscriber: logical replication worker for subscription 16411 (index_build+0x14b) [0x569c1b]
postgres: subscriber: logical replication worker for subscription 16411 (reindex_index+0x19a) [0x56caea]
postgres: subscriber: logical replication worker for subscription 16411 (reindex_relation+0xc0) [0x56d090]
postgres: subscriber: logical replication worker for subscription 16411 (ExecuteTruncateGuts+0x376) [0x62f0d6]
postgres: subscriber: logical replication worker for subscription 16411 () [0x78d592]
postgres: subscriber: logical replication worker for subscription 16411 (ApplyWorkerMain+0x5ab) [0x78e4eb]
postgres: subscriber: logical replication worker for subscription 16411 (StartBackgroundWorker+0x23f) [0x75522f]
postgres: subscriber: logical replication worker for subscription 16411 () [0x762a6d]
postgres: subscriber: logical replication worker for subscription 16411 () [0x7635ee]
/lib64/libpthread.so.0(+0xf630) [0x7fe081e97630]
/lib64/libc.so.6(__select+0x13) [0x7fe0805c0983]
postgres: subscriber: logical replication worker for subscription 16411 () [0x4887ac]
postgres: subscriber: logical replication worker for subscription 16411 (PostmasterMain+0x1118) [0x764c88]
postgres: subscriber: logical replication worker for subscription 16411 (main+0x6f2) [0x48aae2]
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7fe0804ed555]
postgres: subscriber: logical replication worker for subscription 16411 () [0x48ab49]
2020-12-19 17:54:04.683 PST [3629353:5] LOG: background worker "logical replication worker" (PID 3629509) exited with exit code 1

(To see that particular failure at commit 039eb6e, one would need to
cherry-pick f90e80b to avoid an earlier failure. One would also modify
PostgresNode to inject the parallelism settings, because PostgresNode did not
support TEMP_CONFIG in those days.)