On Tue, Feb 16, 2016 at 12:12 PM, Noah Misch <n...@leadboat.com> wrote: > On Mon, Feb 15, 2016 at 06:07:48PM -0500, Tom Lane wrote: >> Noah Misch <n...@leadboat.com> writes: >> > I configured a copy of animal "mandrill" that way and launched a test run. >> > The postgres_fdw suite failed as attached. A manual "make -C contrib >> > installcheck" fails the same way on a ppc64 GNU/Linux box, but it passes on >> > x86_64 and aarch64. Since contrib test suites don't recognize TEMP_CONFIG, >> > check-world passes everywhere. >> >> Hm, is this with or without the ppc-related atomics fix you just found? > > Without those. The ppc64 GNU/Linux configuration used gcc, though, and the > atomics change affects xlC only. Also, the postgres_fdw behavior does not > appear probabilistic; it failed twenty times in a row.
The postgres_fdw failure is a visibility-of-my-own-uncommitted-work problem. The first command in a transaction updates a row via an FDW, and then the SELECT expects to see the effects, but when run in a background worker it creates a new FDW connection that can't see the uncommitted UPDATE. I wonder if parallelism of queries involving an FDW should not be allowed if your transaction has written through the FDW. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
