| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Change timeline field of IDENTIFY_SYSTEM to int8 |
| Date: | 2022-07-05 00:49:07 |
| Message-ID: | YsOKgyhZRXfjts3A@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Mon, Jul 04, 2022 at 01:55:13AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> > Change timeline field of IDENTIFY_SYSTEM to int8
>
> Surely this patch is far from complete?
Yeah..
> But what about whatever code is reading the output? And what if
> that code isn't v16? I can't believe that we can make a wire
> protocol change as summarily as this.
Assuming that one reaches a timeline of 2 billion, this change would
make the TLI consumption of the client safe to signedness. But why is
it safe to do a protocol change when running IDENTIFY_SYSTEM? We've
been very strict to maintain compatibility for any protocol change,
hence why should the replication protocol be treated differently?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-07-05 01:16:58 | pgsql: Replace durable_rename_excl() by durable_rename(), take two |
| Previous Message | Andres Freund | 2022-07-04 23:25:38 | Re: pgsql: dshash: Add sequential scan support. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-07-05 01:19:49 | Re: avoid multiple hard links to same WAL file after a crash |
| Previous Message | Peter Smith | 2022-07-05 00:44:32 | Re: Handle infinite recursion in logical replication setup |