Andres Freund wrote:
> On 2014-02-14 13:33:46 -0500, Josh Berkus wrote:
> > On 02/14/2014 01:11 PM, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2014-02-14 13:08:34 -0500, Josh Berkus wrote:
> > >> Do the 9.3.3 replication fixes mean that users should reclone their
> > >> replicas, like 9.3.2 did? Or not?
> > >
> > > Which replication replication fixes are you referring to?
> > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ebde6c40148c9f811f7c6d35f67e7ea3ce2d9b34
> > > ?
> > > If so, no, that doesn't require a reclone.
> >
> > Hmmm. I thought there were also 9.3-only replication fixes in this
> > release? No?
>
> I don't know any. There's further multixact fixes but AFAIK there's
> nothing replication specific, and they shouldn't cause problems but lost
> row locks in some edge cases.
There is one issue that might cause foreign keys to go unchecked. In
cases where applications update referenced tuples and then delete them
in the same transaction, it might be wise to recheck foreign keys. This
is the relevant commit:
commit db1014bc46de21a6de1751b807ea084e607104ad
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Wed Dec 18 13:31:27 2013 -0300
Don't ignore tuple locks propagated by our updates If a tuple was locked by transaction A, and transaction B
updatedit, the new version of the tuple created by B would be locked by A, yet visible only to B; due to an
oversightin HeapTupleSatisfiesUpdate, the lock held by A wouldn't get checked if transaction B later deleted (or
key-updated)the new version of the tuple. This might cause referential integrity checks to give false positives
(thatis, allow deletes that should have been rejected). This is an easy oversight to have made, because prior to
improvedtuple locks in commit 0ac5ad5134f it wasn't possible to have tuples created by our own transaction that
werealso locked by remote transactions, and so locks weren't even considered in that code path. It is
recommendedthat foreign keys be rechecked manually in bulk after installing this update, in case some referenced rows
aremissing with some referencing row remaining. Per bug reported by Daniel Wood in
CAPweHKe5QQ1747X2c0tA=5zf4YnS2xcvGf13Opd-1Mq24rF1cQ@mail.gmail.com
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
