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 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.

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