Re: cache lookup failed for index

From: Willy-Bas Loos <willybas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: cache lookup failed for index
Date: 2016-06-29 10:06:42
Message-ID: CAHnozTiLwZD=KHovfMO=AE7winK9rV8FqUfJmVxvmGLbEoSxgw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jun 29, 2016 at 11:16 AM, Willy-Bas Loos <willybas(at)gmail(dot)com> wrote:

> Ah OK. So it needs a lock for the visibility to be registered to the
> transaction, is that it?
>

Wait that doesn't make sense. pg_dump merely describes the table in DDL, so
it doesn't even need access to the index pages. It only needs to read the
pg_catalog afaik.
However, the indexes are created as a last step in the pg_dump process (at
least in the resulting dump file). So it first makes the DDL to create the
table, then dumps the data, and in the end it describes the constraints,
indexes and privileges.
So maybe pg_dump first creates the DDL, then acquires a access share lock
on the table for dumping the data, and then when it's time to create DDL
for the index, it is gone from the pg_catalog.
So what i don't get is, -if the above is the case- If pg_dump expects to
find an index, it already knows about its existence. Then why does it need
to look for it again?

--
Willy-Bas Loos

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2016-06-29 12:34:40 Re: Sub-query having NULL row returning FALSE result
Previous Message Willy-Bas Loos 2016-06-29 09:16:39 Re: cache lookup failed for index