From: | Vladimir Borodin <root(at)simply(dot)name> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: pg_rewind to skip config files |
Date: | 2017-09-05 13:20:02 |
Message-ID: | 557E49EB-4A7A-4EA3-80EC-B9E8B58BCF05@simply.name |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 5 сент. 2017 г., в 15:48, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> написал(а):
>
> On Tue, Sep 5, 2017 at 9:40 PM, Vladimir Borodin <root(at)simply(dot)name> wrote:
>> We do compress WALs and send them over network. Doing it via archive_command
>> in single thread is sometimes slower than new WALs are written under heavy
>> load.
>
> Ah, yeah, true. I do use pg_receivexlog --compress for that locally
> and do a bulk copy of only the compressed WALs needed, when needed...
> So there is a guarantee that completed segments are durable locally,
> which is very useful.
It seems that option --compress appeared only in postgres 10 which is not ready for production yet. BTW I assume that pg_receivexlog is single-threaded too? So it still may be the bottleneck when 3-5 WALs per second are written.
> You should definitely avoid putting that in
> PGDATA though, the same counts for tablespaces within PGDATA for
> example.
I would love to but there might be some problems with archiving and in many cases the only partition with enough space to accumulate WALs is partition for PGDATA.
--
May the force be with you…
https://simply.name
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-09-05 13:22:18 | Re: pg_upgrade changes can it use CREATE EXTENSION? |
Previous Message | Peter Eisentraut | 2017-09-05 13:19:55 | Re: Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos |