ghgo.ca/2020/03/26/postgresql-gssapi-authentication-with-kerberos-part-2-postgresql-configuration/
https://www.highgo.ca/2020/03/30/postgresql-gssapi-authentication-with-kerberos-part-3-the-status-of-authentication-encryption-and-user-principal/
>
--
Regards,
Michael Holzman
,
Michael Holzman
ns in tableB
while there is an open transaction on tableA.
But the tables have nothing in common. They are handled by separate
applications and there are no transactions that touch both tables
simultaneously.
Why does autovacuum create an artificial dependency on the tables?
--
Regards,
Michael Holzman
that data from tableB is needed in this same transaction, so
> old versions of the rows from tableB matching with the snapshot hold
> by this long-running transaction still have to be around.
>
> Yes, I thought so. I just hoped there may be a workaround decoupling the
tables.
Thanks
COMMITs without breaking the flow. It is quite a complex
thing. I hoped we can avoid that.
--
Regards,
Michael Holzman
transaction can lead to “snapshot too old” error.
>
Yes, I am saying just that. With one important clarification: there were no
transactions as SELECT does not open them and the application does not
change anything on that connection.
So, no 'snapshot too old' and no COMMITs.
--
Regards,
Michael Holzman
it for the first time. I just wanted to
understand it deeper and, fortunately, find a work around that would
simplify our current development.
Thanks to all.
--
Regards,
Michael Holzman
removal of rows from a table it has not touched is not a bug.
>
It's obviously not a bug. I was just surprised when I figured that out.
It's also quite complex to explain to my colleagues. Actually, this is the
main reason I started this thread: I tried to explain to someone and felt
that I miss something.
--
Regards,
Michael Holzman
mons working with PG via ODBC on RHEL. We use
default ODBC settings.
--
Regards,
Michael Holzman
at long
> since we fixed things so that an idle read-committed transaction
> advertises no xmin. It's also possible that the transaction isn't really
> idle between statements (eg, if it's holding open cursors, or the like).
>
There are no open cursors.
--
Regards,
Michael Holzman
do have open cursors. Thanks.
--
Regards,
Michael Holzman
11 matches
Mail list logo
