Hello hackers,
I'd like design feedback on a problem I'm hitting with parallel restores and short-lived credentials.
Context: Cloud IAM authentication (AWS RDS/Aurora PostgreSQL) uses tokens that are valid for a fixed window — 15 minutes — supplied through the password channel.
Problem: A parallel pg_restore -j N that runs longer than the token lifetime fails on the leader's postfork reconnect with FATAL: ... authentication failed.
The jobs uses to reconnect and the reconnect reuses the password cached at first connect (AH->savedPassword), and an explicit password makes libpq skip PGPASSFILE/PGPASSWORD resolution — so a freshly refreshed token is ignored and the expired one is replayed.
This is correct for static passwords but incompatible with expiring credentials (like IAM token)
Possible solutions:
- An opt-in option to re-resolve the password on reconnect: pass no explicit password and let libpq resolve per-connection, with the user keeping a current token in the passfile/env. Default would preserve current behavior (e.g. --no-reuse-password / --reconnect-password=reuse|resolve).
- Alternatively, avoid the leader reconnect so no re-auth is needed — though this may affect resource usage and cuts against the current phased design, so I see it as the weaker option.
Could this direction be agreed ? At the moment this issue is blocking the possibility to work with IAM and having multiple jobs for restoring a db (at the moment this means to make a choice between security and performance)
Thanks a lot in advance,
Fabrizio
