Re: including PID or backend ID in relpath of temp rels

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

In response to

Browse pgsql-hackers by date

  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