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 nee
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 funct
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 ce
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 ce
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 n
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 thin
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 t
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);
ro
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 u
"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
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 a
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 i
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 underst
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 y
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
>
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
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);
>
> i
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:
> 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:
> >>
"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
Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > If the TODO-list-with-dash isn't the correct place to have looked, is
> > there another list of committed changes for the next release?
>
> We tend to rely on the CVS commit logs as the definitive source. You
> can pull the info from
--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
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.
--
B
[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 p
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 s
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
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: [H
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 i
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 mig
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 designe
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?
[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
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 evic
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 p
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 constrain
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
--
Oli
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 pl
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 completed/com
We got a problem ticket from the customer.
Messages in the error_log indicated problem trying to insert
a duplicate value into a table.
Looking at the database (v.7.3.2 on Solaris) I'm puzzled with this:
syncdb=# \d
ERROR: Cache lookup failed for relation 17075
syncdb=# \di
ERROR: Cache looku
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 l
40 matches
Mail list logo
