On Tue, 06 Apr 2021 10:46:08 +0200
Laurenz Albe wrote:
> On Sat, 2021-04-03 at 15:22 +0200, Luca Ferrari wrote:
> > why having a TransactionId that is 32 bits
> > in depth while it is exposed (thru txid_current()) as a 64 bits value?
> > I mean, having 64 bits would reduce the need for anti-wrap
On Sat, 2021-04-03 at 15:22 +0200, Luca Ferrari wrote:
> why having a TransactionId that is 32 bits
> in depth while it is exposed (thru txid_current()) as a 64 bits value?
> I mean, having 64 bits would reduce the need for anti-wrap arpund
> vacuum. I suspect the usage of 32 bits is both for compa
On Fri, Apr 2, 2021 at 10:29 AM Jehan-Guillaume de Rorthais
wrote:
>
> On Thu, 18 Mar 2021 09:56:16 +0100
> Luca Ferrari wrote:
> [...]
> > Therefore my question is: shouldn't autovacuum be able to freeze other
> > tables/databases? I mean, the wraparound problem in this scenario will
> > cause p
On Thu, 18 Mar 2021 09:56:16 +0100
Luca Ferrari wrote:
[...]
> Therefore my question is: shouldn't autovacuum be able to freeze other
> tables/databases? I mean, the wraparound problem in this scenario will
> cause problems, but I was expecting different numbers for different
> tables/databases.
Hi Luca,
On Mon, 22 Mar 2021 08:56:46 +0100
Luca Ferrari wrote:
> I can confirm that freezing a template database is done by means of setting
> it age to zero.
[...]
> and here it is the situation after a restart:
>
> testdb=> select datname, age( datfrozenxid ) from pg_database;
> datname
On Mon, Mar 29, 2021 at 7:12 PM Laurenz Albe wrote:
> I didn't follow the rest of the thread, but autovacuum should handle
> those databases and advance their "datfrozenxid".
That did not happen.
In short: I turned off autovacuum globally, then in a database I
consumed a lot of xid while keeping
On Mon, 2021-03-29 at 16:58 +0200, Luca Ferrari wrote:
> > If there is no activity on a database, its "datfrozenxid" stays
> > the same. So, as transaction IDs are consumed, it is getting older
> > automatically. That means that even inactive databases will receive
> > an anti-wraparound vacuum o
On Mon, Mar 29, 2021 at 11:14 AM Laurenz Albe wrote:
>
> If there is no activity on a database, its "datfrozenxid" stays
> the same. So, as transaction IDs are consumed, it is getting older
> automatically. That means that even inactive databases will receive
> an anti-wraparound vacuum occasion
On Mon, 2021-03-29 at 10:33 +0200, Luca Ferrari wrote:
> Another thing that comes into my mind as a doubt is: why are all
> databases becoming old? I mean, I'm provoking activity _only_ on
> testdb, therefore other database such as template1 are not doing
> anything.
That one I can answer.
If the
On Mon, Mar 22, 2021 at 8:56 AM Luca Ferrari wrote:
> backend> select datname, age( datfrozenxid), current_setting(
> 1: datname = "template0" (typeid = 19, len = 64, typmod
> = -1, byval = f)
> 2: age = "2138438218" (typeid = 23, len = 4, typmod = -1, byval = t)
>
On Sat, Mar 20, 2021 at 12:07 PM Luca Ferrari wrote:
> I suspect freezing is doing it "totally" for a idatistemplate
> database, even if I don't understand why.
I can confirm that freezing a template database is done by means of
setting it age to zero. I've set the datistempalte flag for testdb a
On Thu, Mar 18, 2021 at 12:14 PM Luca Ferrari wrote:
> testdb=> select datname, datfrozenxid, age(datfrozenxid) from pg_database;
> datname | datfrozenxid | age
> ---+--+--
> postgres | 3318163526 | 5002
> backupdb | 3318163526 | 5002
> template1 |
On Thu, Mar 18, 2021 at 9:56 AM Luca Ferrari wrote:
>
> What puzzles me is that I'm somehow "locking" the testdb.wa table (by
> inserting a tuple every 20 minutes), so all other tables and databases
> are free to be frozen by an emergency autovacuum. And I was expecting
> the problem to happen due
Hi all,
I'm doing some experiments on a cluster to see what happens at xid
wraparound, and I'm approaching it. There is no activity in any
database but testdb.
Scenario: I've a procedure that is consuming all xids, while another
connection is inserting a tuple every 20 minutes or so in a table,
jus
14 matches
Mail list logo
