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@sss.pgh.pa.us> wrote:
> Yan Chunlu <springrider@gmail.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
>
