[yugabyte#12843] YSQL: Fix fclose bug when fopen does not succeed whi…

…le changing oom_score_adj

Summary:
When a `ysqlsh` shell is opened, the postmaster tries to set the oom_score_adj to a specific value. This is accomplished by modifying the oom value in the following file `/proc/[pid]/oom_score_adj`. However, when trying to set this sometimes the postmaster crashes with the following error.

```
ysqlsh: could not connect to server: Connection refused\n\tIs the server running on host "172.151.31.53" and accepting\n\tTCP/IP connections on port 5433?
```

```
warning: File "/home/yugabyte/yb-software/yugabyte-2.15.1.0-b3-centos-x86_64/linuxbrew/lib/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
To enable execution of this file add
	add-auto-load-safe-path /home/yugabyte/yb-software/yugabyte-2.15.1.0-b3-centos-x86_64/linuxbrew/lib/libthread_db.so.1
line to your configuration file "/root/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

warning: File "/home/yugabyte/yb-software/yugabyte-2.15.1.0-b3-centos-x86_64/linuxbrew/lib/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Core was generated by `/home/yugabyte/yb-software/yugabyte-2.15.1.0-b3-centos-x86_64/postgres/bin/post'.
Program terminated with signal 11, Segmentation fault.
#0  _IO_new_fclose (fp=0x0) at iofclose.c:53
53	iofclose.c: No such file or directory.
(gdb) bt
#0  _IO_new_fclose (fp=0x0) at iofclose.c:53
#1  0x00000000008ab237 in BackendStartup (port=0x1b7c1e0) at ../../../../../../src/postgres/src/backend/postmaster/postmaster.c:4255
#2  ServerLoop () at ../../../../../../src/postgres/src/backend/postmaster/postmaster.c:1767
#3  0x00000000008a7d01 in PostmasterMain (argc=<optimized out>, argv=0x1b92780) at ../../../../../../src/postgres/src/backend/postmaster/postmaster.c:1423
#4  0x00000000007c85c3 in PostgresServerProcessMain (argc=23, argv=0x1b92780) at ../../../../../../src/postgres/src/backend/main/main.c:234
#5  0x00000000004f5ae2 in main ()
```

This is due to the fact that fclose tries to close a file descriptor when fopen fails.

The diff that caused this regression is as follows --> https://phabricator.dev.yugabyte.com/D14099

Log message looks like this

```
2022-06-09 19:12:18.685 UTC [17266] LOG:  error 2: No such file or directory, unable to open file /proc/17390/oom_score_adj123
```

Test Plan:
Force fclose to fail by providing a garbage path to the oom_score_adj.
Make sure that after the fix postmaster does not restart or segfault does not happen.

Reviewers: sagarwal, zyu, mihnea, smishra

Reviewed By: zyu, smishra

Subscribers: rthallam, kannan, yql

Differential Revision: https://phabricator.dev.yugabyte.com/D17567

src/postgres/src/backend/postmaster/postmaster.c

@@ -4246,13 +4246,18 @@ BackendStartup(Port *port)
 	 * high oom_score_adj value for the postgres connection.
 	 */
 	if(fPtr == NULL)
+	{
+		int saved_errno = errno;
 		ereport(LOG,
 			(errcode_for_file_access(),
-				errmsg("unable to open file %s", file_name)));
+				errmsg("error %d: %s, unable to open file %s", saved_errno,
+				strerror(saved_errno), file_name)));
+	}
 	else
+	{
 		fputs(YbBackendOomScoreAdj, fPtr);
-
-	fclose(fPtr);
+		fclose(fPtr);
+	}
 #endif
 
 	return STATUS_OK;