Nasty resource-leak problem in sort code

If a CREATE INDEX fails, the backend returns to the main loop without
having closed the temporary files that are created for sorting.
An easy example that provokes this is

create table titles (adate date);
insert into titles values ('today');
create index titles_f_ind on titles (date(adate) date_ops);
ERROR: SQL-language function not supported in this context.

after which the backend has about a dozen more open files than it had
before.

If you then try to create another index, you will crash for
lack of free file descriptors (unless your kernel has a
higher-than-usual open-files-per-process limit). In any case, the
sort temp files will never get deleted from your database directory.

Offhand I'm not sure how to fix this. The system knows about releasing
memory after an elog(ERROR), but does it have any provisions for
releasing other kinds of resources? I suspect we need something
analogous to the on_shmem_exit() callback-registration list, but I
don't know whether it already exists. Comments?

regards, tom lane