Awesome Tom :)
I'm glad I happened to have all the data required on hand to fully analyze
the problem. Let's hope this make this failure condition go away for all
future postgresql users :)
Chris
On Mon, 26 Jan 2004, Tom Lane wrote:
Okay ... Chris was kind enough to let me examine the WAL
OK, I will attempt to draw together this information as currently
stands. If this makes any sense, we can discuss what the
requirement/process is for regular maintenance (daily/weekly/monthly
etc).
Understood to mean changes in next release (current progress) - items
that have been
Jan,
Happy to continue the discussion...though without changing my suggestion
that we defer any further more specialised improvements for now.
Jan Wieck replied to...
Simon Riggs wrote:
If we know ahead of time that a large scan is going to have this
effect,
why wait for the ARC to play
Hi,
I've upgraded my production system to 741 yesterday, and just discovered
this log message: statistic buffer is full.
What does it mean? filing up too fast, no more stats, need to grow?
What should I do?
Also, Many thanks for this great versionn of PostgreSQL, keep going...
Revgards
--
I notice that pg_dump is still dumping CHECK constraints with the table,
rather than at the very end, as it does with all the other constraints.
As discussed in bug report #787, at
http://archives.postgresql.org/pgsql-bugs/2002-09/msg00278.php
this breaks your restore if your CHECK
Michael Brusser [EMAIL PROTECTED] writes:
Looking at the database (v.7.3.2 on Solaris) I'm puzzled with this:
syncdb=# \d
ERROR: Cache lookup failed for relation 17075
You might try reindexing the indexes on pg_class (particularly the one
on pg_class.oid). See the REINDEX man page for
Simon Riggs wrote:
Jan,
[...]
My thoughts are about multiple concurrent accesses, specifically FTS on
large tables, rather than sequential ones.
Single or multiple backends is irrelevant here because a data block only
exists once, and therefore we have only one shared buffer cache.
Buffers
[EMAIL PROTECTED] writes:
I've upgraded my production system to 741 yesterday, and just discovered
this log message: statistic buffer is full.
If you see this a lot, it might be worth increasing PGSTAT_RECVBUFFERSZ.
regards, tom lane
---(end of
Rod Taylor wrote:
If that was IS, then foo(x is 13) makes sense.
I like that syntax. For example
select interest(amount is 500.00, rate is 1.3)
is very readable, yet brief.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Jan,
I think we should suspend further discussion for now...in summary:
ARC Buffer management is an important new performance feature for 7.5;
the implementation is a good one and should have positive benefit for
everybody's workload. ARC will adapt to a variety of situations and has
been
Peter Eisentraut [EMAIL PROTECTED] writes:
Rod Taylor wrote:
If that was IS, then foo(x is 13) makes sense.
I like that syntax. For example
select interest(amount is 500.00, rate is 1.3)
is very readable, yet brief.
Yes, that does read well. And IS is already a keyword. We might have
Peter Eisentraut [EMAIL PROTECTED] writes:
Rod Taylor wrote:
If that was IS, then foo(x is 13) makes sense.
I like that syntax. For example
select interest(amount is 500.00, rate is 1.3)
is very readable, yet brief.
On second thought though, it doesn't work.
select func(x is
Thanks for replying Tom,
How much is a lot? it occured ~30 times since 23pm (it's 17:48 pm now)
On Mon, 26 Jan 2004, Tom Lane wrote:
Date: Mon, 26 Jan 2004 09:48:03 -0500
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: [HACKERS]
Peter Eisentraut wrote:
Let me point out an implementation I made last time this subject was
discussed:
http://developer.postgresql.org/~petere/xmltable.tar.bz2
This package contains server-side functions that convert a table (more
generally a query result) to an XML document and/or and XSL
I'm trying to use a function that returns a complex type. I have no problem
creating the function but when I try to use it I get the message:
ERROR: function in FROM has unsupported return type
Apparently, this message stems from the parser. Changing the function so
that it returns a SETOF the
[EMAIL PROTECTED] writes:
I've upgraded my production system to 741 yesterday, and just discovered
this log message: statistic buffer is full.
If you see this a lot, it might be worth increasing PGSTAT_RECVBUFFERSZ.
How much is a lot? it occured ~30 times since 23pm (it's 17:48 pm now)
Hm.
Dann Corbit wrote:
I may be able to help on the localization and path stuff. We have
solved those issues for our port of 7.1.3, and I expect the work for 7.5
to be extremely similar.
Where can I get the latest tarball for Win32 development?
CVS HEAD now has all the Win32 work.
--
Bruce
--On Monday, January 26, 2004 12:11:19 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
[EMAIL PROTECTED] writes:
I've upgraded my production system to 741 yesterday, and just
discovered this log message: statistic buffer is full.
If you see this a lot, it might be worth increasing PGSTAT_RECVBUFFERSZ.
Thomas Hallgren [EMAIL PROTECTED] writes:
I'm trying to use a function that returns a complex type. I have no problem
creating the function but when I try to use it I get the message:
ERROR: function in FROM has unsupported return type
AFAICS it's not possible to get that message for a
On Mon, 26 Jan 2004, Tom Lane wrote:
Date: Mon, 26 Jan 2004 12:11:19 -0500
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED],
Jan Wieck [EMAIL PROTECTED]
Subject: Re: [HACKERS] what does it mean
[EMAIL PROTECTED] writes:
I've upgraded
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
It's fine with me if Bruce prefers to build the release notes directly
from the change logs. As I saw it, the purpose of the temporary list of
things-done-so-far is not to be the raw material for the release notes.
It's to let alpha
On Mon, 26 Jan 2004, Tom Lane wrote:
If that was IS, then foo(x is 13) makes sense.
I like that syntax. For example
select interest(amount is 500.00, rate is 1.3)
is very readable, yet brief.
On second thought though, it doesn't work.
select func(x is null);
is ambiguous,
Tom Lane wrote:
I said:
If there wasn't disk space enough to hold the clog page, the checkpoint
attempt should have failed. So it may be that allowing a short read in
slru.c would be patching the symptom of a bug that is really elsewhere.
After more staring at the code, I have a theory.
Excellent analysis. Thanks. Are there any other cases like this?
---
Tom Lane wrote:
Okay ... Chris was kind enough to let me examine the WAL logs and
postmaster stderr log for his recent problem, and I believe that
I
Christopher Kings-Lynne wrote:
-COMMENT ON [ CAST | CONVERSION | OPERATOR CLASS | LARGE OBJECT | LANGUAGE ]
(Christopher)
Hey Bruce,
You probably should add 'Dump LOB comments in custom dump format' to the
todo. That's the last part of that task above which I haven't done yet,
and
On Mon, Jan 26, 2004 at 02:52:58PM +0900, Michael Glaesemann wrote:
I don't know if the 'canaveral' prompt had anything to do with it
(maybe it was just the subject line), but I kept thinking of shuttle
disasters, o-rings, and plane crashes reading through this. I won't
claim to understand
Matthew Kirkwood [EMAIL PROTECTED] writes:
... Perhaps:
select interest(amount := 500.0, rate := 1.3);
That might work, since := isn't a legal operator name. It might pose a
conflict for clients like ECPG that like to use :name as a parameter
indicator, but since we don't have an
The unsupported return type was all my fault. The Form_pg_type typrelid
attribute points to the class of the relation, not the relation as such.
Duh...
But now, when I actually can return complex types, I encounter another
problem. It happens when I pass a complex type returned from one function
Thomas Hallgren [EMAIL PROTECTED] writes:
... exactly the same TupleTableSlot* that is passed into my
printMyComplextType function. This is of course extremely bad since the
MemoryContext where it was allocated has gone out of scope (I guess, since
this is another call).
I don't think so;
Seems posting to this list from the office didn't work...
The patch is attached as requested - this is just a quick hack, written to
do what I needed at the time.. consider it just as a starting point for
further work.
I've tested it on Solaris 9 with Sun's compiler (Sun Studio 8 Compilers)
but
I found the following piece of code in the plpgsql pl_comp.c module:
/*
* This is a bit ugly --- need a permanent copy of the rel's tupdesc.
* Someday all these mallocs should go away in favor of a per-function
* memory context ...
*/
oldcxt = MemoryContextSwitchTo(TopMemoryContext);
Just for the record, the Canaveral you are thinking about is derived
from the spanish word Cañaveral, which is a place where cañas grow
(canes or stems, according to my dictionary -- some sort of vegetal
living form anyway). I suppose Cape Kennedy was filled with those
plants and that's what the
pgman wrote:
PeerDirect handles rename by just looping. We really can't delay a
rename. There is discussion in the Win32 TODO detail that goes over
some options, I think.
Do we really have any problem with rename? We don't rename table files.
The renames I can think of are
Bruce Momjian [EMAIL PROTECTED] writes:
In this way, no one ever has the rename file open while we are holding
the locks, and we can loop without holding an exclusive lock on
pg_shadow, and file writes remain in order.
You're doing this where exactly, and are certain that you are holding no
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
In this way, no one ever has the rename file open while we are holding
the locks, and we can loop without holding an exclusive lock on
pg_shadow, and file writes remain in order.
You're doing this where exactly, and are certain that
Ezra Epstein wrote:
I'd like to extend SET SESSION AUTHORIZATION to support a form which takes a
password. Looking at the source it seems, other than changes to the parser,
there are only 2 relevant functions in 2 files that would be affected. Each
function is quite small and its function
Bruce Momjian [EMAIL PROTECTED] writes:
Ezra Epstein wrote:
I'd like to extend SET SESSION AUTHORIZATION to support a form which takes a
password.
Uh, a password? What purpose would that serve?
Indeed. SET SESSION AUTH is already allowed only to superusers --- a
superuser hardly needs any
37 matches
Mail list logo
