Re: [PATCHES] Added columns to pg_stat_activity

2005-05-07 Thread Neil Conway
Magnus Hagander wrote: Updated patch attached. A few more comments: - why did you add the client address to PgStat_MsgHdr, rather than PgStat_MsgBestart? It would be nice to avoid sending the client address for each and every stats message, as it shouldn't change over the life of the session.

Re: [PATCHES] Added columns to pg_stat_activity

2005-05-07 Thread Magnus Hagander
Updated patch attached. A few more comments: - why did you add the client address to PgStat_MsgHdr, rather than PgStat_MsgBestart? It would be nice to avoid sending the client address for each and every stats message, as it shouldn't change over the life of the session. I guess that's from

Re: [PATCHES] Added columns to pg_stat_activity

2005-05-07 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: I guess that's from not reading things carefully enough. I looked for where backend pid was transmitted, because I thought that would be a good place to put it. Which might bring up the question, why are things like the backend pid sent in msghdr and

Re: [PATCHES] Added columns to pg_stat_activity

2005-05-07 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: - Is the backend startup time sensitive information? Considering this information is available via ps(1), perhaps it would be better to allow any user to see any backend's startup time, rather than providing a false sense of security. Remote database

Re: [HACKERS] [PATCHES] Patch for database locale settings

2005-05-07 Thread Bruce Momjian
Description added to TODO: * Allow locale to be set at database creation Currently locale can only be set during initdb. No global tables have locale-aware columns. However, the database template used during database creation might have

Re: [PATCHES] Cleaning up unreferenced table files

2005-05-07 Thread Heikki Linnakangas
Maybe we should take a different approach to the problem: 1. Create new file with an extension to mark that it's not yet committed (eg. 1234.notcommitted) 2. ... 3. Take CheckpointStartLock 4. Write commit record to WAL, with list of created files. 5. rename created file (1234.notcommitted -

Re: [PATCHES] Cleaning up unreferenced table files

2005-05-07 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes: Maybe we should take a different approach to the problem: 1. Create new file with an extension to mark that it's not yet committed (eg. 1234.notcommitted) This is pushing the problem into the wrong place, viz the lowest-level file access

[PATCHES] Dealing with CLUSTER failures

2005-05-07 Thread Bruce Momjian
Christopher Kings-Lynne wrote: I don't think that's a bug. You may not intend ever to cluster on that index again, and if you try it will tell you about the problem. Except it breaks the 'cluster everything' case: test=# cluster; ERROR: cannot cluster when index access method does not

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

2005-05-07 Thread Christopher Kings-Lynne
Actually, better not apply this - I think I've found some problems in it. Chris On Fri, 6 May 2005, Bruce Momjian wrote: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the

Re: [PATCHES] Dealing with CLUSTER failures

2005-05-07 Thread Christopher Kings-Lynne
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... Chris On Sat, 7 May 2005, Bruce Momjian wrote: Christopher Kings-Lynne wrote: I don't think that's a

Re: [PATCHES] Dealing with CLUSTER failures

2005-05-07 Thread Tom Lane
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.