Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas writes: > On Fri, Mar 4, 2016 at 11:17 AM, Tom Lane wrote: >> Huh? Parallel workers are read-only; what would they be doing sending >> any of these messages? > Mumble. I have no idea what's happening here. OK, after inserting a bunch of

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Fri, Mar 4, 2016 at 11:17 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote: >>> Well, that would make the function more complicated, but maybe it's a >>> better answer. On the other

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas writes: > On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote: >> Well, that would make the function more complicated, but maybe it's a >> better answer. On the other hand, we know that the stats updates are >> delivered in a deterministic

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas wrote: > I'm not sure if that's actually true with parallel mode. I'm pretty > sure the earlier workers will have terminated before the later ones > start, but is that enough to guarantee that the stats collector sees > the messages in that order? Um. So if you have two queries

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> That's what it looks like to me. I now think that the apparent >>> connection to parallel query is a mirage. The reason we've only >>> seen a few cases

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Fri, Mar 4, 2016 at 10:33 AM, Tom Lane wrote: > Robert Haas writes: >> Sure. If you have an idea what the right thing to do is, please go >> ahead. > > Yeah, I'll modify the patch and commit sometime later today. OK, if you're basing that on the

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Alvaro Herrera writes: > Tom Lane wrote: >> That's what it looks like to me. I now think that the apparent >> connection to parallel query is a mirage. The reason we've only >> seen a few cases so far is that the flapping test is new: it >> wad added in commit

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Tom Lane wrote: > Robert Haas writes: > > Sure. If you have an idea what the right thing to do is, please go > > ahead. > > Yeah, I'll modify the patch and commit sometime later today. > > > I actually don't have a clear idea what's going on here. I > > guess it's that

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas writes: > Sure. If you have an idea what the right thing to do is, please go > ahead. Yeah, I'll modify the patch and commit sometime later today. > I actually don't have a clear idea what's going on here. I > guess it's that the wait_for_stats() guarantees

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Fri, Mar 4, 2016 at 12:46 AM, Tom Lane wrote: > Robert Haas writes: >> A couple of my colleagues have been looking into this. It's not >> entirely clear to me what's going on here yet, but it looks like the >> stats get there if you wait long

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas writes: > A couple of my colleagues have been looking into this. It's not > entirely clear to me what's going on here yet, but it looks like the > stats get there if you wait long enough. Rahila Syed was able to > reproduce the problem and says that the

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Thu, Mar 3, 2016 at 1:10 AM, Tom Lane wrote: > Noah Misch writes: >> I've modified buildfarm member mandrill to use force_parallel_mode=regress >> and >> max_parallel_degree=5; a full run passes. We'll now see if it intermittently >> fails the stats

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Noah Misch writes: > I've modified buildfarm member mandrill to use force_parallel_mode=regress and > max_parallel_degree=5; a full run passes. We'll now see if it intermittently > fails the stats test, like Tom witnessed: >

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Sat, Feb 27, 2016 at 7:05 PM, Noah Misch wrote: > On Fri, Feb 26, 2016 at 04:16:58PM +0530, Robert Haas wrote: >> Committed these patches after revising the comment you wrote and >> adding documentation. > > I've modified buildfarm member mandrill to use

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Fri, Feb 26, 2016 at 04:16:58PM +0530, Robert Haas wrote: > Committed these patches after revising the comment you wrote and > adding documentation. I've modified buildfarm member mandrill to use force_parallel_mode=regress and max_parallel_degree=5; a full run passes. We'll now see if it

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Wed, Feb 24, 2016 at 12:59 PM, Thomas Munro wrote: > On Wed, Feb 24, 2016 at 5:48 PM, Thomas Munro > wrote: >> Here is a first pass at that. [...] > > On Wed, Feb 24, 2016 at 1:23 AM, Robert Haas wrote: >>

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Wed, Feb 24, 2016 at 5:48 PM, Thomas Munro wrote: > Here is a first pass at that. [...] On Wed, Feb 24, 2016 at 1:23 AM, Robert Haas wrote: > file_fdw is parallel-safe, ... And here is a patch to apply on top of the last one, to make

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Tue, Feb 23, 2016 at 6:45 PM, Robert Haas wrote: > On Tue, Feb 23, 2016 at 2:06 AM, Tom Lane wrote: >> Robert Haas writes: Foreign tables are supposed to be categorically excluded from parallelism. Not sure why

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Tue, Feb 23, 2016 at 11:47 AM, Tom Lane wrote: > Even if there were, it would not fix this bug, because AFAICS the only > thing that set_rel_consider_parallel is chartered to do is set the > per-relation consider_parallel flag. The failure that is happening in > that

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas writes: > On Tue, Feb 23, 2016 at 2:06 AM, Tom Lane wrote: >> Robert Haas writes: >>> Foreign tables are supposed to be categorically excluded from >>> parallelism. Not sure why that's not working in this instance.

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Tue, Feb 23, 2016 at 2:06 AM, Tom Lane wrote: > Robert Haas writes: >>> Foreign tables are supposed to be categorically excluded from >>> parallelism. Not sure why that's not working in this instance. > > BTW, I wonder where you think that's

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Thomas Munro writes: > On Tue, Feb 23, 2016 at 4:03 AM, Tom Lane wrote: >> I've not looked at the test case to see if this is exactly what's >> going wrong, but it's pretty easy to see how there might be a problem: >> consider a STABLE

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Tue, Feb 23, 2016 at 4:03 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Feb 22, 2016 at 11:02 AM, Thomas Munro >> wrote: >>> The postgres_fdw failure is a visibility-of-my-own-uncommitted-work >>> problem. The

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas writes: >> Foreign tables are supposed to be categorically excluded from >> parallelism. Not sure why that's not working in this instance. BTW, I wonder where you think that's supposed to be enforced, because I sure can't find any such logic. I suppose that

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas writes: > On Mon, Feb 22, 2016 at 11:02 AM, Thomas Munro > wrote: >> 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

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Mon, Feb 22, 2016 at 11:02 AM, Thomas Munro wrote: > On Tue, Feb 16, 2016 at 12:12 PM, Noah Misch wrote: >> On Mon, Feb 15, 2016 at 06:07:48PM -0500, Tom Lane wrote: >>> Noah Misch writes: >>> > I configured a copy of

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Tue, Feb 16, 2016 at 12:12 PM, Noah Misch wrote: > On Mon, Feb 15, 2016 at 06:07:48PM -0500, Tom Lane wrote: >> Noah Misch writes: >> > I configured a copy of animal "mandrill" that way and launched a test run. >> > The postgres_fdw suite failed as

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On 02/15/2016 07:57 PM, Tom Lane wrote: Noah Misch writes: On Mon, Feb 15, 2016 at 07:31:40PM -0500, Robert Haas wrote: Oh, crap. I didn't realize that TEMP_CONFIG didn't affect the contrib test suites. Is there any reason for that, or is it just kinda where we ended

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Noah Misch writes: > On Mon, Feb 15, 2016 at 07:31:40PM -0500, Robert Haas wrote: >> Oh, crap. I didn't realize that TEMP_CONFIG didn't affect the contrib >> test suites. Is there any reason for that, or is it just kinda where >> we ended up? > To my knowledge, it's just the

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Mon, Feb 15, 2016 at 07:31:40PM -0500, Robert Haas wrote: > On Mon, Feb 15, 2016 at 5:52 PM, Noah Misch wrote: > > On Mon, Feb 08, 2016 at 02:49:27PM -0500, Robert Haas wrote: > >> force_parallel_mode=regress > >> max_parallel_degree=2 > >> > >> And then run this: make

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Mon, Feb 15, 2016 at 5:52 PM, Noah Misch wrote: > On Mon, Feb 08, 2016 at 02:49:27PM -0500, Robert Haas wrote: >> Well, what I've done is push into the buildfarm code that will allow >> us to do *the most exhaustive* testing that I know how to do in an >> automated fashion.

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Mon, Feb 15, 2016 at 06:07:48PM -0500, Tom Lane wrote: > Noah Misch 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

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Noah Misch 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