Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id D2D356321ED; Thu, 1 Apr 2010 14:29:44 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 67541-08-3; Thu, 1 Apr 2010 17:29:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id C5A206339CE; Thu, 1 Apr 2010 14:29:11 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o31HT7Oo019263; Thu, 1 Apr 2010 13:29:07 -0400 (EDT) To: Robert Haas cc: Heikki Linnakangas , Fujii Masao , PostgreSQL-development , pgsql-docs@postgresql.org Subject: Re: [HACKERS] Streaming replication document improvements In-reply-to: References: <3f0b79eb1003300152g5327eb47w8f9aecae6002b215@mail.gmail.com> <4BB3B2ED.5080606@enterprisedb.com> <4BB49B0C.1050901@enterprisedb.com> Comments: In-reply-to Robert Haas message dated "Thu, 01 Apr 2010 13:18:45 -0400" Date: Thu, 01 Apr 2010 13:29:06 -0400 Message-ID: <19262.1270142946@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.838 tagged_above=-10 required=5 tests=BAYES_00=-2.599, FS_REPLICA=1.041, SARE_SPEC_REPLICA=0.72 X-Spam-Level: X-Archive-Number: 201004/6 X-Sequence-Number: 5405 Robert Haas writes: > That seems pretty reasonable to me. I haven't checked how much code > impact there is. I know Tom doesn't think we should change it at all, > but surely pre-beta is the time to fix nasty corner cases that were > added by recently committed patches? What nasty corner case? Having replication connections use superuser reserved slots seems exactly the behavior I'd expect given that they are running as superuser. I agree it would be good to decouple that later, but we already decided we are not going to try to separate replication privilege from superuser in 9.0. (Also, autovacuum workers are a quite separate concept since the DBA doesn't set them up or deal with them directly. So I'm unimpressed by pointing to the treatment of autovacuum_max_workers as a precedent.) regards, tom lane