-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Overriding idle_in_transaction_session_timeout
doesn't seem to work properly
#366
Comments
|
Wasn't aware of that, thanks for clearing that up.
I do, yes, but I'd like to avoid having to disable such timeouts during an operation like this. Would now perhaps be a good occasion to rekindle the discussion regarding the overriding of this timeout in Personally, I think this would be a great addition, but perhaps I'm missing some insight as to why not. |
I'd say that pg_repack shouldn't disable But on the other hand the issue is an environment related issue, because
|
I'd say that's also a suitable solution, thanks for being open to it.
But I think I did this correctly, didn't I? If you check the |
Potentially could be the case that it did not react on your ENV because you wrote it twice. So the latest one re-wrote the first (exactly with PGOPTIONS="-c idle_in_transaction_session_timeout=0 -c statement_timeout=0" sudo -u postgres pg_repack --no-kill-backend --wait-timeout=180 --table=<table> <database> |
Possibly related to #222
Today, I was trying to
repack
a table and I got the following warning:ERROR: query failed: FATAL: terminating connection due to idle-in-transaction timeout
.As I had an
idle_in_transaction_session_timeout
of "just"2h
, I thought I'd retry (since it could very well have been 2h since it had begun), this time setting it to0
, and the same behaviour was observed:Details
To check that it does indeed work, I tried running it again, but setting it to
5s
so that it's obvious ifPGOPTIONS
is actually overriding the timeouts or not, and it worked as expected:Details
So this seems to indicate that there's some kind of problem with the timeouts.
Looking forward to hear your perspective on this,
Francisco
The text was updated successfully, but these errors were encountered: