Re: Re:RE: Re:BUG #18369: logical decoding core on AssertTXNLsnOrder()
От | Amit Kapila |
---|---|
Тема | Re: Re:RE: Re:BUG #18369: logical decoding core on AssertTXNLsnOrder() |
Дата | |
Msg-id | CAA4eK1LUp70qKd2k+w_rDM=QO-Y89Jf-A851NWxrvRudXEP-zA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re:RE: Re:BUG #18369: logical decoding core on AssertTXNLsnOrder() (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-bugs |
On Fri, Mar 15, 2024 at 6:16 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Mar 13, 2024 at 3:24 PM Hayato Kuroda (Fujitsu) > <kuroda.hayato@fujitsu.com> wrote: > > > > Regarding the second failure, which was reported the upstream. > > > > While reading some other threads, I found that the similar phenomenon has already > > been reported in [1]. The primal reason was that slots reused the serialized > > snapshot but it was not correct. Therefore, I thought the second failure should > > be discussed on the referred thread and here we should focused on the recently > > proposed fix by me. > > (This meant that my proposed workload may not work well after the fix. Will modify > > the test later if needed.) > > > > I agree with this. Is there a reason you are not using the test for > the issue originally reported in this thread? > To verify my theory, I tried by slight modification in the test proposed by your patch: proposed: "s0_init" "s0_begin" "s0_savepoint" "s0_create_part1" "s0_savepoint_release" "s2_init" "s1_checkpoint" "s1_get_changes" "s0_commit" "s2_get_changes" "s2_stop" changed: "s0_init" "s0_begin" "s0_savepoint" "s0_create_part1" "s0_savepoint_release" "s2_init" "s1_checkpoint" "s1_get_changes" "so_insert_part1" "s0_commit" "s2_get_changes" "s2_stop" Note that so_insert_part1 (define it as: Insert into tbl1_part values(2);) before s0_commit and I get the error: "ERROR: could not map filenode "base/5/16387" to relation OID". So, I feel such a test case needs the fix being discussed in the thread [1]. I don't know whether there will be any relation between the fixes for both the issues but it seems better to evaluate the other one [1] as well before moving forward with the fix in this thread. [1] - https://www.postgresql.org/message-id/29273AF3-9684-4069-9257-D05090B03B99@amazon.com -- With Regards, Amit Kapila.
В списке pgsql-bugs по дате отправления: