Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > This might seem a bit silly, but is there any chance we could add a
> > comment at the end of pg_dump text output that says '-- End of dump'?
>
> Sure --- while you're at it, put a "beginning of dump" at the start.
>
> Is
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> This might seem a bit silly, but is there any chance we could add a
> comment at the end of pg_dump text output that says '-- End of dump'?
Sure --- while you're at it, put a "beginning of dump" at the start.
Is it worth adding the database n
Right off the top of my head, it almost sounds like a file is being
held
open after its been deleted ... we went through that with the new
aspseek
a little while back, where 170gig just disappeared overnight, but du
showed hardly any disk space being used ...
Does restarting the database server
'k, *shouldn't* require a reboot ... but, what I'd try is to do what
you've thought .. disable softupdates and see if you can recreate ... if
killing off the process auto-reclaims the space fast, then it sounds like
a stale file being held open (log file being rotated improperly?) ...
Log file's on
On Tue, 30 Mar 2004, Christopher Kings-Lynne wrote:
> > Right off the top of my head, it almost sounds like a file is being held
> > open after its been deleted ... we went through that with the new aspseek
> > a little while back, where 170gig just disappeared overnight, but du
> > showed hardly
This might seem a bit silly, but is there any chance we could add a
comment at the end of pg_dump text output that says '-- End of dump'?
Would make it useful for checking that you actually have a complete dump...
Chris
---(end of broadcast)---
TI
Right off the top of my head, it almost sounds like a file is being held
open after its been deleted ... we went through that with the new aspseek
a little while back, where 170gig just disappeared overnight, but du
showed hardly any disk space being used ...
Does restarting the database server (no
On Tue, 30 Mar 2004, Christopher Kings-Lynne wrote:
> > what version of FreeBSD are you using? I'm running 4.9-STABLE with
> > softupdates on my db file system ...
>
> FreeBSD goddard.calorieking.com 4.9-STABLE FreeBSD 4.9-STABLE #2: Mon
> Jan 26 23:23:17 EST 2004
> [EMAIL PROTECTED]:/usr/obj/usr
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> How about we allow changing owner of lanugages so I can fix this problem?
> Is it safe for me to just update the catalogs?
Sure.
regards, tom lane
---(end of broadcast)--
what version of FreeBSD are you using? I'm running 4.9-STABLE with
softupdates on my db file system ...
On Tue, 30 Mar 2004, Christopher Kings-Lynne wrote:
> Hi guys,
>
> Does anyone else have this problem?
>
> We have softupdates turned on on our data dir. (Soon to be turned off
> due to thes
what version of FreeBSD are you using? I'm running 4.9-STABLE with
softupdates on my db file system ...
FreeBSD goddard.calorieking.com 4.9-STABLE FreeBSD 4.9-STABLE #2: Mon
Jan 26 23:23:17 EST 2004
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GODDARD i386
We're not 100% sure it's softupdates, but w
If you do this sequence of events, you get a failure to restore:
This is not a pg_dump bug.
Possibly ALTER USER should refuse to drop someone's superuserness if
there is content in the database that depends on his superuserness,
but I don't see how to enforce that.
How about we allow changing owne
Hi guys,
Does anyone else have this problem?
We have softupdates turned on on our data dir. (Soon to be turned off
due to these issues).
The partition is 12GB. 'df' says that we're using 12 and a bit GB but
'du' says we're using 2GB (which we really are).
It seems that perhaps softupdates i
On Mon, Mar 29, 2004 at 03:55:22PM -0800, elein wrote:
> Does anyone have any tools or hints? I can
> determine a lot by just looking at them, but
> hints would help.
> If necessary, I could write a little C program
> to extract the headers if that is what is
> necessary.
Try RedHat's pg_filedu
RedHat with PG 7.3.2
I'm recovering a harddrive failure where all
of the database files were thrown into one
directory. I'm trying to sort out which ones
go with what. (Stop laughing.)
I've identified template1 and template0 files,
but I don't need to recover those...
The rest of the files see
Title: Message
E:\postgresql-snapshot\src>nmake /f
win32.mak
Microsoft (R) Program Maintenance Utility Version
7.10.3077Copyright (C) Microsoft Corporation. All rights
reserved.
cd
include if not exist pg_config.h
copy pg_config.h.win32 pg_config.h
cd .. c
Greg Stark <[EMAIL PROTECTED]> writes:
> If I understand what you're talking about, you would be allowed to
> CREATE TYPE a composite type, like say, "address" and then use that as
> a datatype all over your database? And then if you find "address"
> needs a new field you can add it to the type and
On Mon, 29 Mar 2004 08:50:42 -0800 (PST), [EMAIL PROTECTED] wrote:
>In this case, I've only done 1 per each combination. I've found the
>results for this test to be reproduceable.
Pardon?
>>>Linux-2.6.3, LVM2 Stripe Width
>>>BLCKSZ
>>>(going down)16 KB 32 KB 64 KB
On 30 Mar, Manfred Koizar wrote:
> On Mon, 29 Mar 2004 08:50:42 -0800 (PST), [EMAIL PROTECTED] wrote:
>>In this case, I've only done 1 per each combination. I've found the
>>results for this test to be reproduceable.
>
> Pardon?
I haven't repeated any runs for each combination, e.g. 1 test with
Tom Lane <[EMAIL PROTECTED]> writes:
> We have a number of issues revolving around the fact that composite types
> (row types) aren't first-class objects. I think it's past time to fix
> that.
...
> Only named composite types, not RECORD, will be allowed to be used as
> table column types.
On Mon, 29 Mar 2004, Andrew Dunstan wrote:
> It's that "probably" that niggles a bit. I don't know what usage
> patterns other people have, and since my typical use is exactly *one*
> user other than the owner/dba, and all access is mediated by my
> middleware, none of this affects me. ISTM we nee
Fabien COELHO <[EMAIL PROTECTED]> writes:
> I'm wondering for the rationnal of the types used in various tables in
> pg_catalog (v 7.4.2) so as to represent the very same thing:
History and backwards compatibility, mostly.
>From the standpoint of the backend I don't think there is any
fundamental
On Mon, 29 Mar 2004, Marc G. Fournier wrote:
> On Mon, 29 Mar 2004, Dave Page wrote:
>
> > It's rumoured that Euler Taveira de Oliveira once said:
> > > Hi Christopher,
> > >
> > >> > "The \l command should only list databases that the current user is
> > >> > authorized for, the \du command shou
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I just played around briefly with removing *all* public access to a
couple of catalog tables - pg_class and pg_attrdef. Obviously this
breaks things like \d and friends. I'm not sure how much else it might
break -
pg_dump, for
We have a number of issues revolving around the fact that composite types
(row types) aren't first-class objects. I think it's past time to fix
that. Here are some notes about doing it. I am not sure all these ideas
are fully-baked ... comments appreciated.
When represented as a Datum, the form
It's rumoured that Marc G. Fournier once said:
> On Mon, 29 Mar 2004, Dave Page wrote:
>
> k, but what I'm suggesting shouldn't prevent that, should it? They
> should only be able to see those resources that they have permissions
> to see, not all of them ... no?
Wouldn't that require per-row per
On Mon, 29 Mar 2004, Dave Page wrote:
> It's rumoured that Euler Taveira de Oliveira once said:
> > Hi Christopher,
> >
> >> > "The \l command should only list databases that the current user is
> >> > authorized for, the \du command should only list users authorized
> >> > for the current databas
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I just played around briefly with removing *all* public access to a
> couple of catalog tables - pg_class and pg_attrdef. Obviously this
> breaks things like \d and friends. I'm not sure how much else it might
> break -
pg_dump, for starters ...
I'
It's rumoured that Euler Taveira de Oliveira once said:
> Hi Christopher,
>
>> > "The \l command should only list databases that the current user is
>> > authorized for, the \du command should only list users authorized
>> > for the current database (and perhaps only superusers should get
>> > even
On Mon, 29 Mar 2004, Andrew Dunstan wrote:
> My previous answer to this question has been "use a middleware layer
> that exposes just the operations you want exposed". But this issue has
> come up a few times so maybe some more thought is needed. Of course, we
> are only talking about metadata her
Hi Christopher,
> > "The \l command should only list databases that the current user is
> > authorized for, the \du command should only list users authorized for the
> > current database (and perhaps only superusers should get even that much
> > information), etc. Perhaps it is possible to set PG
Christopher Kings-Lynne wrote:
"The \l command should only list databases that the current user is
authorized for, the \du command should only list users authorized for
the
current database (and perhaps only superusers should get even that much
information), etc. Perhaps it is possible to set PG
Hi Manfred,
On 27 Mar, Manfred Koizar wrote:
> Mark,
>
> how often did you run your tests? Are the results reproduceable?
In this case, I've only done 1 per each combination. I've found the
results for this test to be reproduceable.
> On Fri, 26 Mar 2004 14:00:01 -0800 (PST), [EMAIL PROTECTE
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> I suggest to replace bytea by struct
> typedef struct {
> int32 n; /* number of GISTENTRY */
> GISTENTRY vector[1];
> } GistEntryVector;
Yes, I was thinking the same thing.
> #define GEVHDRSZ (MAXALIGN(sizeof(int32))
> so, allocation
I suppose that a correct fix involves doing MAXALIGN(VARDATA(evec)),
but I do not know what places need to change to support this.
Its only union and picksplit user-defined methods in contrib modules.
If I recall correctly, we decided to go with the present hack because we
found the problem jus
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> If you do this sequence of events, you get a failure to restore:
This is not a pg_dump bug.
Possibly ALTER USER should refuse to drop someone's superuserness if
there is content in the database that depends on his superuserness,
but I don't se
Chris Bowlby <[EMAIL PROTECTED]> writes:
> I need to know how PostgreSQL makes it's
> choices on what rows to sample.
Randomly.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unr
If you do this sequence of events, you get a failure to restore:
1. As superuser, do this:
test2=# CREATE FUNCTION plpgsql_call_handler () RETURNS language_handler
test2-# AS '$libdir/plpgsql.so', 'plpgsql_call_handler'
test2-# LANGUAGE c;
CREATE FUNCTION
2. Drop privs.
test2=# alter use
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I agree we don't want anything that is O(high), but I was thinking of
> something that would be more agressive than 1%, which works well for
> lots of self joins, but I am not sure how well for other cases.
That assumption is without foundation. The pa
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> But all of this is strage for me, because we already faced to problem with
> 8-bytes strict aliasing in GiST code, and we had resolved problem on Sun and
> Alpha boxes. What was it changed?
It looks to me like the HP compiler is expecting that the cons
Hi All,
I'm trying to gain a good understanding of how PostgreSQL determines
what to sample when doing a stats analysis on a table. Using PostgreSQL
7.4's pg_stats table I can get a good overall understanding of
variations in the table, but I need to know how PostgreSQL makes it's
choices on wha
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Right. There are potentially some ranges of LIMIT for which it could
> >> win, I believe.
>
> > What if we take the total cost and divide it by the number of rows returned ---
> > then we have a per-row cost for
Tom Lane wrote:
I've just found out the hard way that Postgres doesn't even build on
recent gcc releases for 64-bit HPPA. The reason is that the compiler
now notices and complains about alignment errors that will lead to
core dump at runtime, and GIST has got some. The particular code that
fails
Hello Andreas,
> No problem, as long as referencing data is contained in the advice
> tables (i.e. referencing the 'offending' object), not just text so the
> advice can be shown as attribute of each object.
What do you mean by 'referencing data'?
Things like oid attributes referencing pg_class
He brings up two good points here ... first one being, where exactly, in
the docs, do we mention getting the OID in either pg_database, or
pg_class, to determine a directory, or file name? I just checked the
pg_database catalog page, and it doesn't ...
Second point, of course being ... how do yo
45 matches
Mail list logo