From: Tom Lane <tgl@sss.pgh.pa.us>
To: Wells Oliver <wells.oliver@gmail.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: pg_restore can't re-mat mat view that uses a function which depends on another mat view
Date: Mon, 14 Jun 2021 02:00:44 -0400
Message-ID: <162829.1623650444@sss.pgh.pa.us> (raw)
In-Reply-To: <CAOC+FBU-2gHrbP+7QOWAbjTFP6=RGjckY7rTj80f=Rh9=+r67A@mail.gmail.com>
References: <CAOC+FBU-2gHrbP+7QOWAbjTFP6=RGjckY7rTj80f=Rh9=+r67A@mail.gmail.com>
Wells Oliver <wells.oliver@gmail.com> writes:
> Odd one here, but after restoring a database in parallel, I notice a few
> mat views are unmaterialized, e.g.
> ...
> The reason being is that vwm_ytd_p uses a function age() which queries from
> vwm_info, which has not yet been materialized. In fact, it is being
> materialized in parallel in another job, so not yet available.
Right.
> Anything to do here?
Not much we can do today. User-defined functions are black boxes,
so pg_dump can't see what their innards might reference.
v14 will have the ability to declare SQL functions in something
closer to SQL-spec syntax, in which the body of the function will
be parsed at definition time. With that style of function, pg_dump
*does* see the dependencies so this sort of thing should work.
That approach is not without some downsides, but it sounds like it'd
improve your case here.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: tgl@sss.pgh.pa.us, wells.oliver@gmail.com
Subject: Re: pg_restore can't re-mat mat view that uses a function which depends on another mat view
In-Reply-To: <162829.1623650444@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox