Re: dynamic shared memory

On Thu, Sep 26, 2013 at 2:45 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> On 9/26/13 8:27 AM, Noah Misch wrote:
>>
>> On Tue, Sep 24, 2013 at 12:19:51PM -0400, Robert Haas wrote:
>>>
>>> >On Fri, Sep 20, 2013 at 7:44 AM, Andres Freund<andres(at)2ndquadrant(dot)com>
>>> > wrote:
>>>>>
>>>>> > >>Actually, I was wondering if we ought
>>>>> > >>to have a directory under pgdata whose explicit charter it was to
>>>>> > >>contain files that shouldn't be copied as part of a base backup.
>>>>> > >>pg_do_not_back_this_up.
>>>>
>>>> > >
>>>> > >Wondered exactly about that as soon as you've mentioned
>>>> > >pg_basebackup. pg_local/?
>>>
>>> >
>>> >That seems reasonable. It's not totally transparent what that's
>>> >supposed to mean, but it's fairly mnemonic once you know. Other
>>> >suggestions welcome, if anyone has ideas.
>>
>> I like the concept and have no improvements on the name.
>>
>>> >Are there any other likely candidates for inclusion in that directory
>>> >other than this stuff?
>>
>> pg_xlog
>
>
> Isn't it also pointless to backup temp objects as well as non-logged tables?
>
> Or is the purpose of pg_local to be a home for things that MUST NOT be
> backed up as opposed to items where backing them up is pointless?

I don't know. I found it surprising that Noah suggested including
pg_xlog; that's certainly not "node-local state" in any meaningful
sense, the way dsm stuff is. But I guess if pg_basebackup excludes it
it arguably qualifies. However, it'd be nice to advertise that
pg_local can be cleared when the server is shut down, and you
certainly CaN nOt do that to pg_xlog. Whee!

I think the way I'd summarize the state of this patch is that everyone
who has looked at it more or less agrees that the big picture is
right, but there are details, which I think everyone admits are pretty
much corner cases, where different people have different ideas about
which way to go and what risks and benefits might be thereby incurred.
I'll not pretend that my opinions are categorically better than any
others, but of course I like them because they are mine. Figuring out
just what to do to about those last details seems challenging; no
answer will completely please everyone.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company