Bug in replication: the limited logins on source database.

Scenario:
Replication server is stopped on a source database for a few hours (4-20 hours).
When we start a replication server again it may write to a database log:
(-----) Enabled limited logins.
instead of:
(-----) Enabled default logins.
It's V11.7.

I guess since V12.8 the messages are numbered:
Enabled <login-type> logins. (20263)
Description: Replication process may enable different type of login so that only certain users can connect to the database at that time. For example, no regular client are allowed during a replication server startup, or transition time.

Disabled logins. (20264)

Description: Replication process may disable login so that no users can connect to the database.

Note that the status of logins is set /before/ a replication server tries to communicate with the agents on target databases. Login types are selected for a source database, and the decision is made solely based on source database.

Documentation describes the limited logins only for the target databases:
Access a target database
Limited logins are allowed immediately after the agent completes its startup. Normal logins that allow the access listed in the table that follows are allowed after synchronization completes.

Limited logins on source databases are nonsense if sessions connected to the database before the replication server was started continue to function as before. And they do. They can logout from a database but new sessions can't login:
Database connections are not allowed at this time. (10829)
Description: You might need to start some plugin processes first.

It’s the message issued by clients on screen. No messages in database log.

Some secondary login brokers at random time (most likely when a remote client is trying to connect a database) may issue the different message:
Database connections are not allowed at this time. (10836)
Description: Either you don't a have license to access the database or the database doesn't accept connection during start up process, try later.


The login status was not changed to the default one even when the source and target databases are synchronized.

The rescue is to restart a replication server. One attempt could be not enough. Once the customer was forced to repeat the attempts up to 6 times. Database restart does not guarantee a solution either. Be patient!

We are going to increate logginglevel to 3 when another incident will happen.
 
Just when you think you've heard every crazy thing that can happen to replication, there's one more.

Thanks for the info George. Do you have any sense of the cause of the "limited logins" message/state? What is the update level of 11.7?
 
Progress OpenEdge Release 11.7 build 2182 SP15 on Linux
35 replication server startups per 2025.
7 times it started with limited logins.
I tried my best to find out the patterns but I see nothing.

DB Size: 7205 GB
Size of the AI files locked while RPLS was not running is the hundreds GBs.
 
Last edited:
I forgot to mention that "limited logins" allows to start promon. It would be interesting to know if it's possible to identify "limited logins" inside promon (as we can do for a proquiet point).
 
Valery Bashkatov adds:
Test environment
logging-level=3
Code:
[2026/03/05@11:56:17.036+0300] P-32070      T-139756064773952 I RPLS     : (-----) Session beginning
...
[2026/03/05@11:56:18.038+0300] P-32070      T-139756064773952 I RPLS     : (10500) The Fathom Replication Server successfully started as PID 32070.
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Gather AI area information...
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Allocating AI Block...
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Setup sync control, sync txnSequence 558699
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Initializing RLAIReadState...
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Attempting to acquire a shared schema lock
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Shared Schema lock granted
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Source Database activity will continue
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Eable default login before configuring RCB
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Enabled default logins.
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Eable default login after configuring RCB
[2026/03/05@11:56:18.039+0300] P-32070      T-139756064773952 I RPLS     : (-----) Enabled default logins.

Extended logging explains why a database log contains two messages Enabled <login-type> logins.

PS. "Eable" is not my typo. :-)
 
I wonder what happens if it can't acquire this lock, e.g. someone holds the exclusive schema lock to perform an online schema change
The client sessions running r-codes put the share schema locks. RPLS would gain a share schema lock as well. Database restart would close a session that holds the exclusive schema lock but it did not help to restore the default logins.

Nevertheless I did check the dates of schema changes in 2025 year. None of them were close to the incidents.

Code:
RPLS     : (-----) Allocating AI Block...
RPLS     : (-----) Setup sync control, sync txnSequence 558699
RPLS     : (-----) Initializing RLAIReadState...
There is a mystery in these messages.
Why it reports TRID rather than AI number and AI block number?
Replication server sends AI blocks to the target databases:
Code:
[2026/03/05@10:34:12.611+0300] P-29750      T-140606101006144 I RPLS     : (-----) Sending AI block 815...

[2026/03/04@15:14:50.644+0300] P-23547      T-140648157071168 I RPLS     : (-----) Last ACK for agent2: aiSeq:89, aiLoc: 5308416, aiArea:17, aiOffset:2854
[2026/03/04@15:14:50.644+0300] P-23547      T-140648157071168 I RPLS     : (-----) INSYNC Data on initial source: AISeq:86, lstmod:1742456644, mbUpdCtr:8.
 
Back
Top