On Sun, 29 Apr 2001, Bruce Momjian wrote:
> > I can even think of a situation, as unlikely as it can be, where this
> > could happen ... run out of inodes on the file system ... last inode used
> > by the table, no inode to stick the symlink onto ...
>
>
> If you run out of inodes, you are going to have much bigger problems
> than symlinks. Sort file creation would fail too.
>
> >
> > its a remote situation, but I've personally had it happen ...
> >
> > I'd personally prefer to see some text file created in the database
> > directory itself that contains the mappings ... so that each time there is
> > a change, it just redumps that data to the dext file ... less to maintain
> > overall ...
>
> Yes, I like that idea, but the problem is that it is hard to update just
> one table in the file. You sort of have to update the entire file each
> time a table changes. That is why I liked symlinks because they are
> per-table, but you are right that the symlink creation could fail
> because the new table file was never created or something, leaving the
> symlink pointing to nothing. Not sure how to address this. Is there a
> way to update a flat file when a single table changes?
Why not just dump the whole file? That way, if a previosu dump failed for
whatever reason, the new dump would correct that omission ...
Then again, why not some sort of 'lsdb' command that looks at where it is
and gives you info as appropriate?
if in data/base, then do a connect to template1 using postgres so that you
can dump and parse the raw data from pg_database ... if in a directory,
you should be able to connect to that database in a similar way to grab
the contents of pg_class ...
no server would need to be running for this to work, and if it was
readonly, it should be workable if a server is running, no?
