"Murali" wrote:
> PostgreSQL version: 8.0.6
> Operating system: Windows Server 2003 Standard 32 Bit
> Description:Postgres hangs / crashes every day
You do realize that Windows is not a supported platform for any
release less than 8.2?
http://wiki.postgresql.org/wiki/PostgreSQL_Rel
"Murali" writes:
> Postgres hangs / crashes every day (gets corrupted?). It neither serves any
> requests from connected applications nor accepts new connections. I canât
> connect to the data base through PG Admin also. Below given is the log
> snippet at the time of failure.
> Log Snippet1:
>
The following bug has been logged online:
Bug reference: 5278
Logged by: Murali
Email address: nmmredd...@hotmail.com
PostgreSQL version: 8.0.6
Operating system: Windows Server 2003 Standard 32 Bit
Description:Postgres hangs / crashes every day
Details:
Postgres han
On Thu, Jan 14, 2010 at 06:41:52PM +, Tim Bunce wrote:
> > > David E. Wheeler wrote:
> > >> Found in 8.4.2, replicated in HEAD. Steps:
> > >>
> > >> 1. Create PL/Perl function.
> > >> 2. Run it.
> > >> 3. Create same function with PL/PerlU
> > >> 4. Run it.
> > >> 5. Create same function again
After upgrading to the latest patch level: PostgreSQL 8.4.2 on
i386-portbld-freebsd8.0
I have got a different core dump
(gdb) bt
#0 0x328b1068 in malloc () from /lib/libc.so.7
#1 0x082f1be9 in load_tzoffsets ()
#2 0x080aa5ef in btrescan ()
#3 0x082db80c in FunctionCall2 ()
#4 0x080a4c15 in
On Jan 14, 2010, at 10:44 AM, Tom Lane wrote:
> Justin Pitts writes:
>> On Jan 14, 2010, at 10:16 AM, Tom Lane wrote:
>>> The 100 temp table creations probably will do that just fine.
>
>> Is there a way to verify this?
>
> You could add an elog(LOG, "message") into ResetPlanCache so you could
> > David E. Wheeler wrote:
> >> Found in 8.4.2, replicated in HEAD. Steps:
> >>
> >> 1. Create PL/Perl function.
> >> 2. Run it.
> >> 3. Create same function with PL/PerlU
> >> 4. Run it.
> >> 5. Create same function again with PL/Perl
> >> 6. Boom.
>
> > This was just discussed in -HACKERS. Hav
Tom Lane writes:
> "louis" writes:
> > Arguments can't be passed to a plperl function
>
> [ scratches head... ] Works for everybody else. I have to suppose
> there's something broken about your libperl, or plperl somehow got
> built wrong. How did you build or come by your copies of perl and
On Thu, Jan 14, 2010 at 04:06, louis wrote:
> Arguments can't be passed to a plperl function
Yeah, this is a bug with safe 2.20 :( see
-http://rt.perl.org/rt3/Ticket/Display.html?id=72068
I would either try out this fix:
http://github.com/timbunce/Safe/commits/master.
Or downgrade to 2.19 for
"louis" writes:
> Arguments can't be passed to a plperl function
[ scratches head... ] Works for everybody else. I have to suppose
there's something broken about your libperl, or plperl somehow got
built wrong. How did you build or come by your copies of perl and
postgresql?
On Jan 14, 2010, at 10:16 AM, Tom Lane wrote:
> Justin Pitts writes:
>> My guess is that I am not provoking a 'SI queue overrun'
>
> The 100 temp table creations probably will do that just fine.
>
Is there a way to verify this?
>> Am I completely off base about how this should be reproduc
As difficult as it was to reproduce the bug, I'd like a clear cut regression
test. The use case where it manifested is fairly rare in normal use - server
start after prolonged outage, where the queue of inbound device events is built
up enough to make serialization errors more likely.
On Jan 14
"James Bellinger" writes:
> While on startup, pg_ctl (correctly) looks in the directory specified by -D
> for postgresql.conf, and then uses that to determine the data directory,
> when stopping it actually expects the directories to be the same and in
> doing so looks for the PID file in the give
Justin Pitts writes:
> On Jan 14, 2010, at 10:16 AM, Tom Lane wrote:
>> The 100 temp table creations probably will do that just fine.
> Is there a way to verify this?
You could add an elog(LOG, "message") into ResetPlanCache so you could
tell when it had been called.
> I don't follow. Are you s
Apologies for over-quoting on the previous message.
My approach to a regression test was this single-threaded test ( actual code at
bottom )
Connection 1 - implicitly autocommiting every statement
create a test table and populate it with a single row.
BTW --- from my own perspective, what is much more interesting is
testing time on your real application to make sure that you don't
see a crash any more. I am certain that I identified and fixed
*a* bug, what I'm less certain about is that it is actually what
you were hitting. The previous advice
Justin Pitts writes:
> My guess is that I am not provoking a 'SI queue overrun'
The 100 temp table creations probably will do that just fine.
> Am I completely off base about how this should be reproducing?
Two points: the session you hope to have crash *must* be in serializable
mode, and the
The following bug has been logged online:
Bug reference: 5277
Logged by: louis
Email address: louis01010...@gmail.com
PostgreSQL version: 8.4.2
Operating system: PostgreSQL 8.4.2 on x86_64-pc-linux-gnu, compiled by GCC
gcc-4.4.real (Ubuntu 4.4.1-4ubuntu8) 4.4.1, 64-bit
Descri
The following bug has been logged online:
Bug reference: 5276
Logged by: James Bellinger
Email address: j...@zer7.com
PostgreSQL version: 8.4.2
Operating system: Ubuntu 9.10
Description:pg_ctl reads data directory on -D instead of
postgresql.conf directoryh
Details:
On Thu, Jan 14, 2010 at 3:21 AM, Kevin Grittner wrote:
>
> I'm inclined to agree with you, but it does present a barrier to
> those migrating. Are there any "migration considerations" documents
> where we should mention this? Standards compliance notes in the
> docs? Some form of this question
> Pavel,
> if it was a simple plain dynami statement, I could create it by string
> concatenation, literal_ and ident_ quoting and so on.
the situation isn't too simply like you see it. PostgreSQL supports
composite and nested types. For this types you cannot use quote*
functions. Next problem is
2010/1/14 Vincenzo Romano :
> 2010/1/14 Pavel Stehule :
>> Hello
>>
>> it is not bug.
>>
>> DDL statements like CREATE TABLE, ALTER TABLE are doesn't support
>> parametrisation - you cannot use a placeholder for parameter
>> everywhere. So you cannot to write PQexecParams(..."ALTER TABLE test
>> AL
2010/1/14 Pavel Stehule :
> Hello
>
> it is not bug.
>
> DDL statements like CREATE TABLE, ALTER TABLE are doesn't support
> parametrisation - you cannot use a placeholder for parameter
> everywhere. So you cannot to write PQexecParams(..."ALTER TABLE test
> ALTER COLUMN $1 ...", ...), so it cannot
Hello
it is not bug.
DDL statements like CREATE TABLE, ALTER TABLE are doesn't support
parametrisation - you cannot use a placeholder for parameter
everywhere. So you cannot to write PQexecParams(..."ALTER TABLE test
ALTER COLUMN $1 ...", ...), so it cannot be supported by EXECUTE
USING. Paramete
24 matches
Mail list logo
