Saturday, August 9, 2008

Re: [pgadmin-hackers] Layout Suggestion

Lucas a écrit :
> [...]
> My suggestion is to have a tree view that suport search filters.

Yeah, I would like to have this too. Not sure how we should do it. I
think we should only filter object names. I also think we should be able
to target database, schema, and objects.

If I type "%foo%", I'll get every object named %foo% (and also databases
and schemas that can help me go to these objects, even if their names
aren't %foo%. %.%.%foo% would be a synonym of it.

If I type foo.s%.%bar%, I should get every %bar% object on every s%
schema on the foo database.

But what would mean foo%.%bar%? Ony the objects contained in %bar%
schemas of the foo% databases?

> Like the options dialog from eclipse.
> And to edit functions without opening a new window or make the edit
> windows not modal-like.

This is something that could be interesting. Problem is that it will
need a complete review of the UI, much much more than what I'm currently
doing. I don't think we'll go that way.


--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-support] How see custom types in pgAdmin?

Bill a écrit :
> I am very new to PostgreSQL so forgive me if I am missing something
> obvious. I have created a custom type using CREATE TYPE. Where can I
> see my custom types in pgAdmin?
>

Have you turned Type display on ? To do so, go in menu File, item
Options. Then click on Display tab. Go to the end of the list and make
sure Types is checked.


--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

Re: [BUGS] ALTER TABLE name RENAME TO new_name; does not work immediately

<megous@gmail.com> writes:

> Here is a script that is able to reproduce the problem (on my machine
> anyway), you may need to play with the number of rows or workmem
> settings to be able to reproduce it:

Egads, i can confirm that this script reproduces the problem on my machine as
well:

ALTER TABLE xxx RENAME TO yyy;
ALTER TABLE
ALTER TABLE yyy RENAME COLUMN col1 TO colA;
ERROR: relation "yyy" does not exist

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[COMMITTERS] psqlodbc - psqlodbc: addition on a document.

Log Message:
-----------
addition on a document.

Modified Files:
--------------
psqlodbc/docs:
release.html (r1.37 -> r1.38)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/docs/release.html.diff?r1=1.37&r2=1.38)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] psqlodbc - psqlodbc: Fix some bugs.

Log Message:
-----------
Fix some bugs.
1. Reset the column binding information after SQLMoreResults().
2. Save the rowset size properly for the FETCH_NEXT operation
in case of >= 3.0 drivers.

Enable geqo optiomizer by default.

Modified Files:
--------------
psqlodbc:
convert.c (r1.168 -> r1.169)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/convert.c.diff?r1=1.168&r2=1.169)
dlg_specific.c (r1.81 -> r1.82)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/dlg_specific.c.diff?r1=1.81&r2=1.82)
dlg_specific.h (r1.57 -> r1.58)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/dlg_specific.h.diff?r1=1.57&r2=1.58)
odbcapi.c (r1.38 -> r1.39)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/odbcapi.c.diff?r1=1.38&r2=1.39)
odbcapi30.c (r1.43 -> r1.44)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/odbcapi30.c.diff?r1=1.43&r2=1.44)
options.c (r1.74 -> r1.75)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/options.c.diff?r1=1.74&r2=1.75)
pgxalib.cpp (r1.4 -> r1.5)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/pgxalib.cpp.diff?r1=1.4&r2=1.5)
results.c (r1.109 -> r1.110)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/results.c.diff?r1=1.109&r2=1.110)
statement.c (r1.136 -> r1.137)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/statement.c.diff?r1=1.136&r2=1.137)
statement.h (r1.77 -> r1.78)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/statement.h.diff?r1=1.77&r2=1.78)
version.h (r1.121 -> r1.122)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/version.h.diff?r1=1.121&r2=1.122)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[pgadmin-support] How see custom types in pgAdmin?

I am very new to PostgreSQL so forgive me if I am missing something
obvious. I have created a custom type using CREATE TYPE. Where can I
see my custom types in pgAdmin?

--
.Bill.

--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Miernik <public@public.miernik.name> wrote:
> Something goes wrong that this query plan thinks there is only gonna be
> 1 row from (SELECT uid FROM alog ... ) so chooses such query plan, and
> thus it runs forever (at least so long that I didn't bother to wait,
> like 10 minutes):
>
>
> miernik=> EXPLAIN UPDATE cnts SET p0 = FALSE WHERE uid IN (SELECT uid FROM alog WHERE pid = 3452654 AND o = 1);
> QUERY PLAN
> -----------------------------------------------------------------------------------------------
> Nested Loop IN Join (cost=0.00..3317.34 rows=1 width=44)
> -> Seq Scan on cnts (cost=0.00..36.00 rows=2000 width=44)
> -> Index Scan using alog_uid_idx on alog (cost=0.00..296.95 rows=1 width=4)
> Index Cond: ((alog.uid)::integer = (cnts.uid)::integer)
> Filter: ((alog.pid = 3452654::numeric) AND (alog.o = 1::numeric))
> (5 rows)

Well, in fact its not only the autovacuum/manual VACUUM ANALYZE that
changed, its a new copy of the cnts table with only 1000 rows, and
before it was a 61729 row table. The new, smaller, 1000 row table is
recreated, but I have a copy of the old 61729 row table, and guess what?
It runs correctly! And the query plan of the exactly the same query, on
a table of the exactly same structure and indexes, differing only by
having 61729 rows instead of 1000 rows, is like this:

I've done a SELECT uid plan, instead of an UPDATE plan, but it should
be no difference. This is a plan that is quick:

miernik=> EXPLAIN SELECT uid FROM cnts_old WHERE uid IN (SELECT uid FROM alog WHERE pid = 3452654 AND o = 1);
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Nested Loop (cost=9077.07..9238.61 rows=12 width=4)
-> HashAggregate (cost=9077.07..9077.29 rows=22 width=4)
-> Bitmap Heap Scan on alog (cost=93.88..9069.00 rows=3229 width=4)
Recheck Cond: ((pid = 3452654::numeric) AND (o = 1::numeric))
-> Bitmap Index Scan on alog_pid_o (cost=0.00..93.07 rows=3229 width=0)
Index Cond: ((pid = 3452654::numeric) AND (o = 1::numeric))
-> Index Scan using cnts_old_pkey on cnts_old (cost=0.00..7.32 rows=1 width=4)
Index Cond: ((cnts_old.uid)::integer = (alog.uid)::integer)
(8 rows)


I present a SELECT uid plan with the 1000 table also below, just to be
sure, this is the "bad" plan, that takes forever:

miernik=> EXPLAIN SELECT uid FROM cnts WHERE uid IN (SELECT uid FROM alog WHERE pid = 3452654 AND o = 1);
QUERY PLAN
-----------------------------------------------------------------------------------------------
Nested Loop IN Join (cost=0.00..3532.70 rows=1 width=4)
-> Seq Scan on cnts (cost=0.00..26.26 rows=1026 width=4)
-> Index Scan using alog_uid_idx on alog (cost=0.00..297.32 rows=1 width=4)
Index Cond: ((alog.uid)::integer = (cnts.uid)::integer)
Filter: ((alog.pid = 3452654::numeric) AND (alog.o = 1::numeric))
(5 rows)


I've also got a version of the cnts table with only 14 rows, called
cnts_small, and the query plan on that one is below:

miernik=> EXPLAIN SELECT uid FROM cnts_small WHERE uid IN (SELECT uid FROM alog WHERE pid = 3452654 AND o = 1);
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Nested Loop IN Join (cost=99.05..1444.29 rows=1 width=4)
-> Seq Scan on cnts_small (cost=0.00..1.14 rows=14 width=4)
-> Bitmap Heap Scan on alog (cost=99.05..103.07 rows=1 width=4)
Recheck Cond: (((alog.uid)::integer = (cnts_small.uid)::integer) AND (alog.pid = 3452654::numeric) AND (alog.o = 1::numeric))
-> BitmapAnd (cost=99.05..99.05 rows=1 width=0)
-> Bitmap Index Scan on alog_uid_idx (cost=0.00..5.21 rows=80 width=0)
Index Cond: ((alog.uid)::integer = (cnts_small.uid)::integer)
-> Bitmap Index Scan on alog_pid_o (cost=0.00..92.78 rows=3229 width=0)
Index Cond: ((alog.pid = 3452654::numeric) AND (alog.o = 1::numeric))
(9 rows)

That one is fast too. And the structure and indexes of cnts_small is
exactly the same as of cnts and cnts_old. So it works OK if I use a 14
row table and if I use a 61729 row table, but breaks when I use a 1000
row table. Any ideas?

--
Miernik
http://miernik.name/


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [pgsql-students] Problem accessing View in VB6

----- Message from andrew@dunslane.net ---------
    Date: Sat, 09 Aug 2008 13:31:54 -0400
    From: Andrew Dunstan <andrew@dunslane.net>
Reply-To: Andrew Dunstan <andrew@dunslane.net>
Subject: Re: [pgsql-students] Problem accessing View in VB6
      To: oca@mvc.edu.ph
      Cc: pgsql-students@postgresql.org


>
>
> oca@mvc.edu.ph wrote:
>>
>>
>> Thank you, that does the job, but i guess i have to use lowercases 
>> for my views names.
>>
>>
>
> I don't see why. Just use:
>
>    .Open "SELECT * FROM ""tvwClassSchedules""", dbConn, adOpenDynamic,
> adLockReadOnly
>
>
> AFAIK that is the way to embed quotes in VB Strings.
>
> cheers
>
> andrew
>
> --
> Sent via pgsql-students mailing list (pgsql-students@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-students
----- End message from andrew@dunslane.net -----

yes, but i guess it would be more easier for me to code when they are in lower cases, i just rename the views to tvw_class_scedules.

thank you and have a great day!


Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

On Sat, Aug 09, 2008 at 05:37:29PM -0400, Tom Lane wrote:
> > miernik=> explain select * from cnts, alog where alog.uid = cnts.uid;
> > QUERY PLAN
> > -----------------------------------------------------------------------------------------
> > Nested Loop (cost=4.95..573640.43 rows=159220 width=76)
> > -> Seq Scan on cnts (cost=0.00..36.00 rows=2000 width=39)
> > -> Bitmap Heap Scan on alog (cost=4.95..285.80 rows=80 width=37)
> > Recheck Cond: ((alog.uid)::integer = (cnts.uid)::integer)
> > -> Bitmap Index Scan on alog_uid_idx (cost=0.00..4.93 rows=80 width=0)
> > Index Cond: ((alog.uid)::integer = (cnts.uid)::integer)
> > (6 rows)
>
> > Trying EXPLAIN ANALZYE now on this makes it run forever...
>
> It couldn't run very long if those rowcounts were accurate.

Well, count "over 5 minutes" as "forever".

> How many
> rows in "cnts" really? How big is "alog", and how many of its rows join
> to "cnts"?

cnts is exactly 1000 rows.
alog as a whole is now 3041833 rows

"SELECT uid FROM alog WHERE pid = 3452654 AND o = 1" gives 870 rows (202
of them NULL), but if I would first try to JOIN alog to cnts, that would
be really huge, like roughly 100000 rows, so to have this work
reasonably well, it MUST first filter alog on pid and o, and then JOIN
the result to cnts, not the other way around. Trying to fist JOIN alog to
cnts, and then filter the whole thing on pid and o is excessively stupid
in this situation, isn't it?

>
> While I'm looking at this, what's the real datatypes of the uid columns?
> Those explicit coercions seem a bit fishy.

uid is of DOMAIN uid which is defined as:

CREATE DOMAIN uid AS integer CHECK (VALUE > 0);

But I don't think its a problem. It was working perfectly for serveral
months until yesterday I decided to mess with autovacuum and manual
ANALYZE.

--
Miernik
http://miernik.name/

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [ADMIN] Problems with connection

H. Hall wrote:
> Курашкин Дмитрий wrote:
>> Hi to all!
>>
>> I have following systems:
>> 1. Local machine with Windows XP SP2 and PostgreSQL 8.2 - test system.
>> 2. Work server in local network (FreeBSD + PostgreSQL 8.2) - work
>> system.
>>
>> I write client with Delphi 7 IDE and use Zeos Lib 6.6.2
>> (http://zeos.firmos.at/) for database access.
>>
>> When I tried to connect to server I recieve error message: "SQL Error:
>> fe_sendauth: authentication type 5 not supported."
>> After searching in internet I found solution: set authentication
>> method "password" instead of "md5".
>> In file pg_hba.conf on local machine I wrote:
>>
>> # TYPE DATABASE USER CIDR-ADDRESS METHOD
>> host all all 127.0.0.1/32 password
>>
>> and on server:
>> # TYPE DATABASE USER CIDR-ADDRESS METHOD
>> host all all 192.168.3.0/24 password
>>
>> My IP-address in local network is 192.168.3.16...
>>
>> After that I can to connect to test PostgreSQL server on localhost,
>> and connection works fine, but attempt to connect to work server
>> finishes by
>> same error message "SQL Error: fe_sendauth: authentication type 5 not
>> supported."
>>
>> I tried to place string in pg_hba.conf on first and last positions,
>> wrote names of databases and users instead of "all" but it doesn't
>> work.
>>
> Understanding the net mask:
> ----------------------------
> The IPv4 address is 32bits, arranged in 4 sets of 8 bits each.
> The decimal range for an IP mask is 0.0.0.0-255.255.255.255.
> The net mask defines how many bits need to match, counting from the left.
>
> For example a netmask /8 means the first 8 bits must exactly match,
> for example 192.168.0.101/8 means all IPs beginning with 192 can
> connect.
> /16 means the: first 16 bits have to match that is the first two
> numbers in the IP must match
> e.g. 192.168.0.101/16 means that all IPs begining with 192.168 can
> connect.
> /32 means: the entire IP must match exactly for example
> 192.168.0.101/32 means that only an IP exactly equal to 192.168.0.101
> may connect.
>
> How can we use it:
>
> # trust anyone attached to same machine as the database (no password
> required)
> host all all 127.0.0.1/32 trust
>
> # allow anyone to attach to any db FROM THIS ONE IP but require a
> password encrypted via md5
> host all all 192.168.0.101/32 md5
>
> Also note that the pg_hba.conf file is read only on server startup or
> when the postmaster receives a SIGHUP signal. If you edit the file,
> you must restart the server or SIGHUP the postmaster for the changes
> to take effect.
>
> You can use
>
> pg_ctl reload -D /usr/local/pgsql/data
> Note: /usr/local/pgsql/data is a Linux path to the database, use
> equivalent for windows. The pg_ctl program is in the postgres bin
> directory.
>
> See this link for more info:
> http://developer.postgresql.org/pgdocs/postgres/auth-pg-hba-conf.html
>
> --Cheers,
> HH
>> As I understand, my main problem is to force PostgreSQL server allow
>> me to connect with password authentication method, isn't it? And how I
>> can do that?
Sorry, got in a hurry and forgot to add some things:
1. Are you using ODBC to connect. If so, it could be that ODBC is having
the problem with MD5. I don't know if ODBC has such problems, just a
thought.
2. If you use password, you may have to change file postgresql.conf to
include this setting:

# (the default is on)
password_encryption = off

If you change this, you may also have to reset the users' passwords so
that they are stored in plain text i.e. non-encrypted.

3. How did you create users and assign passwords. Did you encrypt them?
You may want to review this:
http://www.postgresql.org/docs/8.0/interactive/sql-createuser.html

--Cheers,
HH

>>
>> P. S. Sorry for poor english...
>>
>>
>>
>
>


--
H. Hall
ReedyRiver Group LLC
http://www.reedyriver.com


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Miernik <public@public.miernik.name> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If necessary, turn off enable_hashjoin and enable_mergejoin so we can
>> see a comparable plan.

> After doing that it thinks like this:

> miernik=> explain select * from cnts, alog where alog.uid = cnts.uid;
> QUERY PLAN
> -----------------------------------------------------------------------------------------
> Nested Loop (cost=4.95..573640.43 rows=159220 width=76)
> -> Seq Scan on cnts (cost=0.00..36.00 rows=2000 width=39)
> -> Bitmap Heap Scan on alog (cost=4.95..285.80 rows=80 width=37)
> Recheck Cond: ((alog.uid)::integer = (cnts.uid)::integer)
> -> Bitmap Index Scan on alog_uid_idx (cost=0.00..4.93 rows=80 width=0)
> Index Cond: ((alog.uid)::integer = (cnts.uid)::integer)
> (6 rows)

> Trying EXPLAIN ANALZYE now on this makes it run forever...

It couldn't run very long if those rowcounts were accurate. How many
rows in "cnts" really? How big is "alog", and how many of its rows join
to "cnts"?

While I'm looking at this, what's the real datatypes of the uid columns?
Those explicit coercions seem a bit fishy.

> How can I bring it back to working?

It's premature to ask for a solution when we don't understand the
problem.

regards, tom lane

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Miernik <public@public.miernik.name> wrote:
> How can I bring it back to working? Like un-run ANALYZE on that table or
> something? All was running reasonably well before I changed from
> autovacuum to running ANALYZE manually, and I thought I would improve
> performance... ;(

I now removed all manual ANALYZE commands from the scripts, set
enable_hashjoin = on
enable_mergejoin = on
and set on autovacuum, but it didn't bring back the performance of that query :(

--
Miernik
http://miernik.name/


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [pgsql-fr-generale] PostgreSQL Europe veut faire péter la banque

Salut Damien,

L'April a un compte au Crédit Mutuel et en est très satisfaite
(notamment par rapport à la Banque Populaire, notre ancienne banque).
Le Crédit Mutuel a construit une offre à destination particulière des
associations et propose différents services et outils que nous
n'utilisons pas tous, loin s'en faut (parmi ceux que nous n'utilisons
pas, il y a par exemple un outil de comptabilité spécifique nommé
CyberGestion Association).

Le coût mensuel de l'ensemble des services que nous utilisons est
assez faible (7,50 euros).

- Une interface web nous permet de gérer nos comptes. Elle vient
d'ailleurs de faire peau neuve et est désormais plutôt agréable.
Evidemment, sa consultation depuis Firefox et GNU/Linux se fait sans
encombre (on ne trouve sur l'interface qu'une bannière de pub en
Flash). Le services accessibles depuis cette interface me semblent
très complets.

- Nos adhérents peuvent payer leur cotisation par carte bleue sur le
site de l'April. Pour ce faire, nous utilisons un module PHP fourni
par le Crédit Mutuel (l'intégration de ce module à notre site web a
été un jeu d'enfant paraît-il). La transaction se fait directement
avec le serveur de la banque et aucune information en clair ne
circule ou n'est stockée sur le serveur de l'April. Nous recevons
simplement un acquittement de la banque qui nous indique si la
transaction a été fructueuse.

De mémoire (à vérifier avec le CM), la mise en place de ce TPE est
facturée 150 euros. Par la suite, le CM prélève moins de 1 % sur les
transactions (j'ai en tête un chiffre : 0,27 euro pour 30 euros).

Une interface web nous permet de suivre les transactions de notre
TPE (Terminal de Paiement Electronique). Celle-ci est sommaire mais
finalement efficace.

- Nos adhérents peuvent aussi payer leur cotisation par prélèvement
automatique. Les prélèvements ne nous coûtent rien (sauf anomalie)
et le CM s'est gracieusement chargé de toutes les formalités auprès
de la Banque de France (notamment de l'obtention d'un numéro
national d'émetteur).

A ma connaissance, les outils de gestion ne sont disponibles qu'en
Français.

Au final, je ne sais pas s'il existe mieux mais nous sommes très
contents des services du Crédit Mutuel.

A part cela, voici une petite étude, nullement exhaustive, que nous
avions menée il y a trois ans sur divers moyens de paiement en ligne :

http://wiki.april.org/phpwiki/index.php/PaiementViaWWW

A++, Sébastien

--
Sébastien Dinot, sebastien.dinot@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale

Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Miernik <public@public.miernik.name> writes:
>> miernik=> EXPLAIN UPDATE cnts SET p0 = FALSE WHERE uid IN (SELECT uid FROM alog WHERE pid = 3452654 AND o = 1);
>> QUERY PLAN
>> -----------------------------------------------------------------------------------------------
>> Nested Loop IN Join (cost=0.00..3317.34 rows=1 width=44)
>> -> Seq Scan on cnts (cost=0.00..36.00 rows=2000 width=44)
>> -> Index Scan using alog_uid_idx on alog (cost=0.00..296.95 rows=1 width=4)
>> Index Cond: ((alog.uid)::integer = (cnts.uid)::integer)
>> Filter: ((alog.pid = 3452654::numeric) AND (alog.o = 1::numeric))
>> (5 rows)
>
>> But if I give him only the inner part, it makes reasonable assumptions
>> and runs OK:
>
> What's the results for
>
> explain select * from cnts, alog where alog.uid = cnts.uid

miernik=> explain select * from cnts, alog where alog.uid = cnts.uid;
QUERY PLAN
----------------------------------------------------------------------------
Hash Join (cost=61.00..71810.41 rows=159220 width=76)
Hash Cond: ((alog.uid)::integer = (cnts.uid)::integer)
-> Seq Scan on alog (cost=0.00..54951.81 rows=3041081 width=37)
-> Hash (cost=36.00..36.00 rows=2000 width=39)
-> Seq Scan on cnts (cost=0.00..36.00 rows=2000 width=39)
(5 rows)

> If necessary, turn off enable_hashjoin and enable_mergejoin so we can
> see a comparable plan.

After doing that it thinks like this:

miernik=> explain select * from cnts, alog where alog.uid = cnts.uid;
QUERY PLAN
-----------------------------------------------------------------------------------------
Nested Loop (cost=4.95..573640.43 rows=159220 width=76)
-> Seq Scan on cnts (cost=0.00..36.00 rows=2000 width=39)
-> Bitmap Heap Scan on alog (cost=4.95..285.80 rows=80 width=37)
Recheck Cond: ((alog.uid)::integer = (cnts.uid)::integer)
-> Bitmap Index Scan on alog_uid_idx (cost=0.00..4.93 rows=80 width=0)
Index Cond: ((alog.uid)::integer = (cnts.uid)::integer)
(6 rows)

Trying EXPLAIN ANALZYE now on this makes it run forever...

How can I bring it back to working? Like un-run ANALYZE on that table or
something? All was running reasonably well before I changed from
autovacuum to running ANALYZE manually, and I thought I would improve
performance... ;(

--
Miernik
http://miernik.name/


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Miernik <public@public.miernik.name> writes:
> miernik=> EXPLAIN UPDATE cnts SET p0 = FALSE WHERE uid IN (SELECT uid FROM alog WHERE pid = 3452654 AND o = 1);
> QUERY PLAN
> -----------------------------------------------------------------------------------------------
> Nested Loop IN Join (cost=0.00..3317.34 rows=1 width=44)
> -> Seq Scan on cnts (cost=0.00..36.00 rows=2000 width=44)
> -> Index Scan using alog_uid_idx on alog (cost=0.00..296.95 rows=1 width=4)
> Index Cond: ((alog.uid)::integer = (cnts.uid)::integer)
> Filter: ((alog.pid = 3452654::numeric) AND (alog.o = 1::numeric))
> (5 rows)

> But if I give him only the inner part, it makes reasonable assumptions
> and runs OK:

What's the results for

explain select * from cnts, alog where alog.uid = cnts.uid

?

If necessary, turn off enable_hashjoin and enable_mergejoin so we can
see a comparable plan. I'm suspecting it thinks the condition on
uid is more selective than the one on the other index.

regards, tom lane

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [GENERAL] 100% CPU pg processes that don't die.

On Sat, Aug 9, 2008 at 2:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Scott Marlowe" <scott.marlowe@gmail.com> writes:
>> I'm load testing a machine, and i'm seeing idle in transaction
>> processes that are no longer hooked to any outside client, that pull
>> 100% CPU and can't be kill -9ed.
>
> To my knowledge, the only way a process can't be kill -9'd is if it's
> stuck inside the kernel (typically, doing I/O to a nonresponsive disk).
> There's certainly no way for a userland process to defend itself against
> kill -9. So my immediate response would have been to look for a
> hardware problem, or failing that a kernel bug. I see from the
> subsequent thread that indeed hardware failure looks to be the answer,
> but that should have been your first assumption.

It was before this. That's why I'd swapped the RAID cards. It's just
that this is the first time this has happened without killing the box,
so I wanted to be sure it didn't look like something else to anybody.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 100% CPU pg processes that don't die.

"Scott Marlowe" <scott.marlowe@gmail.com> writes:
> I'm load testing a machine, and i'm seeing idle in transaction
> processes that are no longer hooked to any outside client, that pull
> 100% CPU and can't be kill -9ed.

To my knowledge, the only way a process can't be kill -9'd is if it's
stuck inside the kernel (typically, doing I/O to a nonresponsive disk).
There's certainly no way for a userland process to defend itself against
kill -9. So my immediate response would have been to look for a
hardware problem, or failing that a kernel bug. I see from the
subsequent thread that indeed hardware failure looks to be the answer,
but that should have been your first assumption.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Something goes wrong that this query plan thinks there is only gonna be
1 row from (SELECT uid FROM alog ... ) so chooses such query plan, and
thus it runs forever (at least so long that I didn't bother to wait,
like 10 minutes):


miernik=> EXPLAIN UPDATE cnts SET p0 = FALSE WHERE uid IN (SELECT uid FROM alog WHERE pid = 3452654 AND o = 1);
QUERY PLAN
-----------------------------------------------------------------------------------------------
Nested Loop IN Join (cost=0.00..3317.34 rows=1 width=44)
-> Seq Scan on cnts (cost=0.00..36.00 rows=2000 width=44)
-> Index Scan using alog_uid_idx on alog (cost=0.00..296.95 rows=1 width=4)
Index Cond: ((alog.uid)::integer = (cnts.uid)::integer)
Filter: ((alog.pid = 3452654::numeric) AND (alog.o = 1::numeric))
(5 rows)


But if I give him only the inner part, it makes reasonable assumptions
and runs OK:

miernik=> EXPLAIN SELECT uid FROM alog WHERE pid = 3452654 AND o = 1;
QUERY PLAN
-----------------------------------------------------------------------------------------
Bitmap Heap Scan on alog (cost=100.21..9559.64 rows=3457 width=4)
Recheck Cond: ((pid = 3452654::numeric) AND (o = 1::numeric))
-> Bitmap Index Scan on alog_pid_o_idx (cost=0.00..99.35 rows=3457 width=0)
Index Cond: ((pid = 3452654::numeric) AND (o = 1::numeric))
(4 rows)

Can't show you EXPLAIN ANALYZE for the first one, as it also runds
forver. For the second one, its consistent with the EXPLAIN.

Before it was running OK, but I recently disabled autovacuum and now run
VACUUM manually serveal times a day, and run ANALYZE manually on alog
and cnts tables before runnign the above. How may I fix this to work?

shared_buffers = 5MB
work_mem = 1MB
Machine is a 48 MB RAM Xen.

But not the disabling autovacuum broke it, but running ANALYZE manually
on the tables broke it, and I don't know why, I thougt ANALYZE would
improve the guesses?

--
Miernik
http://miernik.name/


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [GENERAL] 100% CPU pg processes that don't die.

On Sat, Aug 9, 2008 at 1:47 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Scott Marlowe (scott.marlowe@gmail.com) wrote:
>> I take that back. This problem followed the RAID card from one
>> machine to another.
>
> That's certainly curious. The kernel backtrace didn't seem to have
> anything terribly interesting in it (at least to me). Sure there aren't
> more detailed logs? With an actual "Kernel BUG" or 'OOPS' line? What
> does dmesg look like? Maybe try posting to lkml?

That's what I'm thinking, but that machien just hung hard and isn't
coming back up and I don't feel like driving to the hosting center for
a broken machine. We've got a replacement card on the way already,
and the problem is NOT happening with the other card (so far, a week
of testing).

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [ADMIN] Problems with connection

Курашкин Дмитрий wrote:
> Hi to all!
>
> I have following systems:
> 1. Local machine with Windows XP SP2 and PostgreSQL 8.2 - test system.
> 2. Work server in local network (FreeBSD + PostgreSQL 8.2) - work
> system.
>
> I write client with Delphi 7 IDE and use Zeos Lib 6.6.2
> (http://zeos.firmos.at/) for database access.
>
> When I tried to connect to server I recieve error message: "SQL Error:
> fe_sendauth: authentication type 5 not supported."
> After searching in internet I found solution: set authentication
> method "password" instead of "md5".
> In file pg_hba.conf on local machine I wrote:
>
> # TYPE DATABASE USER CIDR-ADDRESS METHOD
> host all all 127.0.0.1/32 password
>
> and on server:
> # TYPE DATABASE USER CIDR-ADDRESS METHOD
> host all all 192.168.3.0/24 password
>
> My IP-address in local network is 192.168.3.16...
>
> After that I can to connect to test PostgreSQL server on localhost,
> and connection works fine, but attempt to connect to work server finishes by
> same error message "SQL Error: fe_sendauth: authentication type 5 not
> supported."
>
> I tried to place string in pg_hba.conf on first and last positions,
> wrote names of databases and users instead of "all" but it doesn't
> work.
>
Understanding the net mask:
----------------------------
The IPv4 address is 32bits, arranged in 4 sets of 8 bits each.
The decimal range for an IP mask is 0.0.0.0-255.255.255.255.
The net mask defines how many bits need to match, counting from the left.

For example a netmask /8 means the first 8 bits must exactly match,
for example 192.168.0.101/8 means all IPs beginning with 192 can connect.
/16 means the: first 16 bits have to match that is the first two numbers
in the IP must match
e.g. 192.168.0.101/16 means that all IPs begining with 192.168 can connect.
/32 means: the entire IP must match exactly for example 192.168.0.101/32
means that only an IP exactly equal to 192.168.0.101 may connect.

How can we use it:

# trust anyone attached to same machine as the database (no password
required)
host all all 127.0.0.1/32 trust

# allow anyone to attach to any db FROM THIS ONE IP but require a
password encrypted via md5
host all all 192.168.0.101/32 md5

Also note that the pg_hba.conf file is read only on server startup or
when the postmaster receives a SIGHUP signal. If you edit the file, you
must restart the server or SIGHUP the postmaster for the changes to take
effect.

You can use

pg_ctl reload -D /usr/local/pgsql/data

Note: /usr/local/pgsql/data is a Linux path to the database, use
equivalent for windows. The pg_ctl program is in the postgres bin directory.

See this link for more info:
http://developer.postgresql.org/pgdocs/postgres/auth-pg-hba-conf.html

--Cheers,
HH
> As I understand, my main problem is to force PostgreSQL server allow
> me to connect with password authentication method, isn't it? And how I
> can do that?
>
> P. S. Sorry for poor english...
>
>
>


--
H. Hall
ReedyRiver Group LLC
http://www.reedyriver.com


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [GENERAL] 100% CPU pg processes that don't die.

* Scott Marlowe (scott.marlowe@gmail.com) wrote:
> I take that back. This problem followed the RAID card from one
> machine to another.

That's certainly curious. The kernel backtrace didn't seem to have
anything terribly interesting in it (at least to me). Sure there aren't
more detailed logs? With an actual "Kernel BUG" or 'OOPS' line? What
does dmesg look like? Maybe try posting to lkml?

Stephen

Re: [BUGS] BUG #3818: Cross compilation problems

Sorry about the delay on this. Just managed to find some time to look
into it again.

I've made a couple of patches, for 8.3.3 and 8.2.9, which enable cross
compilation for windows (mingw32) from a unix platform.

The changes are in these areas:

1. configure.in detecting the target system versions of dllwrap,
dlltool, windres and ar
2. in various makefiles, checking BUILDOS not PORTNAME when deciding
whether to use 'pwd -W' or just 'pwd'
3. Using the local system's 'zic' command when cross compiling, adding a
--with-zic option to configure.in in case zic is not in the path (on my
fedora 9 system it is in /usr/sbin/zic).
4. Some path tweaks in the make files to allow the cross compile build
to occur outside the the source directory.
5. Working round a binutils-2.18 bug in windres when the rc file has /
or \ in the path

If I apply the patches and run autoconf then I can do a full cross
compile and install (to a distribution dir) for 8.3.3 and 8.2.9 using a
configure like:

PATH=/usr/local/xc/bin:$PATH ../postgresql-8.3.3/configure
--host=mingw32 --without-zlib \
--prefix=somedir --libdir=somedir/bin --with-zic=/usr/sbin/zic

I have my cross compilation tool set in /usr/local/xc; I set libdir so
that the dlls end up in the bin dir which makes running on windows
easier ...

I've also tested native builds on a mingw32 system using the patched files.

Hope this helps.

Richard
> Richard, would you send us patches for the cross compile variables you
> needed changed? Thanks.
>
> ---------------------------------------------------------------------------
>
> Richard Evans wrote:
>
>> The following bug has been logged online:
>>
>> Bug reference: 3818
>> Logged by: Richard Evans
>> Email address: richard.evans@blueallegro.net
>> PostgreSQL version: 8.3beta
>> Operating system: Linux/windows
>> Description: Cross compilation problems
>> Details:
>>
>> I've been investigating cross-compiling for mingw32 on a linux build system.
>> I used the current snapshot since it has a fix for the gettimeofday problem
>> with new mingw installs.
>>
>> Mostly it worked, but there were a few problems which I think can all be
>> fixed in the configure script:
>>
>> 1. The configure script does not check for cross-compile installs of ar,
>> dlltool, dllwrap and windres. It manages to find the cross compile gcc
>> (mingw32-gcc in my install), but does not check for mingw32-dlltool, etc.
>> You work round this by setting AR= DLLTOOL= and DLLWRAP= on the make line
>> but ideally it should be done in the configure stage.
>>
>> 2. The Makefile in pgevent/bin refers to dllwrap directly, not $(DLLWRAP).
>>
>> 3. Several makefiles use windres directly; there is no $(WINDRES) variable
>> which can be set.
>>
>> 4. The zic problem in make install - see bug #1311. Simple solution here is
>> to have a configure option which allows the use of the build systems own zic
>> command.
>>
>> I may try coming up with some patches to configure to check for dlltool, etc
>> but I haven't edited configure files before.
>>
>> Once I worked round these problems I was able to cross compile a working
>> postgres for mingw32 on a linux host.
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 1: if posting/reading through Usenet, please send an appropriate
>> subscribe-nomail command to majordomo@postgresql.org so that your
>> message can get through to the mailing list cleanly
>>
>
>

Re: [GENERAL] 100% CPU pg processes that don't die.

On Sat, Aug 9, 2008 at 1:38 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> On Sat, Aug 9, 2008 at 1:31 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> * Scott Marlowe (scott.marlowe@gmail.com) wrote:
>>> Aug 9 13:13:21 engelberg kernel: [71242.735046]
>>>
>>> Does this look like a kernel bug or a pgsql bug to most people?
>>
>> It's certainly something kernel-related. It might be the OOM killer
>> though.. You might want to disable that. Is the box running out of
>> memory (run 'free')?
>
> Hehe, no. It's got 32 Gig of ram and is using 25G of that for kernel
> cache. There are no entries in any log for oom killer that I can see.
>
> Hmmm. I'm running the latest Ubuntu LTS with 2.6.24-19-server kernel.
>
> Just ran the latest apt-get upgrade and only was missing an update to
> pciutils.
>
> btw, here's the output of free:
>
> total used free shared buffers cached
> Mem: 33080292 32983004 97288 0 87992 24882632
> -/+ buffers/cache: 8012380 25067912
> Swap: 7815580 144 7815436
>
> Interesting thing, I've got a machine with the same configuration
> sitting next to it that's not doing this. But it seems odd it could
> be hardware induced.

I take that back. This problem followed the RAID card from one
machine to another.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 100% CPU pg processes that don't die.

On Sat, Aug 9, 2008 at 1:31 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Scott Marlowe (scott.marlowe@gmail.com) wrote:
>> Aug 9 13:13:21 engelberg kernel: [71242.735046]
>>
>> Does this look like a kernel bug or a pgsql bug to most people?
>
> It's certainly something kernel-related. It might be the OOM killer
> though.. You might want to disable that. Is the box running out of
> memory (run 'free')?

Hehe, no. It's got 32 Gig of ram and is using 25G of that for kernel
cache. There are no entries in any log for oom killer that I can see.

Hmmm. I'm running the latest Ubuntu LTS with 2.6.24-19-server kernel.

Just ran the latest apt-get upgrade and only was missing an update to
pciutils.

btw, here's the output of free:

total used free shared buffers cached
Mem: 33080292 32983004 97288 0 87992 24882632
-/+ buffers/cache: 8012380 25067912
Swap: 7815580 144 7815436

Interesting thing, I've got a machine with the same configuration
sitting next to it that's not doing this. But it seems odd it could
be hardware induced.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 100% CPU pg processes that don't die.

* Scott Marlowe (scott.marlowe@gmail.com) wrote:
> Aug 9 13:13:21 engelberg kernel: [71242.735046]
>
> Does this look like a kernel bug or a pgsql bug to most people?

It's certainly something kernel-related. It might be the OOM killer
though.. You might want to disable that. Is the box running out of
memory (run 'free')?

Stephen

Re: [PERFORM] Distant mirroring

On Sat, Aug 9, 2008 at 11:29 AM, dforum <dforums@vieonet.com> wrote:
> Hello,
>
> I'm trying to install a solution to permit me to :
> - Secure the datas, without RAID

Nothing beats a simple mirror set for simplicity while protecting the
data, and for a pretty cheap cost. How much is your data worth?

> - Giving ability to increase the potentiality of the database towards the
> needs.
>
> I have read about slony, DRBD, pgpool....
>
> I don't find the good system to do what I want.
>
> I manage for now 50 millions of request per month.

Assuming they all happen from 9 to 5 and during business days only,
that's about 86 transactions per second. Well within the realm of a
single mirror set to keep up if you don't make your db work real fat.

> I will reach 100 millions in the end of the year I suppose.

That takes us to 172 transactions per second.

> There is 2 difficulties :
> 1 - is the storage : to get faster access,it is recommend to use SAS 15 000
> tps. But the disk I can get are 149 GO of space. As the database is growing
> par 1,7 Go per week at the moment, it will reach is maximum in 3 month. I
> can add 3 disk at least so It can go to 9 month. What to do after, and
> especially what to do today to prevent it?

No, don't piecemeal just enough to outrun the disk space boogieman
each month. Buy enough to last you at least 1 year in the future.
More if you can afford it.

> 2 - The machine will treat more and more simultaneous entrance, so I need to
> loadbalance those inserts/updates on several machine and to replicate the
> datas between them. It's not a real problem if the data are asynchrony.

Then PostgreSQL might not be your best choice. But I think you're
wrong. You can easily handle the load you're talking about on a
mid-sized box for about $5000 to $10000.

You can use 7200 rpm SATA drives, probably 8 to 12 or so, in a RAID-10
with a battery backed cache and hit 172 transactions per second.

Given the 1+ G a week storage requirement, you should definitely look
at using inheritance to do partitioning. Then use slony or something
to replicate the data into the back office for other things. There's
always other things most the time that are read only.

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [BUGS] ALTER TABLE name RENAME TO new_name; does not work immediately

Here is a script that is able to reproduce the problem (on my machine
anyway), you may need to play with the number of rows or workmem
settings to be able to reproduce it:

regards,
Ondrej Jirman

#!/bin/sh

dropdb bug
createdb bug

psql bug << EOF

CREATE TABLE xxx (id SERIAL, col1 TEXT, col2 TEXT);

INSERT INTO xxx
SELECT s AS id, s || 'XXXX' AS col1, s || 'YYYYY' AS col2
FROM generate_series(0, 2000000) AS s;

EOF

psql bug << EOF

SET maintenance_work_mem = 256000;
SET work_mem = 256000;
SHOW maintenance_work_mem;
SHOW work_mem;

VACUUM FULL ANALYZE;
REINDEX DATABASE bug;

BEGIN;

ALTER TABLE xxx RENAME TO yyy;
ALTER TABLE yyy RENAME COLUMN col1 TO colA;
ALTER TABLE yyy RENAME COLUMN col2 TO colB;

COMMIT;

EOF

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[GENERAL] 100% CPU pg processes that don't die.

I'm load testing a machine, and i'm seeing idle in transaction
processes that are no longer hooked to any outside client, that pull
100% CPU and can't be kill -9ed. I'm using pgbench -c 1000 -t 1000.
postgresql.conf attached. This is on a 8 CPU AMD box with hardware
RAID. I'll likely never see this many parallel connections in
production, but who knows... I want to reboot the machine to test at
a lower number of threads but if there's more info in it to gain
knowledge from I'll leave it up.

They look like this in top:

3552 postgres 20 0 8286m 82m 78m R 100 0.3 195:04.22 postgres:
postgres postgres [local] idle in transaction
3561 postgres 20 0 8286m 83m 79m R 100 0.3 195:04.20 postgres:
postgres postgres [local] idle in transaction

This in ps aux|grep postgres:

postgres 3561 95.2 0.2 8485376 85708 ? Rs 09:45 197:17
postgres: postgres postgres [local] idle in transaction

The db is still up and accessable. I'm also getting this in my
/var/log/messages:

Aug 9 13:13:21 engelberg kernel: [71242.734934] CPU 1:
Aug 9 13:13:21 engelberg kernel: [71242.734935] Modules linked in:
iptable_filter ip_tables x_tables parport_pc lp parport loop ipv6
evdev i2c_nforce2 pcspkr shpchp button pci_hotplug i2c_core pata_amd
ata_generic ext3 jbd mbcache sg sr_mod cdrom sd_mod e1000 floppy
arcmsr pata_acpi libata ehci_hcd forcedeth ohci_hcd scsi_mod usbcore
thermal processor fan fbcon tileblit font bitblit softcursor fuse
Aug 9 13:13:21 engelberg kernel: [71242.734972] Pid: 294, comm:
kswapd0 Not tainted 2.6.24-19-server #1
Aug 9 13:13:21 engelberg kernel: [71242.734974] RIP:
0010:[floppy:_spin_lock_irqsave+0x12/0x30]
[floppy:_spin_lock_irqsave+0x12/0x30] _spin_lock_irqsave+0x12/0x30
Aug 9 13:13:21 engelberg kernel: [71242.734980] RSP:
0018:ffff810415423df8 EFLAGS: 00000286
Aug 9 13:13:21 engelberg kernel: [71242.734982] RAX: 0000000000000246
RBX: ffff81000003137d RCX: 0000000000000003
Aug 9 13:13:21 engelberg kernel: [71242.734984] RDX: 0000000000000001
RSI: ffff810415423ea0 RDI: ffff81000003137d
Aug 9 13:13:21 engelberg kernel: [71242.734987] RBP: ffff810415423d60
R08: 0000000000000000 R09: 0000000000000000
Aug 9 13:13:21 engelberg kernel: [71242.734989] R10: 0000000000000000
R11: ffffffff881a46b0 R12: ffff810415423d60
Aug 9 13:13:21 engelberg kernel: [71242.734991] R13: ffffffff8028d11e
R14: ffff81041f6b2670 R15: ffff810420168178
Aug 9 13:13:21 engelberg kernel: [71242.734994] FS:
00007f51096fd700(0000) GS:ffff8108171a2300(0000)
knlGS:0000000000000000
Aug 9 13:13:21 engelberg kernel: [71242.734997] CS: 0010 DS: 0018
ES: 0018 CR0: 000000008005003b
Aug 9 13:13:21 engelberg kernel: [71242.734999] CR2: 00007f4f27ebffd0
CR3: 0000000000201000 CR4: 00000000000006e0
Aug 9 13:13:21 engelberg kernel: [71242.735001] DR0: 0000000000000000
DR1: 0000000000000000 DR2: 0000000000000000
Aug 9 13:13:21 engelberg kernel: [71242.735003] DR3: 0000000000000000
DR6: 00000000ffff0ff0 DR7: 0000000000000400
Aug 9 13:13:21 engelberg kernel: [71242.735006]
Aug 9 13:13:21 engelberg kernel: [71242.735006] Call Trace:
Aug 9 13:13:21 engelberg kernel: [71242.735009]
[usbcore:prepare_to_wait+0x23/0x80] prepare_to_wait+0x23/0x80
Aug 9 13:13:21 engelberg kernel: [71242.735013] [kswapd+0xfa/0x560]
kswapd+0xfa/0x560
Aug 9 13:13:21 engelberg kernel: [71242.735020] [<ffffffff80254260>]
autoremove_wake_function+0x0/0x30
Aug 9 13:13:21 engelberg kernel: [71242.735026] [kswapd+0x0/0x560]
kswapd+0x0/0x560
Aug 9 13:13:21 engelberg kernel: [71242.735030] [kthread+0x4b/0x80]
kthread+0x4b/0x80
Aug 9 13:13:21 engelberg kernel: [71242.735034] [child_rip+0xa/0x12]
child_rip+0xa/0x12
Aug 9 13:13:21 engelberg kernel: [71242.735040] [kthread+0x0/0x80]
kthread+0x0/0x80
Aug 9 13:13:21 engelberg kernel: [71242.735043] [child_rip+0x0/0x12]
child_rip+0x0/0x12
Aug 9 13:13:21 engelberg kernel: [71242.735046]

Does this look like a kernel bug or a pgsql bug to most people?

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [BUGS] ALTER TABLE name RENAME TO new_name; does not work immediately

On 9 Srp, 19:38, st...@enterprisedb.com (Gregory Stark) wrote:
> <meg...@gmail.com> writes:
> > ALTER TABLE name RENAME TO new_name;
> > ALTER TABLE new_name
> >   RENAME COLUMN x TO y;
>
> ...
> > I think the issue might be reproducible by creating table with a lot
> > of rows, setting high work_mem and issuing the commands, but I did not
> > try to reproduce it this way.
>
> The commands you described should take the same length of time regardless of
> the size of table and the memory settings are not relevant. I suspect you're
> actually running some different commands?
>
> --
>   Gregory Stark
>   EnterpriseDB          http://www.enterprisedb.com
>   Ask me about EnterpriseDB's On-Demand Production Tuning
>
> --
> Sent via pgsql-bugs mailing list (pgsql-b...@postgresql.org)
> To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-bugs

-- This script will migrate shema from the version 1.1.18 to the
version 1.2.0
-- (i.e. Gardeners integration)

This is what I actually run:

SET search_path = public, isn, pg_catalog;

SET maintenance_work_mem = 256000;
SET work_mem = 256000;

VACUUM FULL ANALYZE;
REINDEX DATABASE shakes;

BEGIN;

ALTER TABLE btbooks
RENAME TO exbooks;

-- following command returns the error
ALTER TABLE exbooks
RENAME COLUMN bt_price TO list_price;

-- many more other commands ....

COMMIT;

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] ALTER TABLE name RENAME TO new_name; does not work immediately

<megous@gmail.com> writes:

> ALTER TABLE name RENAME TO new_name;
> ALTER TABLE new_name
> RENAME COLUMN x TO y;
>
...
> I think the issue might be reproducible by creating table with a lot
> of rows, setting high work_mem and issuing the commands, but I did not
> try to reproduce it this way.

The commands you described should take the same length of time regardless of
the size of table and the memory settings are not relevant. I suspect you're
actually running some different commands?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [pgsql-students] Problem accessing View in VB6

oca@mvc.edu.ph wrote:
>
>
> Thank you, that does the job, but i guess i have to use lowercases for
> my views names.
>
>

I don't see why. Just use:

.Open "SELECT * FROM ""tvwClassSchedules""", dbConn, adOpenDynamic,
adLockReadOnly


AFAIK that is the way to embed quotes in VB Strings.

cheers

andrew

--
Sent via pgsql-students mailing list (pgsql-students@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-students

[PERFORM] Distant mirroring

Hello,

I'm trying to install a solution to permit me to :
- Secure the datas, without RAID
- Giving ability to increase the potentiality of the database towards
the needs.

I have read about slony, DRBD, pgpool....

I don't find the good system to do what I want.

I manage for now 50 millions of request per month.

I will reach 100 millions in the end of the year I suppose.

There is 2 difficulties :
1 - is the storage : to get faster access,it is recommend to use SAS 15
000 tps. But the disk I can get are 149 GO of space. As the database is
growing par 1,7 Go per week at the moment, it will reach is maximum in 3
month. I can add 3 disk at least so It can go to 9 month. What to do
after, and especially what to do today to prevent it?
2 - The machine will treat more and more simultaneous entrance, so I
need to loadbalance those inserts/updates on several machine and to
replicate the datas between them. It's not a real problem if the data
are asynchrony.

I'm migrating to postgresql 8.3.3.

Thanks for all your remarks, suggestions and helps

David

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [pgsql-fr-generale] PostgreSQL Europe veut faire péter la banque

On 09-08-2008, damien clochard wrote:
> Bonjour à toutes et à tous,
>
> Voici une question qui sort un peu du cadre de cette mailing-list puisqu'elle
> concerne plutot PostgreSQL Europe.
>
> L'association "PostgreSQL Europe" a été lancée officielement en février
> dernier à Bruxelles. Il s'agit d'une association basée en France ( loi
> 1901 ). L'association souhaite ouvrir un compte bancaire en France pour y
> placer l'argent dont elle dispose.

Regardez La Nef http://www.lanef.com plutôt que le crédit-coop (qui fait
parti du groupe banque populaire) tant qu'à faire dans l'éthique... Bien
que pour la gestion du compte chèque ça passe quand même par le
crédit-coop en attendant mieux. C'est surtout intéressant s'il y a de la
trésorerie car on sait exactement où est placé l'argent (dans des
associations écologiques, sociales ou culturelles). Je ne sais pas s'il
y a déjà un précédent dans le domaine des logiciels libres, ça vaudrait
le coup de se renseigner en même temps.

En pratique, je ne sais pas si c'est valable pour les associations mais
à titre personnel j'y ai un compte domicilié à "l'agence en ligne"
plutôt que dans une agence régionale et du coup je n'ai pas de frais
mensuel comme indiqué sur le wiki. Les contacts sont plutôt bons pour ce
qui est de la gestion au quotidien.

--
William Dodé - http://flibuste.net
Informaticien Indépendant


--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale

Re: [pgsql-students] Problem accessing View in VB6

----- Message from andrew@dunslane.net ---------
Date: Sat, 09 Aug 2008 11:46:18 -0400
From: Andrew Dunstan <andrew@dunslane.net>
Reply-To: Andrew Dunstan <andrew@dunslane.net>
Subject: Re: [pgsql-students] Problem accessing View in VB6
To: oca@mvc.edu.ph
Cc: pgsql-students@postgresql.org


>
>
> oca@mvc.edu.ph wrote:
>>
>> hi,
>>
>> I got problem accessing views in Visual Basic 6. Dim rsSchedule As
>> New Recordset
>> With rsSchedule
>> .Open "SELECT * FROM tvwClassSchedules", dbConn, adOpenDynamic,
>> adLockReadOnly
>> .Close
>> End With
>>
>> I got this error:
>>
>> ERROR: relation "tvwClassSchedules" does not exist;
>> Error while executing the query
>>
>> this view exist because i can use the view in pgAdmin to display
>> the records.
>>
>>
>
> If that is really the name of the view then the name needs to be quoted
> in double quotes. Postgres folds unquoted names to lower case.
>
> cheers
>
> andrew
>
> --
> Sent via pgsql-students mailing list (pgsql-students@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-students


----- End message from andrew@dunslane.net -----

Thank you, that does the job, but i guess i have to use lowercases for
my views names.

oscar

--
Sent via pgsql-students mailing list (pgsql-students@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-students

Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

> gcc wasn't the suspected candidate --- the netbsd guys
> thought it was
> as or ld. On my Fedora machine those seem to be part of
> the binutils
> package; dunno how Debian handles it.
>

Yeah, it appears to be the binutils package on debian too. I have the latest version from apt, I've checked backports too but the versions are the same.


__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-students] Problem accessing View in VB6

oca@mvc.edu.ph wrote:
>
> hi,
>
> I got problem accessing views in Visual Basic 6.
>
> Dim rsSchedule As New Recordset
> With rsSchedule
> .Open "SELECT * FROM tvwClassSchedules", dbConn, adOpenDynamic,
> adLockReadOnly
> .Close
> End With
>
> I got this error:
>
> ERROR: relation "tvwClassSchedules" does not exist;
> Error while executing the query
>
> this view exist because i can use the view in pgAdmin to display the
> records.
>
>

If that is really the name of the view then the name needs to be quoted
in double quotes. Postgres folds unquoted names to lower case.

cheers

andrew

--
Sent via pgsql-students mailing list (pgsql-students@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-students

[pgsql-fr-generale] PostgreSQL Europe veut faire péter la banque

Bonjour à toutes et à tous,

Voici une question qui sort un peu du cadre de cette mailing-list puisqu'elle
concerne plutot PostgreSQL Europe.

L'association "PostgreSQL Europe" a été lancée officielement en février
dernier à Bruxelles. Il s'agit d'une association basée en France ( loi
1901 ). L'association souhaite ouvrir un compte bancaire en France pour y
placer l'argent dont elle dispose.

Plusieurs membres du bureau ( ainsi que moi-même ) sont actuellement en train
d'étudier les différentes possibilités. Afin de faire le meilleur choix,
PostgreSQL Europe est à la recherche d'informations concernant les services
et les tarifs que les banques françaises proposent aux associations.

Ces recherches étant un peu fastidueuses et pas franchement passionantes, je
sollicite votre aide.

Si vous êtes membre d'une association, pouvez-vous vous renseigner sur les
services et les conditions de sa banque ?

J'aimerais en particulier avoir des réponses aux questions suivantes :

* Quel est le nom de la banque ?
* Quel est le tarif mensuel ? le cout d'une transaction ?
* L'outil de gestion de compte en ligne est-il traduit en anglais ?
* Le service est-il satisfaisant ?

Je recherche en particulier des informations sur les banques suivantes :

- HSBC
- Société Générale
- Caisse d'Epargne
- Crédit Mutuel

Tout témoignage sur une autre banque est bien-sûr le bienvenu.

Si vous ne souhaitez pas diffuser publiquement ces informations, envoyez-moi
votre réponse en privé à l'adresse suivante : damien@dalibo.info

L'état actuel des recherches est disponible sur le wiki de l'association :

http://wiki.postgresql.eu/wiki/Bank_matrix

Merci d'avance.


--
damien clochard
http://dalibo.org | http://dalibo.com

--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale

[COMMITTERS] psqlodbc - psqlodbc: commit test

Log Message:
-----------
commit test

Modified Files:
--------------
psqlodbc:
readme.txt (r1.9 -> r1.10)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/readme.txt.diff?r1=1.9&r2=1.10)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[pgsql-students] Problem accessing View in VB6

hi,

I got problem accessing views in Visual Basic 6. 

Dim rsSchedule As New Recordset
With rsSchedule
    .Open "SELECT * FROM tvwClassSchedules", dbConn, adOpenDynamic, adLockReadOnly
    .Close
End With

I got this error:

ERROR: relation "tvwClassSchedules" does not exist;
Error while executing the query

this view exist because i can use the view in pgAdmin to display the records.

please help.

thank you,
ocavid


[pgsql-students] Problem accessing View in VB6

hi,

I got problem accessing views in Visual Basic 6. 

Dim rsSchedule As New Recordset
With rsSchedule
    .Open "SELECT * FROM tvwClassSchedules", dbConn, adOpenDynamic, adLockReadOnly
    .Close
End With

I got this error:

ERROR: relation "tvwClassSchedules" does not exist;
Error while executing the query

this view exist because i can use the view in pgAdmin to display the records.

please help.

thank you,
ocavid


[ADMIN] setting datestyle

Dear Friends,
I have tried to set datestyle to 'DMY'. As per manual and many other posts related to this point, I have set datestyle to 'DMY' at database. but still it is needed to execute each time set datestyle to 'DMY' before starting any new connection. Once this is set, there is no problem for that connection till it was live. Is there any solution to this problem? Why even after setting database property datastyle to 'DMY' gives an error when set datestyle to 'DMY' is not executed at starting connection?

Please help.

Thanks
CPK

--
Keep your Environment clean and green.

[HACKERS] which statements need bind/describe messages?

My client library sends Parse/Bind/Describe/Execute/Sync for each query,
unless it's using a previously-prepared statement, in which case it can
omit the Parse message.

For which statements can I also avoid sending Bind and Describe?

As far as I can tell, I can just send Parse/Execute/Sync for any utility
statements (i.e. those that are handled by ProcessUtility()) that do not
UtilityReturnsTuples(). Furthermore, I can omit Describe for ordinary
(i.e. without "returning") INSERT and DELETE and UPDATE. Right?

I could also omit Bind for any queries that do not have bind parameters,
except that I always want binary-format results; so I suppose I always
have to send Bind for non-utility statements.

Comments appreciated.

-- ams

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Verbosity of Function Return Type Checks

Index: src/pl/plpgsql/src/pl_exec.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/pl/plpgsql/src/pl_exec.c,v
retrieving revision 1.216
diff -c -r1.216 pl_exec.c
*** src/pl/plpgsql/src/pl_exec.c 16 May 2008 18:34:51 -0000 1.216
--- src/pl/plpgsql/src/pl_exec.c 9 Aug 2008 10:10:32 -0000
***************
*** 190,196 ****
Oid reqtype, int32 reqtypmod,
bool isnull);
static void exec_init_tuple_store(PLpgSQL_execstate *estate);
! static bool compatible_tupdesc(TupleDesc td1, TupleDesc td2);
static void exec_set_found(PLpgSQL_execstate *estate, bool state);
static void plpgsql_create_econtext(PLpgSQL_execstate *estate);
static void free_var(PLpgSQL_var *var);
--- 190,196 ----
Oid reqtype, int32 reqtypmod,
bool isnull);
static void exec_init_tuple_store(PLpgSQL_execstate *estate);
! static void validate_tupdesc_compat(TupleDesc td1, TupleDesc td2, char *msg);
static void exec_set_found(PLpgSQL_execstate *estate, bool state);
static void plpgsql_create_econtext(PLpgSQL_execstate *estate);
static void free_var(PLpgSQL_var *var);
***************
*** 386,396 ****
{
case TYPEFUNC_COMPOSITE:
/* got the expected result rowtype, now check it */
! if (estate.rettupdesc == NULL ||
! !compatible_tupdesc(estate.rettupdesc, tupdesc))
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("returned record type does not match expected record type")));
break;
case TYPEFUNC_RECORD:

--- 386,394 ----
{
case TYPEFUNC_COMPOSITE:
/* got the expected result rowtype, now check it */
! validate_tupdesc_compat(tupdesc, estate.rettupdesc,
! "returned record type does not "
! "match expected record type");
break;
case TYPEFUNC_RECORD:

***************
*** 707,717 ****
rettup = NULL;
else
{
! if (!compatible_tupdesc(estate.rettupdesc,
! trigdata->tg_relation->rd_att))
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("returned tuple structure does not match table of trigger event")));
/* Copy tuple to upper executor memory */
rettup = SPI_copytuple((HeapTuple) DatumGetPointer(estate.retval));
}
--- 705,714 ----
rettup = NULL;
else
{
! validate_tupdesc_compat(trigdata->tg_relation->rd_att,
! estate.rettupdesc,
! "returned tuple structure does not match "
! "table of trigger event");
/* Copy tuple to upper executor memory */
rettup = SPI_copytuple((HeapTuple) DatumGetPointer(estate.retval));
}
***************
*** 2201,2211 ****
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("record \"%s\" is not assigned yet",
rec->refname),
! errdetail("The tuple structure of a not-yet-assigned record is indeterminate.")));
! if (!compatible_tupdesc(tupdesc, rec->tupdesc))
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("wrong record type supplied in RETURN NEXT")));
tuple = rec->tup;
}
break;
--- 2198,2208 ----
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("record \"%s\" is not assigned yet",
rec->refname),
! errdetail("The tuple structure of a not-yet-assigned"
! " record is indeterminate.")));
! validate_tupdesc_compat(rec->tupdesc, tupdesc,
! "wrong record type supplied in "
! "RETURN NEXT");
tuple = rec->tup;
}
break;
***************
*** 2311,2320 ****
stmt->params);
}

! if (!compatible_tupdesc(estate->rettupdesc, portal->tupDesc))
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("structure of query does not match function result type")));

while (true)
{
--- 2308,2316 ----
stmt->params);
}

! validate_tupdesc_compat(portal->tupDesc, estate->rettupdesc,
! "structure of query does not match function "
! "result type");

while (true)
{
***************
*** 5138,5160 ****
}

/*
! * Check two tupledescs have matching number and types of attributes
*/
! static bool
! compatible_tupdesc(TupleDesc td1, TupleDesc td2)
{
! int i;

if (td1->natts != td2->natts)
! return false;

for (i = 0; i < td1->natts; i++)
- {
if (td1->attrs[i]->atttypid != td2->attrs[i]->atttypid)
! return false;
! }
!
! return true;
}

/* ----------
--- 5134,5170 ----
}

/*
! * Validates compatibility of supplied TupleDesc couple by checking # and type
! * of available arguments.
*/
! static void
! validate_tupdesc_compat(TupleDesc td1, TupleDesc td2, char *msg)
{
! int i;
!
! if (!td1 || !td2)
! ereport(ERROR, (errcode(ERRCODE_DATATYPE_MISMATCH), errmsg(msg)));

if (td1->natts != td2->natts)
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg(msg),
! errdetail("Number of returned columns (%d) does not match "
! "expected column count (%d).",
! td1->natts, td2->natts)));

for (i = 0; i < td1->natts; i++)
if (td1->attrs[i]->atttypid != td2->attrs[i]->atttypid)
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg(msg),
! errdetail("Returned record type (%s) does not match "
! "expected record type (%s) in column %d (%s).",
! format_type_with_typemod(td1->attrs[i]->atttypid,
! td1->attrs[i]->atttypmod),
! format_type_with_typemod(td2->attrs[i]->atttypid,
! td2->attrs[i]->atttypmod),
! (1+i), NameStr(td2->attrs[i]->attname))));
}

/* ----------
[Please ignore the previous reply.]

On Fri, 8 Aug 2008, Alvaro Herrera <alvherre@commandprompt.com> writes:
> I think this is a good idea, but the new error messages need more work.
> Have a look at the message style guidelines please,
> http://www.postgresql.org/docs/8.3/static/error-style-guide.html

Right. Done -- I hope.

> Particularly I think you need to keep the original errmsg() and add the
> new messages as errdetail().

Made callers pass related error message as a string parameter, and
appended required details using errdetail().

> (I notice that there's the slight problem
> that the error messages are different for the different callers.)

Above mentioned change should have addressed this issue too.

> Also, please use context diffs.

Done.


Regards.

Re: [HACKERS] Verbosity of Function Return Type Checks

Index: src/pl/plpgsql/src/pl_exec.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/pl/plpgsql/src/pl_exec.c,v
retrieving revision 1.216
diff -r1.216 pl_exec.c
193c193
< static bool compatible_tupdesc(TupleDesc td1, TupleDesc td2);
---
> static void validate_tupdesc_compat(TupleDesc td1, TupleDesc td2);
389,393c389
< if (estate.rettupdesc == NULL ||
< !compatible_tupdesc(estate.rettupdesc, tupdesc))
< ereport(ERROR,
< (errcode(ERRCODE_DATATYPE_MISMATCH),
< errmsg("returned record type does not match expected record type")));
---
> validate_tupdesc_compat(tupdesc, estate.rettupdesc);
710,714c706,707
< if (!compatible_tupdesc(estate.rettupdesc,
< trigdata->tg_relation->rd_att))
< ereport(ERROR,
< (errcode(ERRCODE_DATATYPE_MISMATCH),
< errmsg("returned tuple structure does not match table of trigger event")));
---
> validate_tupdesc_compat(trigdata->tg_relation->rd_att,
> estate.rettupdesc);
2204,2208c2197,2199
< errdetail("The tuple structure of a not-yet-assigned record is indeterminate.")));
< if (!compatible_tupdesc(tupdesc, rec->tupdesc))
< ereport(ERROR,
< (errcode(ERRCODE_DATATYPE_MISMATCH),
< errmsg("wrong record type supplied in RETURN NEXT")));
---
> errdetail("The tuple structure of a not-yet-assigned"
> " record is indeterminate.")));
> validate_tupdesc_compat(rec->tupdesc, tupdesc);
2314,2317c2305
< if (!compatible_tupdesc(estate->rettupdesc, portal->tupDesc))
< ereport(ERROR,
< (errcode(ERRCODE_DATATYPE_MISMATCH),
< errmsg("structure of query does not match function result type")));
---
> validate_tupdesc_compat(portal->tupDesc, estate->rettupdesc);
5141c5129,5130
< * Check two tupledescs have matching number and types of attributes
---
> * Validates compatibility of supplied TupleDesc couple by checking # and type
> * of available arguments.
5143,5144c5132,5133
< static bool
< compatible_tupdesc(TupleDesc td1, TupleDesc td2)
---
> static void
> validate_tupdesc_compat(TupleDesc td1, TupleDesc td2)
5146c5135,5141
< int i;
---
> int i;
>
> if (!td1 || !td2)
> ereport(ERROR,
> (errcode(ERRCODE_DATATYPE_MISMATCH),
> errmsg("returned record type does not match expected "
> "record type")));
5149c5144,5150
< return false;
---
> ereport(ERROR,
> (errcode(ERRCODE_DATATYPE_MISMATCH),
> errmsg("returned record type does not match expected "
> "record type"),
> errdetail("Number of returned columns (%d) does not match "
> "expected column count (%d).",
> td1->natts, td2->natts)));
5152d5152
< {
5154,5157c5154,5164
< return false;
< }
<
< return true;
---
> ereport(ERROR,
> (errcode(ERRCODE_DATATYPE_MISMATCH),
> errmsg("returned record type does not match expected "
> "record type"),
> errdetail("Returned record type (%s) does not match "
> "expected record type (%s) in column %d (%s).",
> format_type_with_typemod(td1->attrs[i]->atttypid,
> td1->attrs[i]->atttypmod),
> format_type_with_typemod(td2->attrs[i]->atttypid,
> td2->attrs[i]->atttypmod),
> (1+i), NameStr(td2->attrs[i]->attname))));
On Fri, 8 Aug 2008, Alvaro Herrera <alvherre@commandprompt.com> writes:
> I think this is a good idea, but the new error messages need more work.
> Have a look at the message style guidelines please,
> http://www.postgresql.org/docs/8.3/static/error-style-guide.html

Right. Done -- I hope.

> Particularly I think you need to keep the original errmsg() and add the
> new messages as errdetail(). (I notice that there's the slight problem
> that the error messages are different for the different callers.)

Done.

> Also, please use context diffs.

Done.


Regards.

Re: [GENERAL] Disk space occupied by a table in postgresql

On Sat, Aug 09, 2008 at 12:18:46AM -0700, aravind chandu wrote:
> I installed postgresql on linux system, I create a
> table and inserted a large data into the table
> what I would like to know is how to calculate the
> disk space occupied by the table .Is there any
> procedure to find it out or simply a command
> .Please give me some suggestion.

select pg_relation_size('table_name');
or
select pg_total_relation_size('table_name');

both return size in bytes.

pg_total_relation_size includes disk space used by indexes and external
storage (long texts are kept not in table datafile, but in separate
"toast" tables).

Best regards,

depesz

--
Linked in: http://www.linkedin.com/in/depesz
jid/gtalk
: depesz@depesz.com
aim: depeszhdl
skype: depesz_hdl

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Disk space occupied by a table in postgresql

aravind chandu <avin_friends@yahoo.com> schrieb:

> Hello,
>
> I installed postgresql on linux system, I create a table
> and inserted a large data into the table what I would like to know is how to
> calculate the disk space occupied by the table .Is there any procedure to find
> it out or simply a command .Please give me some suggestion.

You can use the pg_relation_size() - function, described here:
http://www.postgresql.org/docs/8.3/interactive/functions-admin.html


Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Disk space occupied by a table in postgresql

Hi Aravind,

Run the following query

SELECT relname, reltuples, relpages * 8 / 1024 AS "MB" FROM pg_class ORDER BY relpages DESC;


relname = table name
relpages = size in MB
reltuples = number of rows.

Hope this help.



Fouad Zaryouh

http://www.flipcore.com




On Sat, Aug 9, 2008 at 3:18 AM, aravind chandu <avin_friends@yahoo.com> wrote:
Hello,

                    I installed postgresql on linux system, I create a table and inserted a large data into the table what I would like to know is how to calculate the disk space occupied by the table .Is there any procedure to find it out or simply a command .Please give me some suggestion.


Thank You,
Avin.


[GENERAL] Disk space occupied by a table in postgresql

Hello,

                    I installed postgresql on linux system, I create a table and inserted a large data into the table what I would like to know is how to calculate the disk space occupied by the table .Is there any procedure to find it out or simply a command .Please give me some suggestion.


Thank You,
Avin.