On Fri, Jun 5, 2015 at 12:00 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-06-05 11:43:45 -0400, Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>> > On Fri, Jun 5, 2015 at 2:20 AM, Noah Misch <noah@leadboat.com> wrote:
>> >> I read through this version and found nothing to change. I encourage other
>> >> hackers to study the patch, though. The surrounding code is challenging.
>>
>> > Andres tested this and discovered that my changes to
>> > find_multixact_start() were far more creative than intended.
>> > Committed and back-patched with a trivial fix for that stupidity and a
>> > novel-length explanation of the changes.
>>
>> So where are we on this? Are we ready to schedule a new set of
>> back-branch releases? If not, what issues remain to be looked at?
>
> We're currently still doing bad things while the database is in an
> inconsistent state (i.e. read from SLRUs and truncate based on the
> results of that). It's quite easy to reproduce base backup startup
> failures.
>
> On the other hand, that's not new. And the fix requires, afaics, a new
> type of WAL record (issued very infrequently). I'll post a first version
> of the patch, rebased ontop of Robert's commit, tonight or tomorrow. I
> guess we can then decide what we'd like to do.
There are at least two other known issues that seem like they should
be fixed before we release:
1. The problem that we might truncate an SLRU members page away when
it's in the buffers, but not drop it from the buffers, leading to a
failure when we try to write it later.
2. Thomas's bug fix for another longstanding but that occurs when you
run his checkpoint-segment-boundary.sh script.
I think we might want to try to fix one or both of those before
cutting a new release. I'm less sold on the idea of installing
WAL-logging in this minor release. That probably needs to be done,
but right now we've got stuff that worked in early 9.3.X release and
is now broken, and I'm in favor of fixing that first.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company