| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'Fujii Masao' <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Jan Nidzwetzki <jan(at)planetscale(dot)com>, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, ♂π≌26218 <1991230470(at)qq(dot)com>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: START_REPLICATION silently truncates an overlong LSN component |
| Date: | 2026-10-21 09:57:38 |
| Message-ID: | OS7PR01MB1831746179FE303840ABEDBD4F5662@OS7PR01MB18317.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi Fujii-san,
> + if (fscanf(lfp, "INCREMENTAL FROM LSN: %17s\n", lsn) > 0 ||
> + !pg_parse_lsn(lsn, &istartpoint))
>
> When fscanf() succeeds, pg_parse_lsn() is skipped. If the line is absent,
> it parses the previous CHECKPOINT LOCATION value instead. Isn't this
> problematic?
>
> Since we don't use this LSN, how about removing the pg_parse_lsn() check
> and istartpoint and simply rejecting the backup if fscanf() returns > 0?
Thanks for the feedback. PSA the fixed version. MAXPG_LSNLEN was also
exported in the header.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0001-Use-pg_parse_lsn-for-START_REPLICATION.patch | application/octet-stream | 2.5 KB |
| v4-0002-Use-pg_paser_lsn-in-libpqwalreceiver.patch | application/octet-stream | 1.4 KB |
| v4-0003-Use-pg_parse_lsn-for-timeline-history-switchpoint.patch | application/octet-stream | 3.1 KB |
| v4-0004-Use-pg_parse_lsn-for-reading-backup-label.patch | application/octet-stream | 3.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhijie Hou | 2026-10-21 10:01:28 | Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction |
| Previous Message | Staroverov Ilja | 2026-10-21 09:04:09 | Re: pg_stat_statements replaces SQL/JSON ON EMPTY / ON ERROR keywords with parameters |