On Tue, Sep 24, 2013 at 9:49 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 20, 2013 at 7:44 AM, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers