Re: Big 7.1 open items - Mailing list pgsql-hackers

> Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026