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

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