Re: [Patch] add new parameter to pg_replication_origin_session_setup
От | Amit Kapila |
---|---|
Тема | Re: [Patch] add new parameter to pg_replication_origin_session_setup |
Дата | |
Msg-id | CAA4eK1LeyzuiRPZB+o7mO0pB6_=tpkjoum5Hj+t1SYydS4K2kQ@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: [Patch] add new parameter to pg_replication_origin_session_setup ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: [Patch] add new parameter to pg_replication_origin_session_setup
|
Список | pgsql-hackers |
On Thu, Sep 18, 2025 at 1:07 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > Dear hackers, > > > I considered a test, please see attached files. > Few comments: 1. +step "s0_compare" { + SELECT s0.lsn < s1.lsn + FROM local_lsn_store as s0, local_lsn_store as s1 + WHERE s0.session = 0 AND s1.session = 1; +} This appears to be a bit tricky to compare the values. Doing a sequential scan won't guarantee the order of rows' appearance. Can't we somehow get the two rows ordered by session_id and compare their values? 2. + else if (candidate_state->acquired_by != acquired_by) + { + if (initialized) + candidate_state->roident = InvalidRepOriginId; + elog(ERROR, "could not find replication state slot for replication origin with OID %u which was acquired by %d", node, acquired_by); + } This doesn't appear neat. Instead, how about checking this case before setting current_state as shown in attached. If we do that, we shouldn't even need new variables like current_state and initialized. Additionally, as shown in attached, it is better to make this a user-facing error by using ereport. 3. Merge all patches as I don't see the need to do any backpatch here. -- With Regards, Amit Kapila.
Вложения
В списке pgsql-hackers по дате отправления: