Re: 2.7.2 still problem with readonly/autocommit, was: Changing set_session implementation

Hi Danielle,

I wonder whether there is any news regarding the bug reported
below ?

Thanks a lot,
Karsten

On Fri, Aug 11, 2017 at 03:33:27PM +0200, Karsten Hilbert wrote:

> > > 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.
>
> Thank you very much and I am sorry for being so stubborn ! :-)
>
> > 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.
>
> That was my suspicion.
>
> > But
> > checking the internal state for idempotence when in autocommit is
> > wrong: the only state that matters is what's in the server session.
>
> Aha, I understand !
>
> > I'll take a look at the logic of the state switching.
>
> Thanks !
>
> Karsten

--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346