Prev: ERROR: incompatible library
Next: combined indexes with Gist - planner issues?
From: David Fetter on 26 Nov 2008 14:57
On Wed, Nov 26, 2008 at 09:15:49PM +0200, Heikki Linnakangas wrote:
> David Fetter wrote:
>> It sounds to me like this should use SQL/MED connections, if it's
>> holding auth information :)
>
> No, the SQL/MED stuff holds authentication information to authenticate
> to other data sources. This is about authentication of *incoming*
> connections.

Thanks for clearing that up :)

Cheers,
David.
--
David Fetter <david(a)fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter(a)gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Fujii Masao" on 27 Nov 2008 22:27
Hello,

On Tue, Nov 25, 2008 at 6:03 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote:
>> [2] User-configurable replication_timeout is dangerous
>> Index: backend/utils/misc/guc.c
>> + {"replication_timeout", PGC_USERSET, WAL_REPLICATION,
>>
>> You export replication_timeout as a PGC_USERSET variable, but it is
>> dangerous. It allows non-superusers to kill servers easily by setting it
>> too low value. Walsender dies with FATAL on timeout.

Unlike other background processes, FATAL by walsender doesn't kill the
whole server. In FATAL case, walsender is treated like the normal backend,
and only walsender dies. Please see reaper() in postmaster.c.

Just to be safe, I re-export the parameter as PGC_SUSET in the latest
patch. Is still this parameter dangerous?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 28 Nov 2008 11:10
"Fujii Masao" <masao.fujii(a)gmail.com> writes:
>>> You export replication_timeout as a PGC_USERSET variable, but it is
>>> dangerous. It allows non-superusers to kill servers easily by setting it
>>> too low value. Walsender dies with FATAL on timeout.

> Unlike other background processes, FATAL by walsender doesn't kill the
> whole server. In FATAL case, walsender is treated like the normal backend,
> and only walsender dies. Please see reaper() in postmaster.c.

> Just to be safe, I re-export the parameter as PGC_SUSET in the latest
> patch. Is still this parameter dangerous?

If this parameter is only used by a background process, then both of
those are wrong. It should be marked SIGHUP to reflect the fact that
the only effective way of modifying it is via postgresql.conf.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Fujii Masao" on 30 Nov 2008 21:17
Hi, thanks for the comment!

On Sat, Nov 29, 2008 at 1:10 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> "Fujii Masao" <masao.fujii(a)gmail.com> writes:
>>>> You export replication_timeout as a PGC_USERSET variable, but it is
>>>> dangerous. It allows non-superusers to kill servers easily by setting it
>>>> too low value. Walsender dies with FATAL on timeout.
>
>> Unlike other background processes, FATAL by walsender doesn't kill the
>> whole server. In FATAL case, walsender is treated like the normal backend,
>> and only walsender dies. Please see reaper() in postmaster.c.
>
>> Just to be safe, I re-export the parameter as PGC_SUSET in the latest
>> patch. Is still this parameter dangerous?
>
> If this parameter is only used by a background process, then both of
> those are wrong. It should be marked SIGHUP to reflect the fact that
> the only effective way of modifying it is via postgresql.conf.

This parameter is used by the backend to wait for replication to complete
for the specified time at most. If the timeout has come, the backend send
the timtout-interrupt to walsender. Then walsender invokes FATAL error,
which doesn't kill the whole server. So, I choosed PGC_USERSET at first.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2 3
Prev: ERROR: incompatible library
Next: combined indexes with Gist - planner issues?