On 08/29/2016 06:42 AM, Daniel Verite wrote:
>
> 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.
Oh it makes perfect sense.
User who isn't a postgres/database person installs X software. X
software uses PostgreSQL and you have read on the intertubes about how
Postgres is awesome. So you install it, get everything up and running
from the README.md on Github. You walk away.
A year later, after it becomes crucial to whatever it is you do the
system crashes. You have no idea what is going on, you just set this up
on some recycled server or VM. You log in, see that all the space and
you find that you are using a ton of disk space. You look around for
anything you can delete. You find a directory called pg_xlog, it says
log, junior ignorant, don't want to be a sysadmin 101 says, "delete logs".
Boom, crushed server. Let us not forget that by far the number of
PostgreSQL users we have, have never done ANYTHING with postgres except
make it so something like Drupal can connect to it.
JD
>
> Best regards,
>
--
Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
