Thanks for the update. Actually I was able to rewrite the query to get rid
of the union. But anyway it would be good to have this issue handled
somehow, it's tricky and it was hard to spot and reproduce.
ср, 8 січ. 2025 р. о 19:01 Tom Lane пише:
> I wrote:
> > Andrey writes:
> >> ... but I woul
I wrote:
> Andrey writes:
>> ... but I would expect to get the same result as previously. Is it a bug
>> or am I doing something wrong here?
> It's a surprising result for sure, but I believe it's explained by
> the algorithm for READ COMMITTED [1], specifically the bit about
Actually, on furthe
Andrey writes:
> Recently I got unexpected results from a query that seems to be legit.
> ...
> ... Once I commit the concurrent query and
> release the lock, I get this:
> -- result 2
>child_id
> --
> 5cb82ceb-c5ef-4c59-a02e-f7b610470f8c
> 5c
Hi everyone,
Recently I got unexpected results from a query that seems to be legit.
The setup is like this:
-- setup
CREATE TABLE parents
(
id uuidnot null primary key,
revision integer not null
);
CREATE TABLE children
(
iduuidnot null primary key,
parent_id
