[GENERAL] Worst case scenario of a compromised non super-user PostgreSQL user account

[Allan Kamau]

We are trying to determine the possible side effects of a rouge user account.

A web application requires a dedicated PostgreSQL database in which to
create tables and other database objects and manipulate data within
this single database. So I have created a database and made the
application's PostgreSQL login role be the owner of this database.
They however have no CREATEDB, CREATEROLE privileges and so on.

If this web application is compromised in one way or another such as
SQL injection (assuming the web application doesn't strictly make use
of parametrized queries). Or somehow the username and password stored
in the application's code are stolen. What extend of damage would the
hacker inflict.

I am assuming:
1) data and database objects may only be deleted, dropped or stolen
from only this single database as the given user role may only login
into this single database. New unwelcome database objects may also be
created in this database.
2) Possible denial of service attack where such user may run expensive
SELECT or data modification queries.

Are there other problems we may expect. Can they run any OS programs
or install any such tools, induce buffer overflows and so on.?

Regards,
Allan.

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

[GENERAL] pgfoundry news page

[Tatsuo Ishii]

Hi,

I noticed in the "the latest news" section on http://pgfoundry.org, no
news has been uploaded since September 10, last year. I know at least
pgpool-II project has made news after September 10 but It did not
appear. I am not in the position speaking for other projects, I
suspect news made by other projects were not appeared on the page.

It seems this is not the first experience of the trouble. Are there
any problems with the software of pgfoundry or with human process?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

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

Re: [GENERAL] problematic view definition

[Karsten Hilbert]

On Sun, Feb 20, 2011 at 02:31:46PM -0500, Tom Lane wrote:

> Karsten Hilbert  writes:
> > On Wed, Feb 09, 2011 at 11:12:01PM +0100, Karsten Hilbert wrote:
> >> Unfortunately I do not understand why PostgreSQL says
> >> 
> >> psql:xx.sql:14: ERROR:  could not implement UNION
> >> DETAIL:  Some of the datatypes only support hashing, while others only 
> >> support sorting.
> 
> > The solution lies in these bits:
> 
> >> pk_context | integer[]| 
> 
> > This data type can only be hashed.
> 
> >> xmin_message_inbox | xid  | 
> 
> > This data type can only be sorted.
> 
> ITYM the other way round, right?

Indeed :-)

> As of 9.1 there will be support for hashing arrays, so this particular
> problem should go away without hacks.

Great. PG is getting better by the day :-)

Anyway, I consider the "explicit cast" not really that bad
of a hack.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

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

Re: [GENERAL] password

[John R Pierce]

On 02/20/11 9:15 PM, Sachin Srivastava wrote:
In case you dont remember the password you set for user 'postgres' 
then you can change the same via "Right Click My 
Computer"-->"Manage"-> Users.. 


note that if you change it here, you also need to change it in the 
postgres service descriptor, in Control Panel->Administration 
Tools->Services



when you initially connect to postgres wtih psql or pgadmin-III, specify 
the user as `postgres` and then once connected,


CREATE USER yourname WITH PASSWORD 'somepass' createdb createrole;

and this will create a SQL account for you with that sql password, and 
give this user permission to create databases and roles (users).




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

Re: [GENERAL] multiple tables as a foreign key

[John R Pierce]

On 02/20/11 2:40 PM, matty jones wrote:
If I were to create three separate attributes for each of 
the separate titles in the seriestitle table then reference those 
attributes from their respective tables that would produce errors I 
believe, because a foreign key can't be null and not every attribute 
will have a value in every tuple.


a foreign key reference most certainly can be NULL, unless you've 
declared it NOT NULL.


The correct answer is as many separate attributes as there are different 
tables you want to reference, some of which might be NULL.




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

Re: [GENERAL] password

[Sachin Srivastava]

Hello,

Installation of postgresql requires you to enter a password for the user 
'postgres'.

 i) If the user 'postgres' is not there, it will create it and set the password 
to whatever you have provided,
 ii) If the user 'postgres' is already existing, then you have to give its 
password to move further in the installation.

You can use any account other that 'postgres' by giving CLI option 
'---serviceaccount '. See --help for more details.

In case you dont remember the password you set for user 'postgres' then you can 
change the same via "Right Click My Computer"-->"Manage"-> Users.. 

You said it rejects the password.  When ? 

And windows user are most welcome here.


On Feb 21, 2011, at 7:40 AM, Roedy Green wrote:

> I gave Postgre a password during install.  However, it always rejects
> it. I tried uninstalling, deleting all files, and reinstalling. Same
> thing.  It complains about user "roedy" (my windows id). It seems to
> me the default user is supposed to be postgres not Roedy.  Perhaps
> that is the source of the problem. I can't find anything relevant in
> the docs.
> 
> The docs talk about installing on Unix by compiling C source.  I have
> Windows 7 64 bit. I get the feeling Windows users are unwelcome.
> -- 
> Roedy Green Canadian Mind Products
> http://mindprod.com
> Refactor early. If you procrastinate, you will have
> even more code to adjust based on the faulty design.
> .
> 
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

--
Regards,
Sachin Srivastava
EnterpriseDB, the Enterprise PostgreSQL company.

[GENERAL] 回复： [GENERAL] How to make the user-defined function or type beingaccessed in the global database server?

[页公倒龙]

Thanks for your replying. But actually there are some difference database now, 
and  I really want to define the user-defined function or type one time so that 
 they can be  accessed as system-defined function or type,  how can I do? 
Thanks!
 
--
 
  
 祝好！
  
 郭逸重
   


 
 
 
-- 原始邮件 --
发件人: "Craig Ringer"; 
发送时间: 2011年2月20日(星期天) 中午12:40
收件人: "77287991"<77287...@qq.com>; 
抄送: "pgsql-general"; 
主题: Re: [GENERAL] How to make the user-defined function or type beingaccessed 
in the global database server?

 
On 02/20/2011 09:57 AM, 页公倒龙 wrote:
> hello, i had defined user-defined function and type in database A by
> using user Root.when i want to access the function and type in another
> database B by using the same user Root, but found that i could't access
> them. How to make the user-defined function or type being accessed in
> the global database server?

You probably want to use one database with multiple schema instead. See 
the manual for more information about schema.

--
Craig Ringer

[GENERAL] multiple tables as a foreign key

[matty jones]

I am not sure if this is possible but is there a way that I can have
multiple columns from different tables be a foreign key to a single column
in another table, or do I need to write a check function and if so how could
I set up a relation?

CREATE TABLE seriestitle (
seriestitle text
);
CREATE TABLE compilationtitle (
compilationtitle text PRIMARY KEY,
pubddate text NOT NULL,
isbn text  NOT NULL,
style text REFERENCES style,
storyline text REFERENCES storyline(storyline) DEFAULT '_default_',
seriestitle text REFERENCES seriestitle DEFAULT '_default_',
price text NOT NULL,
);

CREATE TABLE storytitle (
storytitle text PRIMARY KEY,
notes text DEFAULT '_default_',
);

CREATE TABLE issuetitle (
issuetitle text PRIMARY KEY,
pubdate text NOT NULL,
price text NOT NULL,
bookcover OID REFERENCES bookcover(bookcover),
compilationtitle text REFERENCES compilation(compilation) DEFAULT
'_default_',
seriestitle text REFERENCES seriestitle DEFAULT '_default_',
);
CREATE TABLE noveltitle (
noveltitle text NOT NULL,
isbn text NOT NULL,
pubdate text NOT NULL,
price text NOT NULL,
bookcover OID REFERENCES bookcover(bookcover),
seriestitle text REFERENCES seriestitle DEFAULT '_default_',
);

The seriestitle table will contain a list of all the series names that I am
collecting but I want to be able to relate them to the issuetitle,
compilationtitle, and noveltitle tables.  My thoughts were using a foreign
key to do this.  Create an attribute in seriestitle called booktitle and
have that be referenced from the other three but that doesn't seem possible
or at least I couldn't find out how in the documentation.  If I were to
create three separate attributes for each of the separate titles in the
seriestitle table then reference those attributes from their respective
tables that would produce errors I believe, because a foreign key can't be
null and not every attribute will have a value in every tuple.  In reading
about normalization a single attribute cannot contain multiple values.  For
example:

INSERT INTO issuetitle (seriestitle)
VALUES ('batman, catwoman')
;

Now the seriestitle table would contain 'batman, catwoman' for a value but
that would break normalization rules

The only thing left that I can think of is to create some sort of a function
that checks to see whether the value being entered into noveltitle,
issuetitle, or compilationtitle is contained within seriestitle but then how
would I go about relating a row from one of those three tables to a row in
seriestable from a single attribute without having to do a lot of manual
work?

Thanks.

[GENERAL] password

[Roedy Green]

I gave Postgre a password during install.  However, it always rejects
it. I tried uninstalling, deleting all files, and reinstalling. Same
thing.  It complains about user "roedy" (my windows id). It seems to
me the default user is supposed to be postgres not Roedy.  Perhaps
that is the source of the problem. I can't find anything relevant in
the docs.

The docs talk about installing on Unix by compiling C source.  I have
Windows 7 64 bit. I get the feeling Windows users are unwelcome.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Refactor early. If you procrastinate, you will have
even more code to adjust based on the faulty design.
.


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

Re: [GENERAL] problematic view definition

[Tom Lane]

Karsten Hilbert  writes:
> On Wed, Feb 09, 2011 at 11:12:01PM +0100, Karsten Hilbert wrote:
>> Unfortunately I do not understand why PostgreSQL says
>> 
>> psql:xx.sql:14: ERROR:  could not implement UNION
>> DETAIL:  Some of the datatypes only support hashing, while others only 
>> support sorting.

> The solution lies in these bits:

>> pk_context | integer[]| 

> This data type can only be hashed.

>> xmin_message_inbox | xid  | 

> This data type can only be sorted.

ITYM the other way round, right?

As of 9.1 there will be support for hashing arrays, so this particular
problem should go away without hacks.

regards, tom lane

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

Re: [GENERAL] Questions about octal vs. hex for bytea

[Reuven M. Lerner]

Thanks, everyone, for the swift and clear responses.  It's good to know 
that I did understand things correctly!


Reuven

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

Re: [GENERAL] problematic view definition

[Karsten Hilbert]

For the record:

On Wed, Feb 09, 2011 at 11:12:01PM +0100, Karsten Hilbert wrote:

> Attached find some table and view definitions from the
> GNUmed (www.gnumed.de) database.
> 
> Unfortunately I do not understand why PostgreSQL says
> 
>   psql:xx.sql:14: ERROR:  could not implement UNION
>   DETAIL:  Some of the datatypes only support hashing, while others only 
> support sorting.

The solution lies in these bits:

> View "dem.v_message_inbox"
>Column   |   Type   | Modifiers 
> +--+---
>  received_when  | timestamp with time zone | 
>  provider   | text | 
>  importance | integer  | 
>  category   | text | 
>  l10n_category  | text | 
>  type   | text | 
>  l10n_type  | text | 
>  comment| text | 
>  pk_context | integer[]| 

This data type can only be hashed.

>  data   | text | 
>  pk_inbox_message   | integer  | 
>  pk_staff   | integer  | 
>  pk_category| integer  | 
>  pk_type| integer  | 
>  pk_patient | integer  | 
>  is_virtual | boolean  | 
>  xmin_message_inbox | xid  | 

This data type can only be sorted.

By defining an explicit caster:

create or replace function gm.xid2int(xid)
returns integer
language 'sql'
as 'select $1::text::integer;';

and applying that to the XMIN column inside the view
definition nicely solves the "could not implement UNION".

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

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

Re: [GENERAL] Building extensions on Windows using VS2008

[Tom Lane]

deepak  writes:
> Here's the trimmed down version of the source and the Makefile (copied and
> modified from the 'cube' contrib project)
> (with which I see the error related to redefinition)

> /* myext.c */

> #include 
> #include 
> #include "postgres.h"
> #include "fmgr.h"

As was noted upthread, this ordering is pretty unsafe.  postgres.h
should always be included *first* in any C file that's meant to run in
the backend environment.  There are platforms in which failing to do so
causes crashes because of 32-vs-64-bit issues.  Not sure if this
explains your Windows issue too, but in any case the above is wrong.

> myext.o: myext.c

> clean:
> rm -f myext.o

BTW, these rules are unnecessary --- having listed myext.o in OBJS is
sufficient.

regards, tom lane

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

Re: [GENERAL] Questions about octal vs. hex for bytea

[Tom Lane]

"Reuven M. Lerner"  writes:
> My client is concerned that the internal representation has changed, and 
> is asking me for a script that will change the representation, in order 
> to save space (since hex occupies less space than octal).

This is complete nonsense.  The internal representation is just bytes.

regards, tom lane

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

Re: [GENERAL] Questions about octal vs. hex for bytea

[Radosław Smogura]

"Reuven M. Lerner"  Sunday 20 February 2011 12:31:09
> Hi, everyone.  I've got a client who is planning to upgrade from
> PostgreSQL 8.3 to 9.0 in the coming weeks.  They use a lot of tables
> with bytea columns.  They're worried about the switch from octal to hex
> formats for bytea data.
> 
> 
> Based on everything I know and have read, the change is only for
> external representations, for input and output.  Output is now by
> default in hex, but can be changed with a parameter (bytea_output) that
> provides backward compatibility.  Input can be in either octal or hex,
> with no changes needed.
> 
> 
> My client is concerned that the internal representation has changed, and
> is asking me for a script that will change the representation, in order
> to save space (since hex occupies less space than octal).  I'm not aware
> of such a need, or even the possibility for this to be done; even if the
> internal representation has changed, it'll be handled in the upgrade
> process, and doesn't need to be done with anything external.
> 
> 
> So I've told them that I don't think that anything is necessary for
> either input or output, except (perhaps) to set bytea_output in its
> backward-compatibility mode.  But I wanted to check with people here,
> just to double-check my understanding.
> 
> 
> Thanks in advance,
> 
> 
> Reuven

There is no internal change how bytea is keept or at least internally data are 
not keept in octal or hex represenation. If your client uses JDBC it's better 
to download newest driver. It should support as well hex and octal receive. It 
is safer to turn on backward compatibility. I know nothing how pg_dump will 
work to migrate data.

Regards,
Radek

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

Re: [GENERAL] Questions about octal vs. hex for bytea

[David Johnston]

Been using bytea heavily through JDBC.  In transitioning to 9.0 I've found the 
need to set the bytea_output parameter but otherwise everything else works the 
same as it did before.

As for storage space concerns I do not know for sure but the numbers cannot be 
that substantial to warrant changing an existing database unless large binary 
processing takes up a significant portion of the processing (as opposed to 
simple document storage and retrieval which is what I am doing).

David J.

-Original Message-
From: pgsql-general-ow...@postgresql.org 
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Reuven M. Lerner
Sent: Sunday, February 20, 2011 6:31 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Questions about octal vs. hex for bytea

Hi, everyone.  I've got a client who is planning to upgrade from PostgreSQL 8.3 
to 9.0 in the coming weeks.  They use a lot of tables with bytea columns.  
They're worried about the switch from octal to hex formats for bytea data.


Based on everything I know and have read, the change is only for external 
representations, for input and output.  Output is now by default in hex, but 
can be changed with a parameter (bytea_output) that provides backward 
compatibility.  Input can be in either octal or hex, with no changes needed.


My client is concerned that the internal representation has changed, and is 
asking me for a script that will change the representation, in order to save 
space (since hex occupies less space than octal).  I'm not aware of such a 
need, or even the possibility for this to be done; even if the internal 
representation has changed, it'll be handled in the upgrade process, and 
doesn't need to be done with anything external.


So I've told them that I don't think that anything is necessary for either 
input or output, except (perhaps) to set bytea_output in its 
backward-compatibility mode.  But I wanted to check with people here, just to 
double-check my understanding.


Thanks in advance,


Reuven

--
Reuven M. Lerner -- Web development, consulting, and training
Mobile: +972-54-496-8405 * US phone: 847-230-9795
Skype/AIM: reuvenlerner


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


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

Re: [GENERAL] Questions about octal vs. hex for bytea

[Andreas Kretschmer]

Reuven M. Lerner  wrote:
> So I've told them that I don't think that anything is necessary for  
> either input or output, except (perhaps) to set bytea_output in its  
> backward-compatibility mode.  But I wanted to check with people here,  
> just to double-check my understanding.

You are right, there is no other problem. I have upgraded a customer's
database from 8.3 to 9.0, it was a DRUPAL - database. Only backup &
restore and set the bytea_output - Parameter, that's all. 


Andreas
-- 
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect.  (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly."   (unknown)
Kaufbach, Saxony, Germany, Europe.  N 51.05082°, E 13.56889°

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

Re: [GENERAL] Building extensions on Windows using VS2008

[deepak]

> OK, so you're building it within the main Pg build system. Pg was
> successfully compiled, including files that use elog.h . Yet your extension
> doesn't compile, complaining about a macro/typedef conflict.
>
> This makes me wonder: what's different?
>
> Can you post the full sources of your extension, including the Makefile?
>
> --
> Craig Ringer
>

Here's the trimmed down version of the source and the Makefile (copied and
modified from the 'cube' contrib project)
(with which I see the error related to redefinition)

/* myext.c */

#include 
#include 
#include "postgres.h"
#include "fmgr.h"

#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif

PG_FUNCTION_INFO_V1(total_seconds);
PGDLLEXPORT Datum total_seconds(PG_FUNCTION_ARGS) {
PG_RETURN_INT64(0);
}


# Makefile

MODULE_big = myext
OBJS= myext.o

DATA_built = myext.sql
DATA = uninstall_myext.sql
REGRESS = myext

SHLIB_LINK += $(filter -lm, $(LIBS))

ifdef USE_PGXS
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
else
subdir = contrib/myext
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
endif


myext.o: myext.c

clean:
rm -f myext.o

[GENERAL] Questions about octal vs. hex for bytea

[Reuven M. Lerner]

Hi, everyone.  I've got a client who is planning to upgrade from 
PostgreSQL 8.3 to 9.0 in the coming weeks.  They use a lot of tables 
with bytea columns.  They're worried about the switch from octal to hex 
formats for bytea data.



Based on everything I know and have read, the change is only for 
external representations, for input and output.  Output is now by 
default in hex, but can be changed with a parameter (bytea_output) that 
provides backward compatibility.  Input can be in either octal or hex, 
with no changes needed.



My client is concerned that the internal representation has changed, and 
is asking me for a script that will change the representation, in order 
to save space (since hex occupies less space than octal).  I'm not aware 
of such a need, or even the possibility for this to be done; even if the 
internal representation has changed, it'll be handled in the upgrade 
process, and doesn't need to be done with anything external.



So I've told them that I don't think that anything is necessary for 
either input or output, except (perhaps) to set bytea_output in its 
backward-compatibility mode.  But I wanted to check with people here, 
just to double-check my understanding.



Thanks in advance,


Reuven

--
Reuven M. Lerner -- Web development, consulting, and training
Mobile: +972-54-496-8405 * US phone: 847-230-9795
Skype/AIM: reuvenlerner


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

[GENERAL] Disconnecting idle connections on timeout.

[Dmitriy Igrishin]

Hey general@,

I want the server automatically disconnects idle connections
on timeout. I've tried to find setting parameter for such setting,
but failed. Am I missing something or it is not implemented in
Postgres?

-- 
// Dmitriy.

Re: [GENERAL] Building extensions on Windows using VS2008

[Magnus Hagander]

On Sun, Feb 20, 2011 at 05:39, Craig Ringer  wrote:
> On 02/20/2011 09:38 AM, deepak wrote:
>>
>>
>>    build.pl  parses the Makefile to determine the list
>>    of sources, etc. Essentially, your extension is built using the unix
>>    Makefile.  Since you've already built Pg its self from sources you
>>    will have used build.pl  to do it (right?) and
>>    it'll be easy for you to add the contrib module and re-run.
>>
>>    The downside of this approach is that build.pl 
>>    isn't a complete Makefile parser, and is easily confused by anything
>>    but the most trivial Makefile syntax. I had problems when I was
>>    putting the crashdump module together because build.pl
>>     didn't understand ifndef .
>>
>>    --
>>    Craig Ringer
>>
>>
>> Ok, I hadn't realized that the VS build system extrapolates information
>> from unix Makefiles..
>>
>> I briefly tried adding a new contrib module for my extension and
>> re-running the VS build (src\tools\msvc\build.bat), and still get the
>> same error.
>> (about redefinition of errcode).  Somehow, it seems to me that there's
>> an inherent incompatibility..
>
> OK, so you're building it within the main Pg build system. Pg was
> successfully compiled, including files that use elog.h . Yet your extension
> doesn't compile, complaining about a macro/typedef conflict.
>
> This makes me wonder: what's different?

First check would be that you are including postgres.h *at the top* of
your files. It will bring in some defines that affects the windows
header files.

It does (through c.h) have specific handling of errcode on MSVC, for
example See around line 60.

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

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