The following bug has been logged on the website:
Bug reference: 8237
Logged by: Andrea Lombardoni
Email address: and...@lombardoni.ch
PostgreSQL version: 9.0.4
Operating system: Linux
Description:
I observed the following behaviour (I tested the following statements
and the problem seems temporary solved.
We have made an accurate test on the hardware but it's seems to be ok.
It's seems to be a kernel bug, so I posted the problem to Novell support.
Thanks for the help. Regards
Andrea Grassi
-Messaggio originale-
Da: Tom Lane
and
client wait each other for the other and could be a libpq bug.
What do you think about ? This scenario could be possible or the true
statement is the second ?
Regard, Andrea
-Messaggio originale-
Da: Craig Ringer [mailto:ring...@ringerc.id.au]
Inviato: mercoledì 21 dicembre 2011 0.56
127.0.0.1:5432 127.0.0.1:53129
ESTABLISHED -
tcp 48 0 127.0.0.1:53129 127.0.0.1:5432
ESTABLISHED 29802/g_mrprun.e
Regards, Andrea
-Messaggio originale-
Da: Tom Lane [mailto:t...@sss.pgh.pa.us]
Inviato: martedì 20 dicembre 2011 17.38
A: Andrea Grassi
Cc: harry
libpq.so.5
Can you specify the details of hardware and platform of your machine to
understand if it can have something in common with the mine and so to
understand the reason/origin of the bug?
Thanks.
Andrea
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to y
in sm_jform ()
No symbol table info available.
#37 0x08190135 in sm_jexec_top ()
No symbol table info available.
#38 0x08190015 in sm_jtop ()
No symbol table info available.
#39 0x0807d11b in start_up ()
No symbol table info available.
#40 0x08056a71 in common_main (argc=2, argv=0xffdcd444)
could give me a hint on what could be.
Regards, Andrea
-Messaggio originale-
Da: Craig Ringer [mailto:ring...@ringerc.id.au]
Inviato: sabato 17 dicembre 2011 7.19
A: Andrea Grassi
Cc: pgsql-bugs@postgresql.org
Oggetto: Re: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
Hi, Craig
Now my process is blocked and I have the case in my hands.
Do you have something to ask me in order to have more details ?
Regards, Andrea
-Messaggio originale-
Da: Craig Ringer [mailto:ring...@ringerc.id.au]
Inviato: sabato 17 dicembre 2011 7.19
A: Andrea Grassi
Cc: pgsql
? libpq ? linux release ? hardware ?
If you need other informations let me know.
Regards, Andrea
-Messaggio originale-
Da: Craig Ringer [mailto:ring...@ringerc.id.au]
Inviato: sabato 17 dicembre 2011 7.19
A: Andrea Grassi
Cc: pgsql-bugs@postgresql.org
Oggetto: Re: R: [BUGS] BUG #634
ly will be the same).
Regards,
Andrea Grassi
-Messaggio originale-
Da: Craig Ringer [mailto:ring...@ringerc.id.au]
Inviato: venerdì 16 dicembre 2011 9.24
A: andreagra...@sogeasoft.com
Cc: pgsql-bugs@postgresql.org
Oggetto: Re: [BUGS] BUG #6342: libpq blocks forever in "poll" fun
t;a=commitdiff;h=1679e9feddc94bd7372a6829db92868e55ef7177
and the fix will be included into postgres 9.1.2
(that should be announced on Monday Dec 5, with
tarballs available from Thursday Dec 1)
Andrea
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to y
The following bug has been logged online:
Bug reference: 6120
Logged by: Paula Andrea Carvajal
Email address: paanc...@gmail.com
PostgreSQL version: 9.0.4
Operating system: Mac OS X 10.7 (GM)
Description:Problem running post-install step in Mac OS X Lion (GM)
Details
Hmm. That is suspiciously close to the location of some last-minute
changes in Postgres 9.0. I wonder whether Andrea is using a version of
PostGIS that was compiled against pre-9.0RC1 Postgres sources.
If so, I am to and it's the latest PostGIS binary from their website.
Hi,
Y
le, I use often some field of big size:
VARCHAR(20)
the next try I do is to remove the postgis components to see if again
this happened.
Andrea.
Il 04/10/2010 04:56, Tom Lane ha scritto:
Craig Ringer writes:
While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven'
/postgis-users/2010-October/027843.html
Regards,
Andrea.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
s needed the instruction of
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows#Remote_debugging_with_windbg.exe
Regards,
Andrea Peri.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
your case, as the backend is crashing you will want to use windbg or
Visual Studio Express Edition to collect the crash data; process explorer
will not be enough.
ok, now I try to do this backtrace.
Regards,
Andrea.
2010/10/3 Craig Ringer
> On 2/10/2010 9:08 PM, Andrea Peri wrote:
he same windows machine) using
the postgres 8.4.4 istance and all terminated without any problem.
The procedure is substantially only a huge list of
string sql like
insert into()
executed one by one in many tables and with autocommit.
Andrea Peri.
--
-----
Andrea Peri
. . . . .
On 09/03/2010 17:12, Andrea Suisani wrote:
On 09/03/2010 16:51, Tom Lane wrote:
Andrea Suisani writes:
I'm experiencing something weird. here the session's log
that involves the prob I mentioned
2010-03-08 12:59:41 CET p...@c[3189]error: duplicate key value violates
unique
On 09/03/2010 16:51, Tom Lane wrote:
Andrea Suisani writes:
I'm experiencing something weird. here the session's log
that involves the prob I mentioned
2010-03-08 12:59:41 CET p...@c[3189]error: duplicate key value violates unique
constraint "pg_type_typname_nsp_index"
lem seems
to goes away after restarting postgresql (the
box is turned off during the night).
The sql command are submitted by a tcl/tk applications
that use a persistent connection via libpgtcl.
Unfortunately I'm not able to set up a reproducible test-case :/
Andrea
--
Sent via pgsq
The following bug has been logged online:
Bug reference: 4391
Logged by: Andrea Villardino
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: windows server 2003(or vista).
Description:initdb doen't work with options -U username a
The following bug has been logged online:
Bug reference: 4392
Logged by: Andrea Villardino
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: windows server 2003(or vista)
Description:initdb doen't work with options -U username a
The following bug has been logged online:
Bug reference: 2700
Logged by: Andrea C. Granata
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2beta1
Operating system: Linux
Description:tsearch2: snowball api outdated.
Details:
Hi,
Please update snowball api
Thanks for the quick reply
Tom Lane wrote:
andrea suisani <[EMAIL PROTECTED]> writes:
[cut]
Hmm ... what do you get from
select oid from pg_class where relname = 'nominativi';
oid
561644
(1 row)
afaics it seems weird does this mean that another postgresql
hardware failure. We run long self-tests on our SCSI disk through
smartmontools on a regular basis. see attached file for "smartctl -a /dev/sda"
output. All suggestions are welcome.
Regards,
Andrea
smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
Home page is http:/
tnks for the hint ;)
I'll try something similar here.
Andrea
Josh Berkus wrote:
Andrea,
i'm sorry for the curiosity but
could you share, if it's possible, this workaround? ;)
(if it's not the one you describe at the beginning thread
e.g. don't use LIMIT 1)
Well,
hi!
Josh Berkus wrote:
> Bruce,
>
[snip]
>
>
> Well, limit+for update can be useful under some circumstances, as long as you
> understand its limitations.We found a workaround.
i'm sorry for the curiosity but
could you share, if it's possible
dump
the schema and data separately, as one file was to big to manage, but it
was just a matter of confort.
Thank for the great work.
Postgresql is really a wonderfull thing.
Andrea from Italy
---(end of broadcast)---
TIP 1: subscribe and unsubscribe c
hello all,
here follows the regression test run on postgres 8.0.0b1.
Hardware Ultra 2 dual 300MHz CPUS 768MB RAM
OS Solaris 10 b 5
--
== creating temporary installation==
== initializing database system ===
hello all,
this is the output as asked by Tom Lane.
test8=> \set VERBOSITY verbose
test8=> SELECT 'infinity'::float4;
float4
--
Infinity
(1 row)
test8=> SELECT 'infinity'::float4;
ERROR: 22P02: invalid input syntax for type real: "infinity"
LOCATION: float4in, float.c:330
Followi
hello,
attached are the regression.out and regression.diffs files from make check on a
Ultra 2 dual 300MHz CPU running Solaris 9 OS.
Looks like no errorbut the expected due to difference in fp results.
regression.diffs
Description: Binary data
regression.out
Description: Binary data
---
lem of mine)?
I remember Tom solved something like this years ago.
b) if so, can you show me next steps to narrow down the problem to give you
a little help?
Thanks a lot for your work,
Andrea Gelmini
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
d, with these packages installed:
ii postgresql 7.3.3-1 Object-relational SQL database, descended from
POSTGRES
ii postgresql-client 7.3.3-1 Front-end programs for PostgreSQL
ii postgresql-dev 7.3.3-1 Header files for libpq (postgresql library)
ii postgresql-doc 7.3.3-1 Documentation for the PostgreSQL database
Thanks a lot for your work,
Andrea Gelmini
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
14:24:51 CET 2002 i686 unknown
debian (sid)
PostgreSQL 7.3devel on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.1
(Debian)
all regression tests passed.
thanks a lot for your work,
andrea gelmini
--
Jesus died for your sins. Make it worth his time.
---(end of broadcast)
w if you can still see the problem with today's snapshot.
i've tried in these days, and it seems everything work right now...
thanks a lot for your time,
andrea
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http:/
you told
me), without vacuumdb.
> cvs (make sure you get src/backend/utils/time/tqual.c v 1.46) and then
> see if you still see the problem. If you do, a backtrace from the point
> where elog() is called would be really helpful.
tomorrow i will redo all my tests, but i guess now the
000 (I think that's about as small as you can make it without
> breaking anything). That gives you a shot at a problem every 64K
> transactions.
thanks for your time,
andrea
---(end of broadcast)---
TIP 2: you can get off all lis
need your opinion if it is something
to do or not. as i said, it takes longer to reproduce this (and maybe i'm
doing something wrong).
thanks a lot for your work,
andrea
n.b.: well, if i try on the same postgres to run other db i've got no
problem, but they are a lot smaller and have
On Tue, Apr 03, 2001 at 12:59:31AM -0400, Tom Lane wrote:
> However, the horology diffs are not, and I can't reproduce them here.
> Did anyone else see that?
me too (the problem started in these days)
ciao,
andrea
---(end of broadcast)--
Your name : Andrea Baldoni
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture : Intel Pentium III 500
Operating System : Linux 2.4.0-test10 (same problem on 2.2.17),
debian 2.2
POSTGRESQL BUG REPORT TEMPLATE
Your name : Andrea Girotto
Your email address : [EMAIL
42 matches
Mail list logo
