Re: BUG #1970: Existing /etc/pam.d/postgresql clobbered by

Hi,

On Tue, 18 Oct 2005, Tom Lane wrote:

> Devrim GUNDUZ <devrim(at)gunduz(dot)org> writes:
>> I can't see any problems with adding
>> account required pam_stack.so service=system-auth
>
> See also
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167040
> which is what inspired this to start with. Not knowing enough about
> PAM, I didn't get it right the first time :-(

Ok, I fixed it with

%if %pam
%config(noreplace) /etc/pam.d/postgresql
%endif

in PGDG RPM spec file. However, as I wrote in pgsqlrpms-hackers list, in
PGDG RPMs we can't use include directive in PAM config file since we are
using same spec for all distros.

Regards,
--
Devrim GUNDUZ
Kivi Bilişim Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
>From pgsql-bugs-owner(at)postgresql(dot)org Thu Oct 20 00:07:58 2005
X-Original-To: pgsql-bugs-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
Received: from localhost (av.hub.org [200.46.204.144])
by svr1.postgresql.org (Postfix) with ESMTP id 18978D9C48
for <pgsql-bugs-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Thu, 20 Oct 2005 00:07:58 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
with ESMTP id 48002-08
for <pgsql-bugs-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>;
Thu, 20 Oct 2005 03:07:56 +0000 (GMT)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
by svr1.postgresql.org (Postfix) with ESMTP id 12810D7205
for <pgsql-bugs(at)postgreSQL(dot)org>; Thu, 20 Oct 2005 00:07:55 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl(at)localhost [127.0.0.1])
by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j9K37kfk003473;
Wed, 19 Oct 2005 23:07:46 -0400 (EDT)
To: Stanislav Sukholet <ctac(at)osib(dot)so-cdu(dot)ru>
Cc: pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: BUG #1976: steps to reproduce BUG #1438: Non UTF-8 client encoding problem
In-reply-to: <200510200808(dot)11883(dot)ctac(at)osib(dot)so-cdu(dot)ru>
References: <20051019023130(dot)0D4ADF0C4D(at)svr2(dot)postgresql(dot)org> <22330(dot)1129738328(at)sss(dot)pgh(dot)pa(dot)us> <200510200808(dot)11883(dot)ctac(at)osib(dot)so-cdu(dot)ru>
Comments: In-reply-to Stanislav Sukholet <ctac(at)osib(dot)so-cdu(dot)ru>
message dated "Thu, 20 Oct 2005 08:08:11 +0800"
Date: Wed, 19 Oct 2005 23:07:46 -0400
Message-ID: <3472(dot)1129777666(at)sss(dot)pgh(dot)pa(dot)us>
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006]
X-Spam-Level:
X-Archive-Number: 200510/233
X-Sequence-Number: 13214

Stanislav Sukholet <ctac(at)osib(dot)so-cdu(dot)ru> writes:
>> Can't reproduce this here.  What locale settings are you using in the
>> database?  (Particularly lc_ctype and lc_messages)

> mydb=> SHOW client_encoding ;
> client_encoding
> -----------------
> KOI8
> (1 запись)

> mydb=> show LC_CTYPE;
> lc_ctype
> -------------
> ru_RU.koi8r
> (1 запись)

> mydb=> show LC_MESSAGES;
> lc_messages
> -------------
> ru_RU.koi8r
> (1 запись)

> mydb=> CREATE TABLE a (b INTEGER PRIMARY KEY);
> ERROR: ignoring unconvertible UTF-8 character 0xd3cf

OK, with that I can reproduce it in 7.4, but more recent releases
produce a bunch of "WARNING: ignoring unconvertible UTF-8 character"
notices and then complete the operation successfully.

This is basically the same problem discussed in this thread:
http://archives.postgresql.org/pgsql-patches/2005-08/msg00037.php
namely that gettext() converts the translated error message to the
encoding implied by LC_CTYPE ... but the error reporting machinery
expects the string to be in the encoding specified for the database.

I have applied a minor tweak to the 7.4 branch to make it behave more
like the later releases, ie you get a WARNING not an ERROR. However
this is certainly not really a solution --- the only reason the behavior
isn't worse is that the ru_RU message catalog doesn't try to translate
"ignoring unconvertible UTF-8 character" and so you don't get into the
recursive failure discussed in the above thread.

The bottom line is that this is one of several reasons why it's a bad
idea to use a database encoding that's incompatible with the underlying
locale settings. I doubt that we'll really be able to fix that until
we replace all our dependence on the C library's locale facilities
... which is something that will probably happen someday, but don't
hold your breath waiting :-(

In short, if you want to use UTF8 database encoding, specify a
UTF8-based locale setting when you initdb. Don't try to change
the database encoding via -E.

regards, tom lane