Re: Skipping logical replication transactions on subscriber side
От | Peter Eisentraut |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | 09f9584f-0d5b-9988-5b5b-891554e32ae8@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Skipping logical replication transactions on subscriber side (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On 03.12.21 03:53, Amit Kapila wrote: >> I don't know how difficult it would be, but allowing multiple xids might >> be desirable. > > Are there many cases where there could be multiple xid failures that > the user can skip? Apply worker always keeps looping at the same error > failure so the user wouldn't know of the second xid failure (if any) > till the first failure is resolved. Yeah, nevermind, doesn't make sense. > Yeah, I also think so. BTW, what do you think of providing extra > flexibility of giving other options like 'operation', 'rel' along with > xid? I think such options could be useful for large transactions that > operate on multiple tables as it is quite possible that only a > particular operation from the entire transaction is the cause of > failure. Now, on one side, we can argue that skipping the entire > transaction is better from the consistency point of view but I think > it is already possible that we just skip a particular update/delete > (if the corresponding tuple doesn't exist on the subscriber). For the > sake of simplicity, we can just allow providing xid at this stage and > then extend it later as required but I am not very sure of that point. Skipping transactions partially sounds dangerous, especially when exposed as an option to users. Needs more careful thought.
В списке pgsql-hackers по дате отправления: