Re: Is PostgreSQL supported on RHEL6?

Hello,

Thank you for your reply. I've been largely relieved. I understood the anser
was as follows:

[A1] Yes, it is safe to use PostgreSQL 8.3.12 on RHEL6.
It is recommended to rebuild it on RHEL6, however, it should be no problem
to use it without rebuilding it.

[A2] N/A because the answer to Q1 is yes (safe).
Applying the newest update is always recommended. However, the newest update
is not a must for RHEL6.

Tom, all, I'm sorry to ask again.

Do I need to set wal_sync_method to fdatasync in postgresql.conf if I use
8.3.12 on RHEL6? From the release note, I got the impression that even
open_datasync is not a problem unless the ext4 file system is mounted with
data=journal.

How about Q3?

Regards
Maumau

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
news:12396(dot)1300373556(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> "MauMau" <maumau307(at)gmail(dot)com> writes:
>> Now I'm trying to support both RHEL5 and RHEL6 with minimal effort (but
>> with
>> safety). If possible, I want to continue to use PostgreSQL 8.3.12 built
>> on
>> RHEL5 for a while. Then, I'd like to ask some questions:
>
> I'd recommend rebuilding the executables on RHEL6 if possible, but
> otherwise this should be no problem.
>
>> I could build 8.3.12 successfully with 167 compilation warnings that
>> report
>> "variable not used" and "uninitialized variable is used" etc. Even if I
>> could run PostgreSQL, I'm not sure that it is safe.
>
> You can reasonably assume those are cosmetic. Newer compilers tend to
> be pickier about that sort of thing than older ones, so we fix those
> sorts of warnings when we see them. If any of them had represented
> actual bugs, we'd have back-patched the fixes into 8.3.x.
>
>> I searched the PostgreSQL mailing lists with "RHEL6" and found the
>> discussion regarding wal_sync_method and O_DSYNC/O_SYNC. The following
>> fix
>> in 8.3.13 makes me wonder if I should update with 8.3.14 which is the
>> latest
>> version of 8.3 series.
>
> That would be a good idea in any case.
>
> regards, tom lane
>