Re: "repliation" as database name - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: "repliation" as database name
Date
Msg-id 20190129.122954.02538830.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: "repliation" as database name  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
At Mon, 28 Jan 2019 17:30:57 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in
<20190128.173057.41178374.horiguchi.kyotaro@lab.ntt.co.jp>
> At Wed, 26 Dec 2018 12:59:32 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in <32289.1545847172@sss.pgh.pa.us>
> > Hm, I agree that the para doesn't read very well now, but I think this
> > could be improved further.  How about something like
> > 
> > # DATABASE can be "all", "sameuser", "samerole", "replication", a
> > # database name, or a comma-separated list thereof.  The "replication"
> > # keyword matches replication connection requests (see example below).
> > # The "all" keyword matches all database names, but not replication
> > # connections.
> 
> I'm afraid that just dropping "it must be enabled in a separate
> record" leads to confusion. How about adding a comment to
> replication connection examples.
> 
> # Allow replication connections from localhost, by a user with the
> # replication privilege. Each definition must have its own record.

Mmm, this doesn't seem to saying what I wanted to say there.
This seems better.

# Allow replication connections from localhost, by a user with
# the replication privilege. They must have separate records from
# non-replication connections.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?
Next
From: Etsuro Fujita
Date:
Subject: Re: postgres_fdw: estimate_path_cost_size fails to re-use cachedcosts