Andres Freund writes:
> On 2021-10-11 14:59:22 -0400, Tom Lane wrote:
>> I doubt we need any code changes beyond changing the indisvalid state.
> I was thinking we'd want to throw an error if an index that's being created is
> accessed during the index build, rather than just not include it in
>
Hi,
On 2021-10-11 14:59:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Perhaps we could set pg_index.indisvalid to false initially, and if opening
> > an
> > index where pg_index.indisvalid error out with a different error message if
> > TransactionIdIsCurrentTransactionId(xmin). And then
Andres Freund writes:
> Perhaps we could set pg_index.indisvalid to false initially, and if opening an
> index where pg_index.indisvalid error out with a different error message if
> TransactionIdIsCurrentTransactionId(xmin). And then use an inplace update to
> set indisvalid to true, to avoid the
Hi,
On 2021-10-11 12:27:44 -0400, Tom Lane wrote:
> While that could be argued to be a bug, I share David's lack of interest in
> fixing it, because I do not believe that there are any cases where a
> function that accesses an index's subject table is really going to be
> immutable.
> To prevent
On Mon, Oct 11, 2021 at 9:27 AM Tom Lane wrote:
> Yeah. What is happening is that the function's SELECT on the subject
> table is trying to examine the not-yet-valid new index. While that could
> be argued to be a bug, I share David's lack of interest in fixing it,
> because I do not believe tha
Tomas Vondra writes:
> True, but I can't reproduce it. So either the build is broken in some
> way, or perhaps there's something else going on. What would be quite
> helpful is a backtrace showing why the error was triggered. i.e. set a
> breakpoint on the ereport in mdread().
It reproduced as
"David G. Johnston" writes:
> On Monday, October 11, 2021, Prabhat Sahu
> wrote:
>> While using IMMUTABLE functions in index expression, we are getting below
>> corruption on HEAD.
> That function is not actually immutable (the system doesn’t check whether
> your claim of immutability and the fu
On 10/11/21 18:08, Andrey Borodin wrote:
11 окт. 2021 г., в 20:47, David G. Johnston
написал(а):
On Monday, October 11, 2021, Prabhat Sahu wrote:
While using IMMUTABLE functions in index expression, we are getting below
corruption on HEAD.
That function is not actually immutable (the
> 11 окт. 2021 г., в 20:47, David G. Johnston
> написал(а):
>
> On Monday, October 11, 2021, Prabhat Sahu
> wrote:
> While using IMMUTABLE functions in index expression, we are getting below
> corruption on HEAD.
>
> That function is not actually immutable (the system doesn’t check whethe
On Monday, October 11, 2021, Prabhat Sahu
wrote:
>
> While using IMMUTABLE functions in index expression, we are getting below
> corruption on HEAD.
>
That function is not actually immutable (the system doesn’t check whether
your claim of immutability and the function definition match, its up to
Hi All,
While using IMMUTABLE functions in index expression, we are getting below
corruption on HEAD.
postgres=# CREATE TABLE tab1 (c1 numeric, c2 numeric);
CREATE TABLE
postgres=# INSERT INTO tab1 values (10, 100);
INSERT 0 1
postgres=# CREATE OR REPLACE FUNCTION func1(var1 numeric)
RETURNS
11 matches
Mail list logo
