Snapshot leak warning with lo_export in subtransaction

Hi,

Andrew B reported this warning off-list:

postgres=# SELECT lo_create(41174);
  lo_create
-----------
      41174
(1 row)

postgres=# DO $$
BEGIN
   PERFORM lo_export(41174, '/invalid/path');
EXCEPTION
   WHEN others THEN RAISE NOTICE 'error: %', sqlerrm;
END;
$$;
NOTICE:  error: could not create server file "/invalid/path": No such 
file or directory
WARNING:  Snapshot reference leak: Snapshot 0x5634afd61cb8 still referenced
DO

The code in be_lo_export does this:

> 
> 	CreateFSContext();
> 
> 	/*
> 	 * open the inversion object (no need to test for failure)
> 	 */
> 	lobj = inv_open(lobjId, INV_READ, fscxt);
> 
> 	/*
> 	 * open the file to be written to
> 	 *
> 	...

And inv_open does this:

>     /* OK to create a descriptor */
>     retval = (LargeObjectDesc *) MemoryContextAlloc(mcxt,
> 													sizeof(LargeObjectDesc));
>     retval->id = lobjId;
>     retval->subid = GetCurrentSubTransactionId();
>     retval->offset = 0;
>     retval->flags = descflags;
> 
>     /*
>      * We must register the snapshot in TopTransaction's resowner, because it
>      * must stay alive until the LO is closed rather than until the current
>      * portal shuts down.  Do this last to avoid uselessly leaking the
>      * snapshot if an error is thrown above.
>      */
>     if (snapshot)
>         snapshot = RegisterSnapshotOnOwner(snapshot,
>                                            TopTransactionResourceOwner);
>     retval->snapshot = snapshot;

So this is pretty clear-cut: if opening the file fails, the snapshot 
reference is leaked in TopTransactionResourceOwner. Similarly, the 
LargeObjectDesc is leaked in 'fscxt', which is a subcontext of 
TopMemoryContext, but that doesn't generate a warning.

I propose the attached patch to fix that. With the patch, we use 
CurrentMemoryContext and no resource owner for transient 
LargeObjectDescs that are opened and closed in the same function call.

This should be backpatched to all supported versions. This adds an 
argument to 'inv_open' function, but I don't think there are extensions 
that use the inv_*() functions directly. inv_api.c relies on 
close_lo_relation() being called at the end of transaction, so I think 
an extension would find it hard to use those functions correctly, anyway.

- Heikki