Tom Lane wrote:
>Thomas Swan <tswan@idigx.com> writes:
>
>
>>Bruce Momjian wrote:
>>
>>
>>>The advantage of symlinks is that an administrator could see how things
>>>are laid out from the command line.
>>>
>>>
>>>
>>That's a poor reason to require symlinks. The administrator can just as
>>easily open up psql and query pg_tablespace to see that same
>>information.
>>
>>
>
>Something to keep in mind here is that one of the times you would most
>likely need that information is when the database is broken and you
>*can't* simply "open up psql" and inspect system catalogs. I like the
>fact that a symlink implementation can be inspected without depending on
>a working database.
>
>
>
That's a sufficient argument, to allow for it. Recoverability would be
one reason.
>If we were going to build a non-symlink implementation, I'd want the
>highlevel-to-lowlevel data transfer to take the form of a flat ASCII
>file that could be inspected by hand, rather than some hidden in-memory
>datastructure. But given the previous discussion in this thread,
>I cannot see any strong reason not to rely on symlinks for the purpose.
>We are not in the business of building replacements for OS features.
>
>
>
I do like the flat file output at least for a record of what went
where. Regardless of whether or not symlinks are used, the admin would
need to know what directories/files/filesystems are to be backed up.
I am concerned as to what extent different filesystems do when you back
the directories up. Would NTFS containing symlinks be able to be
backed up with a tar/zip command, or is something more elaborate needed? In the past, before upgrading, I have had to
tarthe pgdata directory
with the postmaster shutdown to insure a quick restoration of the
database in case an upgrade didn't proceed uneventfully. Also, in the
event of a major version upgrade the restored information may or may not
proceed uneventfully. I just wanted to point out something I thought
might be an issue further down the road.
Perhaps the system catalog / flat file approach would be a more solid
approach, both of which would not involve replacing or duplicating OS
features.