| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'ocean_li_996' <ocean_li_996(at)163(dot)com>, 'Alexander Lakhin' <exclusion(at)gmail(dot)com> |
| Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, "feichanghong(at)qq(dot)com" <feichanghong(at)qq(dot)com> |
| Subject: | RE: Re:RE: Re:BUG #18369: logical decoding core on AssertTXNLsnOrder() |
| Date: | 2024-03-07 04:45:15 |
| Message-ID: | TYCPR01MB12077C2C32B36E311480DBA92F5202@TYCPR01MB12077.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Dear Haiyang, Alexander,
>LGFM. For my observation, the most case failed on AsserTXNOrder is checking empty
>decoded transaction. Maybe we should pay more attention to review ReorderBufferTXNIsEmpty.
While checking on my fresh eyes, I thought the code might be wrong. The first_lsn
would be same as previous one, when the *PREVIOUS transaction* (not cur_txn) was
empty. Thought?
Also I found the crash reported on [1] was not resolved by the patch. I'm
still analyzing but I have not found the good reproducer yet which could be done
by spec file. Can someone find the workload?
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
https://www.fujitsu.com/global/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2024-03-07 06:34:39 | Re: BUG #18379: LDAP bind password exposed |
| Previous Message | Tender Wang | 2024-03-07 02:24:00 | Re: "type with xxxx does not exist" when doing ExecMemoize() |