Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory
От | Heikki Linnakangas |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory |
Дата | |
Msg-id | 48074A96.6070400@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit could leave shared memory (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Repair two places where
SIGTERM exit couldleave shared memory
Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory |
Список | pgsql-hackers |
Alvaro Herrera wrote: > Tom Lane wrote: > >> Also use this method >> for createdb cleanup --- that wasn't a shared-memory-corruption problem, >> but SIGTERM abort of createdb could leave orphaned files lying around. > > I wonder if we could use this mechanism for cleaning up in case of > failed CLUSTER, REINDEX or the like. I think these can leave dangling > files around. They do clean up on abort or SIGTERM. If you experience a sudden power loss, or kill -9 while CLUSTER or REINDEX is running, they will leave behind dangling files, but that's a different problem. It's not limited to utility commands like that either: if you create a table and copy a few gigabytes of data into it in a transaction, and crash before committing, you're left with a dangling file as well. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: