From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Daniel Farina <daniel(at)heroku(dot)com> |
Subject: | Re: Sync Rep v17 |
Date: | 2011-02-20 12:20:15 |
Message-ID: | 3D50260F-0DF3-4B68-9B49-C5F40C2700AB@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Feb20, 2011, at 08:12 , Jaime Casanova wrote:
> considering that synchronous_replication to on means that we *want*
> durability, and that synchronous_commit to off means we don't *care*
> about durability. Then the real question here is: in the presence of
> synchronous_replication to on (which means we want durability), are we
> allowed to assume we can loss data?
From the angle, shouldn't we turn synchronous_replication=on into a third
possible state of synchronous_commit?
We'd then have
synchronous_commit=off #Same as now
synchronous_commit=local #Same as synchronous_commit=on,
#synchronous_replication=off
synchronous_commit=standby #Same as synchronous_commit=on,
#synchronous_replication=on
> one way to manage that is simply disallow that combination with an
> error, maybe that is a bit strict but we haven't to make assumptions;
> the other option is to keep safe which means keep durability so if you
> want to risk some data then you should disable synchronous_replication
> as well as synchronous_commit... maybe sending a message to the log
> when you detect the conflicting situation.
The question is where we'd raise the error, though. Doing it on GUC
assignment makes the behaviour depend on assignment order. That's a
bad idea I believe, since it possibly breaks ALTER ROLE/DATEBASE SET ....
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-02-20 13:49:29 | Re: Update PostgreSQL shared memory usage table for 9.0? |
Previous Message | Devrim GÜNDÜZ | 2011-02-20 12:17:11 | Cannot *start* server because of a typo in pg_hba.conf |