On Thu, Nov 18, 2004 at 04:17:31AM +0100, Palle Girgensohn wrote:
Does the same arguments apply for linking with libc_r (pthreads)?
It is needed by plpython, at least on FreeBSD 4.10 (probably all versions).
There are problem with libc_r on FreeBSD: due to initializing
of red zone for
Palle Girgensohn schrieb:
I'm not a linking guru... Is there a penalty for setting LDFLAGS+=
-lstdc++ when building postgresql?
Postgis includes a bunch of useful functions for manipulating spatial
data. Some of them are provided by geos, a separate c++ library, with
postgis providing wrappers.
Hi,
I got extremely frustrated with having to create a temp table every time
I wanted to access an arbitrary column from a record plpgsql. After
seeing a note on the developers TODO about accessing plpgsql records
with a 'dot bracket' notation I started digging into the plpgsql source.
My diff
It seems that 8.0B4's plpgsql does not diagnose 'ELSIF' being
misspelled as 'ELSEIF' nearly as readily as did 7.4.x. 7.4 emits a
compile error at the right place, whereas 8.0b4 seems to treat
misspelled 'ELSEIF' blocks as unreachable code, making it quite hard to
diagnose what is actually
Guys,
Sorry for writing here. The point is that google does not helps very much
with this error message, and the lists also, cause they throw different posible
diagnosis for the same problem. And I think that the creators of the beast
will further know what it's going on, or at least give
5. Because of the way the expression is parsed (looking for closing
parenth), this will choke if you try and put a function in there. Would
it be better to use curly braces '{expr}' or another character to mark
the expression?
I lie! pgpgsql_read_expression() is smarter than that!
However, I
G u i d o B a r o s i o [EMAIL PROTECTED] writes:
I am worry about a hardware problem.
I think you're right. badblocks (for disk) and memtest86 (for RAM)
are the tools I've seen recommended most often for narrowing down
what's gone flaky.
regards, tom lane
James Robinson [EMAIL PROTECTED] writes:
7.4.6 results:
xs2 /tmp psql ssc_sav pets.sql
BEGIN
ALTER TABLE
CREATE FUNCTION
ERROR: syntax error at or near ELSEIF at character 1
CONTEXT: PL/pgSQL function fix_pets line 16 at SQL statement
Um ... I get the no code determined message in 7.4.6
Hmm. Teach me to not send in the exact script / dataset that caused the
issue. Indeed, I must have (luckily) had a separate syntax error in the
version that caused the 7.4.6 parser to trip up on the ELSEIF line (it
did happen else I'd still be staring at the thing).
Humble apologies and
David Parker [EMAIL PROTECTED] writes:
What I think is happening with the missing pg_statistic entries:
The install of our application involves a lot of data importing (via
JDBC) in one large transaction, which can take up to 30 minutes. (I
realize I left out this key piece of info in my
Tom Lane wrote:
Devrim GUNDUZ [EMAIL PROTECTED] writes:
Off-by-one memory allocation problem --- it only bites you if the string
lengths are just right, which probably explains the lack of prior
reports even though the bug has been there since 7.3.
Is this worth new dot releases?
I'd say
James Robinson [EMAIL PROTECTED] writes:
Hmm. Teach me to not send in the exact script / dataset that caused the
issue. Indeed, I must have (luckily) had a separate syntax error in the
version that caused the 7.4.6 parser to trip up on the ELSEIF line (it
did happen else I'd still be
Between ugly #1 and ugly #2, I'd think that a wart teaching it that
'ELSEIF' is not a valid manner to start a statement (i.e. following a
semicolon) would be preferable. Allowing us hacks to write functions
containing both spellings makes the language look poor since it ought
to slap us into
On Thu, Nov 18, 2004 at 10:45:53 -0500,
Tom Lane [EMAIL PROTECTED] wrote:
G u i d o B a r o s i o [EMAIL PROTECTED] writes:
I am worry about a hardware problem.
I think you're right. badblocks (for disk) and memtest86 (for RAM)
are the tools I've seen recommended most often for
The fix for unflushed changed to pg_database records seems to have fixed
the problem we were seeing on spoonbill ... but it is now seeing
problems with the seg module:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbilldt=2004-11-18%2016:02:58
cheers
andrew
Tom,
This seems like a good change to me. Does anyone not like it?
+1
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
Has anyone else had any problem installing plpgsql into a 7.4.6
database? When I try (on NetBSD 2.0RC5) I get the following message:
createlang: language installation failed: server closed the connection
unexpectedly
This does not happen on 7.4.3, the other system that I have installed.
It
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
Has anyone else had any problem installing plpgsql into a 7.4.6
database? When I try (on NetBSD 2.0RC5) I get the following message:
createlang: language installation failed: server closed the connection
unexpectedly
Probably indicates a failure to
On 11/18/2004 11:43 AM, Tom Lane wrote:
David Parker [EMAIL PROTECTED] writes:
What I think is happening with the missing pg_statistic entries:
The install of our application involves a lot of data importing (via
JDBC) in one large transaction, which can take up to 30 minutes. (I
realize I left
On Thu, 18 Nov 2004 14:25:41 -0500
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
Has anyone else had any problem installing plpgsql into a 7.4.6
database? When I try (on NetBSD 2.0RC5) I get the following
message:
createlang: language installation failed:
Thanks all for the quick reply.
Cheers, Regards, and muchas gracias!!
Guido.
On Thu, Nov 18, 2004 at 10:45:53 -0500,
Tom Lane [EMAIL PROTECTED] wrote:
G u i d o B a r o s i o [EMAIL PROTECTED] writes:
I am worry about a hardware problem.
I think you're right. badblocks (for
Folks,
Some issues have come up repeatedly on IRC with new users, enough so that they
might be worth addressing in the code:
a) new users try just to psql as postgres, and get a no such database
postgres;
b) new users use template1 as a testing database, and then have to re-initdb
to clean it
The only reason not to do it is space; each database takes up about 5mb.
That's nothing to most users but could be a problem for a few. Also, it
would create a minor burden on the fsm to track an extra set of relations.
Perhaps it could have an initdb flag to turn it off and be easily
Josh Berkus [EMAIL PROTECTED] writes:
Some issues have come up repeatedly on IRC with new users, enough so that
they
might be worth addressing in the code:
a) new users try just to psql as postgres, and get a no such database
postgres;
b) new users use template1 as a testing database, and
Tom,
I think you are right that these reflect heap or btree-index extension
operations. Those do not actually take locks on the *table* however,
but locks on a single page within it (which are completely orthogonal to
table locks and don't conflict). The pg_locks output leaves something
to
Andrew Dunstan [EMAIL PROTECTED] writes:
The fix for unflushed changed to pg_database records seems to have fixed
the problem we were seeing on spoonbill ... but it is now seeing
problems with the seg module:
Josh Berkus [EMAIL PROTECTED] writes:
Aside from foriegn keys, though, is there any way in which INSERT page locks
could block other inserts?
Not for longer than the time needed to physically add a tuple to a page.
regards, tom lane
---(end of
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The fix for unflushed changed to pg_database records seems to have fixed
the problem we were seeing on spoonbill ... but it is now seeing
problems with the seg module:
On Thu, 18 Nov 2004, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Some issues have come up repeatedly on IRC with new users, enough so that
they
might be worth addressing in the code:
a) new users try just to psql as postgres, and get a no such database
postgres;
b) new
Andrew Dunstan [EMAIL PROTECTED] writes:
We're only seeing it now because up to now the run on this platform was
bombing out on the error you so brilliantly fixed last night.
Consistently? I'd have thought that problem would only fail once in a
while. It's hard to believe the timing would
Simon Riggs [EMAIL PROTECTED] writes:
The main problem on INSERTs is that it is usually the same few pages:
the lead data block and the lead index block. There are ways of
spreading the load out across an index, but I'm not sure what happens on
the leading edge of the data relation, but I
On Thu, 2004-11-18 at 22:12, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Aside from foriegn keys, though, is there any way in which INSERT page
locks
could block other inserts?
Not for longer than the time needed to physically add a tuple to a page.
The main problem on
Simon, Tom,
The main problem on INSERTs is that it is usually the same few pages:
the lead data block and the lead index block. There are ways of
spreading the load out across an index, but I'm not sure what happens on
the leading edge of the data relation, but I think it hits the same
block
Josh Berkus [EMAIL PROTECTED] writes:
The main problem on INSERTs is that it is usually the same few pages:
the lead data block and the lead index block. There are ways of
spreading the load out across an index, but I'm not sure what happens on
the leading edge of the data relation, but I
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
We're only seeing it now because up to now the run on this platform was
bombing out on the error you so brilliantly fixed last night.
Consistently? I'd have thought that problem would only fail once in a
while. It's hard to
On Thu, 2004-11-18 at 22:51, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The main problem on INSERTs is that it is usually the same few pages:
the lead data block and the lead index block. There are ways of
spreading the load out across an index, but I'm not sure what happens on
Simon Riggs [EMAIL PROTECTED] writes:
Would it be possible to: when a new block is allocated from the relation
file (rather than reused), we check the FSM - if it is empty, then we
allocate 8 new blocks and add them all to the FSM. The next few
INSERTers will then use the FSM blocks normally.
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Consistently? I'd have thought that problem would only fail once in a
while. It's hard to believe the timing would work out to make it a 100%
failure.
You can see the history of the latest build runs here:
Tom Lane wrote:
Can we get personal accounts on the buildfarm
machines?
That's up to the owner of each machine - it's a distributed system.
I've sent email to the owner of this one.
When I get a few minutes soon I hope to start some discussion on
-hackers about what members we want in the
On Thu, 2004-11-18 at 23:19, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Would it be possible to: when a new block is allocated from the relation
file (rather than reused), we check the FSM - if it is empty, then we
allocate 8 new blocks and add them all to the FSM. The next few
Simon Riggs [EMAIL PROTECTED] writes:
Can we subdivide the WALInsertLock so there are multiple entry points to
wal_buffers, based upon hashing the xid?
I don't think so; WAL is inherently a linear log. (Awhile ago there was
some talk of nonlinear log writing to get around the one-commit-per-
I am running of postgresql database servers with generally 30-50 users
at a time per server. I have noticed one thing for web based databases
that they fail to initialse a pg_connection connection every now and
again and return no error message at all. Though one of hte developers
tells me
On Fri, 2004-11-19 at 16:17 +1300, Dru wrote:
Though one of hte developers
tells me that sometimes it gets a link resource allocation error on
opening connections to the database server which i dont know if that is
related.
I'm not sure what you mean by a link resource allocation error.
Andrew Dunstan wrote:
Peter Eisentraut wrote:
It seems that in the new PL/Perl, the result of the spi_exec_query
function changes in meaning depending on the command. For a SELECT,
the value of
$res-{rows}
is a reference to an array of the result rows.
For a different command
$res-{rows}
is a
Josh,
I would agree that seems a little odd ;). Would this be something we
want done for 8.0?
I think we'd better. Otherwise, people will get used to the broken syntax.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
Dru [EMAIL PROTECTED] writes:
I am running of postgresql database servers with generally 30-50 users
at a time per server. I have noticed one thing for web based databases
that they fail to initialse a pg_connection connection every now and
again and return no error message at all.
Josh Berkus [EMAIL PROTECTED] writes:
I would agree that seems a little odd ;). Would this be something we
want done for 8.0?
I think we'd better. Otherwise, people will get used to the broken syntax.
Agreed. Someone's going to step up and patch this, no?
(Not me --- I've already wasted
Neil Conway wrote:
On Fri, 2004-11-19 at 16:17 +1300, Dru wrote:
Though one of hte developers
tells me that sometimes it gets a link resource allocation error on
opening connections to the database server which i dont know if that is
related.
I'm not sure what you mean by a link
Agreed. Someone's going to step up and patch this, no?
(Not me --- I've already wasted more hours than I could afford this week
on plperl.)
We can do it, but it will have to be after thanksgiving.
J
regards, tom lane
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and
Tom Lane wrote:
Dru [EMAIL PROTECTED] writes:
I am running of postgresql database servers with generally 30-50 users
at a time per server. I have noticed one thing for web based databases
that they fail to initialse a pg_connection connection every now and
again and return no error message
On Fri, 2004-11-19 at 17:15 +1300, Dru wrote:
Ok rules out that possibility also. Is there any stress testing
software for postgresql to find out how and when it breaks?
Try contrib/pgbench.
The website uses php,
the problem could be in the wrapper code for PHP though. I havnt
got much
I've spent ages going though logs and turning debugging to max. There
is no
error message returned at all. The connection handle is returned as
NULL.
This is in the php functions though so their pg_last_error() function may
not be catching all error messages but it seems it should pass on
On Fri, Nov 19, 2004 at 05:15:54PM +1300, Dru wrote:
I'll get the developer to write down the exact error when it happens again.
It would be better to cut and paste the error message instead of
writing it down. What people think they see doesn't always match
what's on the screen.
--
Michael
On Thu, 18 Nov 2004, Joshua D. Drake wrote:
Agreed. Someone's going to step up and patch this, no?
(Not me --- I've already wasted more hours than I could afford this week
on plperl.)
We can do it, but it will have to be after thanksgiving.
Humor the Canadian ... when is Thanksgiving? :)
Some other time maybe. Meanwhile, this patch ought to make it compile
more cleanly on Windows - not sure why I get errors there but not
Linux.
Because getopt() is normally declared in unistd.h, not getopt.h (Windows
being an exception?).
getopt is not in any standard Windows headers. The
55 matches
Mail list logo
