Обсуждение: any SELECT statement in the 'psql' console returns 'SELECT'
Hi,
It fact, I wrote on newsgroup yesterday about a problem that seemed to come
from "libqp.dll", but it wasn't.
It looks like something going wrong at the server-side (version 7.3.4-2 on
Cygwin 1.5.1) when sending the result of a query.
When I call a function from 'psql' (or 'libpq'), the client returns
"SELECT " (instead of a number)
and here is the client trace:
To backend> Q
To backend> SELECT news_stockIDtoMDS(10)
From backend> C
From backend> "SELECT"
From backend> Z
From backend> Z
When I write a SELECT statement under 'psql' (either in '/usr/bin" or compiled as 'psql.exe' with VC++) ,
the console displays "SELECT ", and here is the trace at the server side:
LOG: plan:
{ SEQSCAN :startup_cost 0.00 :total_cost 20.00 :rows 1000 :width 346
:qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod
-1 :resname _id :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false }
:expr { VAR :varno 1 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0
:varnoold 1 :varoattno 1}} { TARGETENTRY :resdom { RESDOM :resno 2 :restype
1043 :restypmod 36 :resname _mds_code :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 1 :varattno 2 :vartype 1043 :vartypmod 36
:varlevelsup 0 :varnoold 1 :varoattno 2}} { TARGETENTRY :resdom { RESDOM
:resno 3 :restype 1043 :restypmod 36 :resname _ric :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno 3 :vartype
1043 :vartypmod 36 :varlevelsup 0 :varnoold 1 :varoattno 3}} { TARGETENTRY
:resdom { RESDOM :resno 4 :restype 1043 :restypmod 36 :resname _isin :reskey 0
:reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno
4 :vartype 1043 :vartypmod 36 :varlevelsup 0 :varnoold 1 :varoattno 4}} {
TARGETENTRY :resdom { RESDOM :resno 5 :restype 1043 :restypmod 36 :resname
_bloomberg :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr {
VAR :varno 1 :varattno 5 :vartype 1043 :vartypmod 36 :varlevelsup 0 :varnoold
1 :varoattno 5}} { TARGETENTRY :resdom { RESDOM :resno 6 :restype 1043
:restypmod 260 :resname _name :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 1 :varattno 6 :vartype 1043 :vartypmod 260
:varlevelsup 0 :varnoold 1 :varoattno 6}} { TARGETENTRY :resdom { RESDOM
:resno 7 :restype 1043 :restypmod 68 :resname _sector :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno 7 :vartype
1043 :vartypmod 68 :varlevelsup 0 :varnoold 1 :varoattno 7}} { TARGETENTRY
:resdom { RESDOM :resno 8 :restype 1043 :restypmod 6 :resname _country :reskey
0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 1
:varattno 8 :vartype 1043 :vartypmod 6 :varlevelsup 0 :varnoold 1 :varoattno
8}} { TARGETENTRY :resdom { RESDOM :resno 9 :restype 23 :restypmod -1 :resname
_has_parent :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr {
VAR :varno 1 :varattno 9 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1
:varoattno 9}}) :qpqual <> :lefttree <> :righttree <> :extprm () :locprm ()
:initplan <> :nprm 0 :scanrelid 1 }
SEQSCAN :c=0.00..20.00 :r=1000 :w=346 ( stock_mapping )
The server has found 346 records, so why doesn't it work properly?
Before passing to 'ipc-daemon2.exe', it was working well.
Note: I installed Cygwin + PostgreSQL without having logged as an administrator,
updating an older version that was installed as administrator. But the server
encounters no problem to start.
Thanks for any help,
Cedric
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Cedric, On Wed, Oct 08, 2003 at 02:20:52PM +0200, cedric.lemaire@bnpparibas.com wrote: > It looks like something going wrong at the server-side (version > 7.3.4-2 on Cygwin 1.5.1) when sending the result of a query. Try upgrading Cygwin to 1.5.5-1. I just ran a make installcheck under Cygwin 1.5.5-1 without any problems. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Cedric, Please keep your replies on-list. On Thu, Oct 09, 2003 at 08:29:39AM +0200, Cedric Lemaire wrote: > Thanks for your answer. You are welcome. > >> It looks like something going wrong at the server-side (version > >> 7.3.4-2 on Cygwin 1.5.1) when sending the result of a query. > > > Try upgrading Cygwin to 1.5.5-1. I just ran a make installcheck under > > Cygwin 1.5.5-1 without any problems. > > In fact, I wanted to say "1.5.5-1" (I have forgotten a five). > Yesterday, after posting my mail, I did some trials: > - I downgraded to PGSQL 7.3.4-1 (without uninstalling) > -> initdb failed, because of 'ipc-daemon2.exe' I guess (semaphor > stuff), > - I upgraded to 7.3.4-2 (without uninstalling) > -> initdb failed with 'ipc-daemon2.exe' !? It was surprising, so: > - I uninstalled properly PostGreSQL, then I uninstalled 7.3.4-2 > -> initdb ran correctly, > - I ran '/usr/bin/postmaster' (messages on stdin): > -> I populated the database via server functions: 'psql' was returning > "SELECT" after each call, > -> I wrote SELECT statements in 'psql' that were returning "SELECT" > - I stopped 'postmaster' and I ran 'pg_ctl' instead: > -> I populated the database via server functions NORMALLY, > -> I wrote SELECT statements in 'psql' that were returning their value > AS EXPECTED, > > My conclusion, considering the appearances: > - it is very important to uninstall first before installing or > re-installing > PostGreSQL on Cygwin (I tried the reinstall too), > - under 7.3.4-2, it is better to run 'pg_ctl' instead of 'postmaster', > - for me, the problem is now solved. I'm glad you solved your problem. > However, I can't explain why 'postmaster' returns a 'C' answer on > SELECT-like statement, instead of a 'P' answer in the frontend/backend > protocol (I didn't have time to debug the server), when not running as > a background process (and after doing all what I detailed above). > > Doesn't it sound like a bug? Or is it a misuse of 'postmaster'? Sorry, but I'm not qualified to address the above. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6