On Thu, May 29, 2014 at 1:01 PM, Ashesh Vashi <ashesh.va...@enterprisedb.com> wrote: > On Thu, May 29, 2014 at 8:52 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> >> On Thu, May 29, 2014 at 4:55 AM, Tomas Vondra <t...@fuzzy.cz> wrote: >> > On 28.5.2014 19:52, Fujii Masao wrote: >> >> On Thu, May 29, 2014 at 12:37 AM, Peter Geoghegan <p...@heroku.com> >> >> wrote: >> >>> On Wed, May 28, 2014 at 7:01 AM, Fujii Masao <masao.fu...@gmail.com> >> >>> wrote: >> >>>> But pg_stat_statements file is saved under $PGDATA/global yet. >> >>>> Is this intentional or just oversight? >> >>> >> >>> >> >>> I think it's an oversight. >> >> >> >> OK, patch attached. >> >> >> >> I'm afraid that it's not okay to change the file layout in $PGDATA at >> >> this beta1 >> >> stage because that change basically seems to need initdb. Otherwise >> >> something >> >> like "no such file or directory" error can happen. But in this case >> >> what we need >> >> to change is only the location of the pg_stat_statements permanent >> >> stats file. >> >> So, without initdb, the server will not be able to find the >> >> pg_stat_statements stats >> >> file, but this is not so harmful. Only the problem is that the >> >> pg_stat_statements >> >> stats which were collected in past would disappear. OTOH, the server >> >> can keep >> >> running successfully from then and no critical data will not >> >> disappear. Therefore >> >> I think we can commit this patch even at beta1. Thought? >> > >> > For HEAD, probably yes. But what about backpatching 9.3? >> >> I think No. So we should not backpatch this to 9.3. > > Just curious. > Will it work in upgrade scenario?
You're concerned about the scenario using pg_upgrade? I'm not sure the detail of pg_upgrade. But if it doesn't work properly, we should have gotten the trouble when 9.3 (which pg_stat directory was introduced) was released. But I've not heard such trouble.... Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
