On Tue, Mar 22, 2022 at 5:41 PM Petr Jelinek
<petr.jelinek@enterprisedb.com> wrote:
>
> > On 22. 3. 2022, at 13:09, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Mon, Mar 21, 2022 at 4:25 AM Tomas Vondra
> > <tomas.vondra@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.