Bug 1185952 - [Build 20210510] PostgreSQL 12 and 13 fail to build with LLVM12 on s390x
[Build 20210510] PostgreSQL 12 and 13 fail to build with LLVM12 on s390x
Status: VERIFIED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Other
Current
S/390-64 Other
: P3 - Medium : Normal (vote)
: ---
Assigned To: Reinhard Max
E-mail List
https://openqa.opensuse.org/tests/173...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-05-12 08:16 UTC by Sarah Kriesch
Modified: 2022-08-05 10:45 UTC (History)
7 users (show)

See Also:
Found By: openQA
Services Priority:
Business Priority:
Blocker: Yes
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sarah Kriesch 2021-05-12 08:16:59 UTC
## Observation

openQA test in scenario opensuse-Tumbleweed-DVD-s390x-textmode@s390x-zVM-vswitch-l2 fails in
[postgresql_server](https://openqa.opensuse.org/tests/1734657/modules/postgresql_server/steps/6)
All packages can be installed. The problem is that the PostgreSQL server can not be started. The journal log is saying:
-- Logs begin at Mon 2021-05-10 22:41:06 EDT, end at Mon 2021-05-10 23:23:02 EDT. --
May 10 23:15:15 susetest systemd[1]: Starting PostgreSQL database server...
May 10 23:15:15 susetest systemd[1]: postgresql.service: Control process exited, code=exited, status=1/FAILURE
May 10 23:15:15 susetest systemd[1]: postgresql.service: Failed with result 'exit-code'.
May 10 23:15:15 susetest systemd[1]: Failed to start PostgreSQL database server.
May 10 23:15:15 susetest postgresql-script[12832]:  Cannot find an active PostgreSQL server binary. Please install one of the PostgreSQL
May 10 23:15:15 susetest postgresql-script[12832]:  server packages or activate an already installed version using update-alternatives.


## Test suite description
Maintainer: QE Yast
Installation in textmode and selecting the textmode "desktop" during installation.


## Reproducible

Fails since (at least) Build [20210510](https://openqa.opensuse.org/tests/1734657) (current job)


## Expected result

Last good: [20210507](https://openqa.opensuse.org/tests/1731697) (or more recent)


## Further details

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=s390x&distri=opensuse&flavor=DVD&machine=s390x-zVM-vswitch-l2&test=textmode&version=Tumbleweed)
Comment 1 Reinhard Max 2021-05-12 14:35:58 UTC
This is because a mix of postgresql11 and postgresql13 packages is installed.
postgresql13 is active in update-alternatives, but postgresql13-server is not installed, so the service file cannot start the server of the active version. The server binary from postgresql11 would only be started if postgresql11 was set as the active alternative or if the data directory already contained a set of data files that was initialized with postgresql11.

BTW, it doesn't seem to make sense to me that the test requests the installation of postgresql11-llvmjit together with postgresql13. Is there a reason for that?

For the test to work, depending on the intention one of the following conditions would have to be met:

- Call update-alternatives after package installation to make postgresql11 the default.

- Don't install any postgresql13 package, so that postgresql11 becomes the default in update-alternatives. But notice that postgresql13-* (containing the binaries) is not to be confused with version 13 of postgresql-* which are noarch packages that contain only infrastructure and dependencies.

- Install postgresql13-server, but then the tests will be run on that version.
Comment 2 Sarah Kriesch 2021-05-12 15:41:09 UTC
It seems, that the tests have not been changed for the postgresql-server in the last days:
https://openqa.opensuse.org/tests/1734657#investigation

These packages are installed on Tumbleweed with:
sudo zypper install postgresql-server

In our openQA tests:
zypper_call "in postgresql-server sudo";
Comment 3 Reinhard Max 2021-05-12 17:02:11 UTC
Ah, sorry, I misread the screenshots.

I did recently work on the logic that decides whether to build or not build the llvmjit subpackage, but the SR for that was accepted 20 days ago, so I would have expected problems to surface earlier than this has.

Can I see the package list of the medium somewhere that was used for that test? An excerpt showing all packages that match "postgresql" would be sufficient.
Comment 4 Sarah Kriesch 2021-05-12 19:03:58 UTC
These repositories should be used after pubilshing:
http://download.opensuse.org/ports/zsystems/factory/repo/oss/s390x/
together with
http://download.opensuse.org/ports/zsystems/factory/repo/oss/noarch/

And as I can see  in screenshot https://openqa.opensuse.org/tests/1734657#step/postgresql_server/2 it is installing:
- postgresql11-11.11-3.2.s390x.rpm
- postgresql13-13.2-2.3.s390x.rpm
- postgresql-server-13-1.32.noarch.rpm
- postgresql-13-1.32.noarch.rpm

It seems, there is the main focus on postgresql13, but postgresql11 has found its way into the installation with postgresql-server. 5 days ago, there wasn't this issue.

Our packages for s390x are coming from our s390x port:
https://build.opensuse.org/project/show/openSUSE:Factory:zSystems
Comment 5 Sarah Kriesch 2021-05-15 17:19:01 UTC
The not public openQA mirror is: http://openqa.opensuse.org/assets/repo/Tumbleweed-oss-s390x-Snapshot20210514
Comment 6 Reinhard Max 2021-05-17 20:18:16 UTC
I tried this with a current (20210516) build of Tumbleweed on an s390x default server installation and couldn't reproduce it:

--- snip ---
# zypper in postgresql-server
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 10 NEW packages are going to be installed:
  libicu67 libicu67-bedata libLLVM11 libpq5 postgresql postgresql13 postgresql13-llvmjit postgresql13-server postgresql-llvmjit postgresql-server

The following 3 recommended packages were automatically selected:
  postgresql13 postgresql13-llvmjit postgresql13-server

10 new packages to install.
Overall download size: 43,3 MiB. Already cached: 0 B. After the operation, additional 151,4 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): 
--- snap ---

Maybe this test failure was just a temporary hickup, so please re-run the test on a current snapshot and let me know if it still happens.
Comment 7 Reinhard Max 2021-05-18 05:11:13 UTC
Same when I switch to https://download.opensuse.org/ports/zsystems/factory/repo/oss/ instead of the Tumbleweed repos that were active after installation: http://download.opensuse.org/ports/zsystems/tumbleweed/repo/oss/ .
Comment 8 Sarah Kriesch 2021-05-18 06:04:48 UTC
The current build of Tumbleweed for s390x is working because the non-working one isn't published because of test failures.

The last Tumbleweed update from s390x is from May 8.
Comment 10 Reinhard Max 2021-05-18 07:16:27 UTC
Ah, postgresql11 is the only PostgreSQL version for which current snapshots on s390x contain a -server subpackage.

# zypper se -s postgresql
Loading repository data...
Reading installed packages...

S | Name                 | Type    | Version   | Arch   | Repository
--+----------------------+---------+-----------+--------+--------------------
  | postgresql           | package | 13-1.32   | noarch | openSUSE-20210516-0
  | postgresql-contrib   | package | 13-1.32   | noarch | openSUSE-20210516-0
  | postgresql-llvmjit   | package | 13-1.32   | noarch | openSUSE-20210516-0
  | postgresql-server    | package | 13-1.32   | noarch | openSUSE-20210516-0
  | postgresql11         | package | 11.11-3.2 | s390x  | openSUSE-20210516-0
  | postgresql11-contrib | package | 11.11-3.2 | s390x  | openSUSE-20210516-0
  | postgresql11-llvmjit | package | 11.11-3.2 | s390x  | openSUSE-20210516-0
  | postgresql11-server  | package | 11.11-3.2 | s390x  | openSUSE-20210516-0
  | postgresql13         | package | 13.2-2.3  | s390x  | openSUSE-20210516-0

The postgresql12 and postgresql13 packages are currently failing to build on openSUSE:Factory:zSystems, which might be related to my recent re-enablement of llvmjit. This leads to postgresql13 being from an older build with llvm still disabled, but I have no idea why all subpackages of postgresql13 and all of postgresql12 are missing on the media. Additionally version 9.6 (postgresql96) which is still in Factory and does build on s390x is also missing.
Comment 12 Reinhard Max 2021-05-18 08:48:32 UTC
No need to keep hammering on these OpenQA test failures, because the reason for them has already been found in the incomplete set of postgresql packages on the media, so let's focus on tracking down why all these packages are missing.

Part of it seems to be that PostgreSQL 12 and 13 currently fail in their regression test suite when built with llvm support on s390x. I meanwhile found that this only happens with the relatively new version 12 of llvm and clang, but not with version 11.

The regression test failures with llvm12 are full of messages like this:
[ 1322s] +ERROR:  failed to JIT module: Added modules have incompatible data layouts: E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64 (module) vs E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64 (jit)

A full log of a failed build can be found here:
https://build.opensuse.org/package/live_build_log/server:database:postgresql/postgresql13/openSUSE_Factory_zSystems/s390x

Aaron and Michael: Do you have any ideas of what's going wrong here? Or shall I just switch back to llvm/clang 11 for now, because version 12 is not yet stable enough?
Comment 13 Aaron Puchert 2021-05-18 12:56:14 UTC
(In reply to Reinhard Max from comment #12)
> The regression test failures with llvm12 are full of messages like this:
> [ 1322s] +ERROR:  failed to JIT module: Added modules have incompatible data
> layouts: E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64 (module) vs
> E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64 (jit)
The difference between both being that the jit data layout has an additional v128:64. This specifies the alignment of 128-bit vectors as 64 bits, whereas the module data layout doesn't specify alignment for any vector type.

It would seem strange if LLVM would randomly choose different data layouts for the pre-compiled module and jit code, more likely it's being invoked with different flags. I'd guess that the jit compilation enables some vector extensions, but regular modules are compiled without that? In src/backend/jit/llvm/llvmjit.c there is this comment:

	/*
	 * We want the generated code to use all available features. Therefore
	 * grab the host CPU string and detect features of the current CPU. The
	 * latter is needed because some CPU architectures default to enabling
	 * features not all CPUs have (weird, huh).
	 */

Presumably s390x doesn't regularly have a vector type, but the CPUs running the  tests have one? I asked on LLVM IRC whether it's a valid expectation that the data layout is independent of selected CPU features, and they said yes. Someone remembered that a similar problem was pointed out previously for zSystems. So this looks like a bug in LLVM. I'll see if I can file something.

> Aaron and Michael: Do you have any ideas of what's going wrong here? Or
> shall I just switch back to llvm/clang 11 for now, because version 12 is not
> yet stable enough?
I don't have a better idea right now. Though it seems that the feature-dependent data layout isn't really new: the commit is from 2015. (https://github.com/llvm/llvm-project/commit/ce4c10958502b8f852dd88496272d262345a2513)

I have no idea what makes this surface with LLVM 12.
Comment 14 Reinhard Max 2021-05-18 13:33:11 UTC
Thanks for your help, Aaron. The question is now whether we wait for an upstream fix for LLVM or work around the by using LLVM 11 on s390x, so that the PostgreSQL packages are usable again until LLVM 12 has been fixed?
Comment 15 Aaron Puchert 2021-05-18 14:54:18 UTC
(In reply to Aaron Puchert from comment #13)
> I have no idea what makes this surface with LLVM 12.
It seems that Postgres is explicitly setting the data layout from the modules, and maybe with LLVM 12 that is augmented/superimposed by the default layout derived from target triple and features? Though I can't find anything in the log.

(In reply to Reinhard Max from comment #14)
> Thanks for your help, Aaron. The question is now whether we wait for an
> upstream fix for LLVM or work around the by using LLVM 11 on s390x, so that
> the PostgreSQL packages are usable again until LLVM 12 has been fixed?
Using LLVM 11 for now (perhaps only on s390x) seems like the best workaround.
Comment 16 Sarah Kriesch 2021-05-19 15:34:37 UTC
@Aaron One hint: We can forward bug reports for IBM via the openSUSE Bugzilla, too. I believe that upstream bug reports require more time than the internal routing process.
Comment 17 Aaron Puchert 2021-05-19 21:46:58 UTC
(In reply to Sarah Kriesch from comment #16)
> @Aaron One hint: We can forward bug reports for IBM via the openSUSE
> Bugzilla, too. I believe that upstream bug reports require more time than
> the internal routing process.
I've got a quick reply from the SystemZ backend maintainer, who seems to be working for IBM. We just didn't get to an agreement so far. The question is whether the ABI should depend on the feature level, which I think it should not.

Do you happen to know about plans to switch SLE/openSUSE to a default architecture level of z13? That would be cutting the Gordian knot.

Thanks anyway for offering help, if this doesn't work out we might come back to your offer.
Comment 18 OBSbugzilla Bot 2021-05-20 08:00:07 UTC
This is an autogenerated message for OBS integration:
This bug (1185952) was mentioned in
https://build.opensuse.org/request/show/894524 Factory / postgresql13
https://build.opensuse.org/request/show/894525 Factory / postgresql12
Comment 19 Reinhard Max 2021-05-20 08:53:34 UTC
Workaround submitted, adjusting the Subject and reassigning to the maintainer of llvm.
Feel free to assign back to me once llvm has been fixed for reverting the workaround.
Comment 20 openQA Review 2021-06-04 05:18:28 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: textmode-server
https://openqa.opensuse.org/tests/1749908

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed
Comment 21 Sarah Kriesch 2021-07-12 09:28:03 UTC
The Bug with LLVM-jit has happened at Fedora, too.
There was a discussion about this bug on the PostgreSQL mailinglist:
https://www.postgresql.org/message-id/fc131116-baef-66a5-362c-b9e1a2b1ebec%40redhat.com

That should be fixed in the next version (response by IBM).
Comment 22 Reinhard Max 2021-07-12 11:15:50 UTC
Thanks for the update, Sarah.

Please clarify whether IBM was talking about the next PostgreSQL version or the next LLVM version that should fix this, as I don't see any IBM statement in the thread you linked to.

BTW, I expect the next round of PostgreSQL minor releases in about a month, but AFAICS so far no fix for this issue has been committed.
Comment 23 Sarah Kriesch 2021-07-12 12:32:52 UTC
The next Postgre version has been meant.

Here is the "German" statement by Andreas Krebbel (Compiler Product Owner):
"Das wird ein temporäres Problem für einige Zeit sein, welches sich aber von selbst erledigen wird
sobald alle Distros mit einem z13 default bauen. Dann werden auch die statischen Postgres Anteile
die Z Hardware Vektor-ABI nutzen.

Ich denke das Problem kann man jetzt nicht wirklich "fixen". Vermutlich kann man nur versuchen in
dem JIT Part das VX feature auszumaskieren. Damit verliert man natürlich Performance in diesen
Codeteilen, was aber hoffentlich nicht von Dauer ist."
Comment 24 Aaron Puchert 2021-07-12 22:49:01 UTC
(In reply to Sarah Kriesch from comment #21)
> The Bug with LLVM-jit has happened at Fedora, too.
> There was a discussion about this bug on the PostgreSQL mailinglist:
> https://www.postgresql.org/message-id/fc131116-baef-66a5-362c-
> b9e1a2b1ebec%40redhat.com
Thanks for the link. And apparently there is even a patch that might work for now: https://www.postgresql.org/message-id/attachment/122331/0001-jit-Workaround-potential-datalayout-mismatch-on-s390.patch. Reinhard, could you try this out?
Comment 25 Reinhard Max 2021-07-13 07:23:40 UTC
It looks like upstream wasn't completely satisfied with it yet and hence hasn't commited it so far. Therefore I'd prefer to stick with our current workaround to keep using llvm/clang 11 for s390x. Or do you see an urgent need to go for llvm12 within the next weeks?
Comment 26 Aaron Puchert 2021-07-13 22:42:16 UTC
(In reply to Reinhard Max from comment #25)
> It looks like upstream wasn't completely satisfied with it yet and hence
> hasn't commited it so far.
I was reading this as mostly stylistic concerns, but maybe I've overlooked something.

> Or do you see an urgent need to go for llvm12 within the next weeks?
It's not urgent, we'll have to leave llvm11 in the distribution for some time. Some packages are even on llvm{7,9,10}. But all the older LLVMs are out of maintenance, I'm basically just fixing the occasional build failure.

Hope you don't mind that I'm assigning this back to you. It is a bug in LLVM in my view, but without the zSystems backend maintainer agreeing to my concerns there is nothing I can do. So we'll have to patch this out in Postgres.
Comment 27 Reinhard Max 2021-07-14 06:30:17 UTC
OK. I'll wait for the next PostgreSQL minor version update and add the patch then, if upstream hasn't already integrated it.
Comment 28 Reinhard Max 2021-08-30 16:35:39 UTC
The fix made it into the latest 11.13, 12.8 and 13.4 releases of PostgreSQL, so I can remove the workaround to fall back to llvm11.
Comment 29 Reinhard Max 2021-08-31 11:12:53 UTC
Unfortunately that fix[1] seems to be about some other change in llvm13 that affects PostgreSQL as well, but building against llvm12 still fails on s390x.

So I'll go ahead and apply the the patch linked in comment 24, given that there was no progress in the respective thread since April.

[1] https://github.com/postgres/postgres/commit/d9c05a9ec49399a45d30acacac748625922cbe40
Comment 30 Sarah Kriesch 2021-09-01 09:51:55 UTC
Hi Reinhard,

can you tell "which error messages" are happening (or give me a link to the log), that I can look what is happening there, please?

2 weeks ago I did a small change in our project config of ZSystems because filesystems was not buildable with the existing config. I would be surprised about the incompatibility of all LLVM versions with PostgreSQL. If I know the bugs, I would look to Fedora as my first step, how they are doing their workarounds then. That is the upstream development Linux distribution (with the highest priority) of IBM. Therefore, that is the place for testing upstream solution implementation (besides of Enterprise distributions).
Comment 31 Reinhard Max 2021-09-01 10:33:04 UTC
Hi Sarah,

I am not sure what you mean by "there"?

I already have a fix for this bug here, which is the patch I linked in comment 29 that applies unchanged to PostgreSQL 13 and can easily be backported to versions 12 and 11. Older versions have no support for LLVM.

As for the LLVM13 fix that upstream made in the latest PostgreSQL releases, that one does not seem to be specific for s390x, and this upstream commit seems to be a good starting point for further investigation:

https://github.com/postgres/postgres/commit/d9c05a9ec49399a45d30acacac748625922cbe40
Comment 32 Aaron Puchert 2021-09-01 22:08:42 UTC
Just FYI, I'm staging release candidates of LLVM 13 in [1], I could branch over Postgres if you're curious whether it works out or not.

[1] https://build.opensuse.org/project/show/home:aaronpuchert:llvm-next
Comment 35 OBSbugzilla Bot 2021-09-08 12:40:11 UTC
This is an autogenerated message for OBS integration:
This bug (1185952) was mentioned in
https://build.opensuse.org/request/show/917538 Factory / postgresql10
https://build.opensuse.org/request/show/917540 Factory / postgresql11
https://build.opensuse.org/request/show/917541 Factory / postgresql12
https://build.opensuse.org/request/show/917542 Factory / postgresql13
Comment 36 Swamp Workflow Management 2021-09-16 22:20:24 UTC
# maintenance_jira_update_notice
SUSE-SU-2021:3119-1: An update that solves one vulnerability and has three fixes is now available.

Category: security (moderate)
Bug References: 1179945,1185952,1187751,1189748
CVE References: CVE-2021-3677
JIRA References: 
Sources used:
SUSE Linux Enterprise Software Development Kit 12-SP5 (src):    postgresql12-12.8-3.18.2
SUSE Linux Enterprise Server 12-SP5 (src):    postgresql12-12.8-3.18.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 37 Swamp Workflow Management 2021-09-16 22:23:21 UTC
# maintenance_jira_update_notice
SUSE-SU-2021:3120-1: An update that solves one vulnerability and has three fixes is now available.

Category: security (moderate)
Bug References: 1179945,1185952,1187751,1189748
CVE References: CVE-2021-3677
JIRA References: 
Sources used:
SUSE Linux Enterprise Software Development Kit 12-SP5 (src):    postgresql13-13.4-3.12.2
SUSE Linux Enterprise Server 12-SP5 (src):    postgresql13-13.4-3.12.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 38 Sarah Kriesch 2021-09-20 13:25:46 UTC
I am happy, that openQA is working again for s390x.
But we have got a new failure for PostgreSQL11, because it can not be built successfully with LLVM.

/usr/lib64/gcc/s390x-suse-linux/11/../../../../s390x-suse-linux/bin/ld: @GLIBCXX_3.4.11: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so
 /usr/lib64/gcc/s390x-suse-linux/11/../../../../s390x-suse-linux/bin/ld: /usr/lib64/libLLVM.so: error adding symbols: bad value
 collect2: error: ld returned 1 exit status
make[2]: *** [../../../../src/Makefile.shlib:309: llvmjit.so] Error 1

Should I create a new bugreport for that? That is a result of this bug reference.
Comment 39 Reinhard Max 2021-09-20 16:25:23 UTC
I've seen this happen on all three versions of PostgreSQL that support LLVM (11, 12 and 13), but only on s390x and only in about 4 out of 5 build runs (within the short period over which I monitored it).

I think this should be handled in a separate bug report, because the bug at hand got fixed and the reason for these new failures likely lies outside of the PostgreSQL packages.
Comment 40 Aaron Puchert 2021-09-20 22:30:08 UTC
(In reply to Reinhard Max from comment #39)
> I've seen this happen on all three versions of PostgreSQL that support LLVM
> (11, 12 and 13), but only on s390x and only in about 4 out of 5 build runs
> (within the short period over which I monitored it).

Since it comes from ld (or collect2?) and that's an LTO link, I suppose it might be a race condition. I agree, it should be a separate bug. Maybe add Michael Matz for binutils and Martin Liska for GCC LTO. IBM tends to have weaker memory models, and that race might just not materialize with the stronger model of x86.
Comment 41 Michael Matz 2021-09-21 13:11:50 UTC
(In reply to Aaron Puchert from comment #40)
> (In reply to Reinhard Max from comment #39)
> > I've seen this happen on all three versions of PostgreSQL that support LLVM
> > (11, 12 and 13), but only on s390x and only in about 4 out of 5 build runs
> > (within the short period over which I monitored it).
> 
> Since it comes from ld (or collect2?) and that's an LTO link, I suppose it
> might be a race condition. I agree, it should be a separate bug. Maybe add
> Michael Matz for binutils and Martin Liska for GCC LTO. IBM tends to have
> weaker memory models, and that race might just not materialize with the
> stronger model of x86.

I was involved for that already.  I never was able to reproduce it with a local build (on s390x of course), with none of the postgres packages.  And triggering a rebuild of an affected package, even if it got to the same build machine, sometime
also makes it build through (just to fail on the next rebuilds again).  So, it's most definitely a race somewhere, but without being at least somewhat locally reproducable it's hopeless.
Comment 42 Reinhard Max 2021-09-21 15:15:47 UTC
OK, let's track the linking issue in bug 1190740.
Comment 43 Swamp Workflow Management 2021-09-29 19:19:26 UTC
SUSE-SU-2021:3256-1: An update that solves one vulnerability and has three fixes is now available.

Category: security (moderate)
Bug References: 1179945,1185952,1187751,1189748
CVE References: CVE-2021-3677
JIRA References: 
Sources used:
SUSE Linux Enterprise Module for Server Applications 15-SP2 (src):    postgresql12-12.8-8.23.2
SUSE Linux Enterprise Module for Legacy Software 15-SP3 (src):    postgresql12-12.8-8.23.2
SUSE Linux Enterprise Module for Basesystem 15-SP2 (src):    postgresql12-12.8-8.23.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 44 Swamp Workflow Management 2021-09-29 19:23:04 UTC
openSUSE-SU-2021:3256-1: An update that solves one vulnerability and has three fixes is now available.

Category: security (moderate)
Bug References: 1179945,1185952,1187751,1189748
CVE References: CVE-2021-3677
JIRA References: 
Sources used:
openSUSE Leap 15.3 (src):    postgresql12-12.8-8.23.2
Comment 45 Swamp Workflow Management 2021-09-29 19:24:47 UTC
SUSE-SU-2021:3255-1: An update that solves one vulnerability and has three fixes is now available.

Category: security (moderate)
Bug References: 1179945,1185952,1187751,1189748
CVE References: CVE-2021-3677
JIRA References: 
Sources used:
SUSE Linux Enterprise Module for Server Applications 15-SP3 (src):    postgresql13-13.4-5.16.1, postgresql13-13.4-5.16.2
SUSE Linux Enterprise Module for Server Applications 15-SP2 (src):    postgresql13-13.4-5.16.1, postgresql13-13.4-5.16.2
SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP3 (src):    postgresql13-13.4-5.16.2
SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP2 (src):    postgresql13-13.4-5.16.2
SUSE Linux Enterprise Module for Basesystem 15-SP3 (src):    postgresql13-13.4-5.16.1, postgresql13-13.4-5.16.2
SUSE Linux Enterprise Module for Basesystem 15-SP2 (src):    postgresql13-13.4-5.16.1, postgresql13-13.4-5.16.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 46 Swamp Workflow Management 2021-09-29 19:26:16 UTC
openSUSE-SU-2021:3255-1: An update that solves one vulnerability and has three fixes is now available.

Category: security (moderate)
Bug References: 1179945,1185952,1187751,1189748
CVE References: CVE-2021-3677
JIRA References: 
Sources used:
openSUSE Leap 15.3 (src):    postgresql13-13.4-5.16.1, postgresql13-13.4-5.16.2
Comment 47 Swamp Workflow Management 2021-10-06 22:20:14 UTC
SUSE-RU-2021:3317-1: An update that has four recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1179945,1185952,1187751,1190177
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Module for Server Applications 15-SP2 (src):    postgresql10-10.18-8.38.1
SUSE Linux Enterprise Module for Legacy Software 15-SP3 (src):    postgresql10-10.18-8.38.1
SUSE Linux Enterprise Module for Basesystem 15-SP2 (src):    postgresql10-10.18-8.38.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 48 Swamp Workflow Management 2021-10-06 22:27:37 UTC
openSUSE-RU-2021:3317-1: An update that has four recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1179945,1185952,1187751,1190177
CVE References: 
JIRA References: 
Sources used:
openSUSE Leap 15.3 (src):    postgresql10-10.18-8.38.1
Comment 49 Swamp Workflow Management 2021-10-12 16:53:41 UTC
openSUSE-RU-2021:1351-1: An update that has four recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1179945,1185952,1187751,1190177
CVE References: 
JIRA References: 
Sources used:
openSUSE Leap 15.2 (src):    postgresql10-10.18-lp152.2.24.1
Comment 51 Swamp Workflow Management 2021-10-20 16:21:01 UTC
SUSE-SU-2021:3481-1: An update that solves two vulnerabilities and has 8 fixes is now available.

Category: security (important)
Bug References: 1178961,1179765,1179945,1183118,1183168,1185924,1185925,1185952,1187751,1190177
CVE References: CVE-2021-32027,CVE-2021-32028
JIRA References: 
Sources used:
SUSE OpenStack Cloud Crowbar 9 (src):    postgresql10-10.18-4.19.6
SUSE OpenStack Cloud Crowbar 8 (src):    postgresql10-10.18-4.19.6
SUSE OpenStack Cloud 9 (src):    postgresql10-10.18-4.19.6
SUSE OpenStack Cloud 8 (src):    postgresql10-10.18-4.19.6
SUSE Linux Enterprise Software Development Kit 12-SP5 (src):    postgresql10-10.18-4.19.6
SUSE Linux Enterprise Server for SAP 12-SP4 (src):    postgresql10-10.18-4.19.6
SUSE Linux Enterprise Server for SAP 12-SP3 (src):    postgresql10-10.18-4.19.6
SUSE Linux Enterprise Server 12-SP5 (src):    postgresql10-10.18-4.19.6
SUSE Linux Enterprise Server 12-SP4-LTSS (src):    postgresql10-10.18-4.19.6
SUSE Linux Enterprise Server 12-SP3-LTSS (src):    postgresql10-10.18-4.19.6
SUSE Linux Enterprise Server 12-SP3-BCL (src):    postgresql10-10.18-4.19.6
SUSE Linux Enterprise Server 12-SP2-BCL (src):    postgresql10-10.18-4.19.6
HPE Helion Openstack 8 (src):    postgresql10-10.18-4.19.6

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 52 Ihno Krumreich 2021-10-29 14:44:11 UTC
Verifed