From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: why not using a mountpoint as PGDATA? |
Date: | 2019-02-27 18:43:44 |
Message-ID: | 2235949b-a1a6-662f-d4b1-23d5fc10d182@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2/27/19 11:49 AM, Peter J. Holzer wrote:
> On 2019-02-27 10:42:12 -0500, Tom Lane wrote:
>> Luca Ferrari <fluca1978(at)gmail(dot)com> writes:
>> > On Wed, Feb 27, 2019 at 12:33 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>> >> You can see most obvious reasons at
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1247477
> [...]
>> The case that I can recall most clearly was actually in the other
>> direction: during system bootup, some NFS volume that was being abused
>> this way (mount point == data dir) was slow to mount. Compounding the
>> problem, postgres was being started through some init script that would
>> helpfully run initdb if it saw the specified data directory was empty.
>> So, rather than failing like a properly paranoid DBA would wish, it
>> ran initdb and then started the postmaster.
>
> Ouch.
>
> I wonder though why that directory was writable by the postgres user.
> But maybe the helpful start script chown'ed it to fix the "wrong"
> permissions.
FWIW, if you want to read the whole gory details of that incident, here
it is:
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Derek Hans | 2019-02-27 18:53:48 | Re: Update does not move row across foreign partitions in v11 |
Previous Message | Stephen Eilert | 2019-02-27 18:39:10 | Re: cannot execute VACUUM during recovery |