Re: pg_dump bug in 9.4beta2 and HEAD

On 15 August 2014 16:31, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

> Hi
>
>
> 2014-08-14 9:03 GMT+02:00 Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>:
>
>> 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.
>>
>
> I am sending two patches
>
> first is fast fix
>
> second fix is implementation of Heikki' idea.
>

I'm guessing this issue is still unresolved? It would be nice to get this
off the open items list.

Thom