On Thu, Aug 15, 2019 at 5:49 PM Tom Lane wrote:
> So that leads to the thought that "the infinite_recurse test is fine
> if it runs by itself, but it tends to fall over if there are
> concurrently-running backends". I have absolutely no idea how that
> would happen on anything that passes for a
Thomas Munro writes:
> Here's another crash like that.
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=cavefish=2019-07-13%2003%3A49%3A38
> 2019-07-13 04:01:23.437 UTC [9365:70] LOG: server process (PID 12951)
> was terminated by signal 11: Segmentation fault
> 2019-07-13 04:01:23.437
On Tue, May 21, 2019 at 9:22 AM Mark Wong wrote:
> Andrew let me know I need to get on v10. I've upgraded demoiselle, and
> am trying to work through the rest now...
Here's another crash like that.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=cavefish=2019-07-13%2003%3A49%3A38
On Mon, May 20, 2019 at 12:15:49PM -0700, Mark Wong wrote:
> On Sun, May 19, 2019 at 02:38:26PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2019-05-14 08:31:37 -0700, Mark Wong wrote:
> > > Ok, I have this added to everyone now.
> > >
> > > I think I also have caught up on this thread, but
On Sun, May 19, 2019 at 02:38:26PM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-14 08:31:37 -0700, Mark Wong wrote:
> > Ok, I have this added to everyone now.
> >
> > I think I also have caught up on this thread, but let me know if I
> > missed anything.
>
> I notice
>
Hi,
On 2019-05-14 08:31:37 -0700, Mark Wong wrote:
> Ok, I have this added to everyone now.
>
> I think I also have caught up on this thread, but let me know if I
> missed anything.
I notice
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=demoiselle=2019-05-19%2014%3A22%3A23
failed
On Fri, May 10, 2019 at 05:26:43PM -0400, Andrew Dunstan wrote:
>
> On 5/10/19 3:35 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2019-05-10 11:38:57 -0400, Tom Lane wrote:
> >>> I am wondering if, somehow, the stack depth limit seen by the postmaster
> >>> sometimes doesn't apply to its
On Tue, May 14, 2019 at 10:52:07AM -0400, Tom Lane wrote:
> Mark Wong writes:
> > Slowly catching up on my collection of ppc64le animals...
>
> Oh, btw ... you didn't answer my question from before: are these animals
> all running on a common platform (and if so, what is that), or are they
>
On Fri, May 10, 2019 at 11:27:07AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-10 11:38:57 -0400, Tom Lane wrote:
> > Core was generated by `postgres: debian regression [local] SELECT
> > '.
> > Program terminated with signal SIGSEGV, Segmentation fault.
Mark Wong writes:
> Slowly catching up on my collection of ppc64le animals...
Oh, btw ... you didn't answer my question from before: are these animals
all running on a common platform (and if so, what is that), or are they
really different hardware? If they're all VMs on one machine then it
Mark Wong writes:
> The following I've enabled force_parallel_mode for HEAD, 11, 10, and
> 9.6:
Thanks Mark!
In theory, the stack trace we now have from shoveler proves that parallel
mode has nothing to do with this, because the crash happens during
planning (specifically, inlining SQL
On Fri, May 03, 2019 at 11:45:33AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-03 10:08:59 -0700, Mark Wong wrote:
> > Ok, I think I have gdb installed now...
>
> Thanks! Any chance you could turn on force_parallel_mode for the other
> branches it applies to too? Makes it easier to figure
On 5/12/19 4:57 AM, Michael Paquier wrote:
> On Fri, May 10, 2019 at 05:26:43PM -0400, Andrew Dunstan wrote:
>> I think we'll need to write that as:
>>
>> print $handle 'p $_siginfo',"\n";
>>
>> As you have it written perl will try to interpolate a variable called
>> $_siginfo.
> Anything in
On Fri, May 10, 2019 at 05:26:43PM -0400, Andrew Dunstan wrote:
> I think we'll need to write that as:
>
> print $handle 'p $_siginfo',"\n";
>
> As you have it written perl will try to interpolate a variable called
> $_siginfo.
Anything in double quotes with a dollar sign would be
On 5/10/19 3:35 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2019-05-10 11:38:57 -0400, Tom Lane wrote:
>>> I am wondering if, somehow, the stack depth limit seen by the postmaster
>>> sometimes doesn't apply to its children. That would be pretty wacko
>>> kernel behavior, especially if
Andres Freund writes:
> On 2019-05-10 11:38:57 -0400, Tom Lane wrote:
>> I am wondering if, somehow, the stack depth limit seen by the postmaster
>> sometimes doesn't apply to its children. That would be pretty wacko
>> kernel behavior, especially if it's only intermittently true.
>> But we're
Hi,
On 2019-05-10 11:38:57 -0400, Tom Lane wrote:
> Core was generated by `postgres: debian regression [local] SELECT
> '.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 sysmalloc (nb=8208, av=0x3fff916e0d28 ) at malloc.c:2748
> 2748
We just got another one of these, on yet another member of Mark's
ppc64 armada:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=shoveler=2019-05-10%2014%3A04%3A34
Now we have a stack trace (thanks Mark!), but it is pretty unsurprising:
Core was generated by `postgres: debian regression
Mark Wong writes:
> On Thu, May 02, 2019 at 11:45:34AM -0400, Tom Lane wrote:
>> While we're looking at this --- Mark, if you could install gdb
>> on your buildfarm hosts, that would be really handy. I think that's
>> the only extra thing the buildfarm script needs to extract stack
>> traces
On Thu, May 02, 2019 at 11:45:34AM -0400, Tom Lane wrote:
> Andres Freund writes:
> > Hm, I just noticed:
> >'HEAD' => [
> >'force_parallel_mode =
> > regress'
> >
Andres Freund writes:
> Hm, I just noticed:
>'HEAD' => [
>'force_parallel_mode =
> regress'
> ]
Oooh, I didn't see that.
> on all those animals. So it's
Hi,
On 2019-05-02 11:02:03 -0400, Tom Lane wrote:
> In the past week, four different buildfarm members have shown
> non-reproducing segfaults in the "select infinite_recurse()"
> test case, rather than the expected detection of stack overrun
> before we get to the point of a segfault.
I was just
22 matches
Mail list logo
