Re: [HACKERS] Deadlock in XLogInsert at AIX

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Bernd Helmle <mailings(at)oopsware(dot)de>
Subject: Re: [HACKERS] Deadlock in XLogInsert at AIX
Date: 2018-01-22 20:50:16
Message-ID: CA+TgmoZnEfpLjX-zrzOmoZ--1G-raBHZVxBv-u=90jOSWme-7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 20, 2018 at 6:16 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
>> The most recent patch version is Returned with Feedback. As a matter of
>> procedure, I discourage creating commitfest entries as a tool to solicit new
>> patch versions. If I were the author of a RwF patch, I would dislike finding
>> a commitfest entry that I did not create with myself listed as author.
>
> Per my understanding, this is a bug, and we don't want to lose track of
> them.

I agree with Noah. It's true that having unfixed bugs isn't
particularly good, but it doesn't justify activating a CommitFest
entry under someone else's name. If they don't decide to work further
on the problem, what are we going to do? Keep the entry open forever,
nagging them continually until the end of time? That won't net us
many new contributors.

If nobody is willing to put in the effort to keep AIX supported under
XLC, then we should just update the documentation to say that it isn't
supported. Our support for that platform is pretty marginal anyway if
we're only supporting it up through 6.1; that was released in 2007 and
went out of support in Q2 of last year.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-01-22 21:03:21 Re: pgsql: Move handling of database properties from pg_dumpall into pg_dum
Previous Message Ildar Musin 2018-01-22 20:26:31 Re: [HACKERS] Custom compression methods