Hi,
In my source code, I have:
res = PQexec(conn,"select * from resource");
if(PQresultStatus(res) != PGRES_COMMAND_OK){
switch_log_printf(SWITCH_CHANNEL_LOG,SWITCH_LOG_ERROR,"PQexec
failed:%s\n",PQerrorMessage(conn));
PQclear(res);
return NULL;
}
I used if (PQresultStatus(res) != PGRES_TUPLES_OK) and it is fine now.
Thanks,
JB
On Tue, Aug 11, 2009 at 3:35 PM, Juan Backson wrote:
> Hi,
> In my source code, I have:
>
> res = PQexec(conn,"select * from resource");
> if(PQresultStatus(res) != PGRES_COMMAND_OK){
> switch_log_pr
Hi,
I am writing my own connection pool for libpq's connection.
My goal is to try to reduce the amount of time spent in opening and closing
socket. However, I see that Postgres would close my connection after every
so often.
What is the best solution for that? Should I regularly send some "Sel
On Tue, Aug 11, 2009 at 3:56 AM, Juan Backson wrote:
> Hi,
>
> I am writing my own connection pool for libpq's connection.
>
> My goal is to try to reduce the amount of time spent in opening and closing
> socket. However, I see that Postgres would close my connection after every
> so often.
it's
Hi All,
I was looking in what way it's possible to alert via mail when some conditions
are true in a database.
Thanks in advance!
Jan
On Tue, Aug 11, 2009 at 3:35 AM, Juan Backson wrote:
> PGRES_COMMAND_OK
You want PGRES_TUPLES_OK for a select statement. You're not getting an
actual failure- you're checking for the wrong status.
--
- David T. Wilson
david.t.wil...@gmail.com
--
Sent via pgsql-general mailing list (pgsql-gener
Jan Verheyden wrote:
Hi All,
I was looking in what way it’s possible to alert via mail when some
conditions are true in a database.
a probe script that runs periodically (from crontab?) and checks said
conditions, would probably be the best way. this could be tied into a
Nagios style mon
On Aug 11, 2009, at 12:19 AM, Jan Verheyden wrote:
I was looking in what way it’s possible to alert via mail when some
conditions are true in a database.
An external script that connects to the database, checks for the
condition, and sends the email if it exists is probably your best
solu
If I do the following in a pl/pgsql function, will an update lock be
held until the end of the transaction?
PERFORM c FROM t FOR UPDATE;
--
Peter Headland
Architect
Actuate Corporation
I believe that the following statement was originally suggested by Tom Lane; I
got it from Pavel Stehule's PostgreSQL Tips page.
My question is, does this code contain a race hazard, because the list from the
SELECT might get changed by another session before the DELETE uses it?
delete from de
"Peter Headland" writes:
> My question is, does this code contain a race hazard, because the list from
> the SELECT might get changed by another session before the DELETE uses it?
> delete from del where ctid = any(array(select ctid from del limit 10))
Well, the CTID of a row you can see can'
Peter Headland wrote:
> If I do the following in a pl/pgsql function, will an update lock be
> held until the end of the transaction?
>
> PERFORM c FROM t FOR UPDATE;
Yes. (PERFORM is translated to SELECT by the plpgsql engine, so to the
SQL executor this is the same as SELECT FOR UPDATE).
--
> Well, the CTID of a row you can see can't be changed by another
> transaction while your transaction is still live. However, if
> someone else does modify/delete one of those rows concurrently,
> it will fail the outer WHERE check and thus silently not be
> deleted. Net effect is that you might
Hello all,
I wonder if I could have some help interpreting the output of
pg_stat_bgwriter. Here's my output:
checkpoints_timed | checkpoints_req | buffers_checkpoint | buffers_clean |
maxwritten_clean | buffers_backend | buffers_alloc
---+-++--
Hello,
I'm using version 8.4 on Windows 7 RC (build 7100). When using SSPI I
could never get it to work on loopback with IPv6 but it worked on IPv4
just fine. However, after I installed the latest Windows updates I
cannot get SSPI to work on either loopback address. The error I get is
the
I'm starting to use DBLink / DBI-Link and one of the "bad" things is that
the password is out in the clear.
What can I do to prevent it from being such? How do I protect it from
'innocent' users?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your sub
16 matches
Mail list logo