Hi all,
I have postgresql 7.4.2 running on debian and I have the oddest
postgresql behaviour I've ever seen.
I do the following queries:
espsm_asme=# select customer_app_config_id, customer_app_config_name
from customer_app_config where customer_app_config_id = 5929 or
customer_app_confi
Arnau,
I'm not sure about this for 7.4.2, but I'm running 8.1.3 and when I ran into
a problem like that (having to select two distinct options) the solution that
worked for me was to put the entire or statement within parentheses. In your
case, that would be this:
espsm_asme=# select cu
Hi Andrew,
I'm not sure about this for 7.4.2, but I'm running 8.1.3 and when I ran
into a problem like that (having to select two distinct options) the
solution that worked for me was to put the entire or statement within
parentheses. In your case, that would be this:
espsm_asme=# select cu
Is there a way to terminate a client session without having to restart
Postgres.
Thanks
--
Robert D Oden
Database Marketing Technologies, Inc
951 Locust Hill Circle
Belton MO 64012-1786
Ph: 816-318-8840
Fax: 816-318-8841
[EMAIL PROTECTED]
---(end of broadcast)-
Arnau <[EMAIL PROTECTED]> writes:
>I have postgresql 7.4.2 running on debian and I have the oddest
> postgresql behaviour I've ever seen.
Is this specific to these two rows? If so it might be a case of this
bug, which was repaired in 7.4.13:
http://archives.postgresql.org/pgsql-general/2006
Hi,
We are wondering whether there has been US Commerce Department review of
the Postgres application for export. Specifically, we understand
Postgres contains encryption capabilities, and we would like to include
the application with our products delivered outside the US. Can you let
me know w
Tom Lane wrote:
Arnau <[EMAIL PROTECTED]> writes:
I have postgresql 7.4.2 running on debian and I have the oddest
postgresql behaviour I've ever seen.
Is this specific to these two rows? If so it might be a case of this
bug, which was repaired in 7.4.13:
I don't know, we have discovere
Arnau <[EMAIL PROTECTED]> writes:
>I don't know, we have discovered those two rows but I'm not sure if
> there are more. Is there any way to check it?
Update and see if the problem is gone ...
regards, tom lane
---(end of broadcast)---
Hi all,
Thanks for your help thus far. I almost have 8.2 ready (hooray no more
ancient 7.4). I do have one more problem which is likely the last thing
before pushing out live support. pg_dumpall isn't working.
Right now, we run pg_dumpall as a non-superuser, let's call it backup, whom
we give re
"Peter Koczan" <[EMAIL PROTECTED]> writes:
> Right now, we run pg_dumpall as a non-superuser,
[ raised eyebrow... ] That's never been a recommended procedure.
> The weird thing is, whenever I run this exact same command from psql as the
> backup user, it works.
Maybe you're not trying it in the
Can youo be a bit more specific...? What client?
Psql should terminate the connection when it exist. pgAdmin will close it
when you exit the ap, or if you choose 'Disconnect' from the menu. In PHP
you'll need to call pg_close function... Every 'client' will have a
different method...
-Origina
Hmm, if you are a sysadmin you may want to get the process id for the
query, running something like:
Select procpid,current_query
from pg_stat_activity
where datname="dbname";
If you are running Linux, you'll get the procpid (pid) for the
offending query and by sending "kill -15 " you are
killi
You can also kill the postgres process corresponding to the hung query. do NOT
kill -9. Only kill. Postgres will rollback any uncomitted transaction and
finish that connection gracefully.
On Monday 29 January 2007 18:35, Phillip Smith wrote:
> Can youo be a bit more specific...? What client?
>
>
13 matches
Mail list logo