Hi, > As far as I can see, PerformWalRecovery() uses LOG as elevel > [...] > On top of my mind, any solution I can think of needs to add more > information to XLogReaderState, where we'd either track the type of > error that happened close to errormsg_buf which is where these errors > are tracked, but any of that cannot be backpatched, unfortunately.
Probably I'm missing something, but if memory allocation is required during WAL replay and it fails, wouldn't it be a better solution to log the error and terminate the DBMS immediately? Clearly Postgres doesn't have control of the amount of memory available. It's up to the DBA to resolve the problem and start the recovery again. If this happens on a replica, it indicates a misconfiguration of the system and/or lack of the corresponding configuration options. Maybe a certain amount of memory should be reserved for the WAL replay and perhaps other needs. In the recent case the system should account for the overcommitment of the OS - cases when a successful malloc() doesn't necessarily allocate the required amount of *physical* memory, as it's done on Linux. -- Best regards, Aleksander Alekseev
