functions in postgreSql

Server Signaling Functions :-
Use of these functions is usually restricted to superusers
pg_cancel_backend():- cancels the running query
pg_terminate_backend():- terminates the entire process and thus the database connection.Terminate a                                                   backend A connection which is idle or idle in transaction does not have a current                                          query to cancel, but it has a backend process which can be terminated.
pg_reload_conf():-  Cause server processes to reload their configuration files
pg_rotate_logfile():- Rotate server’s log file

Backup Control Functions:-
These functions cannot be executed during recovery (except pg_is_in_backup, pg_backup_start_time and pg_xlog_location_diff).
pg_create_restore_point(name text):- Create a named point for performing restore (restricted to superusers)
pg_current_xlog_insert_location():- Get current transaction log insert location
pg_current_xlog_location():- Get current transaction log write location
pg_start_backup(label text [, fast boolean ]):- Prepare for performing on-line backup (restricted to superusers or replication roles)
pg_stop_backup():- Finish performing on-line backup (restricted to superusers or replication roles)
pg_is_in_backup():- True if an on-line exclusive backup is still in progress.
pg_backup_start_time():- Get start time of an on-line exclusive backup in progress.
pg_switch_xlog():- Force switch to a new transaction log file (restricted to superusers)
pg_xlogfile_name(location text):- Convert transaction log location string to file name
pg_xlogfile_name_offset(location text):- Convert transaction log location string to file name and decimal byte offset within file
pg_xlog_location_diff(location text, location text):- Calculate the difference between two transaction log locations


Recovery Control Functions:-
The functions shows provide information about the current status of the standby. These functions may be executed both during recovery and in normal running.
pg_is_xlog_replay_paused():- True if recovery is paused.
pg_xlog_replay_pause():- Pauses recovery immediately.
pg_xlog_replay_resume():- Restarts recovery if it was paused.

Database Object Size Functions:-
The functions shows to calculate the disk space usage of database objects.
pg_column_size(any):- Number of bytes used to store a particular value (possibly compressed)
pg_database_size(oid):- Disk space used by the database with the specified OID
pg_database_size(name):- Disk space used by the database with the specified name
pg_indexes_size(regclass):- Total disk space used by indexes attached to the specified table
pg_relation_size(relation regclass, fork text):- Disk space used by the specified fork (‘main’, ‘fsm’, ‘vm’, or ‘init’) of the specified table or index
pg_relation_size(relation regclass):- Shorthand for pg_relation_size(…, ‘main’)
pg_size_pretty(bigint):- Converts a size in bytes expressed as a 64-bit integer into a human-readable format with size units
pg_size_pretty(numeric):- Converts a size in bytes expressed as a numeric value into a human-readable format with size units
pg_table_size(regclass):- Disk space used by the specified table, excluding indexes (but including TOAST, free space map, and visibility map)
pg_tablespace_size(oid):- Disk space used by the tablespace with the specified OID
pg_tablespace_size(name):- Disk space used by the tablespace with the specified name
pg_total_relation_size(regclass):- Total disk space used by the specified table, including all indexes and TOAST data

Database Object Location Functions
pg_relation_filenode(relation regclass):- Filenode number of the specified relation
pg_relation_filepath(relation regclass):- File path name of the specified relation

difference between pg_cancel_backend() and pg_terminate_backend() in postgreSql

pg_cancel_backend():- 
                             Cancels the running query ,Cancel a backend’s current query

pg_terminate_backend():-
                             Terminates the entire process and thus the database connection,terminate a backend A connection which is idle or idle in transaction does not have a current query to cancel, but it has a backend process which can be terminated.

Cancel/Termination Examples

                   One of the small little treats provided in PostgreSQL 8.4 is the new pg_terminate_backend function. In the past when we wanted to kill runaway postgresql queries issued by a database or user or hmm us, we would call the pg_cancel_backend function. The problem with that is it would simply cancel the query in the backend process, but often times the offending application would simply launch the same query again.
            In PostgreSQL 8.4 a new function was introduced called pg_terminate_backend. This doesn’t completely replace pg_cancel_backend, but basically does what you do when you go into say a Windows Task manager and kill the offending postgres process or on Linux, you call a kill command on a postgres process. Its nicer in the sense that you can do it all within PostgreSQL and you can use the pg_stat_activity query to help you out a bit. Also you don’t run the risk as easily of killing the root postgres process and killing the postgres service all together.

Below are the ways we commonly use these functions. One of the features I really love about PostgreSQL which I miss when working with SQL Server, is the ability to call a function that does something from within a query. This feature makes SQL so much more powerful.

Cancel/Termination Examples

    — Cancel all queries in an annoying database
SELECT pg_cancel_backend(procpid)
FROM pg_stat_activity
WHERE datname = ‘baddatabase’;

— Cancel all queries by an annoying user
SELECT pg_cancel_backend(procpid)
FROM pg_stat_activity
WHERE usename = ‘baduser’;

Baseball bat to the head
Terminating backends is also useful for freeing up memory from idle postgres processes that for whatever reason were not released or if you need to rename a database and need to kill all live connections to a database to do so.

— terminate process by annoying database
SELECT pg_terminate_backend(procpid)
FROM pg_stat_activity
WHERE datname = ‘baddatabase’;

— terminate process by an annoying user
SELECT pg_terminate_backend(procpid)
FROM pg_stat_activity
WHERE usename = ‘baduser’;

One thing we have noticed with the baseball approach to database management is that it doesn’t always play well with pooled connection like things. For example in one PHP app we had that uses pooled connections, the connections became stale. Or at least we think this is the culprit. So you sometimes have to restart the app, or it sometimes gives annoying messages to the user until the dead connections are released. With that said, we still try the slap on the wrist before reaching for the baseball bat. Its always nice to have an easy to swing baseball bat handy though.

Cancel query as non-superuser in postgreSQL

                     A non-superuser on a PostgreSQL 9.1 database, and they have just created a bad trigger function that won’t stop. They can see the process, e.g.:

thedb=> SELECT * FROM pg_stat_activity WHERE procpid = 45678;
-[ RECORD 1 ]—-+——————————————————————-
datid            | 596281
datname          | thedb
procpid          | 45678
usesysid         | 596282
usename          | myuser
application_name | QGIS
client_addr      | 1.2.3.4
client_hostname  |
client_port      | 12345
backend_start    | 2015-04-16 13:45:27.482691+12
xact_start       | 2015-04-16 14:17:34.633156+12
query_start      | 2015-04-16 14:17:34.633665+12
waiting          | f
current_query    | UPDATE …

But they  can’t stop it:
thedb=> SELECT pg_terminate_backend(45678);
ERROR:  must be superuser to signal other server processes

solution
You must either be the superuser or logged in as the same user who owns the session you wish to cancel.

So connect as user myuser and you’ll be able to pg_cancel_backend, or, if that doesn’t respond, pg_terminate_backend.

Create VLAN interface in linux

VLAN (virtual local area network) is very useful concept as you can easily separate device management from users by using appropriate network devices and configuration.

Preparations
Install user mode programs to enable VLANs on your ethernet devices:
$ sudo apt-get install vlan
Load 8021q module (IEEE 802.1Q):

$ sudo modprobe 8021q
To load 8021q module at the boot time add it to the /etc/modules file:

$ sudo echo 8021q >> /etc/modules
$ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.

# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with “#” are ignored.
# Parameters can be specified after the module name.
oop
8021q



Solution For Temporary 
Create VLAN 700 on the eth0 device:
$ sudo vconfig add eth0 700

Add VLAN with VID == 700 to IF -:eth0:-
Set IP address (10.100.10.77 netmask 255.255.255.0 in this example):
$ sudo ifconfig eth0.700 10.100.10.77/24

Created interface is named as eth0.700:
$ sudo ifconfig -a
eth0      Link encap:Ethernet  HWaddr 84:8f:69:b0:fa:0a
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:49

eth0.700  Link encap:Ethernet  HWaddr 84:8f:69:b0:fa:0a
          inet addr:10.100.10.77  Bcast:10.100.10.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:884 (884.0 B)  TX bytes:3158 (3.0 KiB)

Now you can access other hosts available in VLAN 700:
$ ping -c 1 10.100.10.1
PING 10.100.10.1 (10.100.10.1) 56(84) bytes of data.
64 bytes from 10.100.10.1: icmp_req=1 ttl=64 time=1.28 ms

— 10.100.10.1 ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.282/1.282/1.282/0.000 ms
To remove VLAN 700 from the eth0 interface execute command:

$ sudo vconfig rem eth0.700

Removed VLAN -:eth0.700:-
Permanent solution
To create VLAN at the boot time you need to get familiar with /etc/network/interfaces configuration file (man interfaces, man vlan-interfaces).

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

To create VLAN 700 on the eth0 interface at the boot time just add similar configuration:
# add vlan 700 on eth0 – static IP address
auto eth0.700
iface eth0.700 inet static
 address 10.100.10.77
 netmask 255.255.255.0

Terminate PostgreSQL sessions

This blog post is based on a PostgreSQL 9.1 version.

problems:-
Sometimes you need to terminate connections initiated by badly behaving client application, or just make sure nobody is querying database during a major update.
The solution is to use pg_stat_activity view to identify and filter active database sessions and then use pg_terminate_backend function to terminate them.
To prevent access during an update process or any other important activity you can simply revoke connect permission for selected database users or alter pg_database system table.


Who is permitted terminate connections:-
Every database role with superuser rights is permitted to terminate database connections.


How to display database sessions
pg_stat_activity system view provides detailed information about server processes.
SELECT datname as database,
       procpid as pid,
       usename as username,
       application_name as application,
       client_addr as client_address,
       current_query
  FROM pg_stat_activity

Sample output that will be used in the following examples.
database | pid  | username | application | client_address |                                                                           current_query
———-+——+———-+————-+—————-+——————————————————————————————————————————————————————-
 blog     | 8603 | blog     | blog_app    | 192.168.3.11   | select * from posts order by pub_date
 postgres | 8979 | postgres | psql        |                | select datname as database,procpid as pid,usename as username,application_name as application, client_addr as client_address, current_query from pg_stat_activity
 wiki     | 8706 | wiki     | wiki_app    | 192.168.3.8    |
(3 rows)



How to terminate all connections to the specified database
Use the following query to terminate all connections to the specified database.
SELECT pg_terminate_backend(procpid)
  FROM pg_stat_activity
 WHERE datname = ‘wiki’

improvements in PostgreSQL 9.4 and postgres activity

                           With the beta release of PostgreSQL 9.4, DBA’s have been given some cool features like pg_prewarm, JSONB, ALTER SYSTEM, Replication Slots and many more. Out of numerous architectural level features presented in this version, likewise there are other few minor enhancements those I have attempted to cover in this blog.
pg_stat_activity view included two new columns (backend_xid/backend_min) to track the transaction id information. pg_stat_activity.backend_xid column covers the id of top-level transaction currently begin executed and pg_stat_activity.backend_xmin column covers the information of minimal running XID. Check out below two query outputs executed in two different situations, first one show the hierarchal information of the transaction id in backend_xmin column of sessions trying to acquire lock(table/Row) on same row, whereas other one just an independent transactions happening without disturbing the same row. This kind of a information help user to know more about the transactions when waiting queries found in the database.
postgres=# select pid,backend_xid,backend_xmin,query from pg_stat_activity where pidpg_backend_pid();
  pid  | backend_xid | backend_xmin |           query
——-+————-+————–+—————————
 22351 |        1905 |         1904 | insert into a values (1);
   785 |        1904 |              | insert into a values (1);
 12796 |             |         1904 | truncate  a;
 12905 |             |         1904 | delete from a ;

postgres=# select pid,backend_xid,backend_xmin,query from pg_stat_activity where pidpg_backend_pid();
  pid  | backend_xid | backend_xmin |            query
——-+————-+————–+—————————–
 22351 |             |              | insert into foo values (1);
   785 |        1900 |              | insert into foo values (1);
(2 rows)

New clauses in CREATE TABLESPACE/ALTER TABLESPACE as “with” and “move” options respectively. Similarly, meta command \db+ to give detailed information about the parameters set for a particular TABLESPACE using “with” option.

postgres=# \h create tablespace
Command:     CREATE TABLESPACE
Description: define a new tablespace
Syntax:
CREATE TABLESPACE tablespace_name
    [ OWNER user_name ]
    LOCATION ‘directory’
    [ WITH ( tablespace_option = value [, … ] ) ]


Example:
postgres=# create tablespace t1 location ‘/usr/local/pgpatch/pg/ts’ with (seq_page_cost=1,random_page_cost=3); 
CREATE TABLESPACE

postgres=# \db+
                                                    List of tablespaces

    Name    |  Owner   |         Location         | Access privileges |               Options                | Description
————+———-+————————–+——————-+————————————–+————-
 pg_default | postgres |                          |                   |                                      |
 pg_global  | postgres |                          |                   |                                      |
 t1         | postgres | /usr/local/pgpatch/pg/ts |                   | {seq_page_cost=1,random_page_cost=3} |
(3 rows)

                               New system functions to give information on type regclass,regproc,regprocedure,regoper,regoperator and regtype. For all the types, new functions are to_regclass(), to_regproc(), to_regprocedure(), to_regoper(), to_regoperator() and to_regtype().

Example:
select to_regclass(‘pg_catalog.pg_class’),to_regtype(‘pg_catalog.int4’),to_regprocedure(‘pg_catalog.abs(numeric)’),to_regproc(‘pg_catalog.now’),to_regoper(‘pg_catalog.||/’);
 to_regclass | to_regtype | to_regprocedure | to_regproc | to_regoper
————-+————+—————–+————+————
 pg_class    | integer    | abs(numeric)    | now        | ||/
(1 row)

New “-g” option in command line utility CREATEUSER to specify role membership.
-bash-4.1$ createuser -g rw -p 10407 r1 
-bash-4.1$ psql -p 10407

psql (9.4beta1) Type “help” for help.
postgres=# \dg
                             List of roles
 Role name |                   Attributes                   | Member of
———–+————————————————+———–
 postgres  | Superuser, Create role, Create DB, Replication | {}
 r1        |                                                | {rw}

pg_stat_all_tables view, has a new column “n_mod_since_analyze”, which highlights on the number of rows has been modified since the table was last analyzed. Below outputs brief about the “n_mod_since_analyze” column changes, first time manual analyze executed and after sometime autovacuum invoked on the table, in this duration we can figure out how many rows effected with different catalog update calls.

postgres=# analyze a;
ANALYZE

postgres=# select relname,last_autoanalyze,last_analyze,n_mod_since_analyze from pg_stat_all_tables where relname=’a’;
 relname | last_autoanalyze |         last_analyze          | n_mod_since_analyze
———+——————+——————————-+———————
 a       |                  | 2014-05-03 02:09:51.002006-07 |                   0
(1 row)


postgres=# insert into a values(generate_series(1,100));
INSERT 0 100

postgres=# select relname,last_autoanalyze,last_analyze,n_mod_since_analyze from pg_stat_all_tables where relname=’a’;
 relname | last_autoanalyze |         last_analyze          | n_mod_since_analyze
———+——————+——————————-+———————
 a       |                  | 2014-05-03 02:09:51.002006-07 |                 100
(1 row)

postgres=# truncate a;
TRUNCATE TABLE

postgres=# select relname,last_autoanalyze,last_analyze,n_mod_since_analyze from pg_stat_all_tables where relname=’a’;
 relname | last_autoanalyze |         last_analyze          | n_mod_since_analyze
———+——————+——————————-+———————
 a       |                  | 2014-05-03 02:09:51.002006-07 |                 100
(1 row)

postgres=# select relname,last_autoanalyze,last_analyze,n_mod_since_analyze from pg_stat_all_tables where relname=’a’;
 relname |       last_autoanalyze        |         last_analyze          | n_mod_since_analyze
———+——————————-+——————————-+———————
 a       | 2014-05-03 02:14:21.806912-07 | 2014-05-03 02:09:51.002006-07 |                   0
(1 row)

pg_stat_archiver, its a new view introduced to track all WALs generated and it also captures failed WAL’s count. If you are from Oracle then this one is like “ARCHIVE LOG LIST”.
postgres=# select * from pg_stat_archiver ;
-[ RECORD 1 ]——+——————————
 archived_count     | 167
 last_archived_wal  | 00000001000000000000009B
 last_archived_time | 2014-05-02 20:42:36.230998-07
 failed_count       | 75
 last_failed_wal    | 000000010000000000000012
 last_failed_time   | 2014-05-01 12:09:57.087644-07
 stats_reset        | 2014-04-30 19:02:01.288521-07

pg_stat_statements, extension module has a new column queryid to track the internal hash code, computed from the statement’s parse tree.
postgres=# select queryid,query from pg_stat_statements;
  queryid   |               query
————+————————————
 1144716789 | select * from pg_stat_statements ;
(1 row)

current PostgreSQL queries View

An important tool for debugging PostgreSQL performance issues is the ability to view all the currently executing queries. With newer versions of PostgreSQL we get some more details. Here’s an example I’ve used on PostgreSQL 8.2:
SELECT datname,usename,procpid,client_addr,waiting,query_start,current_query FROM pg_stat_activity ;
Configuration

Storing of query strings is usually disabled in PostgreSQL by default.  To enable it, use this line in your postgresql.conf
stats_command_string = true

This setting can be changed on a running database without restarting or effecting open connections by telling the PostgreSQL parent process, postmaster, to reload its config.  Send it a SIGHUP or use the safer pg_ctl command with the reload option.  Example:
pg_ctl reload

Queries
When stats_command_string is enabled the pg_stat_activity table holds all currently active query strings.  The simplest query will show all current query strings along with which database they refer to and the process ID (PID) of the process serving that query.

SELECT datname,procpid,current_query FROM pg_stat_activity

Example:
database1=# SELECT datname,procpid,current_query FROM pg_stat_activity ORDER BY procpid ;

    datname    | procpid | current_query 
—————+———+—————
 mydatabaseabc |    2587 |
 anotherdb     |   15726 | SELECT * FROM users WHERE id=123 ;  
 mydatabaseabc |   15851 |
(3 rows)

Each row of pg_stat_activity represents one PostgreSQL process (PostgreSQL uses one server process per connection).Any processes that are not currently performing any queries will show as the current_query.
Note that queries from all databases within the server will be shown.  If the user querying pg_stat_activity does not have privileges to access a database then it will not show the current_query.
The query_start column can also be used to show when the query started executing.
Another of my favourite queries is to show a top-like view of current queries, grouped by how many of the same query are running at that instant and the usernames belonging to each connection.

SELECT count(*) as cnt, usename, current_query FROM pg_stat_activity GROUP BY usename,current_query ORDER BY cnt DESC;

Example:
database1=# SELECT count(*) as cnt, usename, current_query FROM pg_stat_activity GROUP BY usename,current_query ORDER BY cnt DESC;
 cnt |    usename    | current_query 
—–+—————+—————
   7 | freddykrueger |
   3 | freddykrueger | SELECT name FROM users WHERE id=50;
   1 | postgres      |
(3 rows)

Postgres deadlock debugg

There is a better way to view Postgres locks and blocking chains.
select
pg_stat_activity.datname,
pg_class.relname,
pg_locks.transactionid, 
pg_locks.mode,
pg_locks.granted,
pg_stat_activity.usename,
substr(pg_stat_activity.current_query,1,40) as current_query, 
pg_stat_activity.query_start, 
age(now(),pg_stat_activity.query_start) as “age”, 
pg_stat_activity.procpid 
from pg_stat_activity,pg_locks 
left outer join pg_class on (pg_locks.relation = pg_class.oid) 
where pg_locks.pid=pg_stat_activity.procpid order by query_start;