| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, Andrew Sullivan <andrew(at)libertyrms(dot)info>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WAL file location |
| Date: | 2002-07-31 17:16:40 |
| Message-ID: | Pine.LNX.4.44.0207310001350.6899-100000@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian writes:
> Thomas, are you going to extend this to locations for any table/index?
> Seems whatever we do for WAL should fix in that scheme.
The trick is that it might not. For relations you simply need a system
table mapping location names to file system locations, and you can add and
remove those mappings at will. Moving an object between locations can be
accomplished by locking the object down, moving the files, updating the
system catalogs, and unlocking.
But the location of the WAL logs, and the commit logs, if anyone is
thinking in that direction, needs to be known to initdb. And if you want
to move them later you'd need to halt the entire system or implement some
smarts for transition. So I'm not sure if these things fit under one
umbrella. It would probably be nice if they did.
--
Peter Eisentraut peter_e(at)gmx(dot)net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Sullivan | 2002-07-31 17:22:20 | Re: Trim the Fat (Was: Re: Open 7.3 items ) |
| Previous Message | Marc G. Fournier | 2002-07-31 17:10:17 | Re: Open 7.3 items |