Re: idle_in_transaction_timeout
| От | David G Johnston |
|---|---|
| Тема | Re: idle_in_transaction_timeout |
| Дата | |
| Msg-id | CAKFQuwZJDpTDrVtezUABsTUEMN+5o5MJrV0F0JPoYa7zYKCe0w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: idle_in_transaction_timeout (Vik Fearing <vik.fearing@dalibo.com>) |
| Ответы |
Re: idle_in_transaction_timeout
Re: idle_in_transaction_timeout |
| Список | pgsql-hackers |
On 06/22/2014 05:11 PM, Kevin Grittner wrote:My reasoning for doing it the way I did is that if a transaction touches
> I found one substantive issue that had been missed in discussion,
> though. The patch modifies the postgres_fdw extension to make it
> automatically exempt from an attempt to set a limit like this on
> the server to which it connects. I'm not sure that's a good idea.
> Why should this type of connection be allowed to sit indefinitely
> with an idle open transaction? I'm inclined to omit this part of
> the patch
a foreign table and then goes bumbling along with other things the
transaction is active but the connection to the remote server remains
idle in transaction. If it hits the timeout, when the local transaction
goes to commit it errors out and you lose all your work.
If the local transaction is actually idle in transaction and the local
server doesn't have a timeout, we're no worse off than before this patch.
Going off of this reading alone wouldn't we have to allow the client to set the timeout on the fdw_server - to zero - to ensure reasonable operation? If the client has a process that requires 10 minutes to complete, and the foreign server has a default 5 minute timeout, if the client does not disable the timeout on the server wouldn't the foreign server always cause the process to abort?
David J.
View this message in context: Re: idle_in_transaction_timeout
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
В списке pgsql-hackers по дате отправления: