Before reading this article, I would suggest please read about MVCC because of PostgreSQL based on MVCC architecture.

What is Multi Version Concurrency Control (MVCC)

The day before yesterday, one of our developers asked a question like I want updated data on a table while a function is running in PostgreSQL.

If you are from Microsoft SQL Server background, of course, you will need this because you can get an updated data on a table while a function is running. Why? Because SQL Server is auto-committed by default.

When you create a function in PostgreSQL, you must put all your code between BEGIN and END. In PostgreSQL, it treats as transaction block, and you can get only updated table data once function execution completed or you can get the previous state of your table if execution of a function failed.

Why? because of MVCC architecture you cannot get partially updated table otherwise other users can update those value which breaks the rule of MVCC.

While function is running, a user can still access the old records of a table, and once function execution got completed, a user can access the newly updated records of a table.

CREATE FUNCTION fn_test()
  RETURNS as
$$
declare
	-- declare variables...
begin
	-- do operations...
end
$$ language plpgsql;

Then, they asked one more question like If the function code is default between BEGIN and END transaction block when we should define explicitly BEGIN TRANSACTION and COMMIT TRANSACTION in a PostgreSQL function?

My answer was, you can also set BEGIN TRANSACTION and COMMIT TRANSACTION explicitly when you want ROLLBACK or SAVEPOINT action.
But if you do not define this, by default everything is in transaction block and you will get all the output once your function completes its execution.

REATE FUNCTION fn_test()
  RETURNS as
$$
declare
	-- declare variables...
begin	
	-- do operations...
	begin transaction
		-- do transactions...
	commit transaction
end
$$ language plpgsql;

In this post, I am sharing the use of SQL Server IMPLICIT TRANSACTIONS.

When you set the IMPLICIT TRANSACTION, database engine automatically considers a new transaction after every COMMIT/ROLLBACK.
We are writing DML statements between BEGIN and COMMIT/ROLLBACK. If our logic is divided into the different batches, managing BEGIN…COMMIT is difficult.

Just, you can set IMPLICIT TRANSACTION, and do COMMIT/ROLLBACK for each of your batches.

Note: Once you set IMPLICIT TRANSACTION, all your query tables will lock because IMPLICIT TRANSACTION applies the standard lock on the table. I can see only one feature is, not require to write BEGIN TRANSACTION that’s it.

Check the below demonstration:

Set IMPLICIT TRANSACTION:

SET IMPLICIT_TRANSACTIONS ON
GO

Create a sample table:

CREATE TABLE tbl_TestTransactions (ID INT, Name VARCHAR(10))
GO

Do COMMIT:

COMMIT TRANSACTION
GO

Now insert a sample record and do ROLLBACK:

INSERT INTO tbl_TestTransactions VALUES (1,'Anvesh')
ROLLBACK TRANSACTION 
GO

Test one more COMMIT:

INSERT INTO tbl_TestTransactions VALUES (2,'Roy')
COMMIT TRANSACTION
GO

Try ROLLBACK:
You will get an error because above there is no any open transaction.

ROLLBACK TRANSACTION
GO

Msg 3903, Level 16, State 1, Line 18
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.

Try one more ROLLBACK:

INSERT INTO tbl_TestTransactions VALUES (3,'Jenny')
GO
ROLLBACK TRANSACTION
GO

Check the final result:

SELECT *FROM tbl_TestTransactions

ID          Name
----------- ----------
2           Roy

PostgreSQL 10 introduced many useful features that we can use in day to day work.

Now, we can trace the status of the running transaction in PostgreSQL 10. If we have transaction IDs of our sessions and suddenly database crashed or shutdown, we can check the status of those transactions.

We can check the status like Committed, In Progress, Rollback or Aborted. This facility will help a lot for taking a necessary decision on crashed transactions.

PostgreSQL 10 introduced two functions:

txid_current() – will return the current transaction id of a session
txid_status() – will return the status of transaction

Please check the below sample:

Create a sample table:

CREATE TABLE tbl_stud
(Rno INT, Name Character Varying);

Open a transaction, and insert a record:

BEGIN TRANSACTION;

INSERT INTO tbl_stud
VALUES (1,'Anvesh');

Check the current transaction id:

SELECT *FROM txid_current();

txid_current
------------
    587

Check the status of above transaction id:
It is showing “in progress” because I didn’t commit the transaction yet.

SELECT txid_status(BIGINT '587');

txid_status
-----------
in progress

Now, execute the COMMIT:

COMMIT TRANSACTION;

Now, check the status again:

SELECT txid_status(BIGINT '587');

txid_status
-----------
committed

You can also return transaction id, with the insert statement: (Using RETURNING)

SELECT txid_status(BIGINT '587');

txid_status
-----------
committed

In this post, I am sharing a demonstration in which you can get to know that committed inner transactions are not releasing any log disk space in SQL Server.

One of our developers was telling me like when we commit the transaction it will release the occupied log space, but it is not entirely correct.
If you are dealing with nested transactions, it is true only for outer committed transactions.

Please check the below demonstration of this.

Create a sample database:

CREATE DATABASE Test_Tran;
GO
USE Test_Tran
GO

Check the log size:

CHECKPOINT
GO
DBCC SQLPERF ('LOGSPACE')
GO
-- the result
-- 4.557673

Create a sample table:

CREATE TABLE tbl_TestTrans(ID INT)
GO

Open outer and inner transaction and insert few sample records:

BEGIN TRANSACTION OuterTrans
GO
	BEGIN TRANSACTION InnerTrans
	GO
		INSERT INTO tbl_TestTrans VALUES(88)
		GO 1000
	COMMIT TRANSACTION InnerTrans
	GO

Check the log size:
The inner transaction is committed, but log size is increased, and it didn’t release the logs.

CHECKPOINT;
GO
DBCC SQLPERF ('LOGSPACE');
GO

-- the result:
-- 8.767107

Now, commit outer transaction:

COMMIT TRANSACTION OuterTrans
GO

Check the log size:
Once you commit your outer transaction, it releases the log size.

CHECKPOINT;
GO
DBCC SQLPERF ('LOGSPACE');
GO

-- the result:
-- 5.08

In PostgreSQL, We can apply different lock mode on the table.
This is also one of the important topics because PostgreSQL has a default MVCC architecture.

What is Multi Version Concurrency Control (MVCC)

Because of MVCC architecture, all other sessions can access table new data or an old version of the data.
Sometimes Isolation Level like Repeatable Read, Serializable might not help us.

When we require explicitly lock on the table, we can use PostgreSQL different types of lock mode like:
ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE.
For highly secure tables, we require lock mode like ACCESS EXCLUSIVE MODE.

Example of ACCESS EXCLUSIVE MODE:

Create a sample table:

CREATE TABLE tbl_Employee
(
	EmpID INTEGER
	,EmpName VARCHAR(50)
);

INSERT INTO tbl_Employee
VALUES 
(1,'Anvesh'),(2,'Neevan')
,(3,'Roy'),(4,'Martin');

Apply ACCESS EXCLUSIVE MODE on tbl_Employee:

BEGIN TRANSACTION;
LOCK TABLE tbl_Employee IN ACCESS EXCLUSIVE MODE;

Open another session and,try to SELECT tbl_Employee data:
You can not access this table because ACCESS EXCLUSIVE MODE on tbl_Employee.

Now execute COMMIT to release the ACCESS EXCLUSIVE MODE and now you can access tbl_Employee in another session.

COMMIT TRANSACTION;

Note: You can apply LOCK MODE on a table only in transaction block like between BEGIN…COMMIT.

The DeadLock in a database system is a very common thing and all Database Administrator responsible to detect and manage a DeadLock situation.

In this post, I am sharing one small demonstration t to generate a DeadLock situation in a PostgreSQL.

Database Theory: What is Timeout, Lock, Block, and Deadlock in a Database System?

Most of the time, We are facing DeadLock problem in our Production Database Server.
But What happen, when Database Administrator wants to generate DeadLock situation and wants to create a script for detecting a DeadLock.

First create two sample tables:

CREATE TABLE ABC (ID INT PRIMARY KEY);
CREATE TABLE XYZ (ID INT PRIMARY KEY);

Open Session – 1 and execute below code:

BEGIN;
INSERT INTO ABC VALUES (1);

Open Session – 2 and execute below code:

BEGIN;
INSERT INTO XYZ VALUES (1);
INSERT INTO ABC VALUES (1);

Again open Session – 1 and execute below Insert Statement:

INSERT INTO XYZ VALUES (1);

You will get a below deadlock message:

ERROR:  deadlock detected
DETAIL:  Process 5944 waits for ShareLock on transaction 892; blocked by process 4884.
Process 4884 waits for ShareLock on transaction 891; blocked by process 5944.
HINT:  See server log for query details.
CONTEXT:  while inserting index tuple (0,2) in relation "xyz_pkey"

Please visit other related articles:

PostgreSQL 9.5: Using FOR UPDATE SKIP LOCKED Option SELECT only Committed Records

PostgreSQL: Script to find information about the Locks held by Open Transactions (pg_locks)

Script to find sessions that are blocking other sessions in PostgreSQL

Today morning, one of our Associate DB Developer working with Transactions and PostgreSQL is also new for him.
The COMMIT, ROLLBACK and SAVEPOINT are very common for all RDBMS.

In this post, I am sharing one basic demonstration on COMMIT, ROLLBACK and SAVEPOINT of PostgreSQL which helps to Associate level DB Developer.

Create a table with Sample Data:

CREATE TABLE tbl_Employees
(
	EmpID INT
	,EmpName CHARACTER VARYING
);

INSERT INTO tbl_Employees
VALUES	
(1,'Anvesh'),(2,'Loother'),(3,'Roy'),(4,'Martin')
,(5,'Jenny'),(6,'Monika'),(7,'Rajesh'),(8,'Eric');

Commit: We can use COMMIT to end our all transactions and make It as permanent changes.

Commit the Transaction:

BEGIN;
	UPDATE tbl_Employees
	SET EmpName = 'Nivu'
	WHERE EmpID = 3;
COMMIT;

Rollback: Using ROLLBACK, we can jump to the previous last committed state of the Transaction.
Rollback the Transaction:

BEGIN;
	UPDATE tbl_Employees
	SET EmpName = 'Vinay'
	WHERE EmpID = 2;
ROLLBACK;

Savepoint: Using SAVEPOINT, we can jump to the particular point which defines by the SAVEPOINT.

Rollback changes to the Save Point:

BEGIN;
	UPDATE tbl_Employees
	SET EmpName = 'Grace'
	WHERE EmpID = 4;
	
SAVEPOINT EmpSave;

	UPDATE tbl_Employees
	SET EmpName = 'Kunal'
	WHERE EmpID = 5;
	
ROLLBACK TO EmpSave;

The Result:

SELECT * FROM tbl_Employees ORDER BY 1 ;

EmpID    EmpName
--------------------
  1      Anvesh
  2      Loother
  3      Nivu
  4      Grace
  5      Jenny
  6      Monika
  7      Rajesh
  8      Eric