Scott Goodwin <[EMAIL PROTECTED]> writes:
> Hoping someone can help me figure out why I can't get PL/Tcl to load
> without crashing the backend on Mac OS 10.3.2.
FWIW, pltcl seems to work for me. Using up-to-date Darwin 10.3.2
and PG CVS tip, I did
configure --with-tcl --without-tk
then
I've looked into Olivier Hubaut's recent reports of 'Too many open
files' errors on OS X. What I find is that on Darwin, where we are
using Posix semaphores rather than SysV semaphores, each Posix semaphore
is treated as an open file --- it shows up in "lsof" output, and more to
the point it appea
"Nicolai Tufar" <[EMAIL PROTECTED]> writes:
> Under locale-ignorant FreeBSD it works fine.
> But under Fedora Core 1 initdb it crashes under all
> locales I tested -C, en_US, tr_TR with message given below.
Hmm. It seems that tr_TR has problems much more extensive than you've
indicated previously
Hoping someone can help me figure out why I can't get PL/Tcl to load
without crashing the backend on Mac OS 10.3.2.
I compile Tcl, PostgreSQL, create the database and then run the
following:
create function plpgsql_call_handler() RETURNS LANGUAGE_HANDLER
as 'plpgsql.so' language 'c';
create t
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
>
> I've committed the attached fix, which I believe will solve this
> problem. Could you test it?
Thank you very much for your effort and attention!
I am not sure I am testing the right version. I am testing the
one with R
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've implemented a pretty simple Materialized Views scheme. It's not
terribly complicated, and it works quite well.
This is what I do.
0) Initialize the materialized view environment. This will allow the
system to track which tables and views are p
On Thu, 2004-02-19 at 11:01, Bruce Momjian wrote:
> Zeugswetter Andreas SB SD wrote:
> >
> > > > The question is whether we should have a GUC variable to control no
> > > > waiting on locks or add NO WAIT to specific SQL commands.
> > > >
> > > > Does anyone want to vote _against_ the GUC idea fo
The reason it is a bug rather than an unimplemented feature
is that it pokes a hole in the effectiveness of domains.
What good is a domain if it cannot be enforced everywhere
you use it? That is like having a hole in referential
integrity. (Though I admit not many people will run into
this until
Hello,
I am trying to test some of my techniques, and for that i need the nested
loop join plan node (NestLoop) not to restart the scan of the inner relation
for a change of outer relation correlation value, instead start from the
current position where the search ended for the previous scan.
Right. Sorry. My brain was over on parameter issues and
I did not reread my original bug...
On Fri, Feb 20, 2004 at 01:03:08PM -0500, Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > Shouldn't all function calls go (through fast path or fmgr
> > or the language manager?) to a centralized p
Thomas Hallgren wrote:
> How about,
>
> "Allow outside agents to extend the GUC variable set"
Added:
* Allow external interfaces to extend the GUC variable set
---
>
> - thomas
>
> - Original Message -
elein <[EMAIL PROTECTED]> writes:
> Shouldn't all function calls go (through fast path or fmgr
> or the language manager?) to a centralized parameter marshalling?
We're talking about what happens inside the function, not how you pass
parameters to it.
regards, tom lane
Robert Treat <[EMAIL PROTECTED]> writes:
> so ISTM that your example is certainly a deficiency if not a bug.
I believe it is a bug or at least an unimplemented feature in plpgsql:
plpgsql has its own implementation of casting, and is not aware that
casting to a domain should involve running check
plpgsql should be trying to coerce the return value to the functions return
type:
rms=# create or replace function retval(integer) returns text as ' begin
return $1::integer; end; ' language 'plpgsql';
CREATE FUNCTION
rms=# select retval(1) || ' is text';
?column?
---
1 is text
(1 row
> Rod, can you lay out some psdueo code / logic involved in the process? I'm
> guessing you lock the entry in pg_class, you up dependent objects, lock them,
> update them all... is there more to it?
It was one an offline database at the time with only a single user -- so
locking wasn't a concer
How about,
"Allow outside agents to extend the GUC variable set"
- thomas
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Thomas Hallgren" <[EMAIL PROTECTED]>
Cc: "Joe Conway" <[EMAIL PROTECTED]>; "Tom Lane" <[EMAIL PROTECTED]>;
"Peter Eisentraut" <[EMAIL PROTECTED]>
On Sunday 15 February 2004 07:53, Rod Taylor wrote:
> On Sun, 2004-02-15 at 01:34, Neil Conway wrote:
> > [EMAIL PROTECTED] writes:
> > > The capability to move objects to other schemas would be quite
> > > useful.
> >
> > I agree. It's not utterly-trivial to implement (for one thing, you
> > need
On Friday 20 February 2004 14:21, Tom Lane wrote:
> Richard Huxton <[EMAIL PROTECTED]> writes:
> > Could have sworn this was already listed as a TODO, but can't see it on
> > the developer website. IMHO it's something that's needed, especially with
> > differing behaviour due to compiled plans.
>
>
Richard Huxton <[EMAIL PROTECTED]> writes:
> Could have sworn this was already listed as a TODO, but can't see it on the
> developer website. IMHO it's something that's needed, especially with
> differing behaviour due to compiled plans.
See PREPARE and EXPLAIN EXECUTE.
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>>Kenneth Marshall would like me to post this:
>> I agree that in order to manage today's large memory machines, we
>> need to have less contention in our buffer management strategies.
>> The two main main choke points are in the buffer hash table routines
Could have sworn this was already listed as a TODO, but can't see it on the
developer website. IMHO it's something that's needed, especially with
differing behaviour due to compiled plans.
--
Richard Huxton
Archonet Ltd
---(end of broadcast)-
21 matches
Mail list logo
