On Tue, Mar 22, 2022 at 5:41 PM Petr Jelinek <petr.jeli...@enterprisedb.com> wrote: > > > On 22. 3. 2022, at 13:09, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Mon, Mar 21, 2022 at 4:25 AM Tomas Vondra > > <tomas.von...@enterprisedb.com> wrote: > >> > >> Hi, > >> > >> Attached is a rebased patch, addressing most of the remaining issues. > >> > > > > It appears that on the apply side, the patch always creates a new > > relfilenode irrespective of whether the sequence message is > > transactional or not. Is it required to create a new relfilenode for > > non-transactional messages? If not that could be costly? > > > > > That's a good catch, I think we should just write the page in the > non-transactional case, no need to mess with relnodes. >
What if the current node has also incremented from the existing sequence? Basically, how will we deal with conflicts? It seems we will overwrite the actions done on the existing node which means sequence values can go back. On looking a bit more closely, I think I see some more fundamental problems here: * Don't we need some syncing mechanism between apply worker and sequence sync worker so that apply worker skips the sequence changes till the sync worker is finished, otherwise, there is a risk of one overriding the values of the other? * Currently, the patch uses one sync worker per sequence. It seems to be a waste of resources considering apart from one additional process, we need origin/slot to sync each sequence. * Don't we need explicit privilege checking before applying sequence data as we do in commit a2ab9c06ea15fbcb2bfde570986a06b37f52bcca for tables? -- With Regards, Amit Kapila.
