[BUGS] BUG #4121: ERROR: could not open relation 1663/16403/469917: Invalid argument
The following bug has been logged online:
Bug reference: 4121
Logged by: Boldinov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Windows Server 2003 Standart
Description:ERROR: could not open relation 1663/16403/469917:
Invalid argument
Details:
2008-04-21 14:35:41 ERROR: could not open relation 1663/16403/469917:
Invalid argument
2008-04-21 14:35:41 STATEMENT: SELECT
_Reference130._IDRRef AS f_3,
_Reference130._Description AS f_4
FROM
_Reference130
WHERE
_Reference130._IDRRef =
'\\200"\\000\\033x0\\004\\032\\021\\334\\250\\246\\360\\024\\017_'::bytea
AND (FALSE = TRUE OR
EXISTS(
SELECT
0 AS f_2
FROM
(
SELECT
TRUE AS _f_1
) _V8TblAli1
INNER JOIN _InfoReg16060 _InfoReg16060_Q_000_T_002
ON _InfoReg16060_Q_000_T_002._Fld16061_TYPE = '\\010'::bytea AND
_InfoReg16060_Q_000_T_002._Fld16061_RTRef = '\\000\\000\\000\\236'::bytea
AND _InfoReg16060_Q_000_T_002._Fld16061_RRRef = _Reference130._OwnerIDRRef
AND _InfoReg16060_Q_000_T_002._Fld16062RRef =
'\\205Y\\011U\\377\\362\\015\\220D''_3\\367\\352\\200\\247'::bytea AND
_InfoReg16060_Q_000_T_002._Fld16063_TYPE = '\\010'::bytea AND
(_InfoReg16060_Q_000_T_002._Fld16063_RTRef ||
_InfoReg16060_Q_000_T_002._Fld16063_RRRef) IN ('\\000\\000\\0002'::bytea ||
'\\200"\\000\\033x0\\004\\032\\021\\334\\262\\273<\\265)4'::bytea,'\\000\\00
0\\0002'::bytea ||
'\\245\\230\\272~\\361\\313\\223fG\\034\\011\\207X\\325q\\016'::bytea,'\\000
\\000\\000\\324'::bytea ||
'\\257\\332\\000\\004#R\\244\\374\\021\\334\\206\\326\\355\\252j\\360'::byte
a) AND _InfoReg16060_Q_000_T_002._Fld16065 = TRUE))
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] ERROR: failed to re-find parent key in "sl_seqlog_idx" for deletion target
Hi! Hope anyone can shed some light on this. I was struck by the following error in the slony log but I believe it's not a slony error, rather that slony triggers an error in PostgreSQL. The error message is: cleanupThread: vacuum analyze sl_seqlog; - ERROR: failed to re-find parent key in "sl_seqlog_idx" for deletion target I've tried to find some posts about it and I could only find one post where Tom states that reindexing should do the trick, but there is no answer that reindexing did solve the case. The post is here: http://archives.postgresql.org/pgsql-bugs/2007-08/msg00035.php Well, it is supposed to have been fixed to version 8.2, but it's a PostgreSQL 8.2.4 x86_64 server running on Debian that triggers the error. Thank in advance! // John
Re: [BUGS] BUG #4121: ERROR: could not open relation 1663/16403/469917: Invalid argument
Try to look into base/16403/ directory and check if file 469917 exists. And run
select relname from pg_class where relfilenode=469917
to determine which relation (table) is affected.
Zdenek
PS: 8.1 version of PostgreSQL is not supported on win. Use 8.3
Boldinov napsal(a):
The following bug has been logged online:
Bug reference: 4121
Logged by: Boldinov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Windows Server 2003 Standart
Description:ERROR: could not open relation 1663/16403/469917:
Invalid argument
Details:
2008-04-21 14:35:41 ERROR: could not open relation 1663/16403/469917:
Invalid argument
2008-04-21 14:35:41 STATEMENT: SELECT
_Reference130._IDRRef AS f_3,
_Reference130._Description AS f_4
FROM
_Reference130
WHERE
_Reference130._IDRRef =
'\\200"\\000\\033x0\\004\\032\\021\\334\\250\\246\\360\\024\\017_'::bytea
AND (FALSE = TRUE OR
EXISTS(
SELECT
0 AS f_2
FROM
(
SELECT
TRUE AS _f_1
) _V8TblAli1
INNER JOIN _InfoReg16060 _InfoReg16060_Q_000_T_002
ON _InfoReg16060_Q_000_T_002._Fld16061_TYPE = '\\010'::bytea AND
_InfoReg16060_Q_000_T_002._Fld16061_RTRef = '\\000\\000\\000\\236'::bytea
AND _InfoReg16060_Q_000_T_002._Fld16061_RRRef = _Reference130._OwnerIDRRef
AND _InfoReg16060_Q_000_T_002._Fld16062RRef =
'\\205Y\\011U\\377\\362\\015\\220D''_3\\367\\352\\200\\247'::bytea AND
_InfoReg16060_Q_000_T_002._Fld16063_TYPE = '\\010'::bytea AND
(_InfoReg16060_Q_000_T_002._Fld16063_RTRef ||
_InfoReg16060_Q_000_T_002._Fld16063_RRRef) IN ('\\000\\000\\0002'::bytea ||
'\\200"\\000\\033x0\\004\\032\\021\\334\\262\\273<\\265)4'::bytea,'\\000\\00
0\\0002'::bytea ||
'\\245\\230\\272~\\361\\313\\223fG\\034\\011\\207X\\325q\\016'::bytea,'\\000
\\000\\000\\324'::bytea ||
'\\257\\332\\000\\004#R\\244\\374\\021\\334\\206\\326\\355\\252j\\360'::byte
a) AND _InfoReg16060_Q_000_T_002._Fld16065 = TRUE))
--
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] ERROR: failed to re-find parent key in "sl_seqlog_idx" for deletion target
John Parnefjord wrote: > Hi! > > Hope anyone can shed some light on this. I was struck by the > following error in the slony log but I believe it's not a slony > error, rather that slony triggers an error in PostgreSQL. The error > message is: Correct, that's not a backend error. > cleanupThread: vacuum analyze sl_seqlog; - ERROR: failed to re-find > parent key in "sl_seqlog_idx" for deletion target > > I've tried to find some posts about it and I could only find one post > where Tom states that reindexing should do the trick, but there is no > answer that reindexing did solve the case. The post is here: > http://archives.postgresql.org/pgsql-bugs/2007-08/msg00035.php > > Well, it is supposed to have been fixed to version 8.2, but it's a > PostgreSQL 8.2.4 x86_64 server running on Debian that triggers the > error. Hi! Please copy out the files as requested in that email - I'm sure Tom is still interested in debugging it to find the issue. After that, try a REINDEX to see if it solves your problem. And while you're at it, you guys should be at 8.2.7, not 8.2.4.. :-P There are some index fixes between those versions (specifically in 8.2.5), but I don't know the details of them enough to say if this could be the problem you're hitting. //Magnus -- 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 #4122: ./postres 'restart' does not start server with same options as 'start' does
The following bug has been logged online: Bug reference: 4122 Logged by: Eugen Konkov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: FreeBSD 6.3 Description:./postres 'restart' does not start server with same options as 'start' does Details: sturtup script bug: http://pgsql.privatepaste.com/2d1s3IvbIp -- 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 #4123: Statement.setQueryTimeout does not work with Postgres Java Driver
The following bug has been logged online: Bug reference: 4123 Logged by: Amit Mujawar Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Windows XP Description:Statement.setQueryTimeout does not work with Postgres Java Driver Details: I am using PostgreSQL through JDBC PostgreSQL â 8.1, Driver - org.postgresql.Driver 8.1-408.jdbc3 When I set Statement.setQueryTimeout, the timeout value does not show any effect on actual timeout...The query blocks for a specific time always [may be configured by another global variable - statement_timeout? not sure] I suspect there is a problem with JDBC driver implementation for setQueryTimeout API. -- 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] ERROR: failed to re-find parent key in "sl_seqlog_idx" for deletion target
> Please copy out the files as requested in that email - I'm sure Tom is > still interested in debugging it to find the issue. After that, try a > REINDEX to see if it solves your problem. Ok, see the snippets below. I just cut them from the PgAdminIII interface. Drop me a mail if you need more info. > And while you're at it, you guys should be at 8.2.7, not 8.2.4.. :-P Yes, you're right. But as we are trying out tsearch2 for full text searching it might just as well be a good idea to go straight to 8.3 during the summer. > There are some index fixes between those versions (specifically in > 8.2.5), but I don't know the details of them enough to say if this > could be the problem you're hitting. Thanks Magnus! // John -- Table: _replication.sl_seqlog CREATE TABLE _replication.sl_seqlog ( seql_seqid integer, -- Sequence ID seql_origin integer, -- Publisher node at which the sequence originates seql_ev_seqno bigint, -- Slony-I Event with which this sequence update is associated seql_last_value bigint -- Last value published for this sequence ) WITH (OIDS=FALSE); ALTER TABLE _replication.sl_seqlog OWNER TO slony; COMMENT ON TABLE _replication.sl_seqlog IS 'Log of Sequence updates'; COMMENT ON COLUMN _replication.sl_seqlog.seql_seqid IS 'Sequence ID'; COMMENT ON COLUMN _replication.sl_seqlog.seql_origin IS 'Publisher node at which the sequence originates'; COMMENT ON COLUMN _replication.sl_seqlog.seql_ev_seqno IS 'Slony-I Event with which this sequence update is associated'; COMMENT ON COLUMN _replication.sl_seqlog.seql_last_value IS 'Last value published for this sequence'; -- Index: _replication.sl_seqlog_idx CREATE INDEX sl_seqlog_idx ON _replication.sl_seqlog USING btree (seql_origin, seql_ev_seqno, seql_seqid); -- 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] ERROR: failed to re-find parent key in "sl_seqlog_idx" for deletion target
John Parnefjord wrote: > > Please copy out the files as requested in that email - I'm sure Tom > > is still interested in debugging it to find the issue. After that, > > try a REINDEX to see if it solves your problem. > > Ok, see the snippets below. I just cut them from the PgAdminIII > interface. Drop me a mail if you need more info. Ok, misunderstandment. What's needed are the actual data files, not the definition of the tables. That is, the files under $PGDATA that contains the table and it's indexes. Can't send those on-list, they're too large, but if you can put together a .tar.gz for someone to look at. Before you send it, we'll want to check with Tom that he's still interested in looking at it :-) > > And while you're at it, you guys should be at 8.2.7, not 8.2.4.. :-P > > Yes, you're right. But as we are trying out tsearch2 for full text > searching it might just as well be a good idea to go straight to 8.3 > during the summer. Probably, yes. //Magnus -- 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] ERROR: failed to re-find parent key in "sl_seqlog_idx" for deletion target
Yikes! I already done a reindexing of the table as there where locks that were holding back some jobs that needed to finished. But in case the problem should appear again we will take a copy of the actual data file. Anyway, the case must regarded as solved. Put shortly, reindex the table/index. By the way thanks for all the effort you put into making PostgreSQL such a marvelous database manager! // John > -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-bugs- > [EMAIL PROTECTED] On Behalf Of Magnus Hagander > Sent: den 22 april 2008 13:58 > To: John Parnefjord > Cc: pgsql-bugs@postgresql.org; Tom Lane > Subject: Re: [BUGS] ERROR: failed to re-find parent key in > "sl_seqlog_idx" for deletion target > > John Parnefjord wrote: > > > Please copy out the files as requested in that email - I'm sure Tom > > > is still interested in debugging it to find the issue. After that, > > > try a REINDEX to see if it solves your problem. > > > > Ok, see the snippets below. I just cut them from the PgAdminIII > > interface. Drop me a mail if you need more info. > > Ok, misunderstandment. What's needed are the actual data files, not the > definition of the tables. That is, the files under $PGDATA that > contains the table and it's indexes. > > Can't send those on-list, they're too large, but if you can put > together a .tar.gz for someone to look at. Before you send it, we'll > want to check with Tom that he's still interested in looking at it :-) > > > > > And while you're at it, you guys should be at 8.2.7, not 8.2.4.. :- > P > > > > Yes, you're right. But as we are trying out tsearch2 for full text > > searching it might just as well be a good idea to go straight to 8.3 > > during the summer. > > Probably, yes. > > > //Magnus > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- 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 #4122: ./postres 'restart' does not start server with same options as 'start' does
"Eugen Konkov" <[EMAIL PROTECTED]> writes: > PostgreSQL version: 8.3.1 > Operating system: FreeBSD 6.3 > Description:./postres 'restart' does not start server with same > options as 'start' does You'd need to take that up with whoever supplied your startup script. The one we provide (in contrib/start-scripts/freebsd) clearly does use the same options for start and restart. 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] DISTINCT MAX() results mismatch on 8.2 and 8.3
>>> On Wed, Mar 26, 2008 at 9:23 PM, in message <[EMAIL PROTECTED]>, Taiki Yamaguchi <[EMAIL PROTECTED]> wrote: > 8.3.0 > == > yamaguti=# create table t1 (i int, j int primary key); > NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index > "t1_pkey" for table "t1" CREATE TABLE > yamaguti=# insert into t1 select g, g from generate_series(1, 100) as g; > INSERT 0 100 > yamaguti=# select distinct max(i) from t1; > max > - > 100 > (1 row) > > yamaguti=# select distinct max(j) from t1; > ERROR: could not find pathkey item to sort > == For the benefit of anyone searching the archives for the problem we just hit, this message also occurs in 8.3.1 and also occurs against the above test table for this statement: test=# select max(j) as "maxj" from t1 order by "maxj"; ERROR: could not find pathkey item to sort Neither statement causes the error when run against a build from REL8_3_STABLE from 35 minutes ago (2008-04-22 10:15 CDT). -Kevin -- 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 #4123: Statement.setQueryTimeout does not work with Postgres Java Driver
On Tue, 22 Apr 2008, Amit Mujawar wrote: The following bug has been logged online: Bug reference: 4123 PostgreSQL version: 8.1 Description:Statement.setQueryTimeout does not work with Postgres Java Driver Details: I am using PostgreSQL through JDBC PostgreSQL ??? 8.1, Driver - org.postgresql.Driver 8.1-408.jdbc3 I suspect there is a problem with JDBC driver implementation for setQueryTimeout API. setQueryTimeout is not implemented at all. Newer drivers (8.3+) will throw an exception telling you that if you try to call setQueryTimeout while older drivers silently accept the value and do nothing. Kris Jurka -- 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] DISTINCT MAX() results mismatch on 8.2 and 8.3
"Kevin Grittner" <[EMAIL PROTECTED]> writes: >> yamaguti=# select distinct max(j) from t1; >> ERROR: could not find pathkey item to sort > For the benefit of anyone searching the archives for the problem we > just hit, this message also occurs in 8.3.1 and also occurs against > the above test table for this statement: > test=# select max(j) as "maxj" from t1 order by "maxj"; > ERROR: could not find pathkey item to sort > Neither statement causes the error when run against a build from > REL8_3_STABLE from 35 minutes ago (2008-04-22 10:15 CDT). Yeah, this was repaired here: http://archives.postgresql.org/pgsql-committers/2008-03/msg00563.php The fix will be in 8.3.2. 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 #4122: ./postres 'restart' does not start server with same options as 'start' does
I have just installed Postgres 8.3.1. And /usr/local/etc/rc.d/postgresql and /contrib/start-scripts/freebsd scripts are different BUG in installator? - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Eugen Konkov" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, April 22, 2008 6:11 PM Subject: Re: [BUGS] BUG #4122: ./postres 'restart' does not start server with same options as 'start' does "Eugen Konkov" <[EMAIL PROTECTED]> writes: PostgreSQL version: 8.3.1 Operating system: FreeBSD 6.3 Description:./postres 'restart' does not start server with same options as 'start' does You'd need to take that up with whoever supplied your startup script. The one we provide (in contrib/start-scripts/freebsd) clearly does use the same options for start and restart. 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 #4122: ./postres 'restart' does not start server with same options as 'start' does
[EMAIL PROTECTED] wrote: I have just installed Postgres 8.3.1. And /usr/local/etc/rc.d/postgresql and /contrib/start-scripts/freebsd scripts are different BUG in installator? the one in /usr/local/etc/rc.d/postgresql is likely the on that freebsd supplies if you install from the porttree so you should ask them ... Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Patch for LISTEN/NOTIFY race condition?
Hi all, After upgrading to 8.3 and Slony 1.2.13, one of our import processes started constantly failing because of deadlock. Our import process (pl/pgsql function) just uses COPY FROM to populate a temp table and then inserts from that (without any special locks, etc). And, the deadlock error showed that the import process was waiting on sl_event and a slon process was waiting on pg_listener. I found the following thread in the archives: http://archives.postgresql.org/pgsql-bugs/2008-03/msg00117.php and it seemed like it could be the cause of the problem. Is the patch available anywhere? Also, if it will be available in 8.3.2, is there any information on when that will be released? Thanks and sorry if I missed this information posted somewhere, Meetesh
Re: [BUGS] BUG #4122: ./postres 'restart' does not start server with same options as 'start' does
Stefan Kaltenbrunner wrote: [EMAIL PROTECTED] wrote: I have just installed Postgres 8.3.1. And /usr/local/etc/rc.d/postgresql and /contrib/start-scripts/freebsd scripts are different BUG in installator? the one in /usr/local/etc/rc.d/postgresql is likely the on that freebsd supplies if you install from the porttree so you should ask them ... Stefan Actually this looks like an issue with pg_ctl on freebsd. If I invoke pg_ctl manually to do a start: pg_ctl -D /usr/local/pgsql/data start and then ps aux the root postgres process shows as: /usr/local/bin/postgres -D /usr/local/pgsql/data However, if I manually do a restart: pg_ctl -D /usr/local/pgsql/data restart the root postgres process shows as: /usr/local/bin/postgres i.e without the parameters. The init script is not the problem as it invokes the same pg_ctl command line in each case of start, stop, restart (apart from the start, stop, restart bit of course). Cheers, Gary. -- 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] Patch for LISTEN/NOTIFY race condition?
Meetesh Karia wrote: > Hi all, > > After upgrading to 8.3 and Slony 1.2.13, one of our import processes > started constantly failing because of deadlock. Our import process > (pl/pgsql function) just uses COPY FROM to populate a temp table and > then inserts from that (without any special locks, etc). And, the > deadlock error showed that the import process was waiting on sl_event > and a slon process was waiting on pg_listener. > > I found the following thread in the archives: > http://archives.postgresql.org/pgsql-bugs/2008-03/msg00117.php and it > seemed like it could be the cause of the problem. > > Is the patch available anywhere? Also, if it will be available in > 8.3.2, is there any information on when that will be released? Hmm, AFAICS the patch should be present on 8.3.1, because it was tagged on March 14th and the patch was committed on March 12. 2008-03-12 17:11 tgl * doc/src/sgml/ref/prepare_transaction.sgml (1.6.2.1), src/backend/commands/async.c (1.138.2.1): Fix LISTEN/NOTIFY race condition reported by Laurent Birtz, by postponing pg_listener modifications commanded by LISTEN and UNLISTEN until the end of the current transaction. This allows us to hold the ExclusiveLock on pg_listener until after commit, with no greater risk of deadlock than there was before. Aside from fixing the race condition, this gets rid of a truly ugly kludge that was there before, namely having to ignore HeapTupleBeingUpdated failures during NOTIFY. There is a small potential incompatibility, which is that if a transaction issues LISTEN or UNLISTEN and then looks into pg_listener before committing, it won't see any resulting row insertion or deletion, where before it would have. It seems unlikely that anyone would be depending on that, though. This patch also disallows LISTEN and UNLISTEN inside a prepared transaction. That case had some pretty undesirable properties already, such as possibly allowing pg_listener entries to be made for PIDs no longer present, so disallowing it seems like a better idea than trying to maintain the behavior. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Patch for LISTEN/NOTIFY race condition?
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Meetesh Karia wrote: >> After upgrading to 8.3 and Slony 1.2.13, one of our import processes >> started constantly failing because of deadlock. Our import process >> (pl/pgsql function) just uses COPY FROM to populate a temp table and >> then inserts from that (without any special locks, etc). And, the >> deadlock error showed that the import process was waiting on sl_event >> and a slon process was waiting on pg_listener. >> >> I found the following thread in the archives: >> http://archives.postgresql.org/pgsql-bugs/2008-03/msg00117.php and it >> seemed like it could be the cause of the problem. >> >> Is the patch available anywhere? Also, if it will be available in >> 8.3.2, is there any information on when that will be released? > Hmm, AFAICS the patch should be present on 8.3.1, because it was tagged > on March 14th and the patch was committed on March 12. Yes, but in any case (a) that's about a race condition not a deadlock, and (b) the issue has been there since forever, so it is unlikely to explain or fix a problem that you weren't seeing before 8.3. 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
