Re: Autovacuum of independent tables

2020-09-08 Thread Michael Holzman
do have open cursors. Thanks. -- Regards, Michael Holzman

Re: Autovacuum of independent tables

2020-09-08 Thread 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

Re: Autovacuum of independent tables

2020-09-08 Thread Michael Holzman
mons working with PG via ODBC on RHEL. We use default ODBC settings. -- Regards, Michael Holzman

Re: Autovacuum of independent tables

2020-09-08 Thread 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

Re: Autovacuum of independent tables

2020-09-08 Thread 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

Re: Autovacuum of independent tables

2020-09-08 Thread 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

Re: Autovacuum of independent tables

2020-09-08 Thread Michael Holzman
COMMITs without breaking the flow. It is quite a complex thing. I hoped we can avoid that. -- Regards, Michael Holzman

Re: Autovacuum of independent tables

2020-09-08 Thread 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

Re: Autovacuum of independent tables

2020-09-08 Thread 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

Autovacuum of independent tables

2020-09-08 Thread Michael Holzman
, Michael Holzman

Re: Kerberos-Postgresql implementation for user authentication

2020-07-09 Thread Michael Holzman
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