[PATCHES] Updated kerberos service name patch

2005-05-09 Thread Magnus Hagander
Here is an updated version of the patch from
http://candle.pha.pa.us/mhonarc/patches2/msg00025.html. It handles the
options for libpq connections the same way other options are handled,
and it also updates the kerberos documentation. It contains a couple of
minor changes to the Kerberos documentation that's not directly related
to this patch, to make it easier to read. And it updates the Kerberos
information URL to the current MIT pages.

I refactored my own code so now the Kerberos 4 specific changes are very
small. I have not verified them, but I think they shuold work. That
doesn't mean I'm still in favour of ripping out the krb4 code, just that
it's fairly easy to do it as a separate step instead.

//Magnus


krbsrvname.patch
Description: krbsrvname.patch

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] Added columns to pg_stat_activity

2005-05-09 Thread Neil Conway
Tom Lane wrote:
If the stats collector gets sufficiently backed up, you will lose 
messages. [...] Please do not try to make piecemeal changes in that
basic design decision.
Fair enough.
 (Actually, we could skinny it down to backend PID only ...
but that would add a hashtable lookup to every message reception in
the stats collector, instead of just indexing into a BackendId array,
so it'd probably be a net loss.)
Yeah, I agree -- backend ID and database ID isn't too bad.
I've applied Magnus patch and bumped the catalog version. I'll take a 
look at reorganizing the statistics collector so that the message header 
is smaller shortly.

-Neil
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] Added columns to pg_stat_activity

2005-05-09 Thread Magnus Hagander
Certainly seems that way. Missed a .diff for the rules output there...
Should be a simple replace, from what I can tell what's in the output on
the buildfarm boxes I checked is correct, the expected file shuold
changed.

Oops.

//Magnus


 
 Is this what broke the regression tests on HEAD?
 
 cheers
 
 andrew
 
 Neil Conway wrote:
 
  Tom Lane wrote:
 
  If the stats collector gets sufficiently backed up, you will lose 
  messages. [...] Please do not try to make piecemeal 
 changes in that 
  basic design decision.
 
 
  Fair enough.
 
   (Actually, we could skinny it down to backend PID only ...
 
  but that would add a hashtable lookup to every message 
 reception in 
  the stats collector, instead of just indexing into a 
 BackendId array, 
  so it'd probably be a net loss.)
 
 
  Yeah, I agree -- backend ID and database ID isn't too bad.
 
  I've applied Magnus patch and bumped the catalog version. 
 I'll take a 
  look at reorganizing the statistics collector so that the message 
  header is smaller shortly.
 
  -
 
 

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] Added columns to pg_stat_activity

2005-05-09 Thread Andrew Dunstan
Is this what broke the regression tests on HEAD?
cheers
andrew
Neil Conway wrote:
Tom Lane wrote:
If the stats collector gets sufficiently backed up, you will lose 
messages. [...] Please do not try to make piecemeal changes in that
basic design decision.

Fair enough.
 (Actually, we could skinny it down to backend PID only ...
but that would add a hashtable lookup to every message reception in
the stats collector, instead of just indexing into a BackendId array,
so it'd probably be a net loss.)

Yeah, I agree -- backend ID and database ID isn't too bad.
I've applied Magnus patch and bumped the catalog version. I'll take a 
look at reorganizing the statistics collector so that the message 
header is smaller shortly.

-

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly


Re: [PATCHES] Added columns to pg_stat_activity

2005-05-09 Thread Neil Conway
Andrew Dunstan wrote:
Is this what broke the regression tests on HEAD?
Yes, it is -- fix checked in to HEAD. My apologies for missing this.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly


[PATCHES] csv header feature regression test

2005-05-09 Thread Andrew Dunstan
tiny patch to test this feature.
cheers
andrew
Index: input/copy.source
===
RCS file: /home/cvsmirror/pgsql/src/test/regress/input/copy.source,v
retrieving revision 1.11
diff -c -r1.11 copy.source
*** input/copy.source	16 Mar 2005 06:05:53 -	1.11
--- input/copy.source	9 May 2005 15:12:49 -
***
*** 86,89 
--- 86,103 
  select * from copytest except select * from copytest2;
  
  
+ -- test header line feature
+ 
+ create temp table copytest3 (
+ 	c1 int, 
+ 	col with , comma text, 
+ 	col with  quote  int);
+ 
+ copy copytest3 from stdin csv header;
+ this is just a line full of junk that would error out if parsed
+ 1,a,1
+ 2,b,2
+ \.
+ 
+ copy copytest3 to stdout csv header;
  
Index: output/copy.source
===
RCS file: /home/cvsmirror/pgsql/src/test/regress/output/copy.source,v
retrieving revision 1.9
diff -c -r1.9 copy.source
*** output/copy.source	16 Mar 2005 06:05:53 -	1.9
--- output/copy.source	9 May 2005 16:42:04 -
***
*** 58,60 
--- 58,70 
  ---+--+
  (0 rows)
  
+ -- test header line feature
+ create temp table copytest3 (
+ 	c1 int, 
+ 	col with , comma text, 
+ 	col with  quote  int);
+ copy copytest3 from stdin csv header;
+ copy copytest3 to stdout csv header;
+ c1,col with , comma,col with  quote
+ 1,a,1
+ 2,b,2

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] csv header feature regression test

2005-05-09 Thread Neil Conway
Andrew Dunstan wrote:
tiny patch to test this feature.
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org


Re: [PATCHES] Dealing with CLUSTER failures

2005-05-09 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian pgman@candle.pha.pa.us writes:
  I looked over this item, originally posted as:
  http://archives.postgresql.org/pgsql-hackers/2005-03/msg01055.php
 
 I still think this is substantial complication (more than likely
 introducing some bugs) to deal with a non problem.
 
 http://archives.postgresql.org/pgsql-hackers/2005-03/msg01058.php

Well, it is a demonstrated problem, and we currently don't even report
the index name that caused the cluster to fail.

Here is a new patch that continues to throw an error for a failed
database-wide cluster (no warning) if a single table fails.  It does
print the index name and it prints a hint that the user can use ALTER
TABLE ... SET WITHOUT CLUSTER to avoid the failure:

test= CLUSTER  test_gist_idx ON  test;
ERROR:  cannot cluster on index test_gist_idx because access method
does not handle null values
HINT:  You may be able to work around this by marking column a NOT
NULL.

test= CLUSTER;
ERROR:  cannot cluster on index test_gist_idx because access method
does not handle null values
HINT:  You may be able to work around this by marking column a NOT
NULL, or use ALTER TABLE ... SET WITHOUT CLUSTER to remove the cluster
specification from the table.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
Index: src/backend/commands/cluster.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/cluster.c,v
retrieving revision 1.137
diff -c -c -r1.137 cluster.c
*** src/backend/commands/cluster.c  6 May 2005 17:24:53 -   1.137
--- src/backend/commands/cluster.c  10 May 2005 00:26:48 -
***
*** 292,298 
OldHeap = heap_open(rvtc-tableOid, AccessExclusiveLock);
  
/* Check index is valid to cluster on */
!   check_index_is_clusterable(OldHeap, rvtc-indexOid);
  
/* rebuild_relation does all the dirty work */
rebuild_relation(OldHeap, rvtc-indexOid);
--- 292,298 
OldHeap = heap_open(rvtc-tableOid, AccessExclusiveLock);
  
/* Check index is valid to cluster on */
!   check_index_is_clusterable(OldHeap, rvtc-indexOid, recheck);
  
/* rebuild_relation does all the dirty work */
rebuild_relation(OldHeap, rvtc-indexOid);
***
*** 309,315 
   * definition can't change under us.
   */
  void
! check_index_is_clusterable(Relation OldHeap, Oid indexOid)
  {
RelationOldIndex;
  
--- 309,315 
   * definition can't change under us.
   */
  void
! check_index_is_clusterable(Relation OldHeap, Oid indexOid, bool recheck)
  {
RelationOldIndex;
  
***
*** 336,342 
if (!heap_attisnull(OldIndex-rd_indextuple, Anum_pg_index_indpred))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
!errmsg(cannot cluster on partial index)));
if (!OldIndex-rd_am-amindexnulls)
{
AttrNumber  colno;
--- 336,344 
if (!heap_attisnull(OldIndex-rd_indextuple, Anum_pg_index_indpred))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
!errmsg(cannot cluster on partial index 
\%s\,
!   
RelationGetRelationName(OldIndex;
!   
if (!OldIndex-rd_am-amindexnulls)
{
AttrNumber  colno;
***
*** 354,374 
if (!OldHeap-rd_att-attrs[colno - 1]-attnotnull)
ereport(ERROR,

(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
!errmsg(cannot cluster when 
index access method does not handle null values),
!errhint(You may be able to 
work around this by marking column \%s\ NOT NULL.,
! NameStr(OldHeap-rd_att-attrs[colno - 
1]-attname;
}
else if (colno  0)
{
/* system column --- okay, always non-null */
}
else
-   {
/* index expression, lose... */
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
!errmsg(cannot cluster on expressional 
index when index access method does not handle null values)));
!   }
}
  
/*
--- 356,380 
if 

Re: [PATCHES] Dealing with CLUSTER failures

2005-05-09 Thread Bruce Momjian
Christopher Kings-Lynne wrote:
 Seems like an idea to me...
 
 On another note, what about the problem I pointed out where it's not 
 possible to drop the default on a serial column after you alter it to a 
 varchar, for example...

Uh, should we allow a columns data type to be changed if it has a
default, and if so, how?  It seems a conversion should have to apply to
the default value as well.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [PATCHES] Update psql and pg_dump for new COPY api

2005-05-09 Thread Bruce Momjian

Path withdrawn by author.

---

Christopher Kings-Lynne wrote:
 This patch updates psql and pg_dump to use the new copy api.  Probably 
 needs some review.
 
 I have tested it with dos and unix newlines, etc.
 
 Chris

Content-Description: 

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


[PATCHES] Translation updates: pt_BR

2005-05-09 Thread Euler Taveira de Oliveira
Hi,

This is translation updates for branchs 7.4 and 8.0.

http://br.geocities.com/eulerto/nls_74_pt-br.tgz
http://br.geocities.com/eulerto/nls_80_pt-br.tgz

Please apply.


Euler Taveira de Oliveira
euler[at]yahoo_com_br

__
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] [HACKERS] read-only database

2005-05-09 Thread Bruce Momjian
Satoshi Nagayasu wrote:
 
 Satoshi Nagayasu wrote:
  I wanted to make the postmaster read-only, and found
  default_transaction_read_only option, but it can be overwritten.
 
 I mean it can be overridden by the user. I don't want that.

I understand, but we haven't gotten enough requests from people for a
new option that can't be overridden.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [PATCHES] [HACKERS] read-only database

2005-05-09 Thread Alvaro Herrera
On Mon, May 09, 2005 at 10:13:22PM -0400, Bruce Momjian wrote:
 Satoshi Nagayasu wrote:
  
  Satoshi Nagayasu wrote:
   I wanted to make the postmaster read-only, and found
   default_transaction_read_only option, but it can be overwritten.
  
  I mean it can be overridden by the user. I don't want that.
 
 I understand, but we haven't gotten enough requests from people for a
 new option that can't be overridden.

The ability to have PGDATA in read-only media (like CDs) has been
requested a lot of times, hasn't it?

-- 
Alvaro Herrera ([EMAIL PROTECTED])
Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?  (Mafalda)

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PATCHES] [HACKERS] read-only database

2005-05-09 Thread Bruce Momjian
Tom Lane wrote:
 Alvaro Herrera [EMAIL PROTECTED] writes:
  The ability to have PGDATA in read-only media (like CDs) has been
  requested a lot of times, hasn't it?
 
 It's come up a few times ... more than an un-overridable read-only mode
 anyway.  Also, I should think that those who want a secure read-only
 mode want it enforced selectively --- for instance, assuredly read-only
 for some users but not others.  I can hardly see any use case for the
 patch as proposed; it seems to have all the disadvantages of a low-level
 read-only mode (eg, not selective) without any of the advantages.

Having removed our security for not allowing override of things like
log_statement, it seems we need a more general capability for
controlling how something can be set that no one can change.

One nify trick would be to use '=' in postgresql.conf for things that
can be over-ridden by the user, and ':=' for values that can not be
changed.  I do think we need that functionality for a variety of
purposes.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] [HACKERS] read-only database

2005-05-09 Thread Bruce Momjian
Alvaro Herrera wrote:
 On Mon, May 09, 2005 at 10:13:22PM -0400, Bruce Momjian wrote:
  Satoshi Nagayasu wrote:
   
   Satoshi Nagayasu wrote:
I wanted to make the postmaster read-only, and found
default_transaction_read_only option, but it can be overwritten.
   
   I mean it can be overridden by the user. I don't want that.
  
  I understand, but we haven't gotten enough requests from people for a
  new option that can't be overridden.
 
 The ability to have PGDATA in read-only media (like CDs) has been
 requested a lot of times, hasn't it?

Right.  I am saying the idea of having a GUC that acts like
default_transaction_read_only but can't be changed isn't something
that has been requested frequently.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] [HACKERS] read-only database

2005-05-09 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes:
 The ability to have PGDATA in read-only media (like CDs) has been
 requested a lot of times, hasn't it?

It's come up a few times ... more than an un-overridable read-only mode
anyway.  Also, I should think that those who want a secure read-only
mode want it enforced selectively --- for instance, assuredly read-only
for some users but not others.  I can hardly see any use case for the
patch as proposed; it seems to have all the disadvantages of a low-level
read-only mode (eg, not selective) without any of the advantages.

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] [HACKERS] read-only database

2005-05-09 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes:
 Having removed our security for not allowing override of things like
 log_statement, it seems we need a more general capability for
 controlling how something can be set that no one can change.

The initial implementation was definitely pretty broken, but I agree
we should try again.

I think that transaction_read_only and default_transaction_read_only
are a special case: they embody our implementation of SQL-spec-mandated
features (SET TRANSACTION READ ONLY and friends), and so any messing
about with them has to surmount the objection that it'll be breaking
spec-mandated behavior.  But the other things we wanted this for in
the past, such as logging control, were outside the scope of the spec
AFAIR.

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] [HACKERS] read-only database

2005-05-09 Thread Satoshi Nagayasu
Bruce Momjian wrote:
(BIt's come up a few times ... more than an un-overridable read-only mode
(Banyway.  Also, I should think that those who want a secure read-only
(Bmode want it enforced selectively --- for instance, assuredly read-only
(Bfor some users but not others.  I can hardly see any use case for the
(Bpatch as proposed; it seems to have all the disadvantages of a low-level
(Bread-only mode (eg, not selective) without any of the advantages.
(B
(BOur company has some PostgreSQL replication systems
(Bfor our customers. I need to switch the database state between
(Bread-only and writable for recovering or maintenance.
(B
(BAs I mentioned before, I wanted to the read-only database mode.
(BIt is the per-database state.
(B
(Bhttp://archives.postgresql.org/pgsql-hackers/2005-03/msg00540.php
(B
(BHowever, if it is not provided, we have to find alternative way
(Bto get our purpose.
(B
(BSo I'm still looking for how to make the (user) database as read-only.
(B
(B-- 
(BNAGAYASU Satoshi [EMAIL PROTECTED]
(BOpenSource Development Center,
(BNTT DATA Corp. http://www.nttdata.co.jp/
(B
(B---(end of broadcast)---
(BTIP 7: don't forget to increase your free space map settings

Re: [PATCHES] [HACKERS] read-only database

2005-05-09 Thread Joshua D. Drake

(B As I mentioned before, I wanted to the read-only database mode.
(B It is the per-database state.
(B 
(B http://archives.postgresql.org/pgsql-hackers/2005-03/msg00540.php
(B 
(B However, if it is not provided, we have to find alternative way
(B to get our purpose.
(B 
(B So I'm still looking for how to make the (user) database as read-only.
(B 
(B
(BMammoth PostgreSQL Replicator could do this. If you set a database to a
(Bslave and tell it to be a slave for all tables it would be read only.
(B
(BSincerely,
(B
(BJoshua D. Drake
(BCommand Prompt, Inc.
(B
(B---(end of broadcast)---
(BTIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[PATCHES] pgstat: reduce message header

2005-05-09 Thread Neil Conway
This patch reduces the size of the message header used by statistics 
collector messages, per recent discussion. This actually required quite 
a few changes -- for example, databaseid != InvalidOid was used to 
check whether a slot in the backend entry table was initialized, but 
that no longer works since the slot might be initialized prior to 
receiving the BESTART message which contains the database id. We know 
use procpid  0 to indicate that a slot is non-empty.

Other changes:
- various comment improvements and cleanups
- there's no need to zero-out the entire activity buffer in 
pgstat_add_backend(), we can just set activity[0] to '\0'.

- remove the counting of the # of connections to a database; this was 
not used anywhere

One change in behavior I wasn't sure about: previously, the code would 
create a hash table entry for a database as soon as any message was 
received whose header referenced that database. Now, we only create hash 
table entries as needed (so for example BESTART won't create a hash 
table entry, since it doesn't need to access the per-db hash table). Is 
it important that we retain the previous behavior? (It would be easy 
enough to do by just calling pgstat_get_db_entry() when processing a 
BESTART.)

Barring any objections I'll apply this to HEAD tomorrow.
-Neil
Index: src/backend/postmaster/pgstat.c
===
RCS file: /var/lib/cvs/pgsql/src/backend/postmaster/pgstat.c,v
retrieving revision 1.93
diff -c -r1.93 pgstat.c
*** src/backend/postmaster/pgstat.c	9 May 2005 11:31:33 -	1.93
--- src/backend/postmaster/pgstat.c	10 May 2005 03:42:54 -
***
*** 162,167 
--- 162,168 
  static void pgstat_die(SIGNAL_ARGS);
  static void pgstat_beshutdown_hook(int code, Datum arg);
  
+ static PgStat_StatDBEntry *pgstat_get_db_entry(int databaseid);
  static int	pgstat_add_backend(PgStat_MsgHdr *msg);
  static void pgstat_sub_backend(int procpid);
  static void pgstat_drop_database(Oid databaseid);
***
*** 653,658 
--- 654,662 
  		return;
  
  	pgstat_setheader(msg.m_hdr, PGSTAT_MTYPE_BESTART);
+ 	msg.m_databaseid = MyDatabaseId;
+ 	msg.m_userid = GetSessionUserId();
+ 	memcpy(msg.m_clientaddr, MyProcPort-raddr, sizeof(msg.m_clientaddr));
  	pgstat_send(msg, sizeof(msg));
  
  	/*
***
*** 748,753 
--- 752,758 
  		pgStatXactRollback = 0;
  
  		pgstat_setheader(tsmsg-m_hdr, PGSTAT_MTYPE_TABSTAT);
+ 		tsmsg-m_databaseid = MyDatabaseId;
  		pgstat_send(tsmsg, len);
  	}
  
***
*** 825,831 
  		}
  
  		/*
! 		 * Add this tables Oid to the message
  		 */
  		msg.m_tableid[msg.m_nentries++] = tabentry-tableid;
  		nobjects++;
--- 830,836 
  		}
  
  		/*
! 		 * Add this table's Oid to the message
  		 */
  		msg.m_tableid[msg.m_nentries++] = tabentry-tableid;
  		nobjects++;
***
*** 854,859 
--- 859,865 
  			+msg.m_nentries * sizeof(Oid);
  
  		pgstat_setheader(msg.m_hdr, PGSTAT_MTYPE_TABPURGE);
+ 		msg.m_databaseid = MyDatabaseId;
  		pgstat_send(msg, len);
  	}
  
***
*** 933,941 
  	if (pgStatSock  0)
  		return;
  
- 	msg.m_databaseid = databaseid;
- 
  	pgstat_setheader(msg.m_hdr, PGSTAT_MTYPE_DROPDB);
  	pgstat_send(msg, sizeof(msg));
  }
  
--- 939,946 
  	if (pgStatSock  0)
  		return;
  
  	pgstat_setheader(msg.m_hdr, PGSTAT_MTYPE_DROPDB);
+ 	msg.m_databaseid = databaseid;
  	pgstat_send(msg, sizeof(msg));
  }
  
***
*** 960,965 
--- 965,971 
  			  errmsg(must be superuser to reset statistics counters)));
  
  	pgstat_setheader(msg.m_hdr, PGSTAT_MTYPE_RESETCOUNTER);
+ 	msg.m_databaseid = MyDatabaseId;
  	pgstat_send(msg, sizeof(msg));
  }
  
***
*** 1176,1183 
  PgStat_StatDBEntry *
  pgstat_fetch_stat_dbentry(Oid dbid)
  {
- 	PgStat_StatDBEntry *dbentry;
- 
  	/*
  	 * If not done for this transaction, read the statistics collector
  	 * stats file into some hash tables.
--- 1182,1187 
***
*** 1185,1199 
  	backend_read_statsfile();
  
  	/*
! 	 * Lookup the requested database
  	 */
! 	dbentry = (PgStat_StatDBEntry *) hash_search(pgStatDBHash,
!  (void *) dbid,
!  HASH_FIND, NULL);
! 	if (dbentry == NULL)
! 		return NULL;
! 
! 	return dbentry;
  }
  
  
--- 1189,1199 
  	backend_read_statsfile();
  
  	/*
! 	 * Lookup the requested database; return NULL if not found
  	 */
! 	return (PgStat_StatDBEntry *) hash_search(pgStatDBHash,
! 			  (void *) dbid,
! 			  HASH_FIND, NULL);
  }
  
  
***
*** 1298,1306 
  	hdr-m_type = mtype;
  	hdr-m_backendid = MyBackendId;
  	hdr-m_procpid = MyProcPid;
- 	hdr-m_databaseid = MyDatabaseId;
- 	hdr-m_userid = GetSessionUserId();
- 	memcpy(hdr-m_clientaddr, MyProcPort-raddr, sizeof(hdr-m_clientaddr));
  }
  
  
--- 1298,1303 
***
*** 1976,1985 
  static int
  pgstat_add_backend(PgStat_MsgHdr *msg)
  {
- 	PgStat_StatDBEntry