Re: Regression on pg_restore to 16.0: DOMAIN not available to SQL function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Hills <mark(at)xwax(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Regression on pg_restore to 16.0: DOMAIN not available to SQL function
Date: 2023-11-03 14:35:44
Message-ID: 3295772.1699022144@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Hills <mark(at)xwax(dot)org> writes:
> I'm having errors restoring with pg_restore to v16.0, it appears to be a
> regression or bug. The same file restored to v15.4 without problem.

> During the restore:

> pg_restore: error: could not execute query: ERROR: type "hash" does not exist
> LINE 7: )::hash;
> [...]
> CONTEXT: SQL function "gen_hash" during inlining

It looks like your gen_hash() function is not proof against being
run with a minimal search_path, which is how the restore script
would call it. However, then it's not clear why it would've worked
in 15.4 which does the same thing. I wonder whether you are
using this function in a column default for the troublesome
table. If so, the discrepancy might be explained by this
fix that I just got done writing a 16.1 release note for:

<listitem>
<!--
Author: Andrew Dunstan <andrew(at)dunslane(dot)net>
Branch: master [276393f53] 2023-10-01 10:18:41 -0400
Branch: REL_16_STABLE [910eb61b2] 2023-10-01 10:25:33 -0400
-->
<para>
In <command>COPY FROM</command>, avoid evaluating column default
values that will not be needed by the command (Laurenz Albe)
</para>

<para>
This avoids a possible error if the default value isn't actually
valid for the column. Previous releases did not fail in this edge
case, so prevent v16 from doing so.
</para>
</listitem>

> It prompted me to separate the restore into steps:
> * An initial "--schema-only" completes
> * The "--data-only" when the error takes place

Uh, *what* prompted you to do that? By and large, separating a
restore into two steps creates more problems than it solves.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2023-11-03 14:53:30 Re: Improve WALRead() to suck data directly from WAL buffers when possible
Previous Message Christoph Berg 2023-11-03 14:26:05 Re: meson documentation build open issues