From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Check return value of pclose() correctly |
Date: | 2022-10-31 08:12:53 |
Message-ID: | 8cd9fb02-bc26-65f1-a809-b1cb360eef73@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I noticed that some (not all) callers didn't check the return value of
pclose() or ClosePipeStream() correctly. Either they didn't check it at
all or they treated it like the return of fclose(). Here is a patch
with fixes.
(A failure to run the command issued by popen() is usually reported via
the pclose() status, so while you can often get away with not checking
fclose() or close(), checking pclose() is more often useful.)
There are some places where the return value is apparently intentionally
ignored, such as in error recovery paths, or psql ignoring a failure to
launch the pager. (The intention can usually be inferred by the kind of
error checking attached to the corresponding popen() call.) But there
are a few places in psql that I'm suspicious about that I have marked,
but need to think about further.
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Check-return-value-of-pclose-correctly.patch | text/plain | 7.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2022-10-31 08:41:47 | Re: heavily contended lwlocks with long wait queues scale badly |
Previous Message | Peter Smith | 2022-10-31 08:07:37 | Re: Support logical replication of DDLs |