Let's drop two obsolete features which are bear-traps for novices
PostgreSQL has two bits of obsolete, incomplete functionality which
entrap and frustrate new users in large numbers. Both of these features
share the following characteristics:
* added more than 10 years ago
* have the same names as useful features from other databases
* were never finished and lack critical functionality
* have not seen significant work in the last 4 releases
Every other day on IRC I run into a newbie who has used one of these
features under the mistaken impression that it is useful, and then had
to be guided in how to get their data out of this broken feature at some
length. Unknown are the number of users who didn't ask for help but
simply chose to use a different database instead.
Of course, I'm talking about the MONEY type and hash indexes (not the
hash ops class, which is useful, just the index type). It's time to put
both of these features out to pasture. Certainly neither of theise
features would be accepted into PostgreSQL today given the shape they're in.
Having these broken features around is like leaving an armed bear-trap
in a public park.
Now, I know the first thing someone will do is jump up and claim that
they were just about to fix WAL-logging on hash indexes, or add casts to
the money type. But if that hasn't happened in the last 5 years, it's
not going to happen.
We'd be doing our users a huge favor by just removing them in 9.5.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
Of course, I'm talking about the MONEY type and hash indexes (not the
hash ops class, which is useful, just the index type). It's time to put
both of these features out to pasture. Certainly neither of theise
features would be accepted into PostgreSQL today given the shape they're in.
I don't care one way or the other about the money type, but I will defend
hash indexes, especially seeing that we've already added a pretty
in-your-face warning as of 9.5:
regression=# create table foo(f1 int);
CREATE TABLE
regression=# create index on foo using hash (f1);
WARNING: hash indexes are not WAL-logged and their use is discouraged
CREATE INDEX
Now, I know the first thing someone will do is jump up and claim that
they were just about to fix WAL-logging on hash indexes,
I don't know if/when that will happen as such, but Simon was making noises
about writing code to treat hash indexes as unlogged automatically, which
would more or less fix the worst risks. That's not just a special case
for hash indexes, but any index AM that lacks WAL support, as third-party
AMs might well do.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 31, 2014 at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I don't know if/when that will happen as such, but Simon was making noises
about writing code to treat hash indexes as unlogged automatically, which
would more or less fix the worst risks. That's not just a special case
for hash indexes, but any index AM that lacks WAL support, as third-party
AMs might well do.
As someone writing a 3rd-party AM, literally right this moment, do you have
a link to that thread? While I follow this list fairly closely I don't
remember seeing this. I'd love to understand the thoughts around handling
extension-based AMs.
eric
Hi,
On Sat, Nov 1, 2014 at 1:21 PM, Eric Ridge <eebbrr@gmail.com> wrote:
On Fri, Oct 31, 2014 at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I don't know if/when that will happen as such, but Simon was making noises
about writing code to treat hash indexes as unlogged automatically, which
would more or less fix the worst risks. That's not just a special case
for hash indexes, but any index AM that lacks WAL support, as third-party
AMs might well do.As someone writing a 3rd-party AM, literally right this moment, do you have
a link to that thread? While I follow this list fairly closely I don't
remember seeing this. I'd love to understand the thoughts around handling
extension-based AMs.
You are looking for this:
/messages/by-id/CAPpHfdsXwZmojm6Dx+TJnpYk27kT4o7Ri6X_4OSWcByu1Rm+VA@mail.gmail.com
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/31/2014 03:07 PM, Tom Lane wrote:
I don't care one way or the other about the money type, but I will defend
hash indexes, especially seeing that we've already added a pretty
in-your-face warning as of 9.5:regression=# create table foo(f1 int);
CREATE TABLE
regression=# create index on foo using hash (f1);
WARNING: hash indexes are not WAL-logged and their use is discouraged
CREATE INDEX
Yes, and I'm arguing that is the wrong decision. If hash indexes are
"discouraged", then they shouldn't be in core in the first place.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WMf320d8cb2db549bd50c102f339d77593bf68219af6e8c140e9c245b2d0f8aac9b43eef3eb080fcaa0888804c37b385a7@asav-2.01.com
On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
On 10/31/2014 03:07 PM, Tom Lane wrote:
I don't care one way or the other about the money type, but I will defend
hash indexes, especially seeing that we've already added a pretty
in-your-face warning as of 9.5:regression=# create table foo(f1 int);
CREATE TABLE
regression=# create index on foo using hash (f1);
WARNING: hash indexes are not WAL-logged and their use is discouraged
CREATE INDEXYes, and I'm arguing that is the wrong decision. If hash indexes are
"discouraged", then they shouldn't be in core in the first place.
Last time we discussed it there were people (IIRC Andrew was one of
them) commenting that they use hash indexes *precisely* because they're
not WAL logged and that they can live with the dangers that creates. I
don't think that's sufficient justification for introducing the feature
at all. But it's nothing new that removing a feature has to fit quite
different criteria than adding one.
So, by that argument we could remove hash indexes once we have unlogged
indexes on logged tables. But then there's no need to remove them
anymore...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
On 10/31/2014 03:07 PM, Tom Lane wrote:
I don't care one way or the other about the money type, but I will defend
hash indexes, especially seeing that we've already added a pretty
in-your-face warning as of 9.5:regression=# create table foo(f1 int);
CREATE TABLE
regression=# create index on foo using hash (f1);
WARNING: hash indexes are not WAL-logged and their use is discouraged
CREATE INDEX
Yes, and I'm arguing that is the wrong decision. If hash indexes are
"discouraged", then they shouldn't be in core in the first place.
There's an awful lot of stuff in core that probably shouldn't be there,
but we've not made a move to rip it out, especially not if there wasn't
a way to make it an external module.
In the case of hash indexes, because we still have to have the hash
opclasses in core, there's no way that it could be pushed out as an
extension module even if we otherwise had full support for AMs as
extensions. So what I hear you proposing is "let's break this so
thoroughly that it *can't* be fixed". I'm not on board with that.
I think the WARNING will do just fine to discourage novices who are
not familiar with the state of the hash AM. In the meantime, we
could push forward with the idea of making hash indexes automatically
unlogged, so that recovering from a crash wouldn't be quite so messy/
dangerous.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
Yes, and I'm arguing that is the wrong decision. If hash indexes are
"discouraged", then they shouldn't be in core in the first place.
Last time we discussed it there were people (IIRC Andrew was one of
them) commenting that they use hash indexes *precisely* because they're
not WAL logged and that they can live with the dangers that creates. I
don't think that's sufficient justification for introducing the feature
at all. But it's nothing new that removing a feature has to fit quite
different criteria than adding one.
So, by that argument we could remove hash indexes once we have unlogged
indexes on logged tables. But then there's no need to remove them
anymore...
Yeah. When we last discussed this, the difficulty was around how to make
that combination work. An unlogged index on an unlogged table is no
problem: the init-fork mechanism is able to make them both go to empty
after a crash. But for an unlogged index on a logged table, just making
the index go to empty is not the correct recovery action.
We'd been wondering how to make crash recovery change the index's pg_index
entry into not indisvalid/indisready status. That's hard to do. But
maybe we don't have to. What about having the init-fork mechanism restore
a hash index into a state with the metapage marked as invalid? hashinsert
etc could simply do nothing when they see this metapage state.
hashgettuple could throw an error saying the index isn't usable until it's
been REINDEXed.
This is not quite as nice as an indisvalid-based solution, because it
requires some extra cooperation from the index AM's code. But setting up
an init fork requires work from the index AM anyway, so that objection
doesn't seem terribly strong to me.
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-11-01 13:58:02 -0400, Tom Lane wrote:
Yeah. When we last discussed this, the difficulty was around how to make
that combination work. An unlogged index on an unlogged table is no
problem: the init-fork mechanism is able to make them both go to empty
after a crash. But for an unlogged index on a logged table, just making
the index go to empty is not the correct recovery action.
Just removing the relfilenode would probably be better than what we have
today. It sure is pretty unsatisfactory to get a ERROR after a
crash/immediate restart, but it's far better than getting wrong results
back (or even crash).
We'd been wondering how to make crash recovery change the index's pg_index
entry into not indisvalid/indisready status. That's hard to do.
It really is hard.
What I've been wondering about whether we should be boring and do it on
backend startup. Roughly similar to the way the relcache init file is
handled. The first backend that starts up for a certain database* scans
pg_index and rechecks all unlogged indexes of logged tables and marks
them as invalid.
* There's a couple ways we could detect that. The most trivial is to
just have a 'initialized' marker file in the database whose presence we
test on startup. That's probably acceptable costwise in comparison to
all the other stuff happening at backend init. We could get more fancy,
but it's probably not needed.
But
maybe we don't have to. What about having the init-fork mechanism restore
a hash index into a state with the metapage marked as invalid? hashinsert
etc could simply do nothing when they see this metapage state.
hashgettuple could throw an error saying the index isn't usable until it's
been REINDEXed.
This is not quite as nice as an indisvalid-based solution, because it
requires some extra cooperation from the index AM's code. But setting up
an init fork requires work from the index AM anyway, so that objection
doesn't seem terribly strong to me.
The most annoying thing I see with that kind of approach is that we'd
need to read the metapage pretty early during planning. The second most
annoying is that it's harder to for the user to detect which indexes are
in that state - we'd probably need to provide a SQL level function to
detect it.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/01/2014 01:26 PM, Andres Freund wrote:
On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
On 10/31/2014 03:07 PM, Tom Lane wrote:
I don't care one way or the other about the money type, but I will defend
hash indexes, especially seeing that we've already added a pretty
in-your-face warning as of 9.5:regression=# create table foo(f1 int);
CREATE TABLE
regression=# create index on foo using hash (f1);
WARNING: hash indexes are not WAL-logged and their use is discouraged
CREATE INDEXYes, and I'm arguing that is the wrong decision. If hash indexes are
"discouraged", then they shouldn't be in core in the first place.Last time we discussed it there were people (IIRC Andrew was one of
them) commenting that they use hash indexes *precisely* because they're
not WAL logged and that they can live with the dangers that creates. I
don't think that's sufficient justification for introducing the feature
at all. But it's nothing new that removing a feature has to fit quite
different criteria than adding one.So, by that argument we could remove hash indexes once we have unlogged
indexes on logged tables. But then there's no need to remove them
anymore...
Yes, although there might not be much reason to use them either. I think
Tom's first step of making hash indexes automatically unlogged makes
sense. Longer term I'd like to see unlogged as an option for all AMs -
especially btree. It makes plenty of sense to me to be able to make the
data resilient even if the indexes, which can after all be recreated in
the unlikely event of a crash, are not.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-11-01 14:13:02 -0400, Andrew Dunstan wrote:
Yes, although there might not be much reason to use them either. I think
Tom's first step of making hash indexes automatically unlogged makes sense.
Longer term I'd like to see unlogged as an option for all AMs - especially
btree.
If we implement unlogged indexes, it should definitely work for all
builtin indexes.
It makes plenty of sense to me to be able to make the data resilient
even if the indexes, which can after all be recreated in the unlikely event
of a crash, are not.
While I agree that it can be useful, I think the fact that replicas/HS
can't use such index makes them far less useful.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/01/2014 01:58 PM, Tom Lane wrote:
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
Yes, and I'm arguing that is the wrong decision. If hash indexes are
"discouraged", then they shouldn't be in core in the first place.Last time we discussed it there were people (IIRC Andrew was one of
them) commenting that they use hash indexes *precisely* because they're
not WAL logged and that they can live with the dangers that creates. I
don't think that's sufficient justification for introducing the feature
at all. But it's nothing new that removing a feature has to fit quite
different criteria than adding one.
So, by that argument we could remove hash indexes once we have unlogged
indexes on logged tables. But then there's no need to remove them
anymore...Yeah. When we last discussed this, the difficulty was around how to make
that combination work. An unlogged index on an unlogged table is no
problem: the init-fork mechanism is able to make them both go to empty
after a crash. But for an unlogged index on a logged table, just making
the index go to empty is not the correct recovery action.We'd been wondering how to make crash recovery change the index's pg_index
entry into not indisvalid/indisready status. That's hard to do. But
maybe we don't have to. What about having the init-fork mechanism restore
a hash index into a state with the metapage marked as invalid? hashinsert
etc could simply do nothing when they see this metapage state.
hashgettuple could throw an error saying the index isn't usable until it's
been REINDEXed.This is not quite as nice as an indisvalid-based solution, because it
requires some extra cooperation from the index AM's code. But setting up
an init fork requires work from the index AM anyway, so that objection
doesn't seem terribly strong to me.Thoughts?
Isn't the planner still going to try to use the index in that case? If
it's not then I'd be OK with it, but if it's going to make the table
largely unusable until it's reindexed that would be rather sad.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-11-01 13:58:02 -0400, Tom Lane wrote:
maybe we don't have to. What about having the init-fork mechanism restore
a hash index into a state with the metapage marked as invalid? hashinsert
etc could simply do nothing when they see this metapage state.
hashgettuple could throw an error saying the index isn't usable until it's
been REINDEXed.
The most annoying thing I see with that kind of approach is that we'd
need to read the metapage pretty early during planning.
No, I was specifically *not* proposing that. What I proposed was if the
planner picks the index for use in a query, you get an error.
Yeah, if we were trying to duplicate the behavior of indisvalid, there'd
need to be a way to detect the invalid index at plan time and not use it.
But I'm not sure that that's actually an improvement from the user's
standpoint: what they'd see is queries suddenly, and silently, performing
a lot worse than they expect. An explicit complaint about the necessary
REINDEX seems more user-friendly from where I sit.
However, if the consensus is that silently ignoring the index is the best
behavior, I would not be too concerned about the cost of checking the
metapage to see if the index is valid. A hash index's metapage would tend
to stay pinned in shared buffers anyway, because it's necessarily touched
on each use of the index. If that opinion proves wrong, the AM could take
steps to cache the state in the index's relcache entry (btree already
maintains similar cached state).
The second most
annoying is that it's harder to for the user to detect which indexes are
in that state - we'd probably need to provide a SQL level function to
detect it.
Sure, we could do that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-11-01 14:19:22 -0400, Andrew Dunstan wrote:
Isn't the planner still going to try to use the index in that case? If it's
not then I'd be OK with it, but if it's going to make the table largely
unusable until it's reindexed that would be rather sad.
Both the planner (for querying) and the executor (to avoid inserting
tuples into the index) would have to query the state of such indexes. I
don't think it can reasonably work otherwise.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-11-01 14:19:22 -0400, Andrew Dunstan wrote:
Isn't the planner still going to try to use the index in that case? If it's
not then I'd be OK with it, but if it's going to make the table largely
unusable until it's reindexed that would be rather sad.
Both the planner (for querying) and the executor (to avoid inserting
tuples into the index) would have to query the state of such indexes. I
don't think it can reasonably work otherwise.
The executor doesn't need to know anything, since the AM can trivially
make aminsert be a no-op if the index is internally invalid. The planner
only needs to know something if we think that silently being slow for a
query meant to search the index is better than throwing an error reminding
the user that the index needs to be reindexed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-11-01 14:23:07 -0400, Tom Lane wrote:
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-11-01 13:58:02 -0400, Tom Lane wrote:
maybe we don't have to. What about having the init-fork mechanism restore
a hash index into a state with the metapage marked as invalid? hashinsert
etc could simply do nothing when they see this metapage state.
hashgettuple could throw an error saying the index isn't usable until it's
been REINDEXed.The most annoying thing I see with that kind of approach is that we'd
need to read the metapage pretty early during planning.No, I was specifically *not* proposing that. What I proposed was if the
planner picks the index for use in a query, you get an error.
Ugh. I think that'll be pretty ugly. At the very least we'd need to
provide a way to mark such indexes as 'actually invalid' in the sense of
indisready. It'll not only block queries that sensibly would end up
using that index, but also all modifications - making the relation
essentially read only.
If we just want this, we can just remove the main fork of such relations
on startup, and not bother with index specific stuff.
Yeah, if we were trying to duplicate the behavior of indisvalid, there'd
need to be a way to detect the invalid index at plan time and not use it.
But I'm not sure that that's actually an improvement from the user's
standpoint: what they'd see is queries suddenly, and silently, performing
a lot worse than they expect. An explicit complaint about the necessary
REINDEX seems more user-friendly from where I sit.
A REINDEX is imo unlikely to be acceptable. It takes long (why would you
bother on a small table?) and locks the relation/indexes.
However, if the consensus is that silently ignoring the index is the best
behavior, I would not be too concerned about the cost of checking the
metapage to see if the index is valid. A hash index's metapage would tend
to stay pinned in shared buffers anyway, because it's necessarily touched
on each use of the index. If that opinion proves wrong, the AM could take
steps to cache the state in the index's relcache entry (btree already
maintains similar cached state).
We also could just put it in the generic relcache code...
Yea.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
A REINDEX is imo unlikely to be acceptable. It takes long (why would you
bother on a small table?) and locks the relation/indexes.
I think the goalposts just took a vacation to Acapulco.
What exactly do you think is going to make a crashed unlogged index valid
again without a REINDEX? Certainly the people who are currently using
hash indexes in the way Andrew describes are expecting to have to REINDEX
them after a crash.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-11-01 14:39:21 -0400, Tom Lane wrote:
Andres Freund <andres@2ndquadrant.com> writes:
A REINDEX is imo unlikely to be acceptable. It takes long (why would you
bother on a small table?) and locks the relation/indexes.I think the goalposts just took a vacation to Acapulco.
I think that might be caused by a misunderstanding.
What exactly do you think is going to make a crashed unlogged index valid
again without a REINDEX? Certainly the people who are currently using
hash indexes in the way Andrew describes are expecting to have to REINDEX
them after a crash.
Obviously that individual index needs to be recreated. What I mean is
that I don't think it'll be acceptable that the table essentially can't
be queried before that's done. The situations in which I'd found
unlogged indexes useful is where there's some indexes are critical for
the OLTP business (those would continue to be logged), but some other
large ones are for things that aren't absolutely essential. Reports and
such.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/01/2014 02:34 PM, Andres Freund wrote:
Yeah, if we were trying to duplicate the behavior of indisvalid, there'd
need to be a way to detect the invalid index at plan time and not use it.
But I'm not sure that that's actually an improvement from the user's
standpoint: what they'd see is queries suddenly, and silently, performing
a lot worse than they expect. An explicit complaint about the necessary
REINDEX seems more user-friendly from where I sit.A REINDEX is imo unlikely to be acceptable. It takes long (why would you
bother on a small table?) and locks the relation/indexes.
It's a bit of a pity we don't have REINDEX CONCURRENTLY.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-11-01 14:39:21 -0400, Tom Lane wrote:
What exactly do you think is going to make a crashed unlogged index valid
again without a REINDEX? Certainly the people who are currently using
hash indexes in the way Andrew describes are expecting to have to REINDEX
them after a crash.
Obviously that individual index needs to be recreated. What I mean is
that I don't think it'll be acceptable that the table essentially can't
be queried before that's done. The situations in which I'd found
unlogged indexes useful is where there's some indexes are critical for
the OLTP business (those would continue to be logged), but some other
large ones are for things that aren't absolutely essential. Reports and
such.
Sure. And as long as you aren't issuing queries that would want to scan
the crashed index, it won't matter either way. The question is whether
you'd rather that your "inessential reporting queries" fail without the
broken index, or that they take extreme amounts of time/resources.
I don't think it's obvious that the first alternative is bad.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
