Seems I was able to mitigate the issue by adding the pool pre_ping and
setting the recycle parameter to 1 minute. Seems indeed to be an RDS thing.
Thanks everyone!
On Sunday, June 3, 2018 at 7:17:55 PM UTC-7, rvd wrote:
>
> Hi all,
>
> I am writing a Flask API that needs to communicate with
In theory what you're claiming should be fine... but there's always a
chance that what you *think* you're doing isn't really what you're doing.
I suggest creating a tiny one-file flask app that mimics your behavior and
reproduces the result -- then share it here. Your example on
On Sun, Jun 3, 2018 at 11:42 PM, rvd wrote:
> Hi Mike,
>
> Thanks for the quick reply. I am using Version 9.6.6 (RDS).
I just realized Amazon offers an RDS for Postgresql. This is
definitely something RDS-specific, like an idle timeout or something,
though I can't find any google results for
On Sun, Jun 3, 2018 at 11:42 PM, rvd wrote:
> Hi Mike,
>
> Thanks for the quick reply. I am using Version 9.6.6 (RDS). Not using any
> proxy. Because this was a rather blocking issue, I have been utilizing a
> terrible workaround (namely creating an engine every single request, and
> using that
Hi Jonathan,
I am not. This is encountered as soon as the app loads. Before request
processing, I just make the engine and sessionmaker. Sessions are made from
the sessionmaker per request. All of the functional code is on the SO link
more or less. Is the overall pattern reasonable or have I
Hi Mike,
Thanks for the quick reply. I am using Version 9.6.6 (RDS). Not using any
proxy. Because this was a rather blocking issue, I have been utilizing a
terrible workaround (namely creating an engine every single request, and
using that session) with some success - obviously not ideal
On Sunday, June 3, 2018 at 7:17:55 PM UTC-7, rvd wrote:
>
> Hi all,
>
> I am writing a Flask API that needs to communicate with many datastores,
> Postgres on AWS RDS being one of them. I want to avoid Flask-SQLAlchemy
> (trying to reduce package dependence); I think the standard SQLAlchemy
