On Wed, Jun 29, 2016 at 4:26 PM, Tom Lane wrote:
> Willy-Bas Loos writes:
> > 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?
>
>
> pg_dump can't tell the index is
Willy-Bas Loos writes:
> 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?
Because what it does is:
BEGIN ISOLATION LEVEL REPEATABLE READ; -- run in a single transaction
On Wed, Jun 29, 2016 at 11:16 AM, Willy-Bas Loos 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
Ah OK. So it needs a lock for the visibility to be registered to the
transaction, is that it?
Willy-Bas Loos writes:
> [ pg_dump sometimes fails with ]
> pg_dump: [archiver (db)] query failed: ERROR: cache lookup failed for
> index 231808363
This wouldn't be too surprising if you're constantly creating and dropping
indexes. There's a small window between where pg_dump starts its
transac
On Tue, Jun 28, 2016 at 7:14 PM, Willy-Bas Loos wrote:
>
> (...)
> Does anyone know what's up?
> --
>
>
oh btw this is postgres 9.3 on debian 7
and londiste 2
--
Willy-Bas Loos
