Re: Funny hang on PostgreSQL 10 during parallel index scan on slave
От | Thomas Munro |
---|---|
Тема | Re: Funny hang on PostgreSQL 10 during parallel index scan on slave |
Дата | |
Msg-id | CAEepm=1fg5Sm92WQB0XjAnsCkMjRges0bxs-2AwM4m9CwhHGSw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Funny hang on PostgreSQL 10 during parallel index scan on slave (Chris Travers <chris.travers@adjust.com>) |
Ответы |
Re: Funny hang on PostgreSQL 10 during parallel index scan on slave
|
Список | pgsql-hackers |
On Wed, Sep 5, 2018 at 10:13 AM Chris Travers <chris.travers@adjust.com> wrote: > On Wed, Sep 5, 2018 at 6:55 PM Andres Freund <andres@anarazel.de> wrote: >> > On Wed, Sep 5, 2018 at 6:40 PM Chris Travers <chris.travers@adjust.com> >> > wrote: >> > >> 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); >> > >> >> >> Probably worthwile to check that the dsm code is properly robust if >> errors are thrown from within here. Yeah, currently dsm_impl_posix_resize() returns and lets dsm_impl_posix() clean up (close(), shm_unlink()) before raising errors. We can't just let CHECK_FOR_INTERRUPTS() take a non-local exit. Some refactoring involving PG_TRY()/PG_CATCH() may be the simplest way forward. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: