> Thanks guys...
>
> I was able to do employ the symbolic link trick to get my old
> filesystems set up for use with 7.1's way of doing things and am glad
> I don't /really/ need to remember what the heck is that mounted on
> /opt/postgresql/data/base/19162, etc..
>
> This would have been less o
Thanks guys...
I was able to do employ the symbolic link trick to get my old
filesystems set up for use with 7.1's way of doing things and am glad
I don't /really/ need to remember what the heck is that mounted on
/opt/postgresql/data/base/19162, etc..
This would have been less of a PITB if it h
Stephan Szabo <[EMAIL PROTECTED]> writes:
> The reason tables got renamed into numbers was due to rollbacks of
> drops or drops followed by creates in the same transaction.
That was one reason, but an equally big reason was to have a compact way
of referencing tables in the WAL logs, such that a
/contrib/oid2name does the job.
> Back in August there was a posting regarding the names of database
> subdirectories. Under PostgreSQL 7.0.x the subdirectory names were
> the name of the database. Made a lot of sense. Now under V7.1.x
> we're supposed to somehow know that some numbered subd
On 16 Oct 2001, Rick Turner wrote:
> Is there some way to revert back to the V7.0.x way of naming things?
Probably not.
> Or is there some workaround to allow one to reasonably manage large
> databases under V7.1.x?
In contrib there's a utility oid2name which will give the number/name
mappings
Back in August there was a posting regarding the names of database
subdirectories. Under PostgreSQL 7.0.x the subdirectory names were
the name of the database. Made a lot of sense. Now under V7.1.x
we're supposed to somehow know that some numbered subdirectory happens
to be the location of a ce
