Re: what's going on with lapwing?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <adunstan(at)postgresql(dot)org>, pgbuildfarm(at)rjuju(dot)net
Subject: Re: what's going on with lapwing?
Date: 2025-03-06 21:27:45
Message-ID: 900942.1741296465@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Mar 6, 2025 at 2:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It's hard to "mandate" anything in a distributed project like this.
>> I don't really see a need to either, at least for cases where an
>> old animal isn't causing us extra work.

> I don't know, to me it feels like we have the argument about whether
> StegosaurOS is actually dead or whether there might be survivors of
> the Chixulub impact hiding somewhere several times a year.

I think you misunderstood my drift. I'm okay with setting a project
policy that we won't support OSes that are more than N years EOL,
as long as it's phrased to account for older PG branches properly.
My point was that we can implement such a policy in a laissez-faire
way: if an older BF animal isn't causing us trouble then why mess
with it? Once we *do* recognize that it's causing us trouble,
we can apply the still-hypothetical policy and ask the owner to
turn it off for branches where it's out of support.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2025-03-06 21:33:06 Re: log_min_messages per backend type
Previous Message Robert Haas 2025-03-06 21:24:00 Re: making EXPLAIN extensible