could not read symbolic link error while executing pg_start_backup function in Postgresql DB In order to take data folder backup in postgres 9.6 database executed the order of functions for backup,
while executing pg_start_backup function produced warning :  could not read symbolic link for pg_tblspace Invalid argument
test=# checkpoint; 
       CHECKPOINT

test=# select pg_switch_xlog();
 pg_switch_xlog
----------------
 5/DF000238
(1 row)
**
test=# select pg_start_backup(to_char(now(), 'yyyy-mm-dd hh24:mi:ss'));
WARNING:  could not read symbolic link &quot;pg_tblspc/oth_data_tbs&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/str_index&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/tbs_temp_default&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/oth_indx_tbs&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/str_data_ids&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/tbs_default&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/top_indx_tbs&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/rpt_data_tbs&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/str_data_h_index&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/rpt_indx_tbs&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/str_data&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/str_data_h&quot;: Invalid argument
WARNING:  could not read symbolic link &quot;pg_tblspc/top_data_tbs&quot;: Invalid argument
 pg_start_backup
-----------------
 5/E0000028
(1 row)
Somebody who was not the PostgreSQL operating system user (normally named postgres) messed with your data directory.
This directory should only contain symbolic links whose names are numbers (the object IDs of tablespaces), and those symbolic links (and the directories that they point to) must belong to postgres.
Put the person who created these files on the pillory (but that won't solve your problem).
One should never manually mess with the PostgreSQL data directory, so the safe way to recover would be to create a new, clean PostgreSQL cluster with initdb, use pg_dumpall to export the data from the one that was messed with and import the data into the new cluster. Then delete the cluster that was messed up.
If you know what you are doing, you might also be able to recover by deleting the offending files – but who knows what else was done to this data directory.