Re: dynamic shared memory

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dynamic shared memory
Date: 2013-09-25 03:18:23
Message-ID: CAA4eK1K1bKkeiODu2N4A0Nc74E6LX5MA82=_J8wXk+=bGeZOhg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 24, 2013 at 9:49 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Sep 20, 2013 at 7:44 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>>> > Hm, I guess you dont't want to add it to global/ or so because of the
>>> > mmap implementation where you presumably scan the directory?
>>>
>>> Yes, and also because I thought this way would make it easier to teach
>>> things like pg_basebackup (or anybody's home-brew scripts) to just
>>> skip that directory completely. 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.
>
> Are there any other likely candidates for inclusion in that directory
> other than this stuff?
pgsql_tmp. Refer sendDir() in basebackup.c, there we avoid sending
files in backup.
Some of future features like ALTER SYSTEM, can also use it for tmp file.

>>> >> + /* Create or truncate the file. */
>>> >> + statefd = open(PG_DYNSHMEM_NEW_STATE_FILE, O_RDWR|O_CREAT|O_TRUNC, 0600);
>>> >
>>> > Doesn't this need a | PG_BINARY?
>>>
>>> It's a text file. Do we need PG_BINARY anyway?
>>
>> I'd say yes. Non binary mode stuff on windows does stuff like
>> transforming LF <=> CRLF on reading/writing, which makes sizes not match
>> up and similar ugliness.
>> Imo there's little reason to use non-binary mode for anything written
>> for postgres' own consumption.
>
> Well, I'm happy to do whatever the consensus is. AFAICT you and Noah
> are both for it and Amit's position is that it doesn't matter either
> way

I am sorry If my mails doesn't say that I am in favour of keeping code
as it is unless there is really a case which requires it.
Basically as per my understanding, I have presented some facts in
above mails which indicates, there is no need for PG_BINARY in this
case.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2013-09-25 06:39:55 Re: Minmax indexes
Previous Message Peter Eisentraut 2013-09-25 02:49:57 Re: UTF8 national character data type support WIP patch and list of open issues.