[BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
What Would Happen if I got NO "localhost" entry in my /etc/hosts ?
statistics and autovacuum would be disabled:
# /usr/local/pgsql/bin/postgres -i -p 15432 -D data
LOG: could not resolve "localhost": no address associated with name
LOG: disabling statistics collector for lack of working socket
WARNING: autovacuum not started because of misconfiguration
HINT: Enable the "track_counts" option.
LOG: database system was shut down at 2011-10-27 09:42:14 GMT
LOG: database system is ready to accept connections
So let's fix it:
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index b468797..fc0f0e7 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -143,6 +143,7 @@ extern bool synchronize_seqscans;
extern bool fullPageWrites;
extern int ssl_renegotiation_limit;
extern char *SSLCipherSuites;
+extern char *StatisticsCollectorListenAddress;
#ifdef TRACE_SORT
extern bool trace_sort;
@@ -3052,6 +3053,16 @@ static struct config_string ConfigureNamesString[] =
},
{
+ {"statistics_collector_listen_address", PGC_POSTMASTER,
QUERY_TUNING_OTHER,
+ gettext_noop("Sets the host name or IP address for
statistics
collector listen to."),
+ NULL
+ },
+ &StatisticsCollectorListenAddress,
+ "localhost",
+ NULL, NULL, NULL
+ },
+
+ {
{"custom_variable_classes", PGC_SIGHUP, CUSTOM_OPTIONS,
gettext_noop("Sets the list of known custom variable
classes."),
NULL,
diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
index 1d80c31..13ac5a9 100644
--- a/src/backend/postmaster/pgstat.c
+++ b/src/backend/postmaster/pgstat.c
@@ -117,6 +117,7 @@ int pgstat_track_activity_query_size = 1024;
* Built from GUC parameter
* --
*/
+char *StatisticsCollectorListenAddress = NULL;
char *pgstat_stat_filename = NULL;
char *pgstat_stat_tmpname = NULL;
@@ -323,12 +324,12 @@ pgstat_init(void)
hints.ai_addr = NULL;
hints.ai_canonname = NULL;
hints.ai_next = NULL;
- ret = pg_getaddrinfo_all("localhost", NULL, &hints, &addrs);
+ ret = pg_getaddrinfo_all(StatisticsCollectorListenAddress, NULL,
&hints, &addrs);
if (ret || !addrs)
{
ereport(LOG,
- (errmsg("could not resolve \"localhost\": %s",
- gai_strerror(ret;
+ (errmsg("could not resolve \"%s\": %s",
+
StatisticsCollectorListenAddress,gai_strerror(ret;
goto startup_failed;
}
@@ -371,7 +372,7 @@ pgstat_init(void)
{
ereport(LOG,
(errcode_for_socket_access(),
- errmsg("could not bind socket for statistics
collector: %m")));
+ errmsg("could not bind socket for
statistics_collector_listen_address(%s):
%m",StatisticsCollectorListenAddress)));
closesocket(pgStatSock);
pgStatSock = PGINVALID_SOCKET;
continue;
diff --git a/src/backend/utils/misc/postgresql.conf.sample
b/src/backend/utils/misc/postgresql.conf.sample
index 0f1745f..630b8fd 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -259,6 +259,7 @@
# - Other Planner Options -
+#statistics_collector_listen_address = 'localhost' # should bind to
loopback interface
#default_statistics_target = 100 # range 1-1
#constraint_exclusion = partition # on, off, or partition
#cursor_tuple_fraction = 0.1 # range 0.0-1.0
Tests:
1.NO localhost entry:
# grep localhost /etc/hosts
# grep statistics_collector_listen_address data/postgresql.conf
#statistics_collector_listen_address = 'localhost' # should bind to
loopback interface
# /usr/local/pgsql/bin/postgres -i -p 5432 -D data
LOG: could not resolve "localhost": no address associated with name
LOG: disabling statistics collector for lack of working socket
WARNING: autovacuum not started because of misconfiguration
HINT: Enable the "track_counts" option.
LOG: database system was shut down at 2011-10-27 09:43:18 GMT
LOG: database system is ready to accept connections
2.Normal circumstance:
# echo 127.0.0.1 localhost > /etc/hosts
# grep localhost /etc/hosts
127.0.0.1 localhost
# grep statistics_collector_listen_address data/postgresql.conf
#statistics_collector_listen_address = 'localhost' # should bind to
loopback interface
# /usr/local/pgsql/bin/postgres -i -p 5432 -D data
LOG: database system was shut down at 2011-10-27 09:48:32 GMT
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
3./etc/hosts mi
Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
Hi Robert, On Thursday, October 27, 2011 12:38:02 PM Robert Young wrote: > What Would Happen if I got NO "localhost" entry in my /etc/hosts ? Why should pg cater for such a broken configuration? Sorry for being harsh but that seems like it would end in heaps of workarounds. Andres -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
But,I think insistence of hard-coding should be even worse than broken configuration. And hard-coding should never be a good work ethics of a professional programmer. On Thu, Oct 27, 2011 at 12:12, Andres Freund wrote: > Hi Robert, > > On Thursday, October 27, 2011 12:38:02 PM Robert Young wrote: >> What Would Happen if I got NO "localhost" entry in my /etc/hosts ? > Why should pg cater for such a broken configuration? Sorry for being harsh but > that seems like it would end in heaps of workarounds. > > Andres > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
On 27.10.2011 15:57, Robert Young wrote: But,I think insistence of hard-coding should be even worse than broken configuration. And hard-coding should never be a good work ethics of a professional programmer. You're exaggerating. There's nothing wrong hard-coding things like number of seconds in a minute (60). While it's not as cast in stone as 60 seconds in a minute, I don't see anything wrong with hardcoding that "localhost" means the local host. BTW, do we have anything in place to stop any user on the same host to send bogus stat messages to the stats collector? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
In reality,sometimes something would be wrong if you hard-coding 1 minute as 60 seconds. Please read: http://www.openbsd.org/cgi-bin/man.cgi?query=strftime "The range of seconds is (00-60) instead of (00-59) to allow for the periodic occurrence of leap seconds." so,it's a bad habit including hard-coding 1 minute as 60 seconds. On Thu, Oct 27, 2011 at 13:13, Heikki Linnakangas wrote: > On 27.10.2011 15:57, Robert Young wrote: >> >> But,I think insistence of hard-coding should be even worse than broken >> configuration. >> And hard-coding should never be a good work ethics of a professional >> programmer. > > You're exaggerating. There's nothing wrong hard-coding things like number of > seconds in a minute (60). While it's not as cast in stone as 60 seconds in a > minute, I don't see anything wrong with hardcoding that "localhost" means > the local host. > > BTW, do we have anything in place to stop any user on the same host to send > bogus stat messages to the stats collector? > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
Heikki Linnakangas writes: > BTW, do we have anything in place to stop any user on the same host to > send bogus stat messages to the stats collector? Yes. Use of the connect() call is supposed to guarantee that we will only receive packets originating from our own socket address. As far as the original topic goes, I agree that it seems rather pointless to worry about systems that fail to resolve "localhost". Doing so is required by relevant RFCs, eg http://www.faqs.org/rfcs/bcp/bcp32.html (That's probably not the only one, it's just the first hit I found while searching the RFC archives.) And, given that we've been doing it this way since 2001 without previous complaints, the number of systems that fail to do it must be pretty small. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6273: Install Error
The following bug has been logged online: Bug reference: 6273 Logged by: Justin Email address: just...@steinhafels.com PostgreSQL version: 9.1.1 Operating system: Windows Server 2003 Description:Install Error Details: On installation, it throws on error stating database cluster initialization failed. I was wondering what the fix for this issue would be. Thanks -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6274: documentation on pg_attribute.atttypmod
The following bug has been logged online: Bug reference: 6274 Logged by: Jan-Peter Seifert Email address: jan-peter.seif...@gmx.de PostgreSQL version: 9.1 Operating system: any Description:documentation on pg_attribute.atttypmod Details: Hello, it looks like that the remarks on column pg_attribute.atttypmod haven't been updated for a while: http://www.postgresql.org/docs/current/interactive/catalog-pg-attribute.html It obviously does contain the actual value ( possibly changed by ALTER TABLE ... ). With best regards, Peter -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6264: Superuser does not have inherent Replication permission
On Tue, Oct 25, 2011 at 8:39 AM, Magnus Hagander wrote:
> On Mon, Oct 24, 2011 at 16:37, Keith Fiske wrote:
>> On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane wrote:
>>> "Keith Fiske" writes:
>>
If you create a user as a NONsuperuser,
then later ALTER them to be one, they will NOT have the replication
permission and cannot be used as a replication user until you explicitly
grant that permission.
>>>
>>> That doesn't sound to me like a bug. These flags are independent, we
>>> just provide a certain default at role creation time.
>>>
>>
>> That is not what the documentation as read would lead people to
>> believe. I'd be more than happy to help with clarifying the
>> documentation myself if needed. Just let me know how.
>
> This part I agree with - it makes sense for ALTER to set both flags
> when it enables superuser. It seems inconsistent now - even if it may
> be technically correct.
>
> If we don't change it, we should definitely accept a docs patch to
> clarify what happens, because I agree it's confusing.
There's a pre-existing catalog flag called rolcatupdate that works a
little bit like this, and we discussed making rolreplication behave
similarly. But we ended up with different semantics:
rhaas=# create user bob nosuperuser;
CREATE ROLE
rhaas=# create user fred nosuperuser;
CREATE ROLE
rhaas=# alter role fred superuser;
ALTER ROLE
rhaas=# create user harry superuser;
CREATE ROLE
rhaas=# select * from pg_authid where rolname in ('bob', 'fred',
'harry') order by rolname;
rolname | rolsuper | rolinherit | rolcreaterole | rolcreatedb |
rolcatupdate | rolcanlogin | rolreplication | rolconnlimit |
rolpassword | rolvaliduntil
-+--++---+-+--+-++--+-+---
bob | f| t | f | f | f
| t | f | -1 | |
fred| t| t | f | f | t
| t | f | -1 | |
harry | t| t | f | f | t
| t | t | -1 | |
(3 rows)
One difference is that, AFAIK, there's no DDL command to change
rolcatupdate separately from rolsuper. If we do decide to change the
behavior, we'd better carefully document that if you want to make
someone a superuser without giving them replication privileges (or
revoke their superuser status without revoking replication
privileges), you need to specify both ALTER TABLE options.
All in all I'm somewhat inclined to think we should just patch the
docs. 9.1 hasn't been out for very long, so maybe expectations aren't
too settled yet, but changing security-critical behavior in back
branches doesn't seem like a wonderful idea; and I think I mildly
prefer the current semantics to the proposed ones.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6264: Superuser does not have inherent Replication permission
Robert Haas writes: > ... If we do decide to change the > behavior, we'd better carefully document that if you want to make > someone a superuser without giving them replication privileges (or > revoke their superuser status without revoking replication > privileges), you need to specify both ALTER TABLE options. You'd also have to be careful about processing-order dependencies; consider ALTER USER joe NOREPLICATION SUPERUSER; which would do the wrong thing with a naive implementation. > All in all I'm somewhat inclined to think we should just patch the > docs. 9.1 hasn't been out for very long, so maybe expectations aren't > too settled yet, but changing security-critical behavior in back > branches doesn't seem like a wonderful idea; and I think I mildly > prefer the current semantics to the proposed ones. +1 regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
On 28/10/11 02:13, Heikki Linnakangas wrote: On 27.10.2011 15:57, Robert Young wrote: But,I think insistence of hard-coding should be even worse than broken configuration. And hard-coding should never be a good work ethics of a professional programmer. You're exaggerating. There's nothing wrong hard-coding things like number of seconds in a minute (60). While it's not as cast in stone as 60 seconds in a minute, I don't see anything wrong with hardcoding that "localhost" means the local host. BTW, do we have anything in place to stop any user on the same host to send bogus stat messages to the stats collector? Actually, a minute is not always 60 seconds, as you can legally have 62 seconds in a minute! From the documentation for the Java class *java.util.Date*: [...] A second is represented by an integer from 0 to 61; the values 60 and 61 occur only for leap seconds and even then only in Java implementations that actually track leap seconds correctly. Because of the manner in which leap seconds are currently introduced, it is extremely unlikely that two leap seconds will occur in the same minute, but this specification follows the date and time conventions for ISO C. [...] Cheers, Gavin
Re: [BUGS] Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
Gavin Flower writes: > Actually, a minute is not always 60 seconds, as you can legally have 62 > seconds in a minute! There never have been, and will never be, two leap seconds declared in the same minute --- the need for such would require that the authorities in charge of declaring leap seconds had been asleep at the switch when they should have declared the first one, and for awhile afterwards as well, since the natural spacing of such events is well over a year. Even if they did get that far behind, they would catch up by declaring *one* added leap second in several successive opportunities. The idea that there could need to be 62 seconds in a minute appears to stem from a typographical error in an ancient version of some Unix documentation or other (hardly a reference material for timekeeping), which has been faithfully copied into a bunch of later computer-oriented standards. But it's wrong, no matter how many places say that. Ask an astronomer rather than a computer scientist, if you're not convinced. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #6264: Superuser does not have inherent Replication permission
On Thu, Oct 27, 2011 at 01:45:34PM -0400, Robert Haas wrote: > On Tue, Oct 25, 2011 at 8:39 AM, Magnus Hagander wrote: > > On Mon, Oct 24, 2011 at 16:37, Keith Fiske wrote: > >> On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane wrote: > >>> "Keith Fiske" writes: > >> > If you create a user as a NONsuperuser, > then later ALTER them to be one, they will NOT have the replication > permission and cannot be used as a replication user until you explicitly > grant that permission. > >>> > >>> That doesn't sound to me like a bug. ?These flags are independent, we > >>> just provide a certain default at role creation time. > >>> > >> > >> That is not what the documentation as read would lead people to > >> believe. I'd be more than happy to help with clarifying the > >> documentation myself if needed. Just let me know how. > > > > This part I agree with - it makes sense for ALTER to set both flags > > when it enables superuser. It seems inconsistent now - even if it may > > be technically correct. > > > > If we don't change it, we should definitely accept a docs patch to > > clarify what happens, because I agree it's confusing. > > There's a pre-existing catalog flag called rolcatupdate that works a > little bit like this, and we discussed making rolreplication behave > similarly. But we ended up with different semantics: [ALTER ROLE sets rolcatupdate = rolsuper when changing rolsuper.] > One difference is that, AFAIK, there's no DDL command to change > rolcatupdate separately from rolsuper. If we do decide to change the > behavior, we'd better carefully document that if you want to make > someone a superuser without giving them replication privileges (or > revoke their superuser status without revoking replication > privileges), you need to specify both ALTER TABLE options. Let's look at the behavior of DDL-exposed access constraints for precedent. We currently have three paradigms for applying access control to superusers: 1. Settings that affect superusers and regular users identically. These include ALTER ROLE ... LOGIN | VALID UNTIL. 2. Rights that superusers possess implicitly and irrevocably; the actual setting recorded in pg_authid or elsewhere has no effect. These include GRANT ... ON TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. I think we should merge #3 into #2; nothing about the REPLICATION setting justifies a distinct paradigm. On a clean slate, #1 might be an equally suitable fit. However, #2 provides better backward compatibility with 9.0. > All in all I'm somewhat inclined to think we should just patch the > docs. 9.1 hasn't been out for very long, so maybe expectations aren't > too settled yet, but changing security-critical behavior in back > branches doesn't seem like a wonderful idea; and I think I mildly > prefer the current semantics to the proposed ones. The implication of my proposal is to remove the possibility of creating a superuser that cannot connect for replication; users so restricted under 9.1.1 would suddenly be able to make replication connections in 9.1.2. Of course, they could already "ALTER ROLE myself REPLICATION". On that account, no secure system would quietly become insecure following such an upgrade. nm -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: BUG #6264: Superuser does not have inherent Replication permission
Noah Misch writes: > Let's look at the behavior of DDL-exposed access constraints for precedent. > We > currently have three paradigms for applying access control to superusers: > 1. Settings that affect superusers and regular users identically. These > include > ALTER ROLE ... LOGIN | VALID UNTIL. > 2. Rights that superusers possess implicitly and irrevocably; the actual > setting > recorded in pg_authid or elsewhere has no effect. These include GRANT ... ON > TABLE and ALTER ROLE ... CREATEDB | CREATEROLE. > 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE > ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION. > I think we should merge #3 into #2; nothing about the REPLICATION setting > justifies a distinct paradigm. Yeah, there's much to be said for that. I thought the notion of a privilege that superusers might not have was pretty bogus to start with. rolcatupdate isn't a very good precedent to rely on because it's never been documented or used to any noticeable extent, so there's no reason to think that it provides a tested-and-accepted behavior. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6273: Install Error
On 27/10/2011 9:46 PM, Justin wrote: The following bug has been logged online: Bug reference: 6273 Logged by: Justin Email address: just...@steinhafels.com PostgreSQL version: 9.1.1 Operating system: Windows Server 2003 Description:Install Error Details: On installation, it throws on error stating database cluster initialization failed. I was wondering what the fix for this issue would be. Not enough information. Please try: http://wiki.postgresql.org/wiki/Troubleshooting_Installation -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6269: Anomaly detection
A few updates from my side: Kevin helped me find two bugs in my test suite. The first: the test suite had a syntax error in setting the isolation level, which resulted in not setting an isolation level at all. Secondly, I made a mistake in the phantom detection code, which resulted in detecting phantoms when there where no phantoms. Afterwards, all tests where repeated on PostgreSQL 9.1.1 with no strange results by both Kevin and me. The results in my earlier posted report can therefore be marked as incorrect. Thanks for the support and replies on my work. -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-6269-Anomaly-detection-tp4936233p4944490.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6275: Horrible performance regression
The following bug has been logged online: Bug reference: 6275 Logged by: Finlay Thompson Email address: fin...@dragonfly.co.nz PostgreSQL version: 8.4.9 Operating system: Ubuntu 11.04 Description:Horrible performance regression Details: After an upgrade from 8.4.8 to 8.4.9 performance of load script went from ~ 3 hours to not finishing after 24 hours. Context: We have a continuous build script, that loads, grooms, matches data every few hours. The script has been run over 100 times in the last few weeks, and has steadily been taking around 3 hours. It is really a group of scripts, something like 15000 lines of sql, and some python scripts to run it together. After upgrading the postgresql*-8.4 packages on ubuntu, to version 8.4.9, the script suddenly stopped working, and consuming all the ram (16GB) on the computer (i7). I spent about a day trying to diagnose the problem, with some help from #postgresql, and ran through the script step by step, but was unable to find any specific issue. Today I reinstalled the 8.4.8 version, and it built the database in 3:02 hours, as before. >From this, I reckon something is broken in the 8.4.9 release. I would love to isolate the problem, and am happy to try anything people suggest. Sorry I can't be more specific about the problem, but I thought I should report the issue. btw: The database uses plpython and postgis. Regards, Finlay Thompson -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6275: Horrible performance regression
"Finlay Thompson" writes: > After an upgrade from 8.4.8 to 8.4.9 performance of load script went from ~ > 3 hours to not finishing after 24 hours. > Context: We have a continuous build script, that loads, grooms, matches data > every few hours. The script has been run over 100 times in the last few > weeks, and has steadily been taking around 3 hours. It is really a group of > scripts, something like 15000 lines of sql, and some python scripts to run > it together. > After upgrading the postgresql*-8.4 packages on ubuntu, to version 8.4.9, > the script suddenly stopped working, and consuming all the ram (16GB) on the > computer (i7). Well, the most likely theory seems to be that one of the planner changes in 8.4.9 is resulting in a much less optimal plan choice for one or more queries, but it's impossible to diagnose it on the basis of this much information. > btw: The database uses plpython and postgis. Hmm, did you change postgis versions at the same time? If so, which upgrade caused the problem, postgres or postgis? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
