Re: BUG #17376: Adding unique column with a function() default results in "could not read block 0 in file" error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Japin Li <japinli(at)hotmail(dot)com>
Cc: adrien(dot)gilmore+pg(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17376: Adding unique column with a function() default results in "could not read block 0 in file" error
Date: 2022-01-21 17:36:44
Message-ID: 1196187.1642786604@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Japin Li <japinli(at)hotmail(dot)com> writes:
> On Fri, 21 Jan 2022 at 17:22, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:
>> The error message content returned is what I suspect of being a bug, not so
>> much that this SQL didn't work.

> +1. The error message makes user confused IMO, maybe we can fix it, but I have
> no idea for this. Any suggestion is welcomed.

Yeah. Ideally we'd throw an error along the lines of "can't access a
table that's in process of being altered". The SELECT inside the function
is not part of the ALTER TABLE machinery and ought to be locked out.
However, I fear we don't have adequate infrastructure to tell which
table accesses *are* part of the ALTER TABLE machinery and which aren't.
Maybe it'd be sufficient to check for an active ALTER TABLE in the
parser, but I'm not sure.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2022-01-21 20:42:28 Re: Further information on BUG #17299: Exit code 3 when open connections concurrently (PQisthreadsafe() == 1)
Previous Message Japin Li 2022-01-21 17:27:55 Re: BUG #17376: Adding unique column with a function() default results in "could not read block 0 in file" error