| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | sthomas(at)optionshouse(dot)com |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Samrat Revagade <revagade(dot)samrat(at)gmail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Ants Aasma <ants(at)cybertec(dot)at>, Andres Freund <andres(at)2ndquadrant(dot)com> |
| Subject: | Re: Inconsistent DB data in Streaming Replication |
| Date: | 2013-04-10 16:40:12 |
| Message-ID: | CAHGQGwH0f4Ww7GgH3NBRMUgrDqCGvgBqdq2ct6KYrfMOLEmNaA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 10, 2013 at 11:26 PM, Shaun Thomas <sthomas(at)optionshouse(dot)com> wrote:
> On 04/10/2013 09:10 AM, Tom Lane wrote:
>
>> IOW, I wouldn't consider skipping the rsync even if I had a feature
>> like this.
>
>
> Totally. Out in the field, we consider the "old" database corrupt the moment
> we fail over.
Strange. If this is really true, shared disk failover solution is
fundamentally broken
because the standby needs to start up with the shared "corrupted"
database at the
failover. Also, we cannot trust the crash recovery at all if we adopt
the same logic
as you think. I think that there are the cases where we can replay and reuse the
old database even after PostgreSQL crashes.
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shaun Thomas | 2013-04-10 16:44:42 | Re: Inconsistent DB data in Streaming Replication |
| Previous Message | Alvaro Herrera | 2013-04-10 16:39:59 | Re: Behaviour of bgworker with SIGHUP |