On Fri, Aug 11, 2017 at 9:19 AM, Karsten Hilbert
<Karsten.Hilbert@gmx.net> wrote:
> I agree with this rationale and I understand your
> explanation. Thanks for taking the time. What I am saying,
> however, is that I think I have found a bug. Notice this
> sequence in my test script:
>
> conn.autocommit = False
> conn.readonly = False
> conn.autocommit = True
> conn.readonly = False
>
> After this I would assume the connection to be in readwrite
> mode (per your explanation, psycopg2 would (also) emit a "set
> default_trans...off" when the last readonly=False is given.
>
> However, it does NOT, as the PostgreSQL log snippet shows.
Ok, I see your point, and yes, I think it is a bug.
In [9]: cnn.autocommit = False
[23759] conn_set_session: autocommit 0, isolevel 5, readonly 2, deferrable 2
In [10]: cnn.readonly = True
[23759] conn_set_session: autocommit 0, isolevel 5, readonly 1, deferrable 2
In [11]: cnn.autocommit = True
[23759] conn_set_session: autocommit 1, isolevel 5, readonly 1, deferrable 2
In [12]: cnn.readonly = True
[23759] conn_set_session: autocommit 1, isolevel 5, readonly 1, deferrable 2
The operation in [12] would be idempotent: the code checks that the
new value is the same of the previous one and bails out early. But
checking the internal state for idempotence when in autocommit is
wrong: the only state that matters is what's in the server session.
I'll take a look at the logic of the state switching.
-- Daniele