Re: How to Identify and Fail Transaction When Slave Node Down

Thanks for your reply.
I was wondering whether there is a transaction level timeout in postgresql
at least to rollback the transaction if it waits for too long, or something
that I can set in connection string(client).
I tried statement_timeout, didn't work though.

Thanks,
Anushka

On Thu, Mar 16, 2017 at 3:21 PM, vinny <vinny(at)xs4all(dot)nl> wrote:

> On 2017-03-16 10:06, Anushka Weerakkodyge wrote:
>
>> Hi,
>>
>> problem still persists.
>> Is there any configuration (parameter?) to set the timeout of the
>> connection ? Because if the slave node is down, transaction to master
>> node waits forever until slave node comes back online.
>> Any suggestion would be highly appreciated.
>>
>> Thanks,
>> Anushka
>> On Thu, Mar 16, 2017 at 5:21 AM, Anushka Weerakkodyge
>> <anushkaw(at)ceylonit(dot)com> wrote:
>>
>> Hi all,
>>>
>>> I have a synchronous streaming replication environment which is
>>> implemented using inbuilt replication mechanism in postgresql.
>>> Replication is working fine except I need to fail the data
>>> modification transactions when the slave node is not accessible.
>>>
>>> Is it possible?
>>>
>>> Please let me know whether there is a way to identify slave node
>>> status and fail the transaction using any inbuilt mechanism or some
>>> other technique.
>>>
>>> Thanks,
>>> Anushka
>>>
>>
>
> As far as I know, which is does not mean much, there is no timeout setting.
> And that's by design; a timeout can occur because the node is down,
> but also because it's busy and cannot answer in time, or there is a
> network hickup.
>
> Adding a timeout would basically break the "syncronous" promise
> because that guarantees that either all nodes are updated, or the
> transaction fails.
>
> And yes I googled this from: https://www.postgresql.org/mes
> sage-id/CADp-Sm7ENFJH4YQmJVYD2qB2OaKa6qb6TEHCJWfce%
> 2BQoQXsdhA%40mail.gmail.com
>
> In the case of a node going down you should probably but some failover
> mechanism in place so you can safely remove the dead node from the setup
> and rebuild it before making it part of the cluster again.
>