On 26.06.2013 17:15, Tom Lane wrote:
Heikki Linnakangas 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() call
, 32 Maskit St., Herzliya 46733, Israel
Mobile: +972 54 6107703, Office: +972 9 9710239; Fax: +972 9 9710222
-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 Lev
Heikki Linnakangas 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 there's more room for a
e; Jeff Davis; Yuri Levinsky; pgsql-bugs@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 wrote:
> > (Though if it is, it's not apparent wh
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 Lane wrote:
> >>> (Though if it is, it's not apparent why such
> >>>failures would only be manifesting o
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 Lane 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 o
On 2013-06-26 13:14:37 +0100, Greg Stark wrote:
> On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane 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 chun
On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane 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 >8k xlog records
Jeff Davis 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 is capable of
On Tue, 2013-06-25 at 09:46 -0400, Tom Lane wrote:
> "Yuri Levinsky" 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 that, or
bricklen 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 given error mes
On Tue, Jun 25, 2013 at 9:43 AM, Yuri Levinsky 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
stats_temp_directory
+972 9 9710222
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 wher
3:00 - (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
+972 9 9710222
-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" writes:
> I hav
"Yuri Levinsky" writes:
> 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
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 destinat
m: Heikki 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 que
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() +
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: c
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 vacu
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 wrote:
> On 1 February 2013 17:54, Colin Dunklau wrote:
>
>> For the below two queries, I expect to get a result of (0.5, 0.5).
>>
>> cdunklau=# select po
Dean Rasheed 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 to the wikipedia
On 1 February 2013 17:54, Colin Dunklau 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 coordinates...
srigg
On 3 February 2013 09:16, Dean Rasheed 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 centroid.
Consider for exam
On 1 February 2013 22:16, Tom Lane wrote:
> Colin Dunklau 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 th
Colin Dunklau 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 on a polygon
> retur
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
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
"liebehenz" 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 planner bugs fixed in betwee
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
b
}
}
-Original Message-
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 worki
On Tue, Sep 25, 2012 at 3:12 PM, Freddie Burgess
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 without making massive c
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;
im
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();
Could
ndles
transactions 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: [B
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
-
From: pgsql-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:
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 wit
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:
Tom
naveen 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 (pgsql-bugs@postgresql.org)
To
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 a
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 er
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
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: dura
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
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 succ
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?
-
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 cont
"simon.marshall" 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 (seen by running ps -eaf
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
rence Cohan
Subject: RE: [BUGS] Postgres not using indexes
Lawrence Cohan 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
>
Lawrence Cohan 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 scripts
> to
r
Sent: March-30-11 4:12 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: Re: [BUGS] Postgres not using indexes
Lawrence Cohan 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
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 p
Greg Stark wrote:
> On Thu, Mar 31, 2011 at 11:33 PM, Kevin Grittner
> wrote:
>> Greg Stark 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
On Thu, Mar 31, 2011 at 11:33 PM, Kevin Grittner
wrote:
> Greg Stark 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 select oi.id from order_items oi inn
Greg Stark 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 the table with 33
On Wed, Mar 30, 2011 at 7:32 PM, Lawrence Cohan 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 this is
> v
: March-30-11 4:12 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: Re: [BUGS] Postgres not using indexes
Lawrence Cohan 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
Lawrence Cohan 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 processing at
Harry Rossignol 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 problem as it once
'log_checkpoints';'on'
'log_destination';'syslog'
'log_line_prefix';'user=%u,db=%d'
'log_min_duration_statement';'1s'
'maintenance_work_mem';'256MB'
'max_connections';'1200'
'ma
7;syslog'
'log_line_prefix';'user=%u,db=%d '
'log_min_duration_statement';'1s'
'maintenance_work_mem';'256MB'
'max_connections';'1200'
'max_stack_depth';'2MB'
'port';'5432'
'server
Lawrence Cohan 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 issue is du
.
-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 wrote:
> From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
>> [conf
Lawrence Cohan 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:
>>
>> htt
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 wrote:
> We have a huge performance issues in Postgres that surfaced due to
> existing i
[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 :
> We have a huge performance issues in Postgres that surfaced due to existing
> indexes not being used like
Lawrence Cohan 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:
http://wiki.postgresql.org/wiki/Tuning_You
rence 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 o
Hello
2011/3/30 Lawrence Cohan :
> 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 r
. 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 in
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 k
Fujii Masao wrote:
On Wed, Mar 23, 2011 at 9:07 PM, Alex Lai 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
On Wed, Mar 23, 2011 at 9:07 PM, Alex Lai 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 master by
@postgresql.org
Subject: Re: [BUGS] postgres 9 streaming replication
On Tue, Jan 25, 2011 at 8:59 PM, Khadtare, Sharad
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
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
ile or
directory
LOG: archive recovery complete
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: pgsq
@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
On Tue, Jan 25, 2011 at 8:59 PM, Khadtare, Sharad
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 this has occurred more th
On Tue, Jan 25, 2011 at 5:01 PM, Khadtare, Sharad
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.
What log messages did
-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 sugges
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 & st
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 will
On 5/10/2010 10:02 AM, Tom Lane wrote:
Craig Ringer 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 attnu
Craig Ringer 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 * index_expr=0x000
On 4/10/2010 10:56 AM, Tom Lane wrote:
Craig Ringer 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
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;
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
sp
On 04/10/10 10:56, Tom Lane wrote:
> Craig Ringer 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 r
Craig Ringer 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.
> It looks like it's o
On 10/03/2010 05:11 PM, Andrea Peri wrote:
Hi, thx for response.
>Does that include PostGIS datatypes?
yes, but after some email with the guys of Posgis team , I think the
problem is related to postgres.
(see this thread on postgis ML):
http://postgis.refractions.net/pipermail/postgis-users/2
On 4/10/2010 4:41 AM, Andrea Peri 2007 wrote:
Hi,
I have some update on the crash of pg9.0.
seem that PG9 will crash even on windows 32bit.
Yes, it will. I've just been able to reproduce it here with your script,
on 32-bit win7. I should be able to report where it's crashing shortly.
I gav
Hi,
I have some update on the crash of pg9.0.
seem that PG9 will crash even on windows 32bit.
But meanwhile in win7-64 bit crash always at first try, in win7 32bit it
crash
from first and second time after restart.
As report here from Postgis Team.
http://postgis.refractions.net/pipermail/p
>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, a
Hi, thx for response.
>Does that include PostGIS datatypes?
yes, but after some email with the guys of Posgis team , I think the problem
is related to postgres.
(see this thread on postgis ML):
http://postgis.refractions.net/pipermail/postgis-users/2010-October/027841.html
The postgis team was
On 2/10/2010 9:08 PM, Andrea Peri wrote:
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.
Do
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 22:38:
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> On Sat, 2010-09-25 at 12:21 +0200, r d wrote:
>> --> I expect the installer to install the system service into the list
>> ofervices/daemons which are started at boot.
> Nope. RPMs have never ever added PostgreSQL to startup sequence by
> default.
Ri
1 - 100 of 247 matches
Mail list logo
