Additional explanation on AccessShareLock in gpbackup 1.25 and above.

Products

• VMware Tanzu Greenplum

Issue/Introduction

  This article is to provide some additional explanation on the new feature introduced in gpbackup 1.25 as mentioned in the release note:

gpbackup can now export synchronized distributed snapshots, ensuring data consistency across parallel worker processes used per the --jobs option. As a result of this enhancement, the worker processes no longer need to hold ACCESS SHARE locks for the entire duration of the backup operation. 
NOTE: This gpbackup feature requires Greenplum Database version 6.21 or higher.

 

 

Environment

Product Version: 6.21

Resolution

It does not mean there will be no Access Share Lock held by the backup processes. The difference is that in gpbackup 1.25 and above, the Access Share Lock is held by the gpbackup primary process throughout the whole backup duration and the worker processes take a lock on a table only for the duration of the COPY command on that table, as a means of deadlock protection in the presence of destructive DDL commands.

Prior to gpbackup 1.25 and Greenplum 6.21.0, without a distributed transaction to rely on, each worker process invoked had to take its own locks to keep data in sync.

The main purpose for this new feature is to reduce overhead with less locks during the backup.