
PostgreSQL 9.6.2, 9.5.6, 9.4.11, 9.3.16 and 9.2.20 released - willlll
https://www.postgresql.org/about/news/1733/
======
gsylvie
I find their branching model interesting (no merges ever!):

    
    
      $ git log --graph --oneline --decorate --date-order --all
    
      * 86d911ec0f (HEAD -> master, origin/master, origin/HEAD) Allow index...
      * 7c5d8c16e1 Add explicit ORDER BY to a few tests that exercise hash-...
      | * 1888fad440 (origin/REL9_4_STABLE) Fix roundoff problems in float8...
      | | * 7786b98482 (origin/REL9_5_STABLE) Fix roundoff problems in float8...
      | | | * 404756fe89 (origin/REL9_6_STABLE) Fix roundoff problems in float8...
      * | | | 8f93bd8512 Fix roundoff problems in float8_timestamptz() and make...
      * | | | a507b86900 Add WAL consistency checking facility.
      * | | | 115cb31597 Fix relcache leaks in get_object_address_publication_rel()
      * | | | e35bbea7dd doc: Some improvements in CREATE SUBSCRIPTION ref page
      * | | | c3c4f6e174 Revise the way the element allocator for a simplehash...
      * | | | 242066cc8e Speed up "brin" regression test a little bit.
      * | | | ac8eb972f2 Avoid redefining simplehash_allocate/simplehash_free.
      * | | | 565903af47 Allow the element allocator for a simplehash to be specified.
      * | | | 94708c0e8c Fix compiler warning.
      * | | | 293e24e507 Cache hash index's metapage in rel->rd_amcache.
      | | | | * 903bfef382 (tag: REL9_2_20, origin/REL9_2_STABLE) Correct thinko...
      | | | | | * 4dd4e3fe10 (origin/REL9_3_STABLE) Correct thinko in last-minute...
      | * | | | | cd898769cb Correct thinko in last-minute release note item.
      | | * | | | 13b30ada99 Correct thinko in last-minute release note item.
      | | | * | | ae8a602c32 Correct thinko in last-minute release note item.
      * | | | | | 39c3ca5161 Correct thinko in last-minute release note item.

~~~
liquidise
Fascinating. Can someone detail the pros/cons of this? Are they
copying/cherry-picking commits from a dev track?

~~~
anarazel
I think there's two different discussions here. One about cherry-picking for
back-branch releases, one about development for the new version.

Re back-branches: It's not particularly practical to use merges from/to stable
branches. It may sound nice at first, but there's enough fixes that don't
apply to all versions (because a feature didn't exist yet, because
refactorings made bugs "accidentally" disappear, ...) that merging either to
or from back-branches leads to very very messy merges, where the merge commit
has to back out changes and such. I don't know of any larger project that
successfully uses merges to merge to/from stable branches. So yes, it's just
cherry-picking.

Re development: The case here is a lot less clear. The project used CVS for a
long while, and during the migration it was decided to not make the migration
harder by changing workflows even more significantly than just CVS->git. So
the, enforced, policy became that no merge commits are to appear. It hasn't
become a significant problem since, so that policy hasn't evolved at this
point. Given the relatively small number of active committers in the project,
and the fact that commits in the project are expected to "stand on their own"
(i.e. are complete and working), rebasing changes before committing them isn't
a problem. Several contributors, including committers, do their development in
separate repositories / branches, however. But usually the history there is
messy enough that they wouldn't be merged anyway. I think merging is more of a
benefit when you have a more hierarchically organized project like the kernel,
with subsystem maintainers that aggregate a large volume of changes, which
then get pushed to Linus, who then integrates all of those.

Hope that roughly answers your question? If not, feel free to ask more about
specifics.

(For context: I'm one of the committers in the project)

~~~
anarazel
Oh, and because it's relevant for the question: There's a tool in the tree
([https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f...](https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/tools/git_changelog;hb=HEAD))
that shows (by heuristics) which branches a commit has been cherry-picked to.
Looks like this:

    
    
        Author: Tom Lane <tgl@sss.pgh.pa.us>
        Branch: master [9d4ca0131] 2017-01-26 12:18:07 -0500
        Branch: REL9_6_STABLE [2dfc12647] 2017-01-26 12:17:47 -0500
        Branch: REL9_5_STABLE [423ad86f4] 2017-01-26 12:17:47 -0500
        Branch: REL9_4_STABLE [2c1976a6c] 2017-01-26 12:17:47 -0500
        Branch: REL9_3_STABLE [2e024f83b] 2017-01-26 12:17:47 -0500
        Branch: REL9_2_STABLE [fe6120f9b] 2017-01-26 12:17:47 -0500
        
            Ensure that a tsquery like '!foo' matches empty tsvectors.
            
            !foo means "the tsvector does not contain foo", and therefore it should
            match an empty tsvector.  ts_match_vq() overenthusiastically supposed
            that an empty tsvector could never match any query, so it forcibly
            returned FALSE, the wrong answer.  Remove the premature optimization.
            
            Our behavior on this point was inconsistent, because while seqscans and
            GIST index searches both failed to match empty tsvectors, GIN index
            searches would find them, since GIN scans don't rely on ts_match_vq().
            That makes this certainly a bug, not a debatable definition disagreement,
            so back-patch to all supported branches.
            
            Report and diagnosis by Tom Dunstan (bug #14515); added test cases by me.
            
            Discussion: https://postgr.es/m/20170126025524.1434.97828@wrigleys.postgresql.org
    
    

Edit: fighting with formatting #2

~~~
richardwhiuk
This is fairly easy to do, if you enforce a policy of requiring cherry-picks
to reference the original commit (i.e. requiring -x in the git cherry-pick
command).

You can the grep the log for all the commits which contain the commit ID you
are interested in (and any that mention those commits).

~~~
anarazel
That's not always that helpful, because you often will want to cherry-pick
from another branch than master. E.g. when cherry-picking a change from master
into 9.6, 9.5, 9.4, 9.3, 9.2 it'll e.g. often be easier to cherry-pick from
9.3 into 9.2, rather than master into 9.2 (due to conflicts increasing the
further back you go). Obviously you could do that manually or script it
regardless. But the current heuristics have worked without problems for years,
so there seems little reason to change things ;)

------
afarrell
> Users should plan to apply this update at the next scheduled downtime.

Folks who are looking for ways to upgrade PostgreSQL without downtime might
want to take a look at this setup using pacemaker:
[https://github.com/gocardless/our-postgresql-
setup](https://github.com/gocardless/our-postgresql-setup)

[http://www.interdb.jp/blog/pgsql/pg_pacemaker_01/](http://www.interdb.jp/blog/pgsql/pg_pacemaker_01/)
digs into playing with the vagrant box a tiny bit.

EDIT-- ah, found the talk explaining it:
[https://www.youtube.com/watch?v=SAkNBiZzEX8](https://www.youtube.com/watch?v=SAkNBiZzEX8)

------
carbocation
All pages on postgresql.org are currently showing an error for me.

~~~
gigatexal
Same for me.

~~~
anarazel
The infrastructure people are on it, sorry for that.

~~~
striking
Wow, it's already fixed. Good work!

------
thejosh
Cached link:

[https://webcache.googleusercontent.com/search?q=cache:CDUXYn...](https://webcache.googleusercontent.com/search?q=cache:CDUXYn8PAEwJ:https://www.postgresql.org/about/news/1733/+&cd=1&hl=en&ct=clnk&gl=au)

------
broswell
OOPs. Here too! Server Error An internal server error occurred.

