[BUGS] server connection

Hello. i tried to follow suggestions,tried to disactivate every service of WIN 7 can trouble  your service,tried to install every version of your software,but I'm not able to connect to the server when i try to open hold em manager. I even tried to read FAQ in your support section,tried to rea

Re: [BUGS] BUG #6269: Anomaly detection

Kevin Grittner wrote: > > Actually, since we (mostly you) found explanations for all the > disallowed phenomena, with no PostgreSQL anomalies showing when > using the corrected test code, I was going to call it done. Well, > except that I think some of your tests are interesting enough to ask >

[BUGS] pg_restore: [custom archiver] error during file seek: Invalid argument

Dear Supporter, We are trying to restore a 3.2GB sized POstgreSql 8.1 Data base. When it is reaching a particular table restoration, giving error as "pg_restore: [custom archiver] error during file seek: Invalid argument" and exiting the restoration. Then when we have googled it, we found that

Re: [BUGS] BUG #6275: Horrible performance regression

Hi Tom Sorry for the delay. The version of postgis didn't change, and when I rolled back to postgresql 8.4.9 the expected performance returned. I am very confident the regression was caused by the 8.4.9 upgrade. Any suggestions on how to diagnose a long run script like this ? I can easily turn

Re: [BUGS] pg_restore: [custom archiver] error during file seek: Invalid argument

On 31.10.2011 07:55, Satheesan K Nair wrote: We are trying to restore a 3.2GB sized POstgreSql 8.1 Data base. When it is reaching a particular table restoration, giving error as "pg_restore: [custom archiver] error during file seek: Invalid argument" and exiting the restoration. Then when we h

Re: [BUGS] BUG #6277: Money datatype conversion wrong with Russian locale

Thank you, Tom. I tried patched file and it works fine now (with Russian locale both in Linux and Windows). I've noticed that you strict mon_decimal_point to one char, but at least two locales (fa_IR and ps_AF) (I looked at glibc-2.14) define mon_decimal_point as "" so it takes two bytes. And I

Re: [BUGS] pg_restore: [custom archiver] error during file seek: Invalid argument

On 31.10.2011 12:12, Satheesan K Nair wrote: Our Operating System is Windows XP. Should we need to do any changes in any kind of configurations in Windows XP or PostgreSql?? According to the commit logs, there was a win32-related fix to this on 8.2, and some further MinGW-related changes in 8

Re: [BUGS] pg_restore: [custom archiver] error during file seek: Invalid argument

On Mon, Oct 31, 2011 at 12:03, Heikki Linnakangas wrote: > On 31.10.2011 12:12, Satheesan K Nair wrote: >> >> Our Operating System is Windows XP. >> >> Should we need to do any changes in any kind of configurations in >> Windows XP or PostgreSql?? > > According to the commit logs, there was a win3

Re: [BUGS] BUG #6275: Horrible performance regression

On Sun, Oct 30, 2011 at 10:30 PM, Finlay Thompson wrote: > Hi Tom > > Sorry for the delay. > > The version of postgis didn't change, and when I rolled back to > postgresql 8.4.9 the expected performance returned. I am very confident > the regression was caused by the 8.4.9 upgrade. > > Any suggest

Re: [BUGS] BUG #6274: documentation on pg_attribute.atttypmod

On Thu, Oct 27, 2011 at 11:23 AM, Jan-Peter Seifert wrote: > it looks like that the remarks on column pg_attribute.atttypmod haven't been > updated for a while: > > http://www.postgresql.org/docs/current/interactive/catalog-pg-attribute.html > > It obviously does contain the actual value ( possibl

Re: [BUGS] BUG #6278: Index scans on '>' condition on field with many NULLS

On Sun, Oct 30, 2011 at 11:39 PM, Maksym Boguk wrote: > However very selective index scan on '>' condition can work pretty > inefficient on column with many nulls. > (in the same time '<' work well). > > Seems index scan on '>' condition going through all nulls in index. > > Test case (tested on 8

[BUGS] BUG #6279: quoting needed for column name with non ascii chars

The following bug has been logged online: Bug reference: 6279 Logged by: Laurian Vostinar Email address: lvosti...@servoy.com PostgreSQL version: 9.0 Operating system: Windows 7 Description:quoting needed for column name with non ascii chars Details: I run sql from

Re: [BUGS] pg_restore: [custom archiver] error during file seek: Invalid argument

ok... let me try the same and check. Thanks for your valuable support. - Original Message - From: "Heikki Linnakangas" To: "Satheesan K Nair" Cc: Sent: Monday, October 31, 2011 4:33 PM Subject: Re: [BUGS] pg_restore: [custom archiver] error during file seek: Invalid argument

Re: [BUGS] pg_restore: [custom archiver] error during file seek: Invalid argument

Hi Heiki, Our Operating System is Windows XP. Should we need to do any changes in any kind of configurations in Windows XP or PostgreSql?? We are trying to restore the data base backup in 8.1 version through 9.1 PGAdmin III. PGDump ran through "Fedora Linux 10 (Data Base Server) OS". Is t

Re: [BUGS] BUG #6278: Index scans on '>' condition on field with many NULLS

Robert Haas writes: > On Sun, Oct 30, 2011 at 11:39 PM, Maksym Boguk wrote: >> Seems index scan cannot stop after finding first NULL during scan on '>' >> condition, and doing scan through all 90% nulls in table. > I can reproduce this. I'm not sure whether it's a bug either, but it > sure seem

Re: [BUGS] BUG #6275: Horrible performance regression

On Mon, Oct 31, 2011 at 1:50 PM, Robert Haas wrote: > If you can't do that for some reason, there's always auto_explain, but > that has some overhead and is a bit more work to set up. If it's a massive load of data with a lot of queries, I think his best bet is to log the queries with log_min_dur

Re: [BUGS] BUG #6278: Index scans on '>' condition on field with many NULLS

On Mon, Oct 31, 2011 at 10:37 AM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Oct 30, 2011 at 11:39 PM, Maksym Boguk wrote: >>> Seems index scan cannot stop after finding first NULL during scan on '>' >>> condition, and doing scan through all 90% nulls in table. > >> I can reproduce this.  

Re: [BUGS] server connection

On Sat, Oct 29, 2011 at 5:05 AM, guido palmieri wrote: > i tried to follow suggestions,tried to disactivate every service of WIN 7 > can trouble  your service,tried to install every version of your > software,but I'm not able to connect to the server when i try to open hold > em manager. > I even

Re: [BUGS] BUG #6279: quoting needed for column name with non ascii chars

On Mon, Oct 31, 2011 at 8:38 AM, Laurian Vostinar wrote: > > The following bug has been logged online: > > Bug reference:      6279 > Logged by:          Laurian Vostinar > Email address:      lvosti...@servoy.com > PostgreSQL version: 9.0 > Operating system:   Windows 7 > Description:        quot

Re: [BUGS] BUG #6278: Index scans on '>' condition on field with many NULLS

I wrote: > I poked at this a bit last night. The reason it's happening is that the > ">" key is only marked SK_BT_REQBKWD, not SK_BT_REQFWD, so _bt_checkkeys > doesn't think it can stop when it hits the NULLs. Right at the moment > it seems like we could mark that key with both flags, which leads

Re: [BUGS] BUG #6279: quoting needed for column name with non ascii chars

Hello, Laurian. You wrote: LV> The following bug has been logged online: LV> Bug reference: 6279 LV> Logged by: Laurian Vostinar LV> Email address: lvosti...@servoy.com LV> PostgreSQL version: 9.0 LV> Operating system: Windows 7 LV> Description:quoting needed for co

Re: [BUGS] BUG #6278: Index scans on '>' condition on field with many NULLS

On Mon, Oct 31, 2011 at 12:43 PM, Tom Lane wrote: > A patch along these lines should be pretty localized.  Has anyone > got an opinion on whether to back-patch or not?  This seems like a > performance bug, but given the lack of prior complaints, maybe we > shouldn't take any risks for it. I think

Re: [BUGS] BUG #6278: Index scans on '>' condition on field with many NULLS

Robert Haas writes: > On Mon, Oct 31, 2011 at 12:43 PM, Tom Lane wrote: >> A patch along these lines should be pretty localized. Has anyone >> got an opinion on whether to back-patch or not? This seems like a >> performance bug, but given the lack of prior complaints, maybe we >> shouldn't take

Re: [BUGS] server connection

On 29/10/11 17:05, guido palmieri wrote: > > > Hello. > i tried to follow suggestions,tried to disactivate every service of WIN > 7 can trouble your service,tried to install every version of your > software,but I'm not able to connect to the server whe

[BUGS] Hanging with pg_restore and large objects

Hi all. I've encountered the following problem: pg_restore hangs while restoring LOBs. The situation is as follows: 1) TARed dump, created by pg_dump 8.3.6 2) pg_restore from Postgresql 9.1.1 3) pg_restore restores schema and most of LOBs, but hangs on one of them (the same

[BUGS] BUG #6280: adminpack.sql not found after postgresql-contrib has been installed

The following bug has been logged online: Bug reference: 6280 Logged by: Eye Gee Email address: eye...@cmg.com.my PostgreSQL version: 9.1.1 Operating system: SUSE 11 SP1 Description:adminpack.sql not found after postgresql-contrib has been installed Details: Hi, I

Re: [BUGS] BUG #6280: adminpack.sql not found after postgresql-contrib has been installed

"Eye Gee" writes: > I got the warning hint: "Server instrumentation not installed" when login > using pgAdminIII. It sounds like you need to get a newer version of pgAdmin, ie, one that has heard of PG 9.1. > I have installed postgresql-contrib-9.1.1-58.2.x86_64.rpm into SUSE 11 SP > 1. > But ad

Re: [BUGS] BUG #6275: Horrible performance regression

On 28/10/11 15:42, Finlay Thompson wrote: After upgrading the postgresql*-8.4 packages on ubuntu, to version 8.4.9, the script suddenly stopped working, and consuming all the ram (16GB) on the computer (i7). If there is one query exhausting all ram, then it could be tricky to catch it in the

Re: [BUGS] Hanging with pg_restore and large objects

On 01/11/11 02:46, Alexander wrote: > Hi all. > > I've encountered the following problem: pg_restore hangs while > restoring LOBs. The situation is as follows: > 1) TARed dump, created by pg_dump 8.3.6 > 2) pg_restore from Postgresql 9.1.1 > 3) pg_restore restores schema and most