From: | Chris Travers <chris(dot)travers(at)adjust(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Funny hang on PostgreSQL 10 during parallel index scan on slave |
Date: | 2018-09-05 16:40:36 |
Message-ID: | CAN-RpxArVPOVXVqwbUCeShr1u4yWAa+pNv=dc8nSK3sqDnqCqw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Yep, Maybe we should check for signals there.
On Wed, Sep 5, 2018 at 5:27 PM Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
wrote:
> On Wed, Sep 5, 2018 at 8:23 AM Chris Travers <chris(dot)travers(at)adjust(dot)com>
> wrote:
> > 1. The query is in a parallel index scan or similar
> > 2. A process is executing a parallel plan and allocating a significant
> chunk of memory (2MB for example) in dynamic shared memory.
> > 3. The startup process goes into a loop where it sends a sigusr1,
> sleeps 5m, and sends another sigusr1 etc.
> > 4. The sigusr1 aborts the system call, which is then retried.
> > 5. Because the system call takes more than 5ms, we end up in an endless
> loop
>
> Do you mean this loop in dsm_impl_posix_resize() is getting
> interrupted constantly and never completing?
>
> /* We may get interrupted, if so just retry. */
> do
> {
> rc = posix_fallocate(fd, 0, size);
> } while (rc == EINTR);
>
> --
> Thomas Munro
> http://www.enterprisedb.com
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-09-05 16:42:06 | Re: Bug fix for glibc broke freebsd build in REL_11_STABLE |
Previous Message | amul sul | 2018-09-05 16:28:15 | Re: [HACKERS] Bug in to_timestamp(). |