Re: PostmasterPid not marked with PGDLLIMPORT

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostmasterPid not marked with PGDLLIMPORT
Date: 2016-06-01 21:59:12
Message-ID: CAKFQuwYopZEhThkBQ38Py8EKks0uORoi05vRoiSsv+WDHqu5Aw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 1, 2016 at 5:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> > On Wed, Jun 1, 2016 at 5:04 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> >> Probably not, but yes, I do want to reduce the commit load. I also
> >> think that we essentially have a contract with our users to limit what
> >> we back-patch to critical bug fixes and security fixes. When we don't
> >> do that, people start asking to have individual fixes cherry-picked
> >> instead of just upgrading, and that's not good. We may know that such
> >> changes are low-risk, but that doesn't mean everyone else does.
>
> I suggest that there's a more principled reason for refusing a back-patch
> here, which is that we don't back-patch new features, only bug fixes.
> This request is certainly not a bug fix. It's in support of a new feature
> --- and one that's not even ours, but a third-party extension.
>

Maybe I don't understand PGDLLEXPORT...

​The PostgreSQL function/feature in question is already in place and can be
accessed by someone using Linux or other unix-like variant. But it cannot
be access by our Window's users because we failed to add a PGDLLEXPORT
somewhere.​ If it is our goal to treat Windows and Linux/Unix equally then
that discrepancy is on its face a bug. The fact we don't catch these until
some third-party points it out doesn't make it any less a bug.

> Considering that said extension isn't finished yet, it's hard to guess
> whether this will be the only blocking factor preventing it from working
> with older versions, but it might well be that there are other problems.
>

​From my prior point the reason someone wants to use the unexposed but
documented public API shouldn't matter.

Also, even if it would work, the author would be reduced to saying things
> like "it will work in 9.4, if it's 9.4.9 or later". Keeping track of that

level of detail is no fun either for the author or for users.

​This seems hollow. "It works on the latest version of all officially
supported PostgreSQL releases" is a reasonable policy for a third-party
application to take.​ That it might work on older releases would be a
bonus for some new users.

It'd be
> a lot simpler all around to just say "my spiffy new extension requires 9.6
> or later".
>

​And it makes the available user base considerably smaller. A small change
to get the other 80% of the users is something to take seriously.

>
> In short, I'd vote for putting this change in HEAD, but I see no need to
> back-patch.
>

​I see a need for back-patching and no technical reason why it cannot be
done - easily.

​David J.​

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-06-01 22:33:18 Re: Perf Benchmarking and regression.
Previous Message Tom Lane 2016-06-01 21:40:26 Re: PostmasterPid not marked with PGDLLIMPORT