Redshift stored procedure transaction keeps state after commit that leads to ERROR 1023 Serializable isolation violation

This stored procedure (excerpt) reliably generates ERROR: 1023 DETAIL: Serializable isolation violation on table tbl_process!

If only a single invocation occurs (Fast or Slow) the process always completes successfully inserting two rows (including updating the first)! However if two overlapping invocations occur with the first being a "Slow" process followed (before completing) by a "Fast" process - then the "Fast" process always completes successfully whilst the "Slow" process generates an exception (always mentioning 3 transactions forming the cycle).

Based on Redshift documentation I understood the BEGIN LOCK COMMIT END construct should prevent this! It appears the scalar var_process_start used in the UPDATE statement has retained some state from Transaction #1 that causes the Transaction #2 to fail - but only if any other processes transactions have been committed to the table. Note that the LOCK or INSERT in Transaction #2 does not fail - only the UPDATE.

How can this exception be avoided?

	DECLARE	var_process_start		INTEGER  ;
	BEGIN
		BEGIN	-- TRANSACTION #1
			LOCK TABLE tbl_process ;
			INSERT
			INTO	tbl_process
			(	process_user
			,	process_pid
			,	start_tstp
			)
			VALUES
			(	CURRENT_USER
			,	PG_BACKEND_PID()
			,	GETDATE()
			) ;
			-- Collect the tbl_process identity value for #1
			SELECT
			INTO	var_process_start
				MAX(process_event)
			FROM	tbl_process ;
			COMMIT ;
		END ;	-- TRANSACTION #1
		--
		/* Slow or Fast running processing here */
		/* Sets var_start_tstp and var_finish_tstp values */
		--
		BEGIN	-- TRANSACTION #2
			-- Avoid serializable isolation violations and deadlocks
			LOCK TABLE tbl_process ;
			-- Commit new process entry #2
			INSERT
			INTO	tbl_process
			(	process_user
			,	process_pid
			,	start_tstp
			,	finish_tstp
			)
			VALUES
			(	CURRENT_USER
			,	PG_BACKEND_PID()
			,	var_start_tstp
			,	var_finish_tstp
			) ;
			IF var_process_start > 0 THEN
				-- Record the end of this processing run on #1
				UPDATE	tbl_process
				SET	finish_tstp	= GETDATE()
				WHERE	process_event	= var_process_start ;
				-- ^^^ this statement generates serialization isolation violation!
			END IF ;
			-- Finished - commit all work to database
			COMMIT ;
		END ;	-- TRANSACTION #2