Re: Single transaction in the tablesync worker?

Поиск
Список
Период
Сортировка
От Peter Smith
Тема Re: Single transaction in the tablesync worker?
Дата
Msg-id CAHut+Ptxb2QKQNnQUp6fV-9AQnnxmtz1+_n-jk_vjQKF4x-7Ow@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Single transaction in the tablesync worker?  (Petr Jelinek <petr.jelinek@enterprisedb.com>)
Ответы Re: Single transaction in the tablesync worker?  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Sat, Feb 6, 2021 at 2:10 AM Petr Jelinek
<petr.jelinek@enterprisedb.com> wrote:
>
> > +ReplicationSlotNameForTablesync(Oid suboid, Oid relid, char syncslotname[NAMEDATALEN])
> > +{
> > +     if (syncslotname)
> > +             sprintf(syncslotname, "pg_%u_sync_%u", suboid, relid);
> > +     else
> > +             syncslotname = psprintf("pg_%u_sync_%u", suboid, relid);
> > +
> > +     return syncslotname;
> > +}
>
> Given that we are now explicitly dropping slots, what happens here if we
> have 2 different downstreams that happen to get same suboid and reloid,
> will one of the drop the slot of the other one? Previously with the
> cleanup being left to temp slot we'd at maximum got error when creating
> it but with the new logic in LogicalRepSyncTableStart it feels like we
> could get into situation where 2 downstreams are fighting over slot no?
>

The PG docs [1] says "there is only one copy of pg_subscription per
cluster, not one per database". IIUC that means it is not possible for
2 different subscriptions to have the same suboid. And if the suboid
is globally unique then syncslotname name is also unique. Is that
understanding not correct?

-----
[1] https://www.postgresql.org/docs/devel/catalog-pg-subscription.html

Kind Regards,
Peter Smith.
Fujitsu Australia



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Key management with tests
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Key management with tests