[GENERAL] Checksums and full_page_writes

[Borodin Vladimir]

Hi all.

I’ve read thread [0], src/backend/storage/page/README and everything I found in 
the documentation about checksums [1, 2] but I haven’t understood what is my 
risk if I enable checksums during initdb and turn off full_page_writes?

Am I right that I can get torn pages on disk in that case but I will somehow 
know about it during checksum checking when this page will be read from disk to 
shared buffers? And is there any way to recover such torn page (from replica or 
backup+archived logs, for example)?

[0] http://www.postgresql.org/message-id/20111217213324.ga4...@fetter.org
[1] 
http://www.postgresql.org/docs/current/static/app-initdb.html#APP-INITDB-DATA-CHECKSUMS
[2] http://www.postgresql.org/docs/current/static/wal-reliability.html

--
Vladimir

Re: [GENERAL] Question about synchronous replication

[Borodin Vladimir]

12 мая 2014 г., в 22:26, Adrian Klaver  написал(а):

> On 05/12/2014 09:42 AM, Borodin Vladimir wrote:
>> Hi all.
>> 
>> Right now synchronous replication in postgresql chooses one replica as
>> synchronous and waits for replies from it (with synchronous_commit = on
>> | remote_write) until this replica host does not disconnect from master.
>> 
>> Are there any plans to implement something like semi synchronous
>> replication in MySQL 5.6 or replication with write_concern=2 in MongoDB
>> when the master waits for a reply from any of the replica hosts?
> 
> This does not work for what you want?:
> 
> http://www.postgresql.org/docs/9.3/interactive/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES

Actually no. I have such settings:

wal_sender_timeout = 3s
wal_receiver_status_interval = 1s
synchronous_standby_names = ‘*’

When the sync replica dies or the network between master and sync replica 
flaps, 3 seconds must pass before the potential replica becomes sync and 
transaction commits continue. Instead postgresql could wait for confirm from 
first or second replica hosts (doesn’t matter which of them answers first), 
couldn’t it? In this case transaction commits will not stuck for 
wal_sender_timeout.

> 
>> 
>> In this case network flaps between master and any one replica will not
>> affect writing load and in case of master fail it would be necessary to
>> find the most recent replica and promote it. Or there are pitfalls that
>> I do not see?
>> 
>> --
>> Vladimir
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Adrian Klaver
> adrian.kla...@aklaver.com


--
Да пребудет с вами сила...
http://simply.name

[GENERAL] Question about synchronous replication

[Borodin Vladimir]

Hi all.

Right now synchronous replication in postgresql chooses one replica as 
synchronous and waits for replies from it (with synchronous_commit = on | 
remote_write) until this replica host does not disconnect from master.

Are there any plans to implement something like semi synchronous replication in 
MySQL 5.6 or replication with write_concern=2 in MongoDB when the master waits 
for a reply from any of the replica hosts? 

In this case network flaps between master and any one replica will not affect 
writing load and in case of master fail it would be necessary to find the most 
recent replica and promote it. Or there are pitfalls that I do not see?

--
Vladimir