Re: First-draft release notes for next week's releases

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: First-draft release notes for next week's releases
Date: 2014-03-17 17:42:59
Message-ID: 23634.1395078179@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-03-17 10:03:52 -0700, Josh Berkus wrote:
>> First, see suggested text in my first-draft release announcement.

> I don't think that text is any better, it's imo even wrong:
> "The bug causes rows to vanish from indexes during recovery due to
> simultaneous updates of rows on both sides of a foreign key."

> Neither is a foreign key, nor simultaneous updates, nor both sides a
> prerequisite.

What I've got at the moment is

This error caused updated rows to disappear from indexes, resulting
in inconsistent query results depending on whether an index scan was
used. Subsequent processing could result in unique-key violations,
since the previously updated row would not be found by later index
searches. Since this error is in WAL replay, it would only manifest
during crash recovery or on standby servers. The improperly-replayed
case can arise when a table row that is referenced by a foreign-key
constraint is updated concurrently with creation of a
referencing row.

OK, or not? The time window for bikeshedding this is dwindling rapidly.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-03-17 17:43:38 Re: Planner hints in Postgresql
Previous Message Tom Lane 2014-03-17 17:41:15 Re: on_exit_reset fails to clear DSM-related exit actions