On Fri, Nov 28, 2014 at 10:24 AM, Teresa Bradbury <t...@quintessencelabs.com> wrote:
> 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 M: *+65 8110 0350* T: +65 6438 3504 | www.ashnik.com *[image: icons]* [image: Email patch] <http://www.ashnik.com/> This email may contain confidential, privileged or copyright material and is solely for the use of the intended recipient(s).
