"Could not access status of transaction" when using Liquibase migration

[iXo]

Hi,

This project is very interesting for me, as I am trying to find a simple way to have a postgresql cluster without a single master node and with 100% data replicated on each nodes.

I have an application that is using liquibase to manage schema migration, and I tried to use it on this project.

So far, I can't use it as just after creating the 2 liquibase tables (databasechangelog and databasechangeloglock) liquibase wants to insert a lock in it's table, and postgresql return an error :

2025-06-09 09:15:25.761 UTC [149] STATEMENT: UPDATE recorder.databasechangeloglock SET LOCKED = FALSE, LOCKEDBY = NULL, LOCKGRANTED = NULL WHERE ID = 1
2025-06-09 09:15:25.761 UTC [149] ERROR: could not access status of transaction 32766
2025-06-09 09:15:25.761 UTC [149] DETAIL: Could not read from file "pg_subtrans/0000" at offset 122880: read too few bytes.
2025-06-09 09:15:25.761 UTC [149] CONTEXT: while inserting index tuple (2613603249,1) in relation "databasechangeloglock_pkey"

This is from the docker cli showing the postgresql logs. I am not an expert in postgresql, therefore I don't know how to deal with that.

Is it something you know is in the limitations of pgfdb ? Is there something I can do to workaround this issue ?

Thanks.

[iXo]

I have another issue, I tried to execute my scripts manually, everything went well until I reach an instruction that was basically a truncate on a table :

TRUNCATE TABLE records_archive_drives CASCADE;

The docker cli show me that :

2025-06-09 09:43:39.619 UTC [321] ERROR: could not access file "postges": No such file or directory

We can see that the 'g' of postgres is missing, but my client (I am using dbeaver) show me something more interesting :

[https://i.ibb.co/chHr32yL/Copie-d-cran-20250609-114705.png](Image here)

It seems there is an invalid character in place of the missing g, the screenshot show that it display an invalid unicode character that would be \u0001

[fabianlindfors]

Hi!

Regarding your first issue, judging by the errors I'd say this is related to the lack of primary key support in pgfdb as noted under "Limitations". Could you try without a primary key? You can emulate it by creating an index for your primary key column instead. Unique indices are not yet supported but I'm working on it!

Regarding your second issue, that's a surprising error message but I also haven't implemented support for truncation yet, so doesn't really surprise me. That is relatively simple to implement so I'll do it eventually but in the meantime you should be able to do DELETE FROM records_archive_drives CASCADE as long as there isn't way too much data in the table to pass FDB's transaction limits. Also a bit unsure if cascade will be supported, haven't tested that myself!

pgfdb is very experimental as you have noticed but I appreciate you taking the time to open an issue, thank you!

[iXo]

Thank you very much for your reply.

I understand the issues with the primary keys, and yes, I saw that it was indeed in the limitations section. Right now I can't change anything in my schema sadly as there are already 123 schema migration script, and liquibase is made in a special way that a deployed script should never changed after that.

If it was new project, maybe it could have been a solution.

I really like this project, and I hope it could be something in the future.