Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Hi,

On 2017-11-13 19:03:41 -0800, Andres Freund wrote:
> diff --git a/src/backend/access/heap/rewriteheap.c b/src/backend/access/heap/rewriteheap.c
> index f93c194e182..7d163c91379 100644
> --- a/src/backend/access/heap/rewriteheap.c
> +++ b/src/backend/access/heap/rewriteheap.c
> @@ -407,7 +407,10 @@ rewrite_heap_tuple(RewriteState state,
> * While we have our hands on the tuple, we may as well freeze any
> * eligible xmin or xmax, so that future VACUUM effort can be saved.
> */
> - heap_freeze_tuple(new_tuple->t_data, state->rs_freeze_xid,
> + heap_freeze_tuple(new_tuple->t_data,
> + state->rs_old_rel->rd_rel->relfrozenxid,
> + state->rs_old_rel->rd_rel->relminmxid,
> + state->rs_freeze_xid,
> state->rs_cutoff_multi);

Hm. So this requires backpatching the introduction of
RewriteStateData->rs_old_rel into 9.3, which in turn requires a new
argument to begin_heap_rewrite(). It originally was added in the
logical decoding commit (i.e. 9.4).

I'm fine with that, but it could theoretically cause issues for somebody
with an extension that calls begin_heap_rewrite() - which seems unlikely
and I couldn't find any that does so.

Does anybody have a problem with that?

Regards,

Andres