I have reproduced this problem in current CVS.
---
Michael Fuhr wrote:
> PostgreSQL version: 8.0.0beta1
> Operating system : Solaris 9
>
> Backups created by pg_dump/pg_dumpall don't set the ownership of
> implicitly-creat
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
> >>SE
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 understan
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 func
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
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 Mo
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
---(end of broadcast)---
TIP 7: don't forget to increase your free space
Dear Tom,
>
>
> "Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes:
> > Besides a no optimization compilation of 7.4.3, what else
> > would you recommend to explore this problem further? Thanks. --Bob
>
> I really haven't the foggiest where to look :-( I don't actually
> believe that it's a
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 th
Josh Berkus <[EMAIL PROTECTED]> writes:
> UPDATE: Turns out the garbage characters were actually in the field names
> themselves. Somehow a previous bad connection caused line breaks to get
> replaced with unicode garbage when I created the table. It seems like, in
> PSQL, the use of non-AS
Josh Berkus <[EMAIL PROTECTED]> writes:
> When I do a \d on one table in PSQL, I get the following:
> Table "public.elbs_timekeep"
> Column |Type | Modifiers
> ---+-+---
> 240240240240240240240
Folks,
> Bug summary: PSQL's \d table displaying garbage characters for one table.
> Severity: Annoyance
> Reproducability: Poor
> Version: 7.4.3 on the client, 7.4.1 on the server. Both compiled from
> source.
> Platform: SuSE Linux 9.1, Linux Kernel 2.6.7 (client), RH Linux 8.0 on
> server. C
Bug summary: PSQL's \d table displaying garbage characters for one table.
Severity: Annoyance
Reproducability: Poor
Version: 7.4.3 on the client, 7.4.1 on the server. Both compiled from
source.
Platform: SuSE Linux 9.1, Linux Kernel 2.6.7 (client), RH Linux 8.0 on server.
Connection bt
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> Database owner should have implicit control over public schema
> and over all objects in his database as well.
The former is debatable, the latter simply wrong. Make the DB owner a
superuser if you want him to have absolute privileges.
There h
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> revoke create on schema do not issues an error when user has no access
> privileges to do that.
> dbmail=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
> REVOKE
> Grant works as expected
> dbmail=> GRANT USAGE on SCHEMA public to public;
> ERROR
The following bug has been logged online:
Bug reference: 1222
Logged by: radim kolar
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.1
Operating system: freebsd
Description:database owner should have implicit control over public
db schema
Details:
Pr
The following bug has been logged online:
Bug reference: 1221
Logged by: radim kolar
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.1
Operating system: freebsd
Description:revoke on schema do not return error on failure
Details:
Problem 1
pgsql 7.4.1
"Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes:
> Besides a no optimization compilation of 7.4.3, what else
> would you recommend to explore this problem further? Thanks. --Bob
I really haven't the foggiest where to look :-( I don't actually
believe that it's a spinlock problem; that wou
Dear Tom,
Besides a no optimization compilation of 7.4.3, what else
would you recommend to explore this problem further? Thanks. --Bob
Tom Lane writes:
>
>
> "Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes:
> > Question: were there any significant changes made to the
> > buffer man
Graeme Hinchliffe <[EMAIL PROTECTED]> writes:
> It didn't dump core for me, it was quite happy :) I would guess because
> I have a function called trigf loaded in memory?
No; the lack of a V1 macro referencing testtrig would definitely cause
the backend to call testtrig using V0 conventions, in o
On Tue, 2004-08-17 at 17:27, Tom Lane wrote:
> Graeme Hinchliffe <[EMAIL PROTECTED]> writes:
> > I have written a trigger in C, and during the course of this I
> > discovered that the LOAD command in psql wasn't updating the object when
> > I made a change and recompiled.
> > As requested
Graeme Hinchliffe <[EMAIL PROTECTED]> writes:
> I have written a trigger in C, and during the course of this I
> discovered that the LOAD command in psql wasn't updating the object when
> I made a change and recompiled.
> As requested by Tom, here is an example of this behaviour. I h
Hiya
I have written a trigger in C, and during the course of this I
discovered that the LOAD command in psql wasn't updating the object when
I made a change and recompiled.
As requested by Tom, here is an example of this behaviour. I have just
added this as a function as it perf
Adam Sah <[EMAIL PROTECTED]> writes:
> well, that's fine I suppose -- but then why does it work the other way
> for DROP TABLE?
It doesn't work the other way for DROP. The error you get in the DROP
case is a low-level error that really should never be seen by users.
But I see that as a proble
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> ==> yikes! in window 2, it should have errored.
Why are you of the opinion that this is a bug? The catalog lookup has
to happen before the second xact can hope to obtain a lock on the table,
no?
regards, tom lane
The following bug has been logged online:
Bug reference: 1220
Logged by: adam sah
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.3
Operating system: linux (suse 9.1 professional)
Description:"alter table rename to" inside a transaction violates
ACID ord
The following bug has been logged online:
Bug reference: 1219
Logged by: Fabien COELHO
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 Beta
Operating system: Linux debian
Description:pgxs does not work fully
Details:
When testing the pgxs framework wit
27 matches
Mail list logo
