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
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. |