aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorAmit Kapila <akapila@postgresql.org>2024-02-22 12:06:44 +0530
committerAmit Kapila <akapila@postgresql.org>2024-02-22 12:06:44 +0530
commitb6df0798a5e2480d28cceee7df3f58650cf6fa7a (patch)
treec51f089802c3e5030e11d56c7381caef2ddea660 /doc/src
parentfbc93b8b5f59cfb23c22a26a46ca7bcc826be442 (diff)
downloadpostgresql-b6df0798a5e2480d28cceee7df3f58650cf6fa7a.tar.gz
postgresql-b6df0798a5e2480d28cceee7df3f58650cf6fa7a.zip
Fix the intermittent buildfarm failures in 031_column_list.
The reason was that the ALTER SUBSCRIPTION .. SET PUBLICATION will lead to the restarting of apply worker and after the restart, the apply worker will use the existing slot and replication origin corresponding to the subscription. Now, it is possible that before restart the origin has not been updated and the WAL start location points to a location before where PUBLICATION exists which can lead to the error "publication ... does not exist". Fix it by recreating the subscription as a newly created subscription will start processing WAL from the recent WAL location and will see the required publication. This behavior has existed from the time logical replication was introduced but is exposed by this test and we have started a discussion for a better fix for this problem. As per Buildfarm Diagnosed-by: Amit Kapila Author: Vignesh C Discussion: https://postgr.es/m/3307255.1706911634@sss.pgh.pa.us
Diffstat (limited to 'doc/src')
0 files changed, 0 insertions, 0 deletions