Thread: 8.0.0 beta 1, contrib/dbsize, GetDatabasePath wrong
dbsize.c was not updated to use the new tablespace-aware function.
I am not well versed enough with the new function to know if "GLOBAL..."
was the correct default for what dbsize is trying to do. I just thought
you guys might want to know.
Thanks for the WORLD'S GREATEST OpenSource DB!
-- /v\atthew
--- postgresql-8.0.0beta1/contrib/dbsize/dbsize.c~ 2004-02-23 18:03:10.000000000 -0500
+++ postgresql-8.0.0beta1/contrib/dbsize/dbsize.c 2004-08-11 17:08:44.000000000 -0400
@@ -7,6 +7,7 @@
#include "access/heapam.h"
#include "catalog/catalog.h"
#include "catalog/namespace.h"
+#include "catalog/pg_tablespace.h"
#include "commands/dbcommands.h"
#include "fmgr.h"
#include "storage/fd.h"
@@ -55,7 +56,7 @@
(errcode(ERRCODE_UNDEFINED_DATABASE),
errmsg("database \"%s\" does not exist", NameStr(*dbname))));
- dbpath = GetDatabasePath(dbid);
+ dbpath = GetDatabasePath(dbid, GLOBALTABLESPACE_OID);
dirdesc = AllocateDir(dbpath);
if (!dirdesc)
This has been corrected in current CVS.
---------------------------------------------------------------------------
Matthew L Daniel wrote:
> dbsize.c was not updated to use the new tablespace-aware function.
>
> I am not well versed enough with the new function to know if "GLOBAL..."
> was the correct default for what dbsize is trying to do. I just thought
> you guys might want to know.
>
> Thanks for the WORLD'S GREATEST OpenSource DB!
> -- /v\atthew
>
> --- postgresql-8.0.0beta1/contrib/dbsize/dbsize.c~ 2004-02-23 18:03:10.000000000 -0500
> +++ postgresql-8.0.0beta1/contrib/dbsize/dbsize.c 2004-08-11 17:08:44.000000000 -0400
> @@ -7,6 +7,7 @@
> #include "access/heapam.h"
> #include "catalog/catalog.h"
> #include "catalog/namespace.h"
> +#include "catalog/pg_tablespace.h"
> #include "commands/dbcommands.h"
> #include "fmgr.h"
> #include "storage/fd.h"
> @@ -55,7 +56,7 @@
> (errcode(ERRCODE_UNDEFINED_DATABASE),
> errmsg("database \"%s\" does not exist", NameStr(*dbname))));
>
> - dbpath = GetDatabasePath(dbid);
> + dbpath = GetDatabasePath(dbid, GLOBALTABLESPACE_OID);
>
> dirdesc = AllocateDir(dbpath);
> if (!dirdesc)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > This has been corrected in current CVS. But it still fails for tables in tablespaces. That's why I posted all new functions a while ago. Regards, Andreas
Andreas Pflug wrote: > Bruce Momjian wrote: > > This has been corrected in current CVS. > > But it still fails for tables in tablespaces. That's why I posted all > new functions a while ago. Yes, you posted the functions, but I don't understand how to integrate that into dbsize. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Andreas Pflug wrote: > >>Bruce Momjian wrote: >> >>>This has been corrected in current CVS. >> >>But it still fails for tables in tablespaces. That's why I posted all >>new functions a while ago. > > > Yes, you posted the functions, but I don't understand how to integrate > that into dbsize. What's the problem? The usage of oids instead of name? The current dbsize functions are not easy to integrate in queries as executed from admin tools, as SELECT *, pg_relation_size(oid) FROM pg_class Regards, Andreas
Andreas Pflug wrote: > Bruce Momjian wrote: > > Andreas Pflug wrote: > > > >>Bruce Momjian wrote: > >> > >>>This has been corrected in current CVS. > >> > >>But it still fails for tables in tablespaces. That's why I posted all > >>new functions a while ago. > > > > > > Yes, you posted the functions, but I don't understand how to integrate > > that into dbsize. > > What's the problem? The usage of oids instead of name? The current > dbsize functions are not easy to integrate in queries as executed from > admin tools, as > SELECT *, pg_relation_size(oid) FROM pg_class I basically didn't understand how it fit in with dbsize, and being in beta, I didn't have time to fiddle with it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Andreas Pflug wrote: > >>Bruce Momjian wrote: >> >>>Andreas Pflug wrote: >>> >>> >>>>Bruce Momjian wrote: >>>> >>>> >>>>>This has been corrected in current CVS. >>>> >>>>But it still fails for tables in tablespaces. That's why I posted all >>>>new functions a while ago. >>> >>> >>>Yes, you posted the functions, but I don't understand how to integrate >>>that into dbsize. >> >>What's the problem? The usage of oids instead of name? The current >>dbsize functions are not easy to integrate in queries as executed from >>admin tools, as >>SELECT *, pg_relation_size(oid) FROM pg_class > > > I basically didn't understand how it fit in with dbsize, and being in > beta, I didn't have time to fiddle with it. OK what can we do? I could create something including my functions, and additionally the old dbsize function api reusing that code if still needed. Regards, Andreas
Andreas Pflug wrote: > >>>Yes, you posted the functions, but I don't understand how to integrate > >>>that into dbsize. > >> > >>What's the problem? The usage of oids instead of name? The current > >>dbsize functions are not easy to integrate in queries as executed from > >>admin tools, as > >>SELECT *, pg_relation_size(oid) FROM pg_class > > > > > > I basically didn't understand how it fit in with dbsize, and being in > > beta, I didn't have time to fiddle with it. > > OK what can we do? > I could create something including my functions, and additionally the > old dbsize function api reusing that code if still needed. Well, if dbsize doesn't currently work properly, we need to fix it before final release so any improvements would be good. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073