New upstream microreleases 9.5.16, 10.7 and 11.2

[Christian Ehrhardt ]

Current versions in supported releases:
 postgresql-9.3 | 9.3.23-0ubuntu0.14.04 trusty <- no upstream updates anymore
 postgresql-9.5 | 9.5.14-0ubuntu0.16.04 xenial
 postgresql-10 | 10.6-0ubuntu0.18.04.1 bionic
 postgresql-10 | 10.6-0ubuntu0.18.10.1 cosmic

Special cases:
- Disco will be synced from Debian soon (we are on 11.1-2)
- This is again a security update, so we prep and security will eval and publish through -security

Last relevant related stable updates: 9.5.16, 10.7

So the todo is to pick:
MRE: Xenial 9.5.14 from https://ftp.postgresql.org/pub/source/v9.5.16/postgresql-9.5.16.tar.gz
MRE: Bionic/Cosmic 10.7 from https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz

Standing MRE - Consider last updates as template:
- pad.lv/1637236
- pad.lv/1664478
- pad.lv/1690730
- pad.lv/1713979
- pad.lv/1730661
- pad.lv/1747676
- pad.lv/1752271
- pad.lv/1786938
New - this bug
- pad.lv/1815665

As usual we test and prep from the PPA and then push through SRU/Security as applicable.

Regression potential:
- usually this works smoothly except a few test hickups that need to be
  clarified to be sure. But this time there are changes worth to
  mention for the SRU team.
  - change [1] is in all branches Xenil/Bionic/Cosmic and after
    coordinating with Debian and Upstream and some members of the SRU Team
    (Malta) and Debian we decided to revert this change in all releases
    that get SRUs (So 11.x in Disco is the only who will get it).
    What makes this slightly more important is that: if
    client_min_messages is misused, then not having that fix
    could cause bad data.
    But users of Ubuntu are either:
    a) not affected at all and therefore are fine as-is (majority)
    b) not affected by the problem but have tests/scripts/CI/... that
       rely on the behavior (we don't want to SRU break them)
    c) have a case that is affected, in that case the "code using
       client_min_messages" is the one to be considered broken (in favor
       of the majority of users) and that code should be changed instead
       of PostgreSQL.
    Furthermore with that decision we are also in sync with Debian
    handling the same
 - Change [2] renaming of symbols rb/rbt is fine doing forward (Disco),
   but not in Bionic/Cosmic as we'd break en external ABI of the past in
   an SRU. Please Note that the offending plruby this change was made for
   is not even in the Archive.
 => Especially in regard to "regression potential" that means that we will
    NOT apply the two changes that are somewhat discussion-worthy. We
    might in later updates reconsider them, but for now when applying the
    latest stable release we revert those two primarily for the reason to
    have the lowest possible regression potential for the SRU.

Note: opening private as it is not yet announced
Public announce will on thursday.

[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c09daa910
[2]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b2e754c14

[Christian Ehrhardt  (paelzer)]

For v11 (Disco, still going along Debian) - there rebuilds are needed.
We probably want to track those in case some syncs would be needed after the FF and auto-sync stop. I'll add a postgresql-11 task for that

One worthwhile note for v11 is that extension that use heap_getattr()
need to be recompiled (because it was broken for fast defaults). And
that extensions recompiled against v11.2 will probably not load into
earlier minor releases, because heap_getattr() will reference
getmissingattr(), which previously was static.

They already work on that quoting:
> > I'm building a lot of extensions -- is there any easy way to find out which
> > extensions are using heap_getattr()?
>
> You should be able to just grep for it. Christoph has done so for
> Debian, I think:
> https://www.postgresql.org/message-id/20190206122229.GB10563%40msg.df7cb.de

For Debian, the list is postgresql-11, postgresql-rum, pglogical,
pgextwlist, citus, postgresql-plsh, wal2json, pg-cron:

https://codesearch.debian.net/search?q=heap_getattr&perpkg=1

[Christian Ehrhardt  (paelzer)]

Release notes can be prechecked at 1d00f275f1601ab6974123b8750a2487e630a185 and efb6b08e527c08a74696c9d41ba5bf068bc47367 from git://git.postgresql.org/git/postgresql.git

[Christian Ehrhardt  (paelzer)]

PPAs started on Bileto
Xenial: https://bileto.ubuntu.com/#/ticket/3645
Bionic: https://bileto.ubuntu.com/#/ticket/3646
Cosmic: https://bileto.ubuntu.com/#/ticket/3647

[Christian Ehrhardt  (paelzer)]

MPs are up and linked here

[Christian Ehrhardt  (paelzer)]

As usual, since the many autopkgtests are meant to be the primary verification lets analyze those we see on the Bileto PPAs:

Xenial [1]:
- bareos, orafce, pgfincore, pgpool2, postgresql-multicorn, postgresql-plproxy - already a force-badtest
* skytools3 had a force-badtest but got a version bump to skytools3/3.2.6-4ubuntu0.1 [1] which was meant to fix those tests interestingly. The history [5] of this is actually good, so this is a legitimate fail we need to investigate.
- gearmand on armhf is known to be flaky

Bionic [2]:
- dovecot-armhf/libvreoffice-i386 known to be flaky
- pglogical already a force-badtest
* postgresql-plproxy [6], postgresql-rum [7], pg-repack [8] fail on all arch while history (linked) is good.

Cosmic [3]:
- pglogical already a force-badtest
* postgresql-plproxy [9], postgresql-rum [10], pg-repack [11] fail on all arch while history (linked) is good.
* pg-partman [12] fails on i386 only, but history is good

Bullet points starting with "*" need investigation.

Lets enumerate the problem areas to be sure to handle all of them:
1. skytools3 fails in Xenial despite [4]
2. postgresql-plproxy, postgresql-rum and pg-repack fail on all arches on Bionic and Cosmic (might become 2a/b/c if the reasons are different)
3. pg-partman fails on i386 on Cosmic

[1]: https://bileto.ubuntu.com/excuses/3645/xenial.html
[2]: https://bileto.ubuntu.com/excuses/3646/bionic.html
[3]: https://bileto.ubuntu.com/excuses/3647/cosmic.html
[4]: https://launchpad.net/ubuntu/+source/skytools3/3.2.6-4ubuntu0.1
[5]: http://autopkgtest.ubuntu.com/packages/skytools3/xenial/amd64
[6]: http://autopkgtest.ubuntu.com/packages/postgresql-plproxy/bionic/amd64
[7]: http://autopkgtest.ubuntu.com/packages/postgresql-rum/bionic/amd64
[8]: http://autopkgtest.ubuntu.com/packages/pg-repack/bionic/amd64
[9]: http://autopkgtest.ubuntu.com/packages/postgresql-plproxy/cosmic/amd64
[10]: http://autopkgtest.ubuntu.com/packages/postgresql-rum/cosmic/amd64
[11]: http://autopkgtest.ubuntu.com/packages/pg-repack/cosmic/amd64
[12]: http://autopkgtest.ubuntu.com/packages/pg-partman/cosmic/i386

[Christian Ehrhardt  (paelzer)]

Investigating #2
- failures are the same across architectures
- failures are the same across releases (both go 10.6 -> 10.7)
- failures are not install/dependency issues, but real mismatches of expected test-behavior vs real-behavior

Note: The changelog didn't mention this need to rebuild extensions even for version 11 where it was discussed, maybe this is an effect of just that with "old" extensions not loading - I'll keep an extra eye for that.

... going to try a local repro with pg-repack which has the lowest amount of failing tests (less logs/output to read)

[Christian Ehrhardt  (paelzer)]

Continue on #2
- local test without the new PPA is working
- local test with the new PPA is failing

So it is at least reproducible and linked with the new build.

While debugging in the autopkgtest guest I'll prep a PPA in the background with those three packages rebuilt.

[Christian Ehrhardt  (paelzer)]

I checked were the mentioned re-build need comes from.
It was introduced by [1] which really only is on the Version 11 branch.
Furthermore it got [2] a mitigation which keeps extensions to be "recommended" but not "required" to be recompiled for that. Therefore we can (twice) stop thinking about that as the reason for the issues we see with version 10.7.

[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=297d627e074ad4aa2a9936b029a4b9231f9a150e
[2]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=920311ab18aac799aee6ad2303b2ed2b6b44c1b8

[Christian Ehrhardt  (paelzer)]

Call:
-- This will fail. Silence the message as it's different across PG versions.
SET client_min_messages = fatal;
CREATE UNIQUE INDEX CONCURRENTLY idx_badindex_n ON tbl_badindex (n);

Error:
ERROR: could not create unique index "idx_badindex_n"
DETAIL: Key (n)=(10) is duplicated.

So the failure is an expected error, but now having different/more "output"?

Test can be re-run - Re-execution via:
$ cd /tmp/autopkgtest.BTTHR0/build.p5M/src/
$ sudo rm -rf /tmp/pg-repack-tablespace; mkdir /tmp/pg-repack-tablespace; LC_ALL=C.UTF-8 pg_buildext -i'--auth=trust' installcheck-10

Modify the failing testcase in regress/sql/repack.sql
Stop silencing the message in the good autopkgtest (before 10.7) to check if the errors are the same.

As expected adding this to the expected output fixes the issue.
--- src/regress/expected/repack_3.out.old 2019-02-13 10:57:21.436486225 +0100
+++ src/regress/expected/repack_3.out.new 2019-02-13 10:57:11.264461520 +0100
@@ -127,6 +127,8 @@
 -- This will fail. Silence the message as it's different across PG versions.
 SET client_min_messages = fatal;
 CREATE UNIQUE INDEX CONCURRENTLY idx_badindex_n ON tbl_badindex (n);
+ERROR: could not create unique index "idx_badindex_n"
+DETAIL: Key (n)=(10) is duplicated.
 SET client_min_messages = warning;
 INSERT INTO tbl_idxopts VALUES (0, 'abc'), (1, 'aaa'), (2, NULL), (3, 'bbb');
 -- Insert no-ordered data

We need to make sure what the old error was, either the silencing dosn't work and more or the error is now considered more severe.

Disabling
 SET client_min_messages = fatal;
in the good run gives these messages:
  + ERROR: could not create unique index "idx_badindex_n"
  + DETAIL: Key (n)=(10) is duplicated.

Ok, those are -exactly- the same - so the message silencing is affected by the update.
That means the actual error is totally fine, but why did the message pop up.
Checking through the REL_10_STABLE branch ...

[Christian Ehrhardt  (paelzer)]

Ok I found the change that triggers this:
- https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c09daa910
- https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=88275ac19
[...]

It is on all branches, it just doesn't affect all test.
To re-iterate - the error is and always was the same, upstream just removed the ability
I think we need to adapt some tests to work properly with that new code.

I agree with the change in terms of SRU considerations.
It is right to fix the FE/BE protocol, the only thing that should be affected are testcases like the ones I found - so maybe some CIs might break, but not more.

I'm checking if the other test breakage I saw might be due to the same change.

[Christian Ehrhardt  (paelzer)]

The git tag is public now, make the bug public as well.

[Christian Ehrhardt  (paelzer)]

https://codesearch.debian.net/search?q=%5BSs%5D%5BEe%5D%5BTt%5D%5Cs*client_min_messages.*fatal
Not sure how I could search that way in a past release, but it gives some confirming hits.

For our current case I can confirm the following issues being due to this:
- skytools3 (xenial, not in archive later) #1
- pg-repack (bionic/cosmic) #2a
- postgres-plproxy (bionic/cosmic) #2b

The following two seems to be a different error thou:
- postgres-rum
This is more like the Tables were never created with errors like:
"operator does not exist: smallint[] % unknown at character 34"
- pg-partman [i386]

I'm adding bug tasks for those we identified and set them to triaged as we know how to fix them.
#3 - pg-partman [i386] - will stay unhandled until analyzed
#4 - postgres-rum - split this from the others and define is as #4

[Christian Ehrhardt  (paelzer)]

Note: there are references to client_min_messages in bacula and bareos as well, but those will just (correctly) get more verbose (if failing a all).

[Christian Ehrhardt  (paelzer)]

#3 - pg-partman (i386) - local execution in autopkgtest and reruns on LP confirmed this was just a flaky test and can be ignored.

#4 - postgresql-rum - local execution in autopkgtest confirmed this is reproducibly linked to the new version in the PPA
Debugging this now (or after lunch) ...

[Christian Ehrhardt  (paelzer)]

From the test log:
    ============== dropping database "contrib_regression" ==============
    DROP DATABASE
    ============== creating database "contrib_regression" ==============
    NOTICE: database "contrib_regression" does not exist, skipping
    CREATE DATABASE
    ALTER DATABASE
    ============== running regression test queries ==============
    [... all fails]

The line 'NOTICE: database "contrib_regression" does not exist, skipping' makes me curious.
Isn't that inverted logic?
It should be created only if it is NOT there.

Comparing the good case confirms that this message isn't there - and I mean not "exactly there" it is a few lines up at "dropping" which makes more sense. This could just be a race to the output, but we need to check.

This is the call to the subtests after spawning the server:
/usr/lib/postgresql/10/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress --inputdir=/tmp/autopkgtest.T6TDFr/build.b8t/src --bindir='/usr/lib/postgresql/10/bin' --dbname=contrib_regression rum rum_hash ruminv timestamp orderby orderby_hash altorder altorder_hash limits int2 int4 int8 float4 float8 money oid time timetz date interval macaddr inet cidr text varchar char bytea bit varbit numeric array

We can just run the first subtest which already fails the same way.
$ sudo su - postgres
$ /usr/lib/postgresql/10/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress --inputdir=/tmp/autopkgtest.T6TDFr/build.b8t/src --bindir='/usr/lib/postgresql/10/bin' --dbname=contrib_regression rum

I can confirm that the message that I wondered above was just racing in the log - this is not the root cause.

Checking the full outfile was more interesting then:
ERROR: could not load library "/usr/lib/postgresql/10/lib/rum.so": /usr/lib/postgresql/10/lib/rum.so: undefined symbol: rb_insert

Checking with a shell into a good case (no PPA) environment the same log file confirms that this works there.

Looking for that symbol in the changes we got in 10.7 now ...

[Christian Ehrhardt  (paelzer)]

The error is due to this change [1]

While we could modify and rebuild postgresql-rum we don't know what else people might have built against that which is not in the Archive.

This applies only to branches 11 (not yet released, so ok) and 10 (Bionic/Cosmic)

My suggestion would be to carry a revert of this change as it is not SRU-able in my opinion.

I thought more about the other change [2] and I must say after considering it more I also think it is a break of the SRU promises. So I'll suggest adding a revert of that to our streams of 9.5 and 10 that are in active releases.

[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b2e754c14e2741a076691e8c6f0099afffaa842e
[2]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c09daa910

[Christian Ehrhardt  (paelzer)]

While we will discuss with the SRU Team which way (revert or break) we as Ubuntu want to go I analyzed the test results with the reverts as they are in the MPs.
This shall ensure that there are no more lingering errors.

Xenial [1]:
- bareos, orafce, pgfincore, pgpool2, postgresql-multicorn, postgresql-plproxy - already a force-badtest
- gearmand @ armhf is known to be flaky
- libdbd-pg-perl was hit by random unrelated error and is good on retry
- skytools3 is good now

Bionic [2]:
- diaspora-installer-armhf/libvreoffice-i386/postgresql-10-armhf known to be flaky
- pglogical already a force-badtest
- postgresql-plproxy, postgresql-rum, pg-repack are all fixed now

Cosmic [3]:
- pglogical already a force-badtest
- postgresql-plproxy, postgresql-rum, pg-repack are all fixed now

To me that looks much better from a "new regression" POV.

[1]: https://bileto.ubuntu.com/excuses/3645/xenial.html
[2]: https://bileto.ubuntu.com/excuses/3646/bionic.html
[3]: https://bileto.ubuntu.com/excuses/3647/cosmic.html

[Christian Ehrhardt  (paelzer)]

While 10.7 needs more work for the work with the extensions in regard to the rb/rbt renaming 9.5 for Xenial is ready - uploaded 9.5.16 to Xenial-unapproved

[Christian Ehrhardt  (paelzer)]

When preparing the changes I happened to realize that we got mislead by too many open tabs and mails in our discussion. The change with a potential to break data is [1] but not [2].
Therefore our discussion was misleading - for [1] there can be no comparable solution for the "check for the symbol in the extensions" as the setting of client_min_messages could be anywhere.

That said I'll switch back to my suggestion to revert of both:
- [1]: client_min_messages: users of Bionic/Cosmic are either
  a) not affected at all and therefore are fine as-is (majority)
  b) not affected by the problem but have tests/scripts/CI/... that relies on the behavior (we
     don't want to SRU break them)
  b) have a case that is affected, in that case the "user" of client_min_messages that is
     considered broken should be changed.
  Furthermore with that decision we are also in sync with Debian handling the same
- [2]: rb/rbt: fine doing forward (Disco), but not Bionic/Cosmic not breaking ABI of the past in
       an SRU

[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c09daa910
[2]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b2e754c14

[Christian Ehrhardt  (paelzer)]

I have updated the bug description accordingly to cover and explain, I'll re-add it to the MPs and open them up for a sanity check.

[Christian Ehrhardt  (paelzer)]

After adapting the description for the new insights I uploaded the two 10.7 branches (Bionic/Cosmic) to the unapproved queue as well (9.5 for Xenial was there already).

[Christian Ehrhardt  (paelzer)]

Due to the reverts this is much less disruptive, plenty of bug tasks got invalid.
As 11.2 gets the change postgresql-rum in Disco is affected, but that is already in 1.3.2-4 which is in Disco.

[Christian Ehrhardt  (paelzer)]

pglogical-ticker is a test that blocks things in Disco atm, we need to resolve that before release

[Steve Langasek (vorlon)]

$ debdiff postgresql-10_10.*dsc | filterdiff -x '**/doc/**' -x '**/*.po' -x '**/src/test/**' -x '**/*.m4' | wc -l
31806
$

That's rather substantial, and a bit frightening for an MRE without any further references to upstream testing. Why is this going via -proposed, vs the security team's public security-proposed ppa?

[Christian Ehrhardt  (paelzer)]

Fixes for pglogical-ticker identified and started to be upstreamed at [1]
This was proven to work well at [2] and therefore is now uploaded to Disco at [3] hopefully unblocking 11.2 in Disco-proposed.

[1]: https://github.com/enova/pglogical_ticker/pull/6
[2]: https://bileto.ubuntu.com/excuses/3677/disco.html
[3]: https://launchpad.net/ubuntu/+source/pglogical-ticker/1.3.1-1ubuntu1

[Launchpad Janitor (janitor)]

This bug was fixed in the package pglogical-ticker - 1.3.1-1ubuntu1

---------------
pglogical-ticker (1.3.1-1ubuntu1) disco; urgency=medium

  * d/p/fix-test-error-11.2.patch: Fix test issue with
    postgresql 11.2 (LP: #1815665)

 -- Christian Ehrhardt <email address hidden> Mon, 11 Mar 2019 13:32:27 +0100

[Robie Basak (racb)]

Hello Christian, or anyone else affected,

Accepted postgresql-9.5 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postgresql-9.5/9.5.16-0ubuntu0.16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Robie Basak (racb)]

Hello Christian, or anyone else affected,

Accepted postgresql-10 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postgresql-10/10.7-0ubuntu0.18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Robie Basak (racb)]

Hello Christian, or anyone else affected,

Accepted postgresql-10 into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postgresql-10/10.7-0ubuntu0.18.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Christian Ehrhardt  (paelzer)]

I was checking the tests, and so far I found:
- Bionic all built and all tests good
- Cosmic all built and just one flake test in diaspora-installer (re-triggered just now)
- Xenial didn't build on ppc64el (WTH it did in the PPAs two weeks ago)
  This seems to be a locking issue in the builders - it runs since 18 hours and show messages like
  INFO: pkgstripfiles: waiting for lock (postgresql-plperl-9.5) ...
  Lets abort and restart that build for now, lets see after a few hours ...

[Christian Ehrhardt  (paelzer)]

- Xenial ppc64el build complete now, tests will run over the weekend.
- The cosmic diaspora test succeeded on the re-run as expected, thereby all of Cosmic is good as well

Marking B&C as verified, X has to wait a bit due to the build issue causing a delay

[Christian Ehrhardt  (paelzer)]

Xenial also built and tested fine over the weekend.

There is a single test issue that I need to mention in libreoffice on i386 [1].
That seems to be a known issue [2] and I provided some further debug for it, but in the SRU context for Xenial this should not be an issue as [3] should mask the test already.

Marking verified due to all tests being good.
I'll ping the SRU member of today to look with me at why this force-badtest might not mask the issue.

Overall this should now be good to be released.

[1]: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/libr/libreoffice/20190329_095234_09821@/log.gz
[2]: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1699529
[3]: https://bazaar.launchpad.net/~ubuntu-sru/britney/hints-ubuntu-xenial/revision/1700

[Christian Ehrhardt  (paelzer)]

Oh it is rather trivial in the looong version string the suffix changed due to another upload.
I'll provide an MP to bump that along this SRU.

[Christian Ehrhardt  (paelzer)]

MP up at https://code.launchpad.net/~paelzer/britney/hints-ubuntu-xenial-i386-libreoffice/+merge/365333

Since all tests are in I marked all releases verified

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-10 - 10.7-0ubuntu0.18.10.1

---------------
postgresql-10 (10.7-0ubuntu0.18.10.1) cosmic; urgency=medium

  * New upstream release (LP: #1815665)
    - By default, panic instead of retrying after fsync() failure, to avoid
      possible data corruption. A new server parameter "guc-data-sync-retry"
      has been added to control this;
    - d/p/pg-10-Disallow-setting-client_min_messages-higher-than-ERR.patch:
      to retain SRU stability this patch reverts one of the changes which
      disabled the error suppression by setting client_min_messages to
      fatal or panic. Overall that means no change to the handling of
      client_min_messages due to this upload.
    - d/p/pg-10-Rename-rbtree.c-functions-to-use-rbt-prefix-not-rb-p.patch:
      this change of 10.7 would break an external ABI/API exposed to
      extensions. To avoid breaking those (especially those not in the Ubuntu
      Archive that we can't control) this change of upstreams stable release
      is reverted. Thereby the ABI/API is unchanged in regard to the rb_
      function prefix by this new package upload to Ubuntu.
    - Details about these and many further changes can be found at:
      https://www.postgresql.org/docs/10/static/release-10-7.html

 -- Christian Ehrhardt <email address hidden> Tue, 12 Feb 2019 21:25:34 +0100

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for postgresql-10 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-10 - 10.7-0ubuntu0.18.04.1

---------------
postgresql-10 (10.7-0ubuntu0.18.04.1) bionic; urgency=medium

  * New upstream release (LP: #1815665)
    - By default, panic instead of retrying after fsync() failure, to avoid
      possible data corruption. A new server parameter "guc-data-sync-retry"
      has been added to control this;
    - d/p/pg-10-Disallow-setting-client_min_messages-higher-than-ERR.patch:
      to retain SRU stability this patch reverts one of the changes which
      disabled the error suppression by setting client_min_messages to
      fatal or panic. Overall that means no change to the handling of
      client_min_messages due to this upload.
    - d/p/pg-10-Rename-rbtree.c-functions-to-use-rbt-prefix-not-rb-p.patch:
      this change of 10.7 would break an external ABI/API exposed to
      extensions. To avoid breaking those (especially those not in the Ubuntu
      Archive that we can't control) this change of upstreams stable release
      is reverted. Thereby the ABI/API is unchanged in regard to the rb_
      function prefix by this new package upload to Ubuntu.
    - Details about these and many further changes can be found at:
      https://www.postgresql.org/docs/10/static/release-10-7.html

 -- Christian Ehrhardt <email address hidden> Tue, 12 Feb 2019 21:25:34 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-9.5 - 9.5.16-0ubuntu0.16.04.1

---------------
postgresql-9.5 (9.5.16-0ubuntu0.16.04.1) xenial; urgency=medium

  * New upstream release(s) (LP: #1815665)
    - By default, panic instead of retrying after fsync() failure, to avoid
      possible data corruption. A new server parameter "guc-data-sync-retry"
      has been added to control this;
    - d/p/pg-9.5-Disallow-setting-client_min_messages-higher-than-ERR.patch:
      to retain SRU stability this patch reverts one of the changes which
      disabled the error suppression by setting client_min_messages to
      fatal or panic. Overall that means no change to the handling of
      client_min_messages due to this upload.
    - Details about these and many further changes can be found at:
      https://www.postgresql.org/docs/9.5/static/release-9-5-15.html
      https://www.postgresql.org/docs/9.5/static/release-9-5-16.html

 -- Christian Ehrhardt <email address hidden> Tue, 12 Feb 2019 21:25:00 +0100