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? :)
Mar
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
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 ever
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 muc
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 messag
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 S/JD
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 resour
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 wa
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,
> 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 broadcast)
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
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 erro
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 th
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
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 ne
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 buil
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:
> http://www.pgbui
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 norma
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 happ
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 beli
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, b
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
> b
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 proble
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
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
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
> > postgre
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:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbil
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
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:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2004-11-18%201
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
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 da
> 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 easil
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
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. b
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 insta
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
"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 fai
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 does
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 co
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=spoonbill&dt=2004-11-18%2016:02:58
cheers
andrew
---(e
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
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 fo
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 s
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 release
"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 m
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 thanks.
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"
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
--
> 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
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
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 amiss
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 (a
>> 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 head
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.
A
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 init
55 matches
Mail list logo
