Alvaro Herrera writes:
> bkrug wrote:
>> The problem I'm facing is that I have many large (several GB) tables that are
>> not being changed (they are several days old) but auto-vacuum keeps scanning
>> and updating them every time the xid wraps around and thus my rsync back-up
>> process sees that
bkrug wrote:
> The problem I'm facing is that I have many large (several GB) tables that are
> not being changed (they are several days old) but auto-vacuum keeps scanning
> and updating them every time the xid wraps around and thus my rsync back-up
> process sees that the disk files have changed a
The problem I'm facing is that I have many large (several GB) tables that are
not being changed (they are several days old) but auto-vacuum keeps scanning
and updating them every time the xid wraps around and thus my rsync back-up
process sees that the disk files have changed and must copy them.
On Mon, Feb 9, 2015 at 4:45 PM, bkrug wrote:
> Should the relfrozenxid of pg_class then equal 2 for very old and already
> vacuumed tables? Because that is not what I am seeing.
hm... You meant in the entire table? Like an static table?
Then no, it is done tuple by tuple only. In older version
bkrug wrote:
> Matheus de Oliveira wrote
> > It changed in recent versions (9.3 or 9.4, I don't recall exactly which)
> > and moved to tuple header, but what you described is exactly what was
> > done,
> > the xid was 2.
>
> Should the relfrozenxid of pg_class then equal 2 for very old and already
Matheus de Oliveira wrote
> It changed in recent versions (9.3 or 9.4, I don't recall exactly which)
> and moved to tuple header, but what you described is exactly what was
> done,
> the xid was 2.
Should the relfrozenxid of pg_class then equal 2 for very old and already
vacuumed tables? Because t
Matheus de Oliveira wrote:
> On Mon, Feb 9, 2015 at 1:58 PM, bkrug wrote:
>
> > Couldn't postgres reserve a special XID that is never available for normal
> > transactions but that indicates that any transaction can see it because it
> > is so old? Then instead of constantly having to freeze old
On Mon, Feb 9, 2015 at 1:58 PM, bkrug wrote:
> Couldn't postgres reserve a special XID that is never available for normal
> transactions but that indicates that any transaction can see it because it
> is so old? Then instead of constantly having to freeze old XIDs each time
> the XID is going to
For a large database with lots of activity (transactions), the XIDs are very
often re-frozen by AutoVacuum. Even when autovacuum_freeze_max_age is set to
2 billion, the XIDs can wrap every couple of days on an active database.
This causes unnecessary changes to otherwise unmodified files and archiv
