before
starting postgres/initdb or the like
install -o postgres -g postgres -d -m 0700 "${PGDATA}"
> The world has changed! And the old standards don't work...
There's enough people running Postgres in Docker containers in production
for almost a decade.
It does work!
Kind regards,
Feike Steenbergen
Hi all,
I'd like to get some feedback on whether or not implementing a DNS SRV feature
for connecting to PostgreSQL would be desirable/useful.
The main use case is to have a DNS SRV record that lists all the possible
primaries of a given replicated PostgreSQL cluster. With auto failover
solutions
On 5 January 2018 at 15:19, Simon Riggs wrote:
> Yup, I got this.
I saw the commit in the master branch but not in the REL_10_STABLE branch,
I'm totally not up-to-date with the backpatching process, but I was wondering
if it still needs to be added to REL_10_STABLE
regards,
Feike
On 23 December 2017 at 11:58, Michael Paquier wrote:
> On Fri, Dec 22, 2017 at 07:55:19AM +0100, Feike Steenbergen wrote:
>> On 21 December 2017 at 05:32, Michael Paquier
>> wrote:
>>
>> > Don't you want to put that in its own block? That's rather
>&
On 21 December 2017 at 05:32, Michael Paquier wrote:
> Don't you want to put that in its own block? That's rather
> important not to miss for administrators.
I didn't want to add yet another block on that documentation page,
as it already has 2, however it may be good to upgrade the
note to a c
On 21 December 2017 at 14:11, Michael Paquier wrote:
> You mean a WAL receiver here, not a WAL sender.
Fixed, thanks
0002-Fix-permissions-check-on-pg_stat_get_wal_senders.patch
Description: Binary data
that, however
pg_stat_get_wal_senders was somehow not part of that commit, that
seems an oversight.
1:
https://www.postgresql.org/message-id/CA%2BOCxoyYxO%2BJmzv2Micj4uAaQdAi6nq0w25BPQgLLxsrvTmREw%40mail.gmail.com\
regards,
Feike Steenbergen
0001-Fix-permissions-check-on
On 20 December 2017 at 06:22, Michael Paquier
wrote:
> prepare_transaction.sgml has a "Caution" block mentioning that it is
> unwise to keep 2PC transactions unfinished for a too-long time as it
> interferes with VACUUM. In doc/src/sgml/logicaldecoding.sgml, it would
> be nice to add the a similar
Hi,
While doing some wraparound debugging, I saw the hint regarding upcoming
wraparound did not include the problem of having a stale replication
slot (which I'm actually using to force wraparound issues).
I remember a few discussions where a stale replication slot was actually
the culprit in the
On 28 November 2017 at 23:17, Peter Geoghegan wrote:
> BTW, a good short term solution for you might be to change the vacuum
> cost delay settings. They're pretty conservative by default.
>
> There is a good chance that your indexes are mostly in memory even on
> large tables, and B-Tree indexes a
On 28 November 2017 at 22:48, Peter Geoghegan wrote:
> There is a patch in the ongoing CF to do this:
Ah, thanks, I'll probably review that one then
> It's a lot harder to do this correctly than it first appears.
I already thought my naive approach would not suffice
Sorry, I didn't attach a good patch, this one should be better
0002-skip_cleanup_for_stale_relation.patch
Description: Binary data
On a server with a very frequent xid wraparound I can see that the
anti-wraparound vacuum is finished very quickly with the heap, yet it still
scans all the indexes, which causes it to still have to read a lot of data,
which takes a considerable amount of time.
I dove into the code a bit and as fa
13 matches
Mail list logo
