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
>From the version string I can suggest that it is vanilla postgres from
The PostgreSQL Global Development Group (PGDG).
But we will ask the user.
I've checked PG source code, it checks system attrs (like xmin)
existence in some cache. Maybe that is really corruption.
Does postgres itself rely on x
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
On Thu, 2021-09-02 at 08:50 +0300, Alexander Kass wrote:
> Hi! I'm Alexander from DataGrip.
> We actively use xmin's from pg_catalog tables to incrementally
> synchronize our database model.
> We have a small number of users that do not have xmin in pg_database
> (we've asked them to try `select xm
