Spurious entries in `spock.resolutions` for update from new origin (5.0.4)

[argggh]

Hi,

Running a two-node distributed active/active scenario based on this docker compose example with pg16/spock 5.0.4:

(n1) test=# create table accounts (id integer primary key, balance integer not null);
[..]
(n1) test=# insert into accounts (id, balance) values (1, 100);
[..]
(n2) test=# update accounts set balance = balance + 7 where id = 1;
[..]
(n1) test=# select * from spock.channel_table_stats where table_name = 'public.accounts';
   subid    | relid | sub_name  |   table_name    | n_tup_ins | n_tup_upd | n_tup_del | n_conflict | n_dca 
------------+-------+-----------+-----------------+-----------+-----------+-----------+------------+-------
          0 | 19379 | <output>  | public.accounts |         1 |         0 |         0 |          0 |     0
 1248781941 | 19379 | sub_n2_n1 | public.accounts |         0 |         1 |         0 |          1 |     0
(2 rows)
(n1) test=# select * from spock.resolutions;
 id | node_name |           log_time            |     relname     |    idxname    | conflict_type | conflict_resolution | local_origin |      local_tuple       | local_xid |        local_timestamp        | remote_origin |      remote_tuple      | remote_xid |       remote_timestamp       | remote_lsn 
----+-----------+-------------------------------+-----------------+---------------+---------------+---------------------+--------------+------------------------+-----------+-------------------------------+---------------+------------------------+------------+------------------------------+------------
  1 | n2        | 2026-01-29 12:02:58.497849+00 | public.accounts | accounts_pkey | update_update | apply_remote        |            0 | {"id":1,"balance":100} |      1003 | 2026-01-29 12:02:55.091901+00 |         49708 | {"id":1,"balance":107} |       1208 | 2026-01-29 12:02:58.49553+00 | 0/2949928
(1 row)

This is surprising to me, as my understanding was that a conflict is defined as overlapping (in time) transactions that operate on the same row(s). In this case the transactions are strictly serial, and this conflict resolution entry does not seem to indicate an actual conflict in the sense that I would understand it. It is also different from what was logged by Spock 4.0.10, as far as I am able to determine based on experiments. This comment also seems to imply that this is not a "true" conflict, but a consequence of how processing is done.

I have some questions based on this:

1. Is it correct that these "conflicts" are expected under this usage pattern, or is something missing in my setup that causes this to be treated as a conflict when it really shouldn't be?
2. If this is expected behavior, it would seem that the severity of the entries in the spock.resolutions log can vary quite significantly. Could we have some way to filter what ends up there? I'm interested in entries that indicate that information may have been lost, but I am not really interested in entries that just indicate that "processing of this row moved from one node to another".

[mason-sharp]

In Spock 5.0.4, whenever there is a detected change in "origin" of the row, it is logged. In this case, the row was inserted on n1 and updated on n2, so the origin of the row changed and it was logged.

I agree it can be noisy. As you noticed from the commit that you referenced, we are making changes to conflict types in 5.1, which is still under development. Also not yet done is the delete origin change (say, inserted on n1, then deleted on n2). For both update and delete origin changes, we intend to make it configurable whether or not to log those since it can be expected in normal operation. We may make it configurable to log origin changes only when they happen within some configurable time interval rather than making it all-or-nothing.