-Original Message-
From: Andres Freund [mailto:and...@2ndquadrant.com]
Sent: Wednesday, June 26, 2013 4:04 PM
To: Heikki Linnakangas
Cc: Greg Stark; Tom Lane; Jeff Davis; Yuri Levinsky;
pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres crash? could not write to log file: No
spaceleft
On 26.06.2013 17:15, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
We've discussed retrying short writes before, and IIRC Tom has argued
that it shouldn't be necessary when writing to disk. Nevertheless, I
think we should retry in XLogWrite(). It can write much bigger
On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
(Though if it is, it's not apparent why such
failures would only be manifesting on the pg_xlog files and not for
anything else.)
Well data files are only ever written to in 8k chunks. Maybe these
errors are only occuring on
On 2013-06-26 13:14:37 +0100, Greg Stark wrote:
On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
(Though if it is, it's not apparent why such
failures would only be manifesting on the pg_xlog files and not for
anything else.)
Well data files are only ever written to
On 26.06.2013 15:21, Andres Freund wrote:
On 2013-06-26 13:14:37 +0100, Greg Stark wrote:
On Wed, Jun 26, 2013 at 12:57 AM, Tom Lanet...@sss.pgh.pa.us wrote:
(Though if it is, it's not apparent why such
failures would only be manifesting on the pg_xlog files and not for
anything else.)
On 2013-06-26 15:40:08 +0300, Heikki Linnakangas wrote:
On 26.06.2013 15:21, Andres Freund wrote:
On 2013-06-26 13:14:37 +0100, Greg Stark wrote:
On Wed, Jun 26, 2013 at 12:57 AM, Tom Lanet...@sss.pgh.pa.us wrote:
(Though if it is, it's not apparent why such
failures would only be
@postgresql.org
Subject: Re: [BUGS] Postgres crash? could not write to log file: No
spaceleft on device
On 2013-06-26 13:14:37 +0100, Greg Stark wrote:
On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
(Though if it is, it's not apparent why such failures would only
Heikki Linnakangas hlinnakan...@vmware.com writes:
We've discussed retrying short writes before, and IIRC Tom has argued
that it shouldn't be necessary when writing to disk. Nevertheless, I
think we should retry in XLogWrite(). It can write much bigger chunks
than most write() calls, so
Dear All,
I have the following issue on Sun Solaris 10. PostgreSQL version is
9.2.3. The wall logging is minimal and no archiving. The DB restarted
several time, the box is up for last 23 days. The PostgreSQL
installation and files under /data/postgres that is half empty. Is it
some other
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Tuesday, June 25, 2013 4:47 PM
To: Yuri Levinsky
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres crash? could not write to log file: No
spaceleft on device
Yuri Levinsky yu...@celltick.com writes:
I have the following
(UTC)
Subject: [BUGS] Postgres crash? could not write to log file: No space left on
device
Dear All, I have the following issue on Sun Solaris 10. PostgreSQL version is
9.2.3. The wall logging is minimal and no archiving. The DB restarted several
time, the box is up for last 23 days
From: Lou Picciano [mailto:loupicci...@comcast.net]
Sent: Tuesday, June 25, 2013 5:34 PM
To: Yuri Levinsky
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres crash? could not write to log file: No spaceleft
on device
Yuri, You're sure the pg xlogs are going where you expect them
On Tue, Jun 25, 2013 at 9:43 AM, Yuri Levinsky yu...@celltick.com wrote:
I inspected my config file and didn't see any destination that isn't
/data/postgres. Have I perform any specific setting to limit it into
/data/postgres?
Execute from psql:
show stats_temp_directory
bricklen brick...@gmail.com writes:
Assuming your stats_temp_directory is pg_stat_tmp, where is that directory
located? Under $PGDATA?
What is the path to $PGDATA?
If your stats_temp_directory is located on a small partition, that could be
a problem
Where is your pg_xlog dir located?
The
On Tue, 2013-06-25 at 09:46 -0400, Tom Lane wrote:
Yuri Levinsky yu...@celltick.com writes:
PANIC: could not write to log file 81, segment 125 at offset 13959168,
length 1392640: No space left on device
That's definitely telling you it got ENOSPC from a write in
$PGDATA/pg_xlog.
Either
Jeff Davis pg...@j-davis.com writes:
On Tue, 2013-06-25 at 09:46 -0400, Tom Lane wrote:
That's definitely telling you it got ENOSPC from a write in
$PGDATA/pg_xlog.
Either that, or write() wrote less than expected but did not set errno.
Good point. I wonder if he's using a filesystem that
Linnakangas [mailto:hlinnakan...@vmware.com]
Sent: Saturday, April 13, 2013 1:40 AM
To: Singh, Devendra
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] postgres 8.4 PQexec hang on HP-UX
On 12.04.2013 09:41, Singh, Devendra wrote:
Hi All,
I hit a hang issue in postgres 8.4 query. Hit this issue
Hi All,
I hit a hang issue in postgres 8.4 query. Hit this issue multiple time on
HP-UX. Below is the snapshot of the hang thread.
lwpid : 600943
---
0: c054ced0 : _poll_sys() + 0x30 (/usr/lib/hpux64/libc.so.1)
1:
On 12.04.2013 09:41, Singh, Devendra wrote:
Hi All,
I hit a hang issue in postgres 8.4 query. Hit this issue multiple time on
HP-UX. Below is the snapshot of the hang thread.
lwpid : 600943
---
0: c054ced0 : _poll_sys()
Hello Guys
I have following situation:
PostgreSQL Database 9.1 32 Bit is crashing immediately, it's an Windows 2008R2.
I have patched to 9.2 64Bit, but is crashing with the same Exit code
What is exit code 9??
Here is an cut from the postgres.log
013-01-31 14:42:08 CETCONTEXT: automatic
You nailed it, stupid typos.
Sorry for the inconvenience, and thank you all for your assistance.
On Sun, Feb 3, 2013 at 3:33 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 1 February 2013 17:54, Colin Dunklau colin.dunk...@gmail.com wrote:
For the below two queries, I expect to get a result
On 1 February 2013 22:16, Tom Lane t...@sss.pgh.pa.us wrote:
Colin Dunklau colin.dunk...@gmail.com writes:
Hello! I believe I've found a bug in the type conversion process from
polygon to point.
In the documentation found here
On 3 February 2013 09:16, Dean Rasheed dean.a.rash...@gmail.com wrote:
It looks like what the code is actually computing is the average X
position and average Y position of the points listed in the polygon.
Although, if that's really how it's being calculated, then that's not
really the
On 1 February 2013 17:54, Colin Dunklau colin.dunk...@gmail.com wrote:
For the below two queries, I expect to get a result of (0.5, 0.5).
cdunklau=# select point( polygon '((0,0),(0,1),(1,1),(0,1))');
point
-
(0.25,0.75)
(1 row)
I think you just simply mistyped the
Dean Rasheed dean.a.rash...@gmail.com writes:
It looks like what the code is actually computing is the average X
position and average Y position of the points listed in the polygon.
Although, if that's really how it's being calculated, then that's not
really the centroid.
Yeah --- according
Hello! I believe I've found a bug in the type conversion process from
polygon to point.
In the documentation found here
http://www.postgresql.org/docs/9.2/interactive/functions-geometry.html,
Table 9-32 claims that running the point() function on a polygon
returns the center of polygon. This is
Colin Dunklau colin.dunk...@gmail.com writes:
Hello! I believe I've found a bug in the type conversion process from
polygon to point.
In the documentation found here
http://www.postgresql.org/docs/9.2/interactive/functions-geometry.html,
Table 9-32 claims that running the point() function
liebehenz liebeh...@mts-software.com writes:
i have here a strange bug.
Can't really say anything about this without a self-contained test case
(which your screenshot isn't, even if it were 100% readable).
However, are you sure that it's 9.2.2 and not 9.2.1 that's wrong?
There were several
liebehenz wrote:
a_name (char var 48) is sometimes empty in the select of the new 9.2.2
Version,
the a_name is in the table column set.
Something is going wrong.
here in screenshot same identical database on 9.2.1 Server and 9.2.2 Server
Character-based results are preferred on a list
Does anyone know of any known issues (show-stoppers) with upgrading to
Postgresql 9.2 but retaining Postgis 1.5.3 or Postgis 1.5.5?
Thanks
In hibernate 3.3.2.GA, We previously utilized this java program to address
ingesting data into our PostgreSQL partitioned tables.
package im.empl.core.service.ingest.postgres;
import org.hibernate.Interceptor;
import org.hibernate.jdbc.Batcher;
import org.hibernate.jdbc.BatchingBatcherFactory;
On Tue, Sep 25, 2012 at 3:12 PM, Freddie Burgess
fburg...@radiantblue.com wrote:
Does anyone know why the previous .jdbc.batcher logic managed the postgres
partitioned inserts without any issues?
Are there any other alternative that will allow us to insert into a Postgres
partition table
-
From: jcasa...@systemguards.com.ec [mailto:jcasa...@systemguards.com.ec] On
Behalf Of Jaime Casanova
Sent: Tuesday, September 25, 2012 4:50 PM
To: Freddie Burgess
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres Partitions not working with hibernate
4.1.6.Final
On Tue, Sep 25, 2012 at 3
programmatically.
Any workarounds to resolve this issue would be greatly appreciated.
thanks
-Original Message-
From: Craig Ringer [mailto:ring...@ringerc.id.au]
Sent: Tuesday, September 18, 2012 12:29 AM
To: Freddie Burgess
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres JDBC-hibernate
On 09/19/2012 03:46 AM, Freddie Burgess wrote:
The Employee ingest behaves a bit differently - it handles transactions
programmatically, for example:
Transaction tx = session.beginTransaction();
session.save(Employee);
tx.commit();
-bugs-ow...@postgresql.org
[mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Craig Ringer
Sent: Monday, September 17, 2012 12:39 AM
To: Freddie Burgess
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres JDBC-hibernate Problem
On 09/12/2012 12:18 AM, Freddie Burgess wrote:
We have
On 09/18/2012 01:23 AM, Freddie Burgess wrote:
Thanks Craig,
We were able to make the necessary adjustments to the way Hibernate manages
the data types differently in version 4.1.6, so we got pass this error. Now
we have to tackle the a problem with the hibernate 4.1.6 batcher process no
longer
On 09/12/2012 12:18 AM, Freddie Burgess wrote:
We have upgraded from PostgreSQL 8.4.3 to PostgreSQL 9.1.4 and we are
getting the following errors when attempting to auto-gen schema DDL.
You've changed quite a bit at once, so it's a bit hard to narrow down.
Does the error occur when you run
We have upgraded from PostgreSQL 8.4.3 to PostgreSQL 9.1.4 and we are
getting the following errors when attempting to auto-gen schema DDL.
Old Configuration:
WEB-INF/lib/postgis-jdbc-1.3.3.jar,
WEB-INF/lib/postgis-stubs-1.3.3.jar,
WEB-INF/lib/postgresql-8.3-603.jdbc4.jar,
New Configuration:
Hi,
I am using postgres database server 8.3 for my internal project
installed in windows machine.
Database size is crossed more than 22 GB and tried to take backup using
the postgres back up command. But, backup process takes more time and
process is unsuccessful.
Can you able to suggest
naveen nav...@vortexindia.co.in wrote:
backup process takes more time
How much?
process is unsuccessful.
In what way? Is there an error message? If so, please paste it.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing list
Hi Team,
I am having a problem using created.exe
I am using the script as follows and is executed from nullsoft
NSIS Script.
Createdb.exe -q -username=postgres pacsdsb
In every os it works fine except in winXP pro. Please suggest on this.
Regards,
Mithun Antony
On 12/08/11 9:55 PM, Mithun Antony wrote:
I am having a problem using created.exe
I am using the script as follows and is executed from nullsoft NSIS
Script.
“Createdb.exe –q –username=postgres pacsdsb”
In every os it works fine except in winXP pro. Please suggest on this.
what is the
We get error with the following query where the paramater is 'att', the
query return result if the parameter is different than 'att'.
Probably a bug.
the postgresql log is:
2011-08-04 10:44:56 CEST [28741]: [59238-1] LOG: execute S_1: BEGIN
2011-08-04 10:44:56 CEST [28741]: [59239-1] LOG:
Hi guys,
When I came to stop my postgres instance (in particular, a replication
database using postgres version 9.0.3 running on port 5442) today it failed
to stop because the postmaster.pid instance wasn't present, despite the
process still running (seen by running ps -eaf | grep post and noting
simon.marshall simon.marsh...@metaswitch.com writes:
When I came to stop my postgres instance (in particular, a replication
database using postgres version 9.0.3 running on port 5442) today it failed
to stop because the postmaster.pid instance wasn't present, despite the
process still running
Thanks for your speedy response Tom. Seems like that is indeed what happens
elsewhere in the convoluted mess that are our backup scripts. Am
disappointed I didn't think of grepping for that myself! Too high a view of
my colleagues, now going downhill ;-)
Thanks,
Simon
--
View this message in
In fact, looking at it further, we stop the database (only continuing if this
succeeds), copy our backup data over, remove the copied over postmaster.pid,
make some config. changes and then (again, only if all this succeeds), start
the database again, which should surely recreate postmaster.pid?
Excerpts from simon.marshall's message of mié ago 03 11:56:55 -0400 2011:
In fact, looking at it further, we stop the database (only continuing if this
succeeds), copy our backup data over, remove the copied over postmaster.pid,
make some config. changes and then (again, only if all this
Exactly so :-) (Seems simpler and I wouldn't have thought it would be a
problem to just remove the one, very small, file after the copy)
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Postgres-running-but-no-postmaster-pid-tp4662510p4662780.html
Sent from the PostgreSQL
-bugs@postgresql.org; Lawrence Cohan
Subject: Re: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com wrote:
looks like we will need to change at least the two values below
and maybe play with work_mem to see if it solves our issues.
You will probably get better throughput by bumping
Lawrence Cohan lco...@web.com wrote:
We managed to put together a new test server running PG 9.0.2 on
2socketsx6cores = 12CPU with 64 GB RAM against a 3PAR 10TB SAN. We
kept the settings I submitted already (and enclosed below) and
after 12 hours of pounding the box with PGBENCH running 8
Cohan
Subject: RE: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com wrote:
We managed to put together a new test server running PG 9.0.2 on
2socketsx6cores = 12CPU with 64 GB RAM against a 3PAR 10TB SAN. We
kept the settings I submitted already (and enclosed below) and
after 12
Greg Stark gsst...@mit.edu wrote:
On Thu, Mar 31, 2011 at 11:33 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Greg Stark gsst...@mit.edu wrote:
your query does require reading all the data.
Huh? It requires reading all the data from at least *one* of the
tables.
The query he
Thank you for all your suggestions and I hope the set enable_seqscan = off;
will work for the time being until we can make PG config changes and more
testing in the near future. We expect indeed much better performance with index
being used on the 33+million rows table vs seq scan and I will
On Wed, Mar 30, 2011 at 7:32 PM, Lawrence Cohan lco...@web.com wrote:
Please see updated attachment that includes the tables involved in the simple
query below and all their indexes. We believe that the performance issue is
due to the query not using any index but doing seq scans instead and
Greg Stark gsst...@mit.edu wrote:
your query does require reading all the data.
Huh? It requires reading all the data from at least *one* of the
tables. I could conceivably be faster to read all the data from the
table with 23,980 rows and randomly pick out the necessary 33,768
rows from
On Thu, Mar 31, 2011 at 11:33 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Greg Stark gsst...@mit.edu wrote:
your query does require reading all the data.
Huh? It requires reading all the data from at least *one* of the
tables.
The query he posted a plan for was:
EXPLAIN ANALYZE
We have a huge performance issues in Postgres that surfaced due to existing
indexes not being used like in the example below in both 8.35 and 9.0 versions.
Client_Orders table with and int ID as PK which is the order_id and indexed -
about 155,000 rows
Order_Items table with and int ID primary
. I've also noticed that limit behavior which is sort of puzzling
to me.
From: pgsql-bugs-ow...@postgresql.org
[mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Lawrence Cohan
Sent: Wednesday, March 30, 2011 10:01 AM
To: pgsql-bugs@postgresql.org
Subject: [BUGS] Postgres not using indexes
Hello
2011/3/30 Lawrence Cohan lco...@web.com:
We have a huge performance issues in Postgres that surfaced due to existing
indexes not being used like in the example below in both 8.35 and 9.0
versions.
Client_Orders table with and int ID as PK which is the order_id and indexed
– about
Cohan; pgsql-bugs@postgresql.org
Subject: RE: [BUGS] Postgres not using indexes
I force postgresql to use indexes instead of sequential scans by setting
enable_seqscan = off in postgresql.conf and it helps in a lot of cases.
Probably not the best practice, but it does improve a lot
Lawrence Cohan lco...@web.com wrote:
We have a huge performance issues in Postgres that surfaced due to
existing indexes not being used
This doesn't sound like a bug; it sounds like you haven't tuned your
server.
For starters, you should check out this page:
[mailto:pavel.steh...@gmail.com]
Sent: March-30-11 12:08 PM
To: Lawrence Cohan
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres not using indexes
Hello
2011/3/30 Lawrence Cohan lco...@web.com:
We have a huge performance issues in Postgres that surfaced due to existing
indexes not being used like
Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: March-30-11 12:45 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: Re: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com wrote:
We have a huge performance issues in Postgres that surfaced due
Lawrence Cohan lco...@web.com wrote:
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
[configuration advice]
If, after reading the above-cited page and tuning your server you
still have performance problems, pick one query to work on first,
and follow the step outlined here:
.
-Original Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: March-30-11 1:33 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: RE: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com wrote:
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov
Lawrence Cohan lco...@web.com wrote:
Please see updated attachment that includes the tables involved in
the simple query below and all their indexes.
Well, that rules out a couple common problems (comparisons between
different types and incorrect indexing).
We believe that the performance
[mailto:kevin.gritt...@wicourts.gov]
Sent: March-30-11 1:33 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: RE: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com wrote:
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
[configuration advice]
If, after reading the above
';'hot_standby'
-Original Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: March-30-11 1:33 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: RE: [BUGS] Postgres not using indexes
Lawrence Cohanlco...@web.com wrote:
From: Kevin Grittner [mailto:kevin.gritt
Harry Rossignol harry...@comcast.net wrote:
I'm just a lowly end user. Bumping the default statistics target
or using ALTER TABLE SET STATISTICS has made large differences in
query performance on large tables.
The default has been bumped up in later versions, so that shouldn't
be as big a
Lawrence Cohan lco...@web.com wrote:
looks like we will need to change at least the two values below
and maybe play with work_mem to see if it solves our issues.
You will probably get better throughput by bumping up
shared_buffers to the recommended setting, but beware of stalls in
query
: March-30-11 4:12 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: Re: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com wrote:
looks like we will need to change at least the two values below
and maybe play with work_mem to see if it solves our issues.
You will probably get
Fujii Masao wrote:
On Wed, Mar 23, 2011 at 9:07 PM, Alex Lai a...@sesda2.com wrote:
I have no idea why I keep getting the message:\
could not connect to the primary server: FATAL: no pg_hba.conf entry for
replication connection from host slave_server_ip, user
my_super_user_name
Can
On Wed, Mar 23, 2011 at 9:07 PM, Alex Lai a...@sesda2.com wrote:
I have no idea why I keep getting the message:\
could not connect to the primary server: FATAL: no pg_hba.conf entry for
replication connection from host slave_server_ip, user
my_super_user_name
Can you connect from slave to
@postgresql.org
Subject: Re: [BUGS] postgres 9 streaming replication
On Tue, Jan 25, 2011 at 8:59 PM, Khadtare, Sharad sharad.khadt...@teamaol.com
wrote:
Pls find below logfile of standby and recovery.conf in standby data directory.
bash-3.2$ cat logfile
LOG: database system was interrupted while
Hi,
Configured postgres 9 streaming replication and changed parameter in
postgresql.conf pg_hba.conf file
Problem is wal sender receiver process not started , is there any way to
check process please suggest.
172.21.132.1 ( primary )
172.18.221.211 ( standby )
pg_hba.conf (primary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Khadtare, Sharad wrote:
Hi,
Configured postgres 9 streaming replication and changed parameter in
postgresql.conf pg_hba.conf file
Problem is wal sender receiver process not started , is there any way
to check process please suggest.
1.
On Tue, Jan 25, 2011 at 5:01 PM, Khadtare, Sharad
sharad.khadt...@teamaol.com wrote:
Configured postgres 9 streaming replication and changed parameter in
postgresql.conf pg_hba.conf file
Problem is wal sender receiver process not started , is there any way to
check process please suggest.
On Tue, Jan 25, 2011 at 8:59 PM, Khadtare, Sharad
sharad.khadt...@teamaol.com wrote:
Pls find below logfile of standby and recovery.conf in standby data directory.
bash-3.2$ cat logfile
LOG: database system was interrupted while in recovery at log time
2011-01-25 05:28:35 EST
HINT: If
@postgresql.org
Subject: Re: [BUGS] postgres 9 streaming replication
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Khadtare, Sharad wrote:
Hi,
Configured postgres 9 streaming replication and changed parameter in
postgresql.conf pg_hba.conf file
Problem is wal sender receiver process not started
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
Regards,
Sharad k
-Original Message-
From: Fujii Masao [mailto:masao.fu...@gmail.com]
Sent: Tuesday, January 25, 2011 3:38 PM
To: Khadtare, Sharad
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS
Hi,
Problem solved after removing trigger entry from recovery.conf file
Thx for help
Regards,
Sharad K
-Original Message-
From: Fujii Masao [mailto:masao.fu...@gmail.com]
Sent: Tuesday, January 25, 2011 5:55 PM
To: Khadtare, Sharad
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS
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,
Yes, I
Just an update on this issue:
I've been able to reproduce the crash (thanks for the test case!) and
obtain the crash information here on my 32-bit windows 7 install, so
there's no need for you to do anything else so far.
I still can't get a usable backtrace. The autovacuum workers/launcher
Hi,
I have do some other test.
I set
autovacuum = off.
With this setting the server don't crash.
But certainly something go bad.
Infact
if (after run the query) I connect with posql as user 'postgres' and try
a single command
VACUUM;
nothing happened.
But if I try a
single command
ANALYZE;
On 4/10/2010 10:56 AM, Tom Lane wrote:
Craig Ringercr...@postnewspapers.com.au writes:
While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
been able to get a backtrace yet. I thought it'd be trivial given the
ease of reproducing the crash - but the process that's crashing
Craig Ringer cr...@postnewspapers.com.au writes:
After turning autovacuum off completely, though, it does crash when
ANALYZE is run.
postgres.exe!pfree(void * pointer=0x68f08610) Line 591 + 0x3 bytes C
postgres.exe!examine_attribute(RelationData * onerel=0x, int
attnum=5, Node *
On 5/10/2010 10:02 AM, Tom Lane wrote:
Craig Ringercr...@postnewspapers.com.au writes:
After turning autovacuum off completely, though, it does crash when
ANALYZE is run.
postgres.exe!pfree(void * pointer=0x68f08610) Line 591 + 0x3 bytes C
postgres.exe!examine_attribute(RelationData *
Truly, the most helpful thing at this point would be to collect a
backtrace showing where in the postgresql server it crashed.
There are instructions on how to do that here:
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
In your case, as
Craig Ringer cr...@postnewspapers.com.au writes:
While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
been able to get a backtrace yet. I thought it'd be trivial given the
ease of reproducing the crash - but the process that's crashing isn't
the backend running the query.
On 04/10/10 10:56, Tom Lane wrote:
Craig Ringer cr...@postnewspapers.com.au writes:
While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
been able to get a backtrace yet. I thought it'd be trivial given the
ease of reproducing the crash - but the process that's crashing
Hi,
I'm using usually
Postgres 8.4.4 (32bit) + Postgis 1.5.1 on Windows7 64bit.
Now I try-ing the last
Postgres 9.0 (32bit) + Postgis 1.5.2 on the same machine (win7 64bit).
I experience a
crash of Postgres while it is running a huge load of data.
This is the report of log.
2010-10-01
Hi,
I updated PostgreSQL from 8.4.4 to 9.0.0 from repo (PGDG) via yum and it
leaves some business unfinished IMHO.
I have a Fedora Core FC12 (Linux 2.6.32.21-168.fc12.x86_64) up-to-date.
So, after the upgrade, I found the following:
a) The postgresql service is not present anymore, so I must
Hi,
I'm using libpq PQexecParams ability to send query parameters as binary data,
more specific - a binary representation of an empty array.
I have the problem:
the code sending empty binary array works on 8.3 and 8.4
but stopped working on postgres 9.0 beta2/3/4, it fails with
vsha...@alliedtesting.com writes:
I have the problem:
the code sending empty binary array works on 8.3 and 8.4
but stopped working on postgres 9.0 beta2/3/4, it fails with '22003','integer
out of range error'.
I think you are right --- this rejects dim[i] == 0, but it should not.
On 09/08/10 17:56, Tom Lane wrote:
vsha...@alliedtesting.com writes:
I have the problem:
the code sending empty binary array works on 8.3 and 8.4
but stopped working on postgres 9.0 beta2/3/4, it fails with '22003','integer
out of range error'.
I think you are right --- this rejects dim[i]
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
The behavior of empty arrays with dimensions is weird in general.
Agreed, but we shouldn't be introducing random restrictions in the name
of security.
Patch looks good to me, except that it occurs to me to wonder about
negative
On 09/08/10 21:26, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
The behavior of empty arrays with dimensions is weird in general.
Agreed, but we shouldn't be introducing random restrictions in the name
of security.
Patch looks good to me, except that it
On Thu, Jun 24, 2010 at 11:02 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 24, 2010 at 4:50 PM, Chris Browne cbbro...@acm.org wrote:
alvhe...@commandprompt.com (Alvaro Herrera) writes:
Excerpts from Chris Browne's message of jue jun 24 14:40:30 -0400 2010:
robertmh...@gmail.com
1 - 100 of 217 matches
Mail list logo
