I have a replication setup with a master and a single synchronous slave. If the slave dies (or the network goes down) I would like any transaction on the master that requires writing to fail so I can roll it back. At the moment, when I commit it just hangs forever or (if I cancel it using ^C in psql or using kill) it commits locally and not on the synchronous slave.
I did that for a customer and I am using a tool (pgpool) to change the config file if the master is going down. You can keep additional configurations in
synchronous_master.conf and add include header in postgresql.conf
You just need to write a shell script (or use something like pgpool) to keep a watch if the slave goes down change synchronous_master.conf to an empty file and reload the postgres config (pg_ctl reload).
Neither of these options are ok in my use case. I have tried setting statement_timeout but it does not work. So my questions are:
1) Is it possible to rollback transactions that fail to commit after a certain amount of time waiting for the slave?
No, AFAIK it would have already committed to WAL files on on master.
It is just blocked till the slave confirms the same being done at its end.
2) If not, is there any intension of implementing such a feature in the near future?
3) Do any of the answers above change if we are dealing with two-phase commits instead? At the moment it hangs forever on ‘prepare transaction’, ‘commit prepared’ and ‘rollback prepared’ commands.
Best Regards,
Sameer Kumar | Database Consultant
ASHNIK PTE. LTD.
101 Cecil Street, #11-11 Tong Eng Building, Singapore 069533