Fix possible crash in tablesync worker.

Commit c3afe8cf5a added a new password_required option but forgot that you
need database access to check whether an arbitrary role ID is a superuser.

Commit e7e7da2f8d fixed a similar bug in apply worker, and this patch
fixes a similar bug in tablesync worker.

Author: Hou Zhijie
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/OS0PR01MB571607F5A9D723755268D36294759@OS0PR01MB5716.jpnprd01.prod.outlook.com
This commit is contained in:
Amit Kapila 2023-06-15 08:37:48 +05:30
parent f9f31aa91f
commit b5c517379a
1 changed files with 6 additions and 4 deletions

View File

@ -1262,6 +1262,12 @@ LogicalRepSyncTableStart(XLogRecPtr *origin_startpos)
relstate = GetSubscriptionRelState(MyLogicalRepWorker->subid,
MyLogicalRepWorker->relid,
&relstate_lsn);
/* Is the use of a password mandatory? */
must_use_password = MySubscription->passwordrequired &&
!superuser_arg(MySubscription->owner);
/* Note that the superuser_arg call can access the DB */
CommitTransactionCommand();
SpinLockAcquire(&MyLogicalRepWorker->relmutex);
@ -1288,10 +1294,6 @@ LogicalRepSyncTableStart(XLogRecPtr *origin_startpos)
slotname,
NAMEDATALEN);
/* Is the use of a password mandatory? */
must_use_password = MySubscription->passwordrequired &&
!superuser_arg(MySubscription->owner);
/*
* Here we use the slot name instead of the subscription name as the
* application_name, so that it is different from the leader apply worker,