Re: including backend ID in relpath of temp rels - updated patch - Mailing list pgsql-hackers

From Jaime Casanova
Subject Re: including backend ID in relpath of temp rels - updated patch
Date
Msg-id AANLkTinGLXj5vyScaPdv_D9NwH_-6pnh2xq2bZnfKNnc@mail.gmail.com
Whole thread Raw
In response to Re: including backend ID in relpath of temp rels - updated patch  (Jaime Casanova <jaime@2ndquadrant.com>)
Responses Re: including backend ID in relpath of temp rels - updated patch
List pgsql-hackers
On Fri, Jul 23, 2010 at 10:05 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
> On Thu, Jun 10, 2010 at 3:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>>
>> I believe that this patch will clear away one major obstacle to
>> implementing global temporary and unlogged tables: it enables us to be
>> sure of cleaning up properly after a crash without relying on catalog
>> entries or XLOG.  Based on previous discussions, however, I believe
>> there is support for making this change independently of what becomes
>> of that project, just for the benefit of having a more robust cleanup
>> mechanism.
>>
>
> Hi,
>
> i was looking at v3 of this patch...
>

Ok, i like what you did in smgrextend, smgrwrite, and others...
changing isTemp for skipFsync is more descriptive

but i have a few questions, maybe is right what you did i only want to
understand it:
- you added this in include/storage/smgr.h, so why is safe to assume
that if the backend != InvalidBackendId it must be a temp relation?

+#define SmgrIsTemp(smgr) \
+   ((smgr)->smgr_rnode.backend != InvalidBackendId)


- you added a question like this "if (rel->rd_backend == MyBackendId)"
in a few places... why are you assuming that? that couldn't be a new
created relation (in current session of course)? is that safe?

--
Jaime Casanova         www.2ndQuadrant.com
Soporte y capacitación de PostgreSQL


pgsql-hackers by date:

Previous
From: "Massa, Harald Armin"
Date:
Subject: Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
Next
From: Martijn van Oosterhout
Date:
Subject: Re: non-overlapping, consecutive partitions