Re: pgsql: Remove pqsignal() from libpq's official exports list.

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Christoph Berg <myon(at)debian(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Remove pqsignal() from libpq's official exports list.
Date: 2019-10-09 13:37:34
Message-ID: 20191009133734.GW6962@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Greetings,

* Christoph Berg (myon(at)debian(dot)org) wrote:
> Re: Tom Lane 2019-10-08 <9333(dot)1570566305(at)sss(dot)pgh(dot)pa(dot)us>
> > Having said all that, if we conclude we can't break compatibility
> > with this legacy code quite yet, I'd be inclined to put a
> > separate, clearly-marked-as-legacy-code version of pqsignal()
> > back into libpq, using the pre-9.3 SA_RESTART semantics.
>
> That would be nice.
>
> > But I'd like some pretty well-defined sunset time for that,
> > because it'd just be trouble waiting to happen. When are
> > you going to remove 9.2 psql?
>
> Note that this change caused breakage on the wiki.postgresql.org
> infrastructure which still had an old 9.2 psql running. It wasn't
> Debian's fault that it had not been upgraded yet.
>
> But I refuse to buy the argument that I'm doing something wrong here.
> Shared libraries have SONAMEs to prevent *exactly* this kind of
> breakage. If you are removing symbols, bump the SONAME.

Yes, this is absolutely the right answer, we shouldn't be removing
symbols without an SONAME bump. If we don't want to bump the SONAME,
then don't remove the symbol. This is utterly basic proper library
maintenance and it isn't appropriate to argue that it's about "well,
your old apps shouldn't exist" because it's blatently our fault for not
bumping the SONAME, no matter how old the apps are.

Thanks,

Stephen

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2019-10-09 15:47:27 Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros)
Previous Message Christoph Berg 2019-10-09 07:33:54 Re: pgsql: Remove pqsignal() from libpq's official exports list.

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-10-09 13:57:10 Re: Standby accepts recovery_target_timeline setting?
Previous Message Robert Haas 2019-10-09 13:25:47 Re: abort-time portal cleanup