Horton

Thread

Commits

  1. Fix multiple bugs in index page locking during hot-standby WAL replay.

  2. Don't ignore tuple locks propagated by our updates

  3. Improve concurrency of foreign key locking

  1. Release schedule for 9.3.3?

    Sean Chittenden <sean@chittenden.org> — 2014-02-06T21:55:04Z

    Are there any tentative plans for the 9.3.3 release date? 9.3.2 was released in December and it’s getting close to the two month mark for another micro release, or at least one seems like one should be right around the corner.

It’s a little early, but I haven’t seen any movement or discussion so I thought I’d prod and ask. Thanks in advance. -sc

--
Sean Chittenden
sean@chittenden.org

  2. Re: Release schedule for 9.3.3?

    Greg Stark <stark@mit.edu> — 2014-02-06T22:00:17Z

    On Thu, Feb 6, 2014 at 10:55 PM, Sean Chittenden <sean@chittenden.org> wrote:
> Are there any tentative plans for the 9.3.3 release date? 9.3.2 was released in December and it's getting close to the two month mark for another micro release, or at least one seems like one should be right around the corner.


Bug fix releases are released when we find bugs, not on a schedule.
That said, there were some bugs fixed in the last few weeks including
one fairly serious one so I would expect one in not too long.

-- 
greg

  3. Re: Release schedule for 9.3.3?

    Tom Lane <tgl@sss.pgh.pa.us> — 2014-02-07T20:56:49Z

    Greg Stark <stark@mit.edu> writes:
> On Thu, Feb 6, 2014 at 10:55 PM, Sean Chittenden <sean@chittenden.org> wrote:
>> Are there any tentative plans for the 9.3.3 release date? 9.3.2 was released in December and it's getting close to the two month mark for another micro release, or at least one seems like one should be right around the corner.

> Bug fix releases are released when we find bugs, not on a schedule.
> That said, there were some bugs fixed in the last few weeks including
> one fairly serious one so I would expect one in not too long.

We're trying to get something organized right now, actually.  Barring
objections from the packagers list, it'll be week after next.

			regards, tom lane

  4. Re: Release schedule for 9.3.3?

    Josh Berkus <josh@agliodbs.com> — 2014-02-14T18:08:34Z

    All,

Do the 9.3.3 replication fixes mean that users should reclone their
replicas, like 9.3.2 did?  Or not?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

  5. Re: Release schedule for 9.3.3?

    Andres Freund <andres@2ndquadrant.com> — 2014-02-14T18:11:22Z

    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.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

  6. Re: Release schedule for 9.3.3?

    Josh Berkus <josh@agliodbs.com> — 2014-02-14T18:33:46Z

    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?


-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

  7. Re: Release schedule for 9.3.3?

    Andres Freund <andres@2ndquadrant.com> — 2014-02-14T18:51:24Z

    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.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

  8. Re: Release schedule for 9.3.3?

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2014-02-14T19:27:56Z

    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 updated it,
    the new version of the tuple created by B would be locked by A, yet
    visible only to B; due to an oversight in 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 (that is, allow deletes that
    should have been rejected).
    
    This is an easy oversight to have made, because prior to improved tuple
    locks in commit 0ac5ad5134f it wasn't possible to have tuples created by
    our own transaction that were also locked by remote transactions, and so
    locks weren't even considered in that code path.
    
    It is recommended that foreign keys be rechecked manually in bulk after
    installing this update, in case some referenced rows are missing 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