| From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Tom Lane <tgl(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory |
| Date: | 2008-04-17 13:03:18 |
| Message-ID: | 48074A96.6070400@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-04-17 13:05:43 | Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory |
| Previous Message | Alvaro Herrera | 2008-04-17 12:30:12 | Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit could leave shared memory |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-04-17 13:05:43 | Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory |
| Previous Message | Alvaro Herrera | 2008-04-17 12:59:05 | Re: Lessons from commit fest |