[PATCHES] trace_checkpoint parameter patch

2007-06-12 Thread Satoshi Nagayasu
Hi all, Here is a brand new patch to log a checkpointing load information to tune the bgwriter parameter. When you enable trace_checkpoint parameter and process the checkpoint, the bgwriter logs the number of flushed buffer pages and the elapsed time.

[PATCHES] trace_checkpoint parameter patch

2007-06-12 Thread Satoshi Nagayasu
Hi all, Here is a brand new patch to log a checkpointing load information to tune the bgwriter parameter. When you enable trace_checkpoint parameter and process the checkpoint, the bgwriter logs the number of flushed buffer pages and the elapsed time.

Re: [PATCHES] trace_checkpoint parameter patch

2007-06-12 Thread Satoshi Nagayasu
2007/6/13, Alvaro Herrera [EMAIL PROTECTED]: Well, more I/O numbers would be more interesting than CPU stats ... Well, I think so too, and I attempted to print block in / out using getrusage(), but I couldn't get them because they were always zero (on my linux). I still can't understand the

Re: [PATCHES] trace_checkpoint parameter patch

2007-06-12 Thread Satoshi Nagayasu
Greg, Thanks for comments. Greg Smith wrote: The idea of using pg_rusage_init is a new one though; I hadn't thought the CPU usage info was interesting enough to figure out how to collect it. The way the patch mentioned above works it would be hard to squeeze it in the line usefully for

Re: [PATCHES] pgstattuple extension for indexes

2006-09-03 Thread Satoshi Nagayasu
. --- Satoshi Nagayasu wrote: Bruce, Attached patch has been cleaned up, and modified to be able to work with CVS HEAD. Thanks. Satoshi Nagayasu wrote: Alvaro, Alvaro Herrera wrote: Huh, I bet it works with 8.1.4, but it doesn't work on CVS HEAD

Re: [PATCHES] pgstattuple extension for indexes

2006-09-03 Thread Satoshi Nagayasu
Tom Lane wrote: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic -I. -I../../src/include -D_GNU_SOURCE -c -o pgstatindex.o pgstatindex.c pgstatindex.c: In function 'bt_page_items': pgstatindex.c:564:

Re: [PATCHES] pgstattuple extension for indexes

2006-08-21 Thread Satoshi Nagayasu
Bruce, Bruce Momjian wrote: BTIem is no longer in CVS HEAD, though it was in 8.1.X. Please update your patch for CVS HEAD. Thanks. I've posted CVS HEAD workable version on Aug.14. Please check it out. Thanks. -- NAGAYASU Satoshi [EMAIL PROTECTED] Phone: +81-3-3523-8122

Re: [PATCHES] pgstattuple extension for indexes

2006-08-21 Thread Satoshi Nagayasu
Sorry, I'll write README (and uninstall.sql?) by tomorrow. Bruce Momjian wrote: Satoshi Nagayasu wrote: Bruce, Bruce Momjian wrote: BTIem is no longer in CVS HEAD, though it was in 8.1.X. Please update your patch for CVS HEAD. Thanks. I've posted CVS HEAD workable version on Aug.14

Re: [PATCHES] pgstattuple extension for indexes

2006-08-13 Thread Satoshi Nagayasu
Bruce, Attached patch has been cleaned up, and modified to be able to work with CVS HEAD. Thanks. Satoshi Nagayasu wrote: Alvaro, Alvaro Herrera wrote: Huh, I bet it works with 8.1.4, but it doesn't work on CVS HEAD: /pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c: In function

Re: [PATCHES] pgstattuple extension for indexes

2006-08-12 Thread Satoshi Nagayasu
Alvaro, Alvaro Herrera wrote: Huh, I bet it works with 8.1.4, but it doesn't work on CVS HEAD: /pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c: In function 'GetBTPageStatistics': /pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c:182: error: 'BTItem' undeclared (first use in

Re: [PATCHES] pgstattuple extension for indexes

2006-08-11 Thread Satoshi Nagayasu
Hi all, Here is a patch to add pgstatindex functions to the pgstattuple module, which can work with 8.1.4. Please review and try it. Thanks. Satoshi Nagayasu wrote: Bruce, I'll fix it in this week. Please wait a few days. Thanks. Bruce Momjian wrote: nagayasu-san, This looks good

Re: [PATCHES] pgstattuple extension for indexes

2006-08-09 Thread Satoshi Nagayasu
. --- satoshi nagayasu wrote: Hi folks, As I said on -PATCHES, I've been working on an utility to get a b-tree index information. I'm happy to introduce my new functions to you. pgstattuple module provides a `pgstatindex()`, and other small

Re: [PATCHES] pgstattuple extension for indexes

2006-07-28 Thread satoshi nagayasu
Hi folks, As I said on -PATCHES, I've been working on an utility to get a b-tree index information. I'm happy to introduce my new functions to you. pgstattuple module provides a `pgstatindex()`, and other small functions, which allow you to get b-tree internal information. I believe this module

[PATCHES] monitoring sort activities

2005-09-24 Thread Satoshi Nagayasu
Hi folks, I've created a patch to get following TODO item. * %Add ability to monitor the use of temporary sort files This patch provides one system view (pg_stat_sorts) and one utility function (pg_stat_get_prev_sort_size). snaga=# SELECT * from pg_stat_sorts; heap_all | index_all |

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-08-15 Thread Satoshi Nagayasu
The message format for elog() report is cleaned up. -- NAGAYASU Satoshi [EMAIL PROTECTED] diff -cr pgsql.orig/src/backend/commands/tablecmds.c pgsql/src/backend/commands/tablecmds.c *** pgsql.orig/src/backend/commands/tablecmds.c 2005-06-28 14:08:54.0 +0900 ---

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-08-08 Thread Satoshi Nagayasu
This isn't really a gain in localizability because it assumes that there are only singular and plural forms. I do agree that plugging words like enabled or disabled into a string is not good style. Please read the message style guidelines at

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-08-07 Thread Satoshi Nagayasu
Here is new patch with pg_dump modification. Bruce Momjian wrote: I am waiting for pg_dump support for this patch. --- Satoshi Nagayasu wrote: Bruce Momjian wrote: I am not sure what to do with this patch

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-08-07 Thread Satoshi Nagayasu
Alvaro Herrera wrote: There are a few elog() calls that should really be ereport(). Also this message I've fixed to call ereport() on permission error. + elog(NOTICE, %d trigger(s) on %s %s., + changed, + NameStr(rel-rd_rel-relname), + enable ?

Re: [PATCHES] A couple of p.tches for PostgreSQL 64bit support

2005-07-10 Thread Satoshi Nagayasu
Hi guys, BTW, I found the work_mem is still limited to 2GB. If we support 64bit shared memory, we also need to support 64bit work_mem. Thanks. -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-07-05 Thread Satoshi Nagayasu
Bruce Momjian wrote: I am not sure what to do with this patch. It is missing dump capability, there is no clause to disable all triggers on a table, and it uses a table owner check when a super user check is required (because of referential integrity). Satoshi, are you still working on it?

[PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-07-01 Thread Satoshi Nagayasu
more user checks. From: Bruce Momjian pgman@candle.pha.pa.us Date: 2005/06/29 20:49 Subject: Re: [HACKERS] Open items To: Satoshi Nagayasu [EMAIL PROTECTED] Cc: PostgreSQL-development pgsql-hackers@postgresql.org Satoshi Nagayasu wrote: How about enable/disable triggers? From TODO

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-07-01 Thread Satoshi Nagayasu
The table owner can drop and create triggers - so why shouldn't they be able to enable and disable them? For convenience or easy operation. I believe the user doesn't like to create same triggers again and again. Christopher Kings-Lynne wrote: ALTER TABLE table ENABLE TRIGGER trigname ALTER

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-07-01 Thread Satoshi Nagayasu
painful. Christopher Kings-Lynne wrote: Satoshi Nagayasu wrote: The table owner can drop and create triggers - so why shouldn't they be able to enable and disable them? For convenience or easy operation. I believe the user doesn't like to create same triggers again and again. I said why

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-07-01 Thread Satoshi Nagayasu
Thanks for comments, Neil. Some are fixed. Neil Conway wrote: Also, you should probably skip the simple_heap_update() if the user tries to disable an already-disabled trigger, to avoid pointless MVCC bloat (and same for enabling an already-enabled trigger, of course). Do we need some

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-07-01 Thread Satoshi Nagayasu
There is one more fix... + tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true, + SnapshotNow, 1, keys); '1' was incorrect, must be '2'. + tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true, +

Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)

2005-07-01 Thread Satoshi Nagayasu
Hi, Gavin Sherry wrote: Hmmm.. just thinking about it for a second. I wonder if we should also support: ALTER TABLE DISABLE TRIGGERS I found some RDBMSes are supporting 'DISABLE TRIGGER ALL TRIGGERS' command. Does anyone know about the SQL99 spec? -- NAGAYASU Satoshi [EMAIL PROTECTED]

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

2005-05-09 Thread Satoshi Nagayasu
Bruce Momjian wrote: 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

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

2005-05-08 Thread Satoshi Nagayasu
I think the read-only has two meanings for the user. First is the internal state. XID, OID or something like that. In these cases, the internal state mustn't be changed. Some users will need the read-only for internal state. Second is read-only for the user data contents. In

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

2005-05-08 Thread Satoshi Nagayasu
But the second is only a subset of the first, no? So why not just implement the first? Put another way, why do you think the second is necessary? Because there is "default_transaction_read_only" option and implementation. My implementation is an extension of the

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

2005-05-08 Thread Satoshi Nagayasu
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. -- NAGAYASU Satoshi [EMAIL PROTECTED] OpenSource Development

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

2005-03-20 Thread Satoshi Nagayasu
Tom Lane wrote: I'd view this as a postmaster state that propagates to backends. Probably you'd enable it by means of a postmaster option, and the only way to get out of it is to shut down and restart the postmaster without the option. I've created a patch to make a