Grigory Smolkin wrote on 06/26/2019 12:37:10 PM:
> From: Grigory Smolkin
> To: pgsql-general@lists.postgresql.org
> Date: 06/26/2019 12:37 PM
> Subject: [EXTERNAL] Re: Enabling checksums on a streaming replica
>
> Hello!
> Very interesting idea, but what about full page writes, that comes
> from
Hello!
Very interesting idea, but what about full page writes, that comes from
master?
Can they be a problem?
On 6/26/19 6:32 PM, Brad Nicholson wrote:
I'm wondering about the validity of using the pg_checksums utility to
enable checksum's on a streaming replication standby, and then
promo
On Wed, Jun 26, 2019 at 8:05 AM John Lumby wrote:
> > There is a very recent research paper that discusses the idea of
> > varying fillfactor with a view to ameliorating page splits:
> >
>
> Thanks, I am chewing my way through that. As you say, it does address
> exactly the issues I raised.
>
I'm wondering about the validity of using the pg_checksums utility to
enable checksum's on a streaming replication standby, and then promoting
that standby as a way to enable checksums on existing clusters.
I've tested the process out, and it "works" (by works I mean doesn't blow
up or log any er
Hi,
PostgreSQL 11.4
Given,
postgresql.conf:
wal_level = replica
synchronous_commit = remote_apply
synchronous_standby_names = '*'
CREATE ROLE repluser WITH LOGIN REPLICATION PASSWORD 'mypwd';
SELECT pg_create_physical_replication_slot('replica1');
Execute
pg_receivewal -D
Thanks Tom and Peter for those thoughts.
>
> I think you've confused REINDEX with VACUUM. It seems like a pretty poor
> substitute for that --- it's much more expensive and has worse locking
> requirements.
>
I think the answer is mainly "I wish it were so" , but in practice, even
with a re
Thank you -
On Tue, Jun 18, 2019 at 3:10 PM Tom Lane wrote:
> Alexander Farber writes:
> > And then I shuffle the letters by -
>
> > CREATE OR REPLACE FUNCTION words_shuffle(in_array text[])
> > RETURNS text[] AS
> > $func$
> > SELECT array_agg(x ORDER BY RANDOM()) FROM UNNEST(i
Hi,
If you reckon the application initiates such a large number of concurrent
connections, I'd suggest you configure a connection pooler to avoid the
connection overhead by PostgreSQL. max_connections will be the parameter you
are looking at to configure but ensure it is configured in conjuncti
