Re: pgsql: Fix row filters with multiple publications
От | Tomas Vondra |
---|---|
Тема | Re: pgsql: Fix row filters with multiple publications |
Дата | |
Msg-id | abd2cfb2-9297-1c6b-002e-329f27efc3b6@enterprisedb.com обсуждение исходный текст |
Ответ на | pgsql: Fix row filters with multiple publications (Tomas Vondra <tomas.vondra@postgresql.org>) |
Ответы |
Re: pgsql: Fix row filters with multiple publications
Re: pgsql: Fix row filters with multiple publications |
Список | pgsql-committers |
Hmm, this seems to have failed on wrasse [1], due to a timeout when waiting for tablesync to complete: 2022-03-17 17:39:28.247 CET [19962:1] LOG: logical replication table synchronization worker for subscription "sub2", table "tab1" has started 2022-03-17 17:39:28.258 CET [19964:1] LOG: logical replication table synchronization worker for subscription "sub2", table "tab4" has started In the previous runs this completed pretty much immediately (less than a second), but this time the workers got stuck, so the script keeps looping on the $synced_query. There's nothing in the log, so either it's some sort of lock wait or infinite loop. However, this fails in 013_partition.sql, which was not modified in this commit. And there have been multiple successful runs since it was modified (in c91f71b9dc). So it's not clear if this is a pre-existing issue and we just happened to hit it now, or maybe it's introduced by either c91f71b9dc or 5a07966225. But neither of these commits touched tablesync at all, so I'm puzzled how could it happen. regards [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wrasse&dt=2022-03-17%2016%3A08%3A19 -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-committers по дате отправления: