Thanks for your answers.
Fatih Öztürk
--- On Thu, 4/9/09, Guillaume Lelarge wrote:
From: Guillaume Lelarge
Subject: Re: [ADMIN] log_statements = mod or all
To: pgsql-admin@postgresql.org
Cc: "Fujii Masao" , oztur...@yahoo.com
Date: Thursday, April 9, 2009, 12:30 PM
Le jeudi 09 avril 2009 à 1
geoffrey.ducha...@gmail.com writes:
> [ ad for StumbleUpon ]
Do that again and you will be ejected from this list.
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
StumbleUpon
Discover your web
Popular Websites
http://www.stumbleupon.com/redirect.php?t=j&u=18579366&d=http%3A%2F%2Fbuzz.stumbleupon.com%2F&l=6&c=mfruyoq65tmdoa15
People Online Now
http://www.stumbleupon.com/redirect.php?t=j&u=18579366&d=http%3A%2F%2Fwww.stumbleupon.com%2Fpeople%2F&l=6&c=mfruyo
The pg_stat_activity table basically shows the same picture as the process list:
- two sessions idle and marked "in transaction"
- one session waiting with an UPDATE as the "current_query"
- a couple of more user sessions idle (and not marked "in transaction")
Time stamps are recent and consistent
Overlooked your mentioning to timestamps in pg_stat_activity. What
patterns do I need to look for there.
Thanks
Peter
2009/4/9 Kevin Grittner :
> Péter Kovács wrote:
>> postgres 14727 9868 0 22:34 ? 00:00:00 postgres: pkovacs
>> chemaxon 127.0.0.1(12496) idle in transaction
>> postgres
Thank you, Kevin, for the tip.
It appears nobody is waiting for a lock (all current locks are granted):
chemaxon=# select
pg_class.relname,pg_locks.pid,pg_locks.mode,pg_locks.granted from
pg_class,pg_locks where pg_class.relfilenode=pg_locks.relation order
by pg_locks.pid;
relname
Péter Kovács wrote:
> postgres 14727 9868 0 22:34 ?00:00:00 postgres: pkovacs
> chemaxon 127.0.0.1(12496) idle in transaction
> postgres 14735 9868 0 22:34 ?00:00:00 postgres: pkovacs
> chemaxon 127.0.0.1(12497) idle in transaction
> postgres 14737 9868 0 22:34 ?00:0
Hi,
I've got a JDBC client which got hung in reading response to a DML statement:
[junit] "Thread-11201" prio=1 tid=0x002ac9df56e0 nid=0x3995
runnable [0x41a7..0x41a70db0]
[junit] at java.net.SocketInputStream.socketRead0(Native Method)
[junit] at java.
Mike angelo writes:
> Reindexing produced no reduction in size of the table in question, and a
> VACUUM ANALYZE VERBOSE pg_toast_293523 produced the message:
> skipping "pg_toast_293523" --- cannot vacuum indexes, views, or special
> system tables.
Issue the vacuum against the owning tab
I'm a newb to Postgres, and need some assistance with pg_toast. I'm running
PostgreSQL 8.3, and am having an issue with one of my pg_toast tables growing
at the rate of 1 GB per day. Can someone offer me some insight on
a) the functionality of the pg_toast_* tables?
b) how can I clear them o
Le jeudi 09 avril 2009 à 11:02:24, Fujii Masao a écrit :
> Hi,
>
> On Thu, Apr 9, 2009 at 5:15 PM, fatih ozturk wrote:
> > Problem is i dont understand the difference between log_statement='all'
> > and log_statement='mod'?
>
> AFAIK, 'mod' doesn't log utility commands, such as CHECKPOINT and VACU
Hi,
On Thu, Apr 9, 2009 at 5:15 PM, fatih ozturk wrote:
> Problem is i dont understand the difference between log_statement='all' and
> log_statement='mod'?
AFAIK, 'mod' doesn't log utility commands, such as CHECKPOINT and VACUUM.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORA
Hi
In http://www.postgresql.org/docs/8.3/static/runtime-config-logging.html
log_statement explained as
"
log_statement (string)Controls which SQL statements are logged. Valid
values are none, ddl, mod, and all. ddl logs all data
definition statements, such as CR
13 matches
Mail list logo
