Re: Renaming of pg_xlog and pg_clog
От | Daniel Verite |
---|---|
Тема | Re: Renaming of pg_xlog and pg_clog |
Дата | |
Msg-id | 1aa50266-418e-4b77-a0b4-5e23b8db35ac@mm обсуждение исходный текст |
Ответ на | Re: Renaming of pg_xlog and pg_clog (Craig Ringer <craig.ringer@2ndquadrant.com>) |
Ответы |
Re: Renaming of pg_xlog and pg_clog
|
Список | pgsql-hackers |
Craig Ringer wrote: > People won't see a README in amongst 5000 xlog segments while > freaking out about the sever being down. Maybe they're more likely to google "pg_xlog". BTW, renaming it will not help with respect to that, as there's a pretty good corpus on knowledge linked to that particular keyword. The first google results of "pg_xlog" are, for me: - Solving pg_xlog out of disk space problem on Postgres - PostgreSQL: Documentation: 9.1: WAL Internals - Why is my pg_xlog directory so huge? - PostgreSQL - Database Soup: Don't delete pg_xlog ... That's spot-on. For each person deleting stuff in pg_xlog and then regretting it, how many look it up in the above results and avoid making the mistake? Will they find comparable results if the directory is "wal" ? Aside from that, we might also question how much of the excuse "pg_xlog looked like it was just deletable logs" is a lie made up after the fact, because anybody wrecking a database is not against deflecting a bit of the blame to the software, that's human. The truth being that they took the gamble that postgres will somehow recover from the deletion, at the risk of possibly loosing the latest transactions. That doesn't necessarily look so bad when current transactions are failing anyway for lack of disk space, users are yelling at you, and you're frantically searching for anything to delete in the FS to come back online quickly. Personally I'm quite skeptical of the *name* of the directory playing that much of a role in this scenario. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
В списке pgsql-hackers по дате отправления: