Hi, On 2023-01-07 21:06:06 +0300, Michail Nikolaev wrote: > 2) It is not an issue at table creation time. Issue is reproducible if > vacuum_defer_cleanup_age set after table preparation. > > 3) To reproduce the issue, vacuum_defer_cleanup_age should flip xid > over zero (be >= txid_current()). > And it is stable.... So, for example - unable to reproduce with 733 > value, but 734 gives error each time. > Just a single additional txid_current() (after data is filled) fixes a > crash... It looks like the first SELECT FOR UPDATE + UPDATE silently > poisons everything somehow. > You could use such PSQL script:
FWIW, the concrete value for vacuum_defer_cleanup_age is not crucial to encounter the problem. It needs to be a value that, when compared to the xid that did the "INSERT INTO something_is_wrong_here", results in value <= 0. Setting vacuum_defer_cleanup_age than the xid to a much larger value allows the crash to be encountered repeatedly. Greetings, Andres Freund
