Re: PostmasterPid not marked with PGDLLIMPORT

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: PostmasterPid not marked with PGDLLIMPORT
Дата
Msg-id CAKFQuwanSKXnPo1OB=dDXu-G7Rd37+w5wGhSZ=Co1LmoBNxV+Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostmasterPid not marked with PGDLLIMPORT  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: PostmasterPid not marked with PGDLLIMPORT  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Jun 1, 2016 at 5:04 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Jun 1, 2016 at 12:24 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> On Wed, Jun 1, 2016 at 12:06 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> > On 1 June 2016 at 11:48, Michael Paquier <michael.paquier@gmail.com> wrote:
>> >> Could it be possible to mark PostmasterPid with PGDLLIMPORT on HEAD
>> >> and back-branches?
>> >
>> > Sounds sensible to me.
>>
>> I don't really want to set a precedent that we'll back-patch
>> PGDLLIMPORT markings every time somebody needs a new symbol for some
>> extension they are writing, but I don't mind changing this in master.
>
> I wonder why is that -- just to reduce the commit load?  I don't think
> this kind of change is likely to break anything, is it?

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.

​Are there two concerns here?  One, that people will think we are back-patching stuff and destabilizing back-branches, and two, that people will see increase back-patching and therefore make unreasonable requests of us to which we dislike saying "no".  The later doesn't seem likely, and I'd say you can't stop people from having badly formed opinions and that our track record on back-patching decisions is excellent.

We want third-party tools​
 
​to support our prior releases and if miss making one of our features available to Windows because of a missing PGDLLIMPORT that's on our heads and should be fixed.  If a user equates that to "please batch-patch jsonb to 9.3 because I don't want to upgrade" I'm not going to feel much guilt saying "that's different, ain't gonna happen".  Informed people will understand the purpose of the back-patch and until I start hearing a vocal uninformed person start griping I'd rather give the community the benefit of the doubt.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Rename max_parallel_degree?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Rename max_parallel_degree?