Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c backe ...
От | Tom Lane |
---|---|
Тема | Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c backe ... |
Дата | |
Msg-id | 11100.1028481252@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c backe ... (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c
Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c |
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Thomas Lockhart wrote: >> Implement WAL log location control using "-X" or PGXLOG. > Woh, I didn't think we had agreement on this. This populates the 'X' > all over the system (postgres, postmaster, initdb, pg_ctl), while the > simple solution would be to add the flag only to initdb and use a > symlink from /data. I also think it is less error-prone because you > can't accidentally point to the wrong XLOG directory. In fact, you > almost have to use an environment variable unles you plan to specify -X > for all the commands. In my mind, PGDATA should take care of the whole > thing for pointing to your data. > If you want to do it this way, I request a vote. I have to vote a strong NO on this. What the patch essentially does is to decouple specification of the data directory ($PGDATA or -D) from the xlog directory ($PGXLOG or -X). This might seem nice and clean and symmetrical, but in fact it has no conceivable use except for shooting yourself in the foot in a particularly nasty manner. The xlog *cannot* be decoupled from the data directory --- there are pointers in pg_control and in every single data page that depend on the state of xlog. Trying to make them look independent is just a recipe for breaking your database by starting the postmaster with the wrong combination of PGDATA and PGXLOG. And I'm not at all sure it'll be possible to recover after you do that: if the postmaster notices the discrepancy, it is likely to try to fix it by rolling forward from the last checkpoint it can find in the mismatching xlog. Oops :-( I think the existing mechanism of using a symlink in the data directory when you want to move xlog is far safer and more reliable. I do not see what functionality is added by this patch that can possibly justify the hazards it creates. regards, tom lane
В списке pgsql-hackers по дате отправления: