Re: Renaming of pg_xlog and pg_clog - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Renaming of pg_xlog and pg_clog
Date
Msg-id 1aa50266-418e-4b77-a0b4-5e23b8db35ac@mm
Whole thread Raw
In response to Re: Renaming of pg_xlog and pg_clog  (Craig Ringer <craig.ringer@2ndquadrant.com>)
Responses Re: Renaming of pg_xlog and pg_clog
List 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 by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Missing checks when malloc returns NULL...
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Send numeric version to clients