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 по дате отправления: