Alexander Kass writes:
> I've asked the user to perform `SELECT xmin, * from pg_attribute WHERE
> attrelid = 'pg_catalog.pg_database'::regclass` to check the
> attributes.
> The user has sent me that a couple of times: both times xmin is
> different, attrelid is different, both have a big value.
>
I've asked the user to perform `SELECT xmin, * from pg_attribute WHERE
attrelid = 'pg_catalog.pg_database'::regclass` to check the
attributes.
The user has sent me that a couple of times: both times xmin is
different, attrelid is different, both have a big value.
Does that mean that pg_database is
> > Now xmins are back and so are the problems.
> > The most recent report is about version `PostgreSQL 12.4 (Ubuntu
> > 12.4-1.pgdg18.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
> > 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit`
> >
> > How can that happen tha
On Thu, 2021-09-02 at 12:10 +0300, Alexander Kass wrote:
> As for xmin usage, we have a working scheme. We fetch objects based on
> dbage(xid), starting from the oldest uncommitted transaction of
> previous synchronization.
> Do you think it does not work?
I don't know what exactly you are doing,
Laurenz Albe writes:
> On Thu, 2021-09-02 at 08:50 +0300, Alexander Kass wrote:
>> We have a small number of users that do not have xmin in pg_database
>> (we've asked them to try `select xmin from pg_database` and got
>> `column xmin does not exist`).
> All PostgreSQL tables have "xmin", and all
ms.
> The most recent report is about version `PostgreSQL 12.4 (Ubuntu
> 12.4-1.pgdg18.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
> 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit`
>
> How can that happen that there is no xmin in pg_database?
> Is it a normal behaviour and that is c
nu, compiled by gcc (Ubuntu
7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit`
How can that happen that there is no xmin in pg_database?
Is it a normal behaviour and that is configurable? Or is this a kind
of data corruption?
Can that happen to other tables?
I haven't been able to find answers myself, so
