Re: pg_dump bug in 9.4beta2 and HEAD

On 08/14/2014 06:53 AM, Joachim Wieland wrote:
> I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
> not ready to handle BLOBs it seems:
>
> pg_dump: pg_backup_archiver.c:472: RestoreArchive: Assertion `mark !=
> ((void *)0)' failed.
>
> To reproduce:
>
> $ createdb test
> $ pg_dump -c --if-exists test (works, dumps empty database)
> $ psql test -c "select lo_create(1);"
> $ pg_dump -c --if-exists test (fails, with the above mentioned assertion)

The code tries to inject an "IF EXISTS" into the already-construct DROP
command, but it doesn't work for large objects, because the deletion
command looks like "SELECT pg_catalog.lo_unlink(xxx)". There is no DROP
there.

I believe we could use "SELECT pg_catalog.lo_unlink(loid) FROM
pg_catalog.pg_largeobject_metadata WHERE loid = xxx".
pg_largeobject_metadata table didn't exist before version 9.0, but we
don't guarantee pg_dump's output to be compatible in that direction
anyway, so I think that's fine.

The quick fix would be to add an exception for blobs, close to where
Assert is. There are a few exceptions there already. A cleaner solution
would be to add a new argument to ArchiveEntry and make the callers
responsible for providing an "DROP IF EXISTS" query, but that's not too
appetizing because for most callers it would be boring boilerplate code.
Perhaps add an argument, but if it's NULL, ArchiveEntry would form the
if-exists query automatically from the DROP query.

- Heikki