On Mon, Feb 22, 2016 at 11:02 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > 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.
Foreign tables are supposed to be categorically excluded from parallelism. Not sure why that's not working in this instance. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
