Re: vacuumdb maintenance-db??

On Wed, Nov 9, 2022 at 3:51 PM Rui DeSousa <rui(at)crazybean(dot)net> wrote:

>
>
> On Nov 9, 2022, at 5:25 PM, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
> wrote:
>
> On Wed, Nov 9, 2022 at 3:12 PM Rui DeSousa <rui(at)crazybean(dot)net> wrote:
>
>>
>> I always drop the postgres database; no need for it; and I also drop the
>> public schema too. I usually use a database name that corresponds to the
>> given project.
>>
>
> I don't see the point of going to that effort - I'd rather just make the
> defaults remain available and ensure they are only accessible to the
> bootstrap superuser via the cluster owner. That way you don't have to
> document your special environment for the next DBA that assumes "sudo -U
> postgres psql" is just going to work (and have a schema sitting there
> waiting for them to quickly do whatever semi-permanent stuff they are
> doing).
>
> I would not want my production databases used for "maintenance purposes".
> And using template1 as the maintenance database seems like a poor choice as
> well; too easy to make a mistake that will show up next time you perform
> CREATE DATABASE.
>
> David J.
>
>
> What maintenance would you do on an empty database?
>

Vacuum...

Create Database

Changing user passwords

>
> Also, most environments that I’ve seen create a new database and leave the
> default postgres database empty — then complain when it alerts due to
> wraparound thresholds. Why do I need a support ticket only to login to an
> unused/empty database to vacuum it?
>

But a fair point that I wasn't considering.

> Setup the PGDATABASE environment variable; and “sudo -U postgres psql”
> works as expected.
>

Arguably a form of documentation but I get the point and mostly agree with
it.

David J.