PG_TRANSACTION_STATUS(3)PG_TRANSACTION_STATUS(3)pg_transaction_status - Returns the current in-transaction status of the server.SYNOPSIS
int pg_transaction_status (resource $connection)
DESCRIPTION
Returns the current in-transaction status of the server.
Caution
pg_transaction_status(3) will give incorrect results when using a PostgreSQL 7.3 server that has the parameter autocommit set to
off. The server-side autocommit feature has been deprecated and does not exist in later server versions.
PARAMETERS
o $connection
- PostgreSQL database connection resource.
RETURN VALUES
The status can be PGSQL_TRANSACTION_IDLE (currently idle), PGSQL_TRANSACTION_ACTIVE (a command is in progress), PGSQL_TRANSACTION_INTRANS
(idle, in a valid transaction block), or PGSQL_TRANSACTION_INERROR (idle, in a failed transaction block). PGSQL_TRANSACTION_UNKNOWN is
reported if the connection is bad. PGSQL_TRANSACTION_ACTIVE is reported only when a query has been sent to the server and not yet com-
pleted.
EXAMPLES
Example #1
pg_transaction_status(3) example
<?php
$dbconn = pg_connect("dbname=publisher") or die("Could not connect");
$stat = pg_transaction_status($dbconn);
if ($stat === PGSQL_TRANSACTION_UNKNOWN) {
echo 'Connection is bad';
} else if ($stat === PGSQL_TRANSACTION_IDLE) {
echo 'Connection is currently idle';
} else {
echo 'Connection is in a transaction state';
}
?>
PHP Documentation Group PG_TRANSACTION_STATUS(3)
Check Out this Related Man Page
PG_LAST_ERROR(3)PG_LAST_ERROR(3)pg_last_error - Get the last error message string of a connectionSYNOPSIS
string pg_last_error ([resource $connection])
DESCRIPTION pg_last_error(3) returns the last error message for a given $connection.
Error messages may be overwritten by internal PostgreSQL (libpq) function calls. It may not return an appropriate error message if multi-
ple errors occur inside a PostgreSQL module function.
Use pg_result_error(3), pg_result_error_field(3), pg_result_status(3) and pg_connection_status(3) for better error handling.
Note
This function used to be called pg_errormessage(3).
PARAMETERS
o $connection
- PostgreSQL database connection resource. When $connection is not present, the default connection is used. The default connection
is the last connection made by pg_connect(3) or pg_pconnect(3).
RETURN VALUES
A string containing the last error message on the given $connection, or FALSE on error.
EXAMPLES
Example #1
pg_last_error(3) example
<?php
$dbconn = pg_connect("dbname=publisher") or die("Could not connect");
// Query that fails
$res = pg_query($dbconn, "select * from doesnotexist");
echo pg_last_error($dbconn);
?>
SEE ALSO pg_result_error(3), pg_result_error_field(3).
PHP Documentation Group PG_LAST_ERROR(3)
Hi,
would like to know the server status from the following 'top' out put. Because, the application is giving a bad performance. would like to know whether the load is within the acceptable limit.
Murali...
System: shpu28 Tue Feb 3 10:03:31... (4 Replies)
OS : Solaris sparc
In c program After socket created when I do Connect() it results "Connection refused", but the system is online and I am able to do telnet, ping everything, but it says connection refused.
What would need to correct ? (6 Replies)
Hi Experts,
I am here with very simple request:
#!bin/bash
a=`stat -c %y log1.csv`
echo $a
and this stat command returning value as
2013-08-11 05:42:10.000000000 -0400:
But I want to see in mm/dd/yyyy format?
any help is highly appreciated thank you
---------- Post... (9 Replies)
Hi Guys,
I have two databases where I copy archivelog files from server A to server B frequently...yesterday we did the VM upgrade now...I am struggling to copy/ship the files from server A to server B...
I manually tested the file transfer but the big files, e.g 46M, stall. I can copy small... (2 Replies)
Hello All,
Actually, We have a problem in our server (RHEL 7.1), 1st server is used for payment apps like switch card payment (passthru only), and 2nd server is used for Database transaction.
When high transaction there is different connection between Apps Server and DB server, Apps Server... (0 Replies)