Re: Add an option to skip loading missing publication to avoid logical replication failure
От | Tom Lane |
---|---|
Тема | Re: Add an option to skip loading missing publication to avoid logical replication failure |
Дата | |
Msg-id | 1916446.1746204841@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add an option to skip loading missing publication to avoid logical replication failure (vignesh C <vignesh21@gmail.com>) |
Ответы |
Re: Add an option to skip loading missing publication to avoid logical replication failure
|
Список | pgsql-hackers |
vignesh C <vignesh21@gmail.com> writes: > Due to the asynchronous nature of these processes, the ALTER > SUBSCRIPTION command may not be immediately observed by the apply > worker. Meanwhile, the walsender may process and decode an INSERT > statement. > If the insert targets a table (e.g., tab_3) that does not belong to > the current publication (pub1), the walsender silently skips > replicating the record and advances its decoding position. This > position is sent in a keepalive message to the subscriber, and since > there are no pending transactions to flush, the apply worker reports > it as the latest received LSN. So this theory presumes that the apply worker receives and reacts to the keepalive message, yet it has not observed a relevant subscriber-side catalog update that surely committed before the keepalive was generated. It's fairly hard to see how that is okay, because it's at least adjacent to something that must be considered a bug: applying transmitted data without having observed DDL updates to the target table. Why is the processing of keepalives laxer than the processing of data messages? regards, tom lane
В списке pgsql-hackers по дате отправления: