[bug fix] pg_ctl always uses the same event source

From: "MauMau" <maumau307@gmail.com>

I've removed a limitation regarding event log on Windows with the attached
patch. I hesitate to admit this is a bug fix and want to regard this an
improvement, but maybe it's a bug fix from users' perspective. Actually,
I
received problem reports from some users.

I've done a small correction. I removed redundant default value from the
pg_ctl.c.

Regards
MauMau

On Sun, Dec 8, 2013 at 3:41 AM, MauMau <maumau307@gmail.com> wrote:

From: "MauMau" <maumau307@gmail.com>

I've removed a limitation regarding event log on Windows with the attached

patch. I hesitate to admit this is a bug fix and want to regard this an
improvement, but maybe it's a bug fix from users' perspective. Actually,
I
received problem reports from some users.

I've done a small correction. I removed redundant default value from the
pg_ctl.c.

Not having looked at it in detail yet, but this seems to completely remove
the default value. What happens if the error that needs to be logged is the
one saying that it couldn't exec postgres to find out the value in the
config file? AFAICT it's going to try to register an eventsource with
whatever random garbage happens to be in the variable.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

From: "Magnus Hagander" <magnus@hagander.net>

Not having looked at it in detail yet, but this seems to completely remove
the default value. What happens if the error that needs to be logged is
the
one saying that it couldn't exec postgres to find out the value in the
config file? AFAICT it's going to try to register an eventsource with
whatever random garbage happens to be in the variable.

Thank you for commenting, Magnus san.
The variable is global and contains an empty string, so even in the unlikely
situation where postgres -C fails, the event source simply becomes blank.

Regards
MauMau

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

On Mon, Dec 9, 2013 at 2:25 AM, MauMau <maumau307@gmail.com> wrote:

From: "Magnus Hagander" <magnus@hagander.net>

Not having looked at it in detail yet, but this seems to completely remove
the default value. What happens if the error that needs to be logged is
the
one saying that it couldn't exec postgres to find out the value in the
config file? AFAICT it's going to try to register an eventsource with
whatever random garbage happens to be in the variable.

Thank you for commenting, Magnus san.
The variable is global and contains an empty string, so even in the unlikely
situation where postgres -C fails, the event source simply becomes blank.

1. isn't it better to handle as it is done in write_eventlog() which
means if string is empty then
use PostgreSQL.
"evtHandle = RegisterEventSource(NULL, event_source ? event_source :
"PostgreSQL");"

2. What will happen if user doesn't change the name in "event_source"
or kept the same name,
won't it hit the same problem again? So shouldn't it try to
generate different name by appending
version string to it?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

From: "Amit Kapila" <amit.kapila16@gmail.com>

1. isn't it better to handle as it is done in write_eventlog() which
means if string is empty then
use PostgreSQL.
"evtHandle = RegisterEventSource(NULL, event_source ? event_source :
"PostgreSQL");"

Thank you for reviewing. Yes, I did so with the first revision of this
patch (see the first mail of this thread.) I wanted to avoid duplicating
the default value in both the server and pg_ctl code. If user does not set
event_source, postgres -C returns the default value "PostgreSQL" in the
normal case, so I wanted to rely on it. I thought the second revision would
be appreciated by PostgreSQL-based products like EnterpriseDB, because there
are fewer source files to modify. But I don't mind which revision will be
adopted.

2. What will happen if user doesn't change the name in "event_source"
or kept the same name,
won't it hit the same problem again? So shouldn't it try to
generate different name by appending
version string to it?

Yes, but I assume that the user has to set his own name to identify his
instance uniquely. Even if version string is added, the same issue can
happen --- in the likely case where the user explicitly installs, for
example, PostgreSQL 9.3 as a standalone database, as well as some packaged
application that embeds PostgreSQL 9.3 which the user is unaware of.
If the user installs multiple versions of PostgreSQL explicitly with the
community installer, the installer can set event_source = 'PostgreSQL 9.3'
and 'PostgreSQL 9.4' for each instance.

Regards
MauMau

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

On Mon, Dec 9, 2013 at 5:52 PM, MauMau <maumau307@gmail.com> wrote:

From: "Amit Kapila" <amit.kapila16@gmail.com>

1. isn't it better to handle as it is done in write_eventlog() which
means if string is empty then
use PostgreSQL.
"evtHandle = RegisterEventSource(NULL, event_source ? event_source :
"PostgreSQL");"

Thank you for reviewing. Yes, I did so with the first revision of this
patch (see the first mail of this thread.) I wanted to avoid duplicating
the default value in both the server and pg_ctl code. If user does not set
event_source, postgres -C returns the default value "PostgreSQL" in the
normal case, so I wanted to rely on it.

I think it is better to keep it like what I suggested above,
because in that case
it will assign default name even if postgres -C fails due to some reason.

2. What will happen if user doesn't change the name in "event_source"
or kept the same name,
won't it hit the same problem again? So shouldn't it try to
generate different name by appending
version string to it?

Yes, but I assume that the user has to set his own name to identify his
instance uniquely. Even if version string is added, the same issue can
happen --- in the likely case where the user explicitly installs, for
example, PostgreSQL 9.3 as a standalone database, as well as some packaged
application that embeds PostgreSQL 9.3 which the user is unaware of.

I mentioned it just to make sure that if such things can happen, it
is good to
either avoid it or document it in some way, so that user can
understand better
how to configure his system.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

From: "Amit Kapila" <amit.kapila16@gmail.com>

I think it is better to keep it like what I suggested above,
because in that case
it will assign default name even if postgres -C fails due to some
reason.

2. What will happen if user doesn't change the name in "event_source"
or kept the same name,
won't it hit the same problem again? So shouldn't it try to
generate different name by appending
version string to it?

I re-considered that. As you suggested, I think I'll do as follows. Would
this be OK?

[pg_ctl.c]
evtHandle = RegisterEventSource(NULL, *event_source ? event_source :
"PostgreSQL " PG_MAJORVERSION);

[guc.c]
{"event_source", PGC_POSTMASTER, LOGGING_WHERE,
...
"PostgreSQL " PG_MAJORVERSION,
NULL, NULL, NULL

[elog.c]
Writing the default value in this file was redundant, because event_source
cannot be NULL. So change

evtHandle = RegisterEventSource(NULL, event_source ? event_source :
"PostgreSQL");

to

evtHandle = RegisterEventSource(NULL, event_source);

Regards
MauMau

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

On Wed, Dec 11, 2013 at 8:31 PM, MauMau <maumau307@gmail.com> wrote:

From: "Amit Kapila" <amit.kapila16@gmail.com>

I re-considered that. As you suggested, I think I'll do as follows. Would
this be OK?

[pg_ctl.c]
evtHandle = RegisterEventSource(NULL, *event_source ? event_source :
"PostgreSQL " PG_MAJORVERSION);

[guc.c]
{"event_source", PGC_POSTMASTER, LOGGING_WHERE,
...
"PostgreSQL " PG_MAJORVERSION,
NULL, NULL, NULL

This is similar to what I had in mind.

[elog.c]
Writing the default value in this file was redundant, because event_source
cannot be NULL. So change

evtHandle = RegisterEventSource(NULL, event_source ? event_source :
"PostgreSQL");

to

evtHandle = RegisterEventSource(NULL, event_source);

I think this change might not be safe as write_eventlog() gets called
from write_stderr() which might get called
before reading postgresql.conf, so the code as exists in PG might be
to handle that case or some other similar
situation where event_source is still not set. Have you confirmed in
all ways that it is never the case that
event_source is not set when the control reaches this function.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Hi, Amit san,

From: "Amit Kapila" <amit.kapila16@gmail.com>

[elog.c]
Writing the default value in this file was redundant, because
event_source
cannot be NULL. So change

I think this change might not be safe as write_eventlog() gets called
from write_stderr() which might get called
before reading postgresql.conf, so the code as exists in PG might be
to handle that case or some other similar
situation where event_source is still not set. Have you confirmed in
all ways that it is never the case that
event_source is not set when the control reaches this function.

Yes, you are right. I considered this again after replying to your previous
mail, and found out write_stderr() calls write_eventlog(). In that case,
event_source is still NULL before GUC initialization.

Please find attached the patch.
I put the default event source name in one place -- pg_config_manual.h,
which seems the best place. This could eliminate duplicate default values
in four places: pgevent.c, pg_ctl.c, elog.c, and guc.c. Thanks to your
review and comment, the code got cleaner and correct. Thank you very much.

Regards
MauMau

On Thu, Dec 12, 2013 at 4:43 PM, MauMau <maumau307@gmail.com> wrote:

Hi, Amit san,

From: "Amit Kapila" <amit.kapila16@gmail.com>

[elog.c]
Writing the default value in this file was redundant, because
event_source
cannot be NULL. So change

I think this change might not be safe as write_eventlog() gets called
from write_stderr() which might get called
before reading postgresql.conf, so the code as exists in PG might be
to handle that case or some other similar
situation where event_source is still not set. Have you confirmed in
all ways that it is never the case that
event_source is not set when the control reaches this function.

Yes, you are right. I considered this again after replying to your previous
mail, and found out write_stderr() calls write_eventlog(). In that case,
event_source is still NULL before GUC initialization.

Few minor things:
1.
evtHandle = RegisterEventSource(NULL,
*event_source? event_source: DEFAULT_EVENT_SOURCE);

In this code, you are trying to access the value (*event_source) and
incase it is not initialised,
it will not contain the value and could cause problem, why not
directly check 'event_source'?

2. minor coding style issue
pg_ctl.c
evtHandle = RegisterEventSource(NULL,
*event_source? event_source: DEFAULT_EVENT_SOURCE);

elog.c
! evtHandle = RegisterEventSource(NULL,
! event_source ? event_source : DEFAULT_EVENT_SOURCE);

In both above usages, it is better that arguments in second line should start
inline with previous lines first argument. You can refer other places,
for ex. refer call to ReportEvent in pg_ctl.c just below
RegisterEventSource call.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

From: "Amit Kapila" <amit.kapila16@gmail.com>

Few minor things:
1.
evtHandle = RegisterEventSource(NULL,
*event_source? event_source: DEFAULT_EVENT_SOURCE);

In this code, you are trying to access the value (*event_source) and
incase it is not initialised,
it will not contain the value and could cause problem, why not
directly check 'event_source'?

event_source here is a global static char array, so it's automatically
initialized with zeros and safe to access.

2. minor coding style issue
pg_ctl.c
evtHandle = RegisterEventSource(NULL,
*event_source? event_source: DEFAULT_EVENT_SOURCE);

elog.c
! evtHandle = RegisterEventSource(NULL,
! event_source ? event_source : DEFAULT_EVENT_SOURCE);

In both above usages, it is better that arguments in second line should
start
inline with previous lines first argument. You can refer other places,
for ex. refer call to ReportEvent in pg_ctl.c just below
RegisterEventSource call.

Thanks. I passed the source files through pgindent and attached the revised
patch. Although the arguments in the second line are not in line with the
first line's arguments, that's what pgindent found good.

Regards
MauMau

On Tue, Dec 17, 2013 at 5:33 PM, MauMau <maumau307@gmail.com> wrote:

From: "Amit Kapila" <amit.kapila16@gmail.com>

Few minor things:

event_source here is a global static char array, so it's automatically
initialized with zeros and safe to access.

Right, I had missed that point.

2. minor coding style issue

Thanks. I passed the source files through pgindent and attached the revised
patch. Although the arguments in the second line are not in line with the
first line's arguments, that's what pgindent found good.

Okay, no problem.

Few other points:
-------------------------
1.
#ifdef WIN32
/* Get event source from postgresql.conf for eventlog output */
get_config_value("event_source", event_source, sizeof(event_source));
#endif

event logging is done for both win32 and cygwin env.
under hash define (Win32 || cygwin),
so event source name should also be retrieved for both
environments. Refer below in code:

#if defined(WIN32) || defined(__CYGWIN__)
static void
write_eventlog(int level, const char *line)

2.
Docs needs to be updated for default value:
http://www.postgresql.org/docs/devel/static/event-log-registration.html
http://www.postgresql.org/docs/devel/static/runtime-config-logging.html#GUC-EVENT-SOURCE

In this patch, we are planing to change default value of event_source
from PostgreSQL to PostgreSQL 9.4 (PostgreSQL PG_MAJORVERSION)
as part of fixing the issue reported in this thread.

If anyone has objection to that, please let us know now to avoid re-work
at later stage.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

From: "Amit Kapila" <amit.kapila16@gmail.com>

Few other points:
-------------------------
1.
#ifdef WIN32
/* Get event source from postgresql.conf for eventlog output */
get_config_value("event_source", event_source, sizeof(event_source));
#endif

event logging is done for both win32 and cygwin env.
under hash define (Win32 || cygwin),
so event source name should also be retrieved for both
environments. Refer below in code:

#if defined(WIN32) || defined(__CYGWIN__)
static void
write_eventlog(int level, const char *line)

2.
Docs needs to be updated for default value:
http://www.postgresql.org/docs/devel/static/event-log-registration.html
http://www.postgresql.org/docs/devel/static/runtime-config-logging.html#GUC-EVENT-SOURCE

Okay, done. Thanks. I'll update the commitfest entry this weekend.

Regards
MauMau

On Fri, Dec 20, 2013 at 5:26 PM, MauMau <maumau307@gmail.com> wrote:

From: "Amit Kapila" <amit.kapila16@gmail.com>

Few other points:

-------------------------
1.
#ifdef WIN32
/* Get event source from postgresql.conf for eventlog output */
get_config_value("event_source", event_source, sizeof(event_source));
#endif

event logging is done for both win32 and cygwin env.
under hash define (Win32 || cygwin),
so event source name should also be retrieved for both
environments. Refer below in code:

#if defined(WIN32) || defined(__CYGWIN__)
static void
write_eventlog(int level, const char *line)

2.
Docs needs to be updated for default value:
http://www.postgresql.org/docs/devel/static/event-log-registration.html

http://www.postgresql.org/docs/devel/static/runtime-config-logging.html#GUC-EVENT-SOURCE

Okay, done. Thanks. I'll update the commitfest entry this weekend.

Your changes are fine. The main part left from myside is test of this patch.
I will do that in next CF or If I get time before that, I will try to
complete it.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

On Thu, Dec 5, 2013 at 7:54 PM, MauMau <maumau307@gmail.com> wrote:

Hello,

I've removed a limitation regarding event log on Windows with the attached
patch. I hesitate to admit this is a bug fix and want to regard this an
improvement, but maybe it's a bug fix from users' perspective. Actually, I
received problem reports from some users.

[Problem]
pg_ctl always uses event source "PostgreSQL" to output messages to the event
log. Some example messages are:

server starting
server started

This causes the problems below:

1. Cannot distinguish PostgreSQL instances because they use the same event
source.

2. If you use multiple installations of PostgreSQL on the same machine,
whether they are the same or different versions, Windows event viewer
reports an error "event source not found" in the following sequence. Other
system administration software which deal with event log may show other
anomalies.
2-1 Install the first PostgreSQL (e.g. 9.3) into <dir_1>, register
<dir_1>\lib\pgevent.dll for event source "PostgreSQL", then creates
<instance_1>.
2-2 Install the second PostgreSQL (e.g. 9.2) into <dir_2> as part of some
packaged application, register <dir_2>\lib\pgevent.dll for event source
"PostgreSQL",

Today, I was trying to reproduce this issue and found that if user tries
to register event source second time with same name, we just replace
the previous event source's path in registry.
Shouldn't we try to stop user at this step only, means if he tries to
register with same event source name more than once return error,
saying event source with same name already exists?

Another thing is after register of pgevent.dll, if I just try to start
PostgreSQL
it shows below messages in EventLog. Although the message has information
about server startup, but the start of Description is something similar to
what you were reporting "event source not found".
Am I missing something?

Steps
1. installation of PostgreSQL from source code using Install.bat in
mdvc directory
2. initdb -D <data_dir>
3. regsvr32 /n /i:PostgreSQL <install_dir_path>\lib\pgevent32.dll
4. Modify postgresql.conf to set log_destination= 'eventlog'
5. pg_ctl.exe start -D ..\..\Data

Log Name: Application
Source: PostgreSQL
Date: 1/19/2014 7:49:54 PM
Event ID: 0
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: WIN-NGNN8PKIMD7
Description:
The description for Event ID 0 from source PostgreSQL cannot be found.
Either the component that raises this event is not installed on your
local computer or the installation is corrupted. You can install or
repair the component on the local computer.

If the event originated on another computer, the display information
had to be saved with the event.

The following information was included with the event:

LOG: ending log output to stderr
HINT: Future log output will go to log destination "eventlog".

the message resource is present but the message is not found in the
string/message table

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

From: "Amit Kapila" <amit.kapila16@gmail.com>

Today, I was trying to reproduce this issue and found that if user tries
to register event source second time with same name, we just replace
the previous event source's path in registry.
Shouldn't we try to stop user at this step only, means if he tries to
register with same event source name more than once return error,
saying event source with same name already exists?

I'm OK with either. If we add the check, I think that would be another
patch. However, I'm afraid the check won't be much effective, because the
packaged application then unregister and register (i.e. regsvr32 /u and then
regsvr32 /i) blindly.

Another thing is after register of pgevent.dll, if I just try to start
PostgreSQL
it shows below messages in EventLog. Although the message has information
about server startup, but the start of Description is something similar to
what you were reporting "event source not found".
Am I missing something?

Steps
1. installation of PostgreSQL from source code using Install.bat in
mdvc directory
2. initdb -D <data_dir>
3. regsvr32 /n /i:PostgreSQL <install_dir_path>\lib\pgevent32.dll

Please specify pgevent.dll, not pgevent32.dll.

Regards
MauMau

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

On Mon, Jan 20, 2014 at 4:05 AM, MauMau <maumau307@gmail.com> wrote:

From: "Amit Kapila" <amit.kapila16@gmail.com>

Today, I was trying to reproduce this issue and found that if user tries
to register event source second time with same name, we just replace
the previous event source's path in registry.
Shouldn't we try to stop user at this step only, means if he tries to
register with same event source name more than once return error,
saying event source with same name already exists?

I'm OK with either. If we add the check, I think that would be another
patch.

Do you think without this the problem reported by you is resolved completely.
User can hit same problem, if he tries to follow similar steps mentioned in
your first mail. I had tried below steps based on description in your
first mail:

Steps
1. installation of PostgreSQL from source code (master) using Install.bat in
msvc directory
2. initdb -D <data_dir>
3. regsvr32 /n /i:PostgreSQL <install_dir_path>\lib\pgevent.dll
4. Modify postgresql.conf to set log_destination= 'eventlog'
5. event_source = 'PostgreSQL'
6. pg_ctl.exe start -D ..\..\Data
7. psql -d postgres
8. Drop table t1; --try dropping some non-existant table
9. Check in Event viewer, you can find proper error.
10. NO Problem till above step.
11. Installation of PostgreSQL from source code (9.2) using Install.bat in
msvc directory
12. initdb -D <9.2_data_dir>
13. regsvr32 /n /i:PostgreSQL <install_9.2_dir_path>\lib\pgevent.dll
14. Remove 9.2 installation (i have just renamed the install folder)
15. now perform step 8 again on master (with or without restart of server)
16. Open Event Viewer, you can see the message
"event source not found"

Now this could have been avoided, if in step-13 we use different
event source name, but I think that will happen even without
this patch.

However, I'm afraid the check won't be much effective, because the
packaged application then unregister and register (i.e. regsvr32 /u and then
regsvr32 /i) blindly.

If user register/unregister different versions of pgevent.dll blindly,
then I think
any fix in this area could not prevent the error "event source not found"

Another thing is after register of pgevent.dll, if I just try to start
PostgreSQL
it shows below messages in EventLog. Although the message has information
about server startup, but the start of Description is something similar to
what you were reporting "event source not found".
Am I missing something?

Steps
1. installation of PostgreSQL from source code using Install.bat in
mdvc directory
2. initdb -D <data_dir>
3. regsvr32 /n /i:PostgreSQL <install_dir_path>\lib\pgevent32.dll

Please specify pgevent.dll, not pgevent32.dll.

Typo, I was using prevent.dll only, I think the reason is I need to restart
Event Viewer after register command.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

From: "Amit Kapila" <amit.kapila16@gmail.com>

Do you think without this the problem reported by you is resolved
completely.
User can hit same problem, if he tries to follow similar steps mentioned
in
your first mail. I had tried below steps based on description in your
first mail:

If user register/unregister different versions of pgevent.dll blindly,
then I think
any fix in this area could not prevent the error "event source not found"

OK, I'll add a check to prevent duplicate registration of the same event
source with the message:

"The specified event source is already registered."

Please correct me if there's better expression in English.

Are there any other suggestions to make this patch ready for committer? I'd
like to make all changes in one submission.

Regards
MauMau

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

On Mon, Jan 20, 2014 at 5:38 PM, MauMau <maumau307@gmail.com> wrote:

From: "Amit Kapila" <amit.kapila16@gmail.com>

Do you think without this the problem reported by you is resolved
completely.
User can hit same problem, if he tries to follow similar steps mentioned
in
your first mail. I had tried below steps based on description in your
first mail:

If user register/unregister different versions of pgevent.dll blindly,
then I think
any fix in this area could not prevent the error "event source not found"

OK, I'll add a check to prevent duplicate registration of the same event
source with the message:

"The specified event source is already registered."

Please correct me if there's better expression in English.

How about below message:

event source "<event_source_name>" is already registered.

This can make it more consistent with any other message in PG,
example create table.

Are there any other suggestions to make this patch ready for committer?

Today, I reviewed the patch again and found it okay, except a small
inconsistency which is about default event source name in
postgresql.conf, all other places it's changed except in .conf file.
Do you think it makes sense to change there as well?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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