I noticed there is a piece of code:
#ifdef CACHEDEBUG
#define InitCatCache_DEBUG2 \
do { \
elog(...
} while(0)
#else
#define InitCatCache_DEBUG2
#endif
Now I'd like to set CACHEDEBUG, how to set up it ? where ?
thanks
peng
2010/4/23 Merlin Moncure :
>
> There's way too much logic going on there for me to test all the
> different cases.
>
> I suspect this is your problem: you triggered a case somehow which is
> not handled properly via your labyrinth of switches and loops. I
> highly doubt this is a case of database
On Apr 23, 2010, at 6:00 PM, Tom Lane wrote:
> Ben Chobot writes:
>> I have a procedure that queries a table. This should be fast because of an
>> index, but some index bloat has caused the index to become expensive, and so
>> the procedure has cached a plan that uses a full table scan. I've si
Ben Chobot writes:
> I have a procedure that queries a table. This should be fast because of an
> index, but some index bloat has caused the index to become expensive, and so
> the procedure has cached a plan that uses a full table scan. I've since fixed
> the index bloat, but the procedure sti
I have a procedure that queries a table. This should be fast because of an
index, but some index bloat has caused the index to become expensive, and so
the procedure has cached a plan that uses a full table scan. I've since fixed
the index bloat, but the procedure still seems to be doing full ta
- Original Message -
From: Alvaro Herrera
Date: Fri, 23 Apr 2010 18:28:03 -0400
Subject: Re: [GENERAL] Postgres stats collector showing high disk I/O
To: Justin Pasher
CC: dep...@depesz.com, pgsql-general@postgresql.org
Justin Pasher wrote:
Agh... I used pg_stats_reset (with an s)
Justin Pasher writes:
> Agh... I used pg_stats_reset (with an s) when searching for it. I ran
> the function and it returned true, but the stats file only shrunk by
> ~100k (still over 18MB total). Is there something else I need to do?
pg_stat_reset only resets the data for the current databas
Justin Pasher wrote:
> Agh... I used pg_stats_reset (with an s) when searching for it. I
> ran the function and it returned true, but the stats file only
> shrunk by ~100k (still over 18MB total). Is there something else I
> need to do? Does this mean the file is mostly bloated with bogus
> data t
> I'm guessing I should just try to delete the file outright?
>
Err... I meant "should NOT" delete.
--
Justin Pasher
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi all.
I'm receiving the following message when I try to use pg_prepare() function:
"Call to undefined function pg_prepare()".
My application works very well with others pg_* commands...
I already checked my configuration files and I have no more ideas about how to
fix it.
Any suggestions?
- Original Message -
From: hubert depesz lubaczewski
Date: Fri, 23 Apr 2010 23:40:35 +0200
Subject: Re: [GENERAL] Postgres stats collector showing high disk I/O
To: Justin Pasher
CC: pgsql-general@postgresql.org
On Fri, Apr 23, 2010 at 03:27:55PM -0500, Justin Pasher wrote:
haven't
On Fri, Apr 23, 2010 at 03:27:55PM -0500, Justin Pasher wrote:
> haven't tweaked any settings from the defaults. My
> $PGDATA/global/pgstat.stat file is about 18MB, if that helps. Does
> it really rewrite this entire file every 500ms? Alvaro suggested
> resetting the stats, but I'm having trouble f
Hello,
Redhat EL4 update 8, 2.6.9-89.0.23.ELsmp
Quad Proc, Dual Core Xeon, 16GB RAM
Postgres 8.1.18
I'm having some trouble pinning down exactly what is causing our
Postgres cluster to run slowly. After some initial investigation, I
noticed that the disk write activity is consistently high, an
2010/4/23 சிவகுமார் மா :
> 2010/4/23 Merlin Moncure :
>>
>> You haven't given enough information to make any sort of reasonable
>> diagnosis. Most people are going to assume the problem is on your end
>> but it's possible to know for sure without having the trigger function
>> at the very least.
>
On Fri, Apr 23, 2010 at 4:03 PM, Watson, Nathaniel wrote:
>
> It appears that no log is being created in %TEMP% that as a result of this
> problem.
Very odd. Does anything get created in %TEMP%? That early in the
installation it's probably unpacking some of the files it'll need for
the pre-flight
Using views in Postgres can be a painful process. Changing a column in a
base table will require you to drop all views that depend on it, and all
views that depend on those views and so on.
My coworker was complaining this morning that he now has a bunch of
queries where a view is joined back
I released new version of my PostgreSQL 8.4 live CD, which is based
on CentOS 5.4. It includes the PostgreSQL related packages that I build
on http://yum.pgrpms.org, along with PostgreSQL 8.4.3.
Details are here:
http://pglivecd.org
http://yum.pgrpms.org/livecd.php
You can add an encrypted home
-Original Message-
From: Dave Page [mailto:dp...@pgadmin.org]
Sent: Thu 4/22/2010 3:35 AM
To: Craig Ringer
Cc: Watson, Nathaniel; pgsql-general@postgresql.org
Subject: Re: [GENERAL] installation on vista
On Thu, Apr 22, 2010 at 1:47 AM, Craig Ringer
wrote:
> On 22/04/2010 1:05 AM, Wat
2010/4/23 Merlin Moncure :
>
> You haven't given enough information to make any sort of reasonable
> diagnosis. Most people are going to assume the problem is on your end
> but it's possible to know for sure without having the trigger function
> at the very least.
>
Thanks merlin for the reply. T
Howard Cole writes:
> I have a database on version 8.2.4 and intend to upgrade to the latest
> 8.4.3 version. The 8.2 version has Tsearch2 and I know there are issues
> in upgrading tsearch2 and therefore I was wondering which is the best
> way to do this upgrade.
There's some suggestions in t
Thanks again Alban. I didn't mention but if I remove the braces then it
gives below error but the meaning is same as the error when I specify
braces.
techdb=# SELECT insert_history_info();
ERROR: error from Perl function "insert_history_info": each EXCEPT query
must have the same number of column
Hi,
I have a database on version 8.2.4 and intend to upgrade to the latest
8.4.3 version. The 8.2 version has Tsearch2 and I know there are issues
in upgrading tsearch2 and therefore I was wondering which is the best
way to do this upgrade.
I am best upgrading from 8.2.4 to the latest 8.2 bu
On 23 Apr 2010, at 14:28, dipti shah wrote:
> Great! Thanks Alban, Alexander, and Thomas.
>
> That solved the issue but could you tell me what is the issue when I give
> brackets in second query?
>
> techdb=# INSERT INTO changelogtest (id, txid, txtime) values (5, 123, now())
> except select
2010/4/23 சிவகுமார் மா :
> 1. We have a production system tracking value added to a batch through
> series of stages. Value table is updated through triggers on data
> tables.
>
> 2. These trigger functions have been tested and validated for over 1.5
> years with more than 100,000 records.
>
> 3.
thanks a lot. I am going thru it
Regards
On Thu, Apr 22, 2010 at 10:56 AM, Ben Chobot wrote:
> On Apr 22, 2010, at 5:43 AM, akp geek wrote:
>
> > Hi all -
> >
> > I would request, If any one has document on how to read and
> interpret the postgres execution plan, can you please share i
1. We have a production system tracking value added to a batch through
series of stages. Value table is updated through triggers on data
tables.
2. These trigger functions have been tested and validated for over 1.5
years with more than 100,000 records.
3. We found a difference in the calculatio
Great! Thanks Alban, Alexander, and Thomas.
That solved the issue but could you tell me what is the issue when I give
brackets in second query?
techdb=# INSERT INTO changelogtest (id, txid, txtime) values (5, 123, now())
except *select id, txid, txtime
*from changelogtest
where id=5;
INSERT 0 1
On 23 Apr 2010, at 13:17, dipti shah wrote:
For this case you're using 3 values in the first half of the expression and
only 1 in the second:
> techdb=# INSERT INTO changelogtest (id, txid, txtime)
> values (5, 123, 'now')
^^ ^^^ --- 3 columns, namely int, int & text.
> except
> s
On Friday 23 April 2010 14:17:32 dipti shah wrote:
> Thanks but I don't have text type in my table.
But you are trying to insert text value 'now' into table, that's why appears
this error.
If you want to insert current time try using function now() not text 'now'
In Your case insert should be f
dipti shah, 23.04.2010 13:17:
Thanks but I don't have text type in my table.
sysdb=# \d changelogtest
techdb=# INSERT INTO changelogtest (id, txid, txtime) values (5, 123, 'now')
except select id, txid, txtime
from changelogtest
where id=5;
'now' *is* a text type value
Thomas
--
Sent via pgs
Thanks but I don't have text type in my table.
sysdb=# \d changelogtest
...
Table "sysdb.changelogtest"
Column |Type |Modifiers
+-+--
Hooray, uninstalling psqlODBC worked! Thank you so much for all of your
help!
Cheers,
Morgan Taschuk
Craig Ringer wrote:
On 23/04/2010 2:06 AM, Tom Lane wrote:
On Red Hat
systems the thing to do is install the postgresql-debuginfo RPM
that matches your postgresql RPMs, but I'm not sure exact
On 23/04/2010 11:31, dipti shah wrote:
> ERROR: EXCEPT types text and timestamp without time zone cannot be matched
> LINE 2: except select id, txid, txtime
Try adding a cast to one of them.
Ray.
--
Raymond O'Donnell :: Galway :: Ireland
r...@iol.ie
--
Sent via pgsql-general mailing list (
it tells you that it is not able to compare timestamp with text. Different
types. Cast if you have to explicitly.
--
GJ
Hi, could anyone please tell me what is wrong in below query. Does it mean
that EXCEPT doesn't allow comparing TIMESTAMP type?
techdb=# INSERT INTO changelogtest (id, txid, txtime) values (5, 123, 'now')
except select id, txid, txtime
from changelogtest
where id=5;
ERROR: EXCEPT types text and t
On 23/04/10 15:50, Adrian von Bidder wrote:
On Friday 23 April 2010 03.27:29 Craig Ringer wrote:
insert into test (a,b) values ('fred',NULL);
insert into test (a,b) values ('fred',NULL);
... and will succeed:
Hmm. Perhaps not as ugly as "none" placeholders:
create unique index on test (b)
On Thursday 22 April 2010 23.36:51 Bjørn T Johansen wrote:
> E.g I have two fields in a table that I want indexed, is it best to
> create one index combining the two fields or creating one for each
> field?
This depends on the queries you run against the table. It's not possible to
give a genera
On Friday 23 April 2010 03.27:29 Craig Ringer wrote:
> insert into test (a,b) values ('fred',NULL);
> insert into test (a,b) values ('fred',NULL);
>
>
> ... and will succeed:
Hmm. Perhaps not as ugly as "none" placeholders:
create unique index on test (b) where a is null;
create unique index o
:) I realized that. Thanks.
On Thu, Apr 22, 2010 at 6:53 PM, Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > I have written following trigger and trying to improve the performance by
> > using prepared query everytime. I have used spi_prepare to prepare
39 matches
Mail list logo
