Re: Big 7.1 open items

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > That was my point --- that in doing this change, we are taking on more
> > TODO items, that may detract from our main TODO items.
>
> True, but they are also TODO items that could be handled by people other
> than the inner circle of key developers. The actual rejiggering of
> table-to-filename mapping is going to have to be done by one of the
> small number of people who are fully up to speed on backend internals.
> But we've got a lot more folks who would be able (and, hopefully,
> willing) to design and code whatever tools are needed to make the
> dbadmin's job easier in the face of the new filesystem layout. I'd
> rather not expend a lot of core time to avoid needing those tools,
> especially when I feel the old approach is fatally flawed anyway.

Yes, it is clearly fatally flawed. I agree.

> > Even gdb shows us the filename/tablename in backtraces. We are never
> > going to be able to reproduce that.
>
> Backtraces from *what*, exactly? 99% of the backend is still going
> to be dealing with the same data as ever. It might be that poking
> around in fd.c will be a little harder, but considering that fd.c
> doesn't really know or care what the files it's manipulating are
> anyway, I'm not convinced that this is a real issue.

I was just throwing gdb out as an example. The bigger ones are ls,
lsof/fstat, and tar.

> > I guess I don't consider table schema commands inside transactions and
> > such to be as big an items as the utility features we will need to
> > build.
>
> You've *got* to be kidding. We're constantly seeing complaints about
> the fact that rolling back DROP or RENAME TABLE fails --- and worse,
> leaves the table in a corrupted/inconsistent state. As far as I can
> tell, that's one of the worst robustness problems we've got left to
> fix. This is a big deal IMHO, and I want it to be fixed and fixed
> right. I don't see how to fix it right if we try to keep physical
> filenames tied to logical tablenames.
>
> Moreover, that restriction will continue to hurt us if we try to
> preserve it while implementing tablespaces, ANSI schemas, etc.
>

Well, we did have someone do a test implementation of oid file names,
and their report was that is looked pretty ugly. However, if people are
convinced it has to be done, we can get started. I guess I was waiting
for Vadim's storage manager, where the whole idea of separate files is
going to go away anyway, I suspect. We would then have to re-write all
our admin tools for the new format.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026