Hi, On 2023-01-18 11:24:19 +0100, Drouvot, Bertrand wrote: > On 1/6/23 4:40 AM, Andres Freund wrote: > > Hm, that's quite expensive. Perhaps worth adding a C helper that can do that > > for us instead? This will likely also be needed in real applications after > > all. > > > > Not sure I got it. What the C helper would be supposed to do?
Call LogStandbySnapshot(). > With a reload in place in my testing, now I notice that the catalog_xmin > is updated on the primary physical slot after logical slots invalidation > when reloading hot_standby_feedback from "off" to "on". > > This is not the case after a re-start (aka catalog_xmin is NULL). > > I think a re-start and reload should produce identical behavior on > the primary physical slot. If so, I'm tempted to think that the catalog_xmin > should be updated in case of a re-start too (even if all the logical slots > are invalidated) > because the slots are not dropped yet. What do you think? I can't quite follow the steps leading up to the difference. Could you list them in a bit more detail? > > Can we do something cheaper than rewriting the entire database? Seems > > rewriting a single table ought to be sufficient? > > > > While implementing the test at the table level I discovered that It looks > like there is no guarantee that say a "vacuum full pg_class;" would > produce a conflict. I assume that's mostly when there weren't any removal > Indeed, from what I can see in my testing it could generate a > XLOG_HEAP2_PRUNE with snapshotConflictHorizon to 0: > > "rmgr: Heap2 len (rec/tot): 107/ 107, tx: 848, lsn: > 0/03B98B30, prev 0/03B98AF0, desc: PRUNE snapshotConflictHorizon 0" > > > Having a snapshotConflictHorizon to zero leads to > ResolveRecoveryConflictWithSnapshot() simply returning > without any conflict handling. That doesn't have to mean anything bad. Some row versions can be removed without creating a conflict. See HeapTupleHeaderAdvanceConflictHorizon(), specifically * Ignore tuples inserted by an aborted transaction or if the tuple was * updated/deleted by the inserting transaction. > It does look like that in the standby decoding case that's not the right > behavior (and that the xid that generated the PRUNING should be used instead) > , what do you think? That'd not work, because that'll be typically newer than the catalog_xmin. So we'd start invalidating things left and right, despite not needing to. Did you see anything else around this making you suspicious? > > > +################################################## > > > +# Test standby promotion and logical decoding behavior > > > +# after the standby gets promoted. > > > +################################################## > > > + > > > > I think this also should test the streaming / walsender case. > > > > Do you mean cascading standby? I mean a logical walsender that starts on a standby and continues across promotion of the standby. Greetings, Andres Freund