Re: Add into REFRESH PUBLICATION parameter exception_behaviour
| От | Andrei Lepikhov |
|---|---|
| Тема | Re: Add into REFRESH PUBLICATION parameter exception_behaviour |
| Дата | |
| Msg-id | db5cc186-6ffd-40a9-9a6d-61e0ab063c0c@gmail.com обсуждение исходный текст |
| Ответ на | Re: Add into REFRESH PUBLICATION parameter exception_behaviour (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Add into REFRESH PUBLICATION parameter exception_behaviour
|
| Список | pgsql-hackers |
On 17/2/26 05:07, Amit Kapila wrote: > On Mon, Feb 16, 2026 at 6:04 PM Andrei Lepikhov <lepihov@gmail.com> wrote: >> ALTER SUBSCRIPTION mysub >> REFRESH PUBLICATION (WITH exception_behaviour = ‘skip’); >> > > It will lead to skipping all future changes to that table by apply > worker as we skip applying till the table is in READY state. So, all > changes for transactions will get applied but the ones where we > skipped copy which could lead to inconsistency. I think the better way > to allow skip copying of initial data for particular tables is to > someway provision copy_data = off for a set of tables. Hmm, in my mind, there should be a FAIL table state introduced to let users know that a specific table has not been synchronised, and they need to check and repeat a smaller part of the job. Or do you mean that a synchronising table might already contain some data, and that it is impossible to undo the sync and repeat it? -- regards, Andrei Lepikhov, pgEdge
В списке pgsql-hackers по дате отправления: