| From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
|---|---|
| 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>, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WAL file location |
| Date: | 2002-07-30 22:50:12 |
| Message-ID: | 3D471824.2F229425@fourpalms.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
...
> Thomas, are you going to extend this to locations for any table/index?
> Seems whatever we do for WAL should fix in that scheme.
Yes, the longer-term goal is enabling table/index-specific locations.
I'm not certain whether WAL can use *exactly* the same mechanism, since
1) the location for WAL is (currently) not particularly related to the
directory structure for other resources such as databases and tables.
2) postmaster may want to access WAL-kinds of information before having
access to the global database info.
I'll have a question for -hackers very soon on why I seem to be having
trouble adding a column to pg_class (which will end up being an OID for
the internally supported view of what "locations" are). I'm getting
access violations after adding a column which is initialized to zero and
never explicitly used in the code...
- Thomas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-07-30 22:51:07 | Re: DROP COLUMN round 4 |
| Previous Message | Bruce Momjian | 2002-07-30 22:33:37 | Re: [GENERAL] Stats Collector |