Re: streaming replication does not work across datacenter with 20ms latency?

oh god...thanks a lot for the tip. I did actually lost some data, the
master server has crashed two times. every time it comes back, the
index were broken. I need to reindex it. I have already set fsync=on.
just thought it was normal behavior....

about gcc version, only 4.6.0 effected? 4.6.1 is okay? then I could
compile my own version with 4.6.1

but how about the data? from the bug information, the data file seems
not compatible....
I need to do pg_dump and pg_restore? what a nightmare.....

On Mon, Jul 25, 2011 at 10:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yan Chunlu <springrider(at)gmail(dot)com> writes:
>> seems the Master server is compiled using 4.6.0:
>
>>  PostgreSQL 9.0.4 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.6.real
>> (Debian 4.6.0-6) 4.6.1 20110428 (prerelease), 64-bit
>
> Hmm.  Given the datestamp, that version of gcc almost certainly does
> have the bug.  I wonder whether Martin Pitt knows about this issue
> and the workaround we put in --- I'd have thought he'd push updated
> .debs with a workaround, as I did for Fedora ...
>
> Martin: see
> http://archives.postgresql.org/pgsql-hackers/2011-06/msg00890.php
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c2ba0121c73b7461331104a46d140156e847572a
>
>> and there is no way  to know what slave is using since I have remove it.
>
> If it was installed from the same .deb then it'd be the same build.
>
>> I think the problem maybe is like Fujii said, does that bug only
>> effect hot-stanby server?  seems master is okay.
>
> Well, actually, the bug affects WAL replay of any sort, which means
> if your master were to crash and restart you'd be at risk of data
> corruption on the master.  I'd replace the master build too, ASAP.
>
>                        regards, tom lane
>