Change the xid_stop_limit param.

[Rodrigo Cardoso]

Hello all.

 

We have a enviorment with GPDB 4.33 which the age od database is near of the xid_stop_limit.

We already accross the xid_warn_limit some times, but now we dont have a period to run a vacuum of entire database to recover the age os transactions.

 

This parameter now is 1Bi, by deafult, I have tried to change it for 1.25Bi but I got errors.

1 - To put the parameter, I have to set using skipvalidation

2 - After change, on restart of the server, the MDM didnt come up, and started by SMDW, and then I made the rollback the param.

 

On the log file shows up msgs of all segments ( are 288 ) like:

2021-10-09 00:46:25.154113 -03,"gpmon","gpperfmon",p687442,th1141942048,"127.0.0.1","7299",2021-10-09 00:46:23 -03,407186736,con32,,seg-1,,,x407186736,sx1,"LOG","58M01","Master unable to connect to seg280 sdw47.gphd.local:1029 with options FATAL: database is not accepting commands to avoid wraparound data loss in database ""warehouse""

 

Whats the best way for change this parameter ?

 

Thanks for all

Rodrigo cardoso

 

 

[alex wood]

For a Greenplum Database environment approaching the xid_stop_limit, increasing the limit should not be treated as a substitute for resolving transaction-age issues, especially when the cluster is already showing wraparound protection errors. A safer approach is to identify databases and tables with the oldest transactions, prioritize an appropriate VACUUM strategy, and monitor transaction IDs before making configuration changes; changing the parameter beyond supported limits with skipvalidation can lead to startup or segment-connection problems, as the reported MDM failure demonstrates. The same principle applies to an inventory management warehouse system: regular maintenance, monitoring, and preventive cleanup are generally safer than increasing thresholds simply to postpone an underlying capacity or maintenance problem.