Tom Lane wrote: >Thomas Swan <[EMAIL PROTECTED]> 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 tar the 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. ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
