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 debug logging I have figured out what is
hap
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 hand, we know that the stats updates are
>>> delivered in a determ
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 order, so why not simply replace the
>> existing
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 that
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 so far is that the flapping test is new: it
>>
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 patch I sent upthread, please credit
Rahila Sy
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 d42358efb16cc811, on 20 Feb.
> It
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 the wait_for_stats() gua
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 that the stats message
>
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 enough. Rahila Syed was able to
>> reproduce the
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 attached patch fixes it. But
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 test, like Tom witnessed:
>> http://www.po
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:
> http://www.postgresql.org/message-id/30385.1456077...@sss.pgh.pa.us
htt
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 force_parallel_mode=regress and
> max_pa
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 inte
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:
>> file_fdw is parallel-safe, ...
>
> And here is a patch to apply on top of the last one,
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 file_fdw
return true. But does it really work correctly u
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 that's not working in this instance.
>>
>> BTW, I wonder where you thin
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 regression test with force
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.
>> BTW, I wonder where you think that's supposed to be enforced, be
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 supposed to be enforced, because
> I sure can't fin
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 user-defined function that does a SELECT from a foreign
>> ta
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 first command in a transaction updates a row via an FDW,
>>> and then the S
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 has_parallel_hazard() wou
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 SELECT expects to see the effects, but when run in a
>> ba
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 animal "mandrill" that way and launched a test run.
>>> > The postgres_fdw
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 attached. A manual "make -C contrib
>> > ins
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 up?
To my knowledge,
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 undesirable place w
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 check-world
> >> TEMP_CO
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. Which is to create a
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 ppc64 GNU/Linux box, but
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 contrib test suites don
33 matches
Mail list logo
