From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: including PID or backend ID in relpath of temp rels |
Date: | 2010-04-26 10:17:50 |
Message-ID: | v2n603c8f071004260317y588fbac3l8cd78457ce466@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Apr 25, 2010 at 10:19 PM, Jaime Casanova
<jcasanov(at)systemguards(dot)com(dot)ec> wrote:
> On Sun, Apr 25, 2010 at 8:07 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> 1. We could move the responsibility for removing the files associated
>> with temp rels from the background writer to the owning backend. I
>> think the reason why we initially truncate the files and only later
>> remove them is because somebody else might have 'em open, so it
>> mightn't be necessary for temp rels.
>>
>
> what happens if the backend crash and obviously doesn't remove the
> file associated with temp rels?
Currently, they just get orphaned. As I understand it, if the catalog
entry survives the crash, autovacuum will remove them 2 BILLION
transactions later (and emit warning messages in the meantime);
otherwise we won't even know they're there.
As I further understand it, the main point of this change is that if
temporary tables have a distinctive name of some kind, then when we
can run through the directory and blow away files with those names
without fearing that it's *permanent* table data that somehow got
orphaned.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-04-26 10:19:34 | Re: CIText and pattern_ops |
Previous Message | Simon Riggs | 2010-04-26 10:08:49 | Re: recovery_connections cannot start |