[GENERAL] failed insert queries to one table-postgis enabled db

2009-01-24 Thread m zyzy
I have two type of INSERT queries that keep getting errors no matter how
many times I run it in pgadminIII 1.8.4 PostgresQL 8.3.4+PostGIS1.3.5 on
centos5 Linux machine.
1. execution of 18MB INSERT queries to one empty table failed in postgis
enabled database.sample one of the thousands queries :

INSERT INTO lutons (gid, area, perimeter, map1a_, map1a_id, no_id, no_id2,
main, use_bgn, unit, lvls, hght, type_bgn, no_, name_biz, addrss, biz2,
code, bgn, code_bgn, builds, note, the_geom) VALUES (1,
1980.087, 179.1345000, 63, 0, '1001001', '1001001',
'Trade', 'Office', 1.000, NULL, '13', 'one', NULL, 'Wayne Co.',
'Elm Street', 'Office', '836', 'Good', 1, 'm', NULL,
'010600010001030001000700CECAEFA1EEA34BC0F618A264232F69C0BF39315DC29748C01E53771C995369C0B0B8C50181173AC080DEED01F6D16BC0D28922835C2450C08EB4F082865E70C048D67B9E1CDA56C09B5ECFBE2B756DC0AF909ABFC40A4DC04CF2D285506169C0CECAEFA1EEA34BC0F618A264232F69C0');

in the Messages tab console in pgadminIII 1.8.4 prompts this error after
30-60 seconds of executing those queries

ERROR:  geometry contains non-closed rings

** Error **

ERROR: geometry contains non-closed rings
SQL state: XX000

==
2. 16mb insert failed . the problem query ;

INSERT INTO lutonszone (gid, area, perimeter, lot_no, unitadmin, zoning,
notes, the_geom, projectid) VALUES (23071, 3.071000, -.00,
'0036\0178', 46, 'ru4', NULL,
'010620E610010001030001000400C61858C7F112594099D87C5C1BDA154072A43330F2125940CC7D721420DA154049F7730AF21259',NULL);
in the Messages tab console :

WARNING:  nonstandard use of escape in a string literal
LINE 23237: ...projectid) VALUES (23071, 3.071000, -.00,
'0036\0178...
 ^
HINT:  Use the escape string syntax for escapes, e.g., E'\r\n'.
ERROR:  geometry requires more points

** Error **

ERROR: geometry requires more points
SQL state: XX000


[GENERAL] SQL Source Search for Emacs

2009-01-24 Thread Volkan YAZICI
Hi,

I've submitted[1] some useful portions of my SQL editing hacks for
emacs. I generally use them for navigating PostgreSQL (dump) scripts,
but it works for other RDBMSes as well. I hope it would work for you as
well.


Regards.

[1] http://www.emacswiki.org/emacs/SQLSourceSearch

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] very long update gin index troubles back?

2009-01-24 Thread Teodor Sigaev

Ответишь ему что-нибудь? Он так мутно излагает, что я ни хрена не понял.

Ivan Sergio Borgonovo wrote:

I've a table that contain a tsvector that is indexed (gin) and
triggers to update the tsvector that should then update the index.

This gin index has always been problematic. Recreation and updates
were very slow.

Now I had to update 1M rows of that table but for columns
that doesn't involve the tsvector
I dropped the trigger to update the tsvector so that when rows get
updated the trigger won't be called so things should be faster...
but still it is taking forever.

begin;
set constraints all deferred;

select * from FT1IDX_trigger_drop();
update catalog_items set
APrice=p.PrezzoA,
BPrice=p.PrezzoB
from import.catalog_prices p where
catalog_items.ItemID=p.id;
select * from FT1IDX_trigger_create();
commit;

function are used since I've 2 triggers actually that I drop and
create.

Is there anything wrong in the above to make this update so slow on
a 2x Xeon 3.2GHz 4GbRAM and a RAID1 [sic] I know it is slow on write.




--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] failed insert queries to one table-postgis enabled db

2009-01-24 Thread Alban Hertroys

On Jan 24, 2009, at 9:13 AM, m zyzy wrote:

I have two type of INSERT queries that keep getting errors no matter  
how
many times I run it in pgadminIII 1.8.4 PostgresQL  
8.3.4+PostGIS1.3.5 on

centos5 Linux machine.



2. 16mb insert failed . the problem query ;

INSERT INTO lutonszone (gid, area, perimeter, lot_no, unitadmin,  
zoning,

notes, the_geom, projectid) VALUES (23071, 3.071000, -.00,
'0036\0178', 46, 'ru4', NULL,
'010620E610010001030001000400C61858C7F112594099D87C5C1BDA154072A43330F2125940CC7D721420DA154049F7730AF21259 
',NULL);

in the Messages tab console :

WARNING:  nonstandard use of escape in a string literal
LINE 23237: ...projectid) VALUES (23071, 3.071000, -.00,
'0036\0178...
^
HINT:  Use the escape string syntax for escapes, e.g., E'\r\n'.
ERROR:  geometry requires more points

** Error **



Looks like the backslash is interpreted as an escape character. Switch  
on 'standard_conforming_strings' and probably turn off  
'escape_string_warning'.


Don't know about the other one, I'm guessing you're supplying a  
polygon or some other shape that is missing a closing segment (and  
thus being a polyline effectively I guess). I've never worked with  
shapes in postGIS though.
It could be caused by the above issue if parts of the shape definition  
contain backslashes as well.


And finally, I know there is a limit on query size somewhere... You  
might be hitting that with 16MB queries.


Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.


!DSPAM:737,497af707747031347810546!



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] Installing PostgreSQL on Windows 7 Beta Build 7000 64bit - first results

2009-01-24 Thread Harald Armin Massa
Hello,

my first results of installation-attempts of PostgreSQL 8.3.5 from
pginstaller on Windows 7 64bit:

1.) after getting up to "initialize database cluster", Dialog appears:
"Secondary Logon" Service not running. Please start this service and retry

Maybe some "net start seclogon" would be helpfull if W7 is detected by
installer?


2) installation copies a lot of stuff, moves up to "services get
started", which takes A LOT OF TIME
as of logfile:
[]
MSI (s) (F0:C4) [12:29:49:297]: Executing op:
ActionStart(Name=StartServices,Description=Dienste werden
gestartet,Template=Dienst: [1])
Aktion 12:29:49: StartServices. Dienste werden gestartet
MSI (s) (F0:C4) [12:29:49:298]: Executing op:
ProgressTotal(Total=1,Type=1,ByteEquivalent=130)
MSI (s) (F0:C4) [12:29:49:298]: Executing op:
ServiceControl(,Name=pgsql-8.3,Action=1,Wait=1,)
StartServices: Dienst: PostgreSQL Database Server 8.3

and finally fails with "... service could not be startet, please check
if you have enough rights to start system services"
[retry] / [cancel]
(btw, I am running the installer from an administrator prompt)

"retry" gives another time period to meditate & contemplate & wait; "Cancel"

leads to rollback of the installation:
MSI (s) (F0:C4) [12:29:49:297]: Executing op:
ActionStart(Name=StartServices,Description=Dienste werden
gestartet,Template=Dienst: [1])
Aktion 12:29:49: StartServices. Dienste werden gestartet
MSI (s) (F0:C4) [12:29:49:298]: Executing op:
ProgressTotal(Total=1,Type=1,ByteEquivalent=130)
MSI (s) (F0:C4) [12:29:49:298]: Executing op:
ServiceControl(,Name=pgsql-8.3,Action=1,Wait=1,)
StartServices: Dienst: PostgreSQL Database Server 8.3
MSI (s) (F0:C4) [12:33:25:956]: Note: 1: 2205 2:  3: Error
MSI (s) (F0:C4) [12:33:25:956]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1920
MSI (c) (DC:50) [12:33:25:958]: Note: 1: 2205 2:  3: Error
MSI (c) (DC:50) [12:33:25:958]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 2835
DEBUG: Error 2835:  The control ErrorIcon was not found on dialog ErrorDlg
Bei der Installation dieses Pakets ist ein unerwarteter Fehler
aufgetreten. Es liegt eventuell ein das Paket betreffendes Problem
vor. Der Fehlercode ist 2835. Argumente: ErrorIcon, ErrorDlg,
Fehler 1920. Der Dienst PostgreSQL Database Server 8.3 (pgsql-8.3)
konnte nicht gestartet werden. Überprüfen Sie, ob Sie ausreichende
Berechtigungen zum Starten von Systemdiensten besitzen.
MSI (s) (F0:18) [12:34:43:812]: I/O on thread 3064 could not be
cancelled. Error: 1168
MSI (s) (F0:18) [12:34:43:812]: I/O on thread 2040 could not be
cancelled. Error: 1168
MSI (s) (F0:18) [12:34:43:812]: I/O on thread 3636 could not be
cancelled. Error: 1168
MSI (s) (F0:18) [12:34:43:812]: I/O on thread 3268 could not be
cancelled. Error: 1168
MSI (s) (F0:18) [12:34:43:812]: I/O on thread 3776 could not be
cancelled. Error: 1168
MSI (s) (F0:18) [12:34:43:812]: I/O on thread 2516 could not be
cancelled. Error: 1168
MSI (s) (F0:18) [12:34:43:812]: I/O on thread 3848 could not be
cancelled. Error: 1168
MSI (s) (F0:C4) [12:34:43:813]: Note: 1: 2205 2:  3: Error
MSI (s) (F0:C4) [12:34:43:813]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1709
MSI (s) (F0:C4) [12:34:43:813]: Produkt: PostgreSQL 8.3 -- Fehler
1920. Der Dienst PostgreSQL Database Server 8.3 (pgsql-8.3) konnte
nicht gestartet werden. Überprüfen Sie, ob Sie ausreichende
Berechtigungen zum Starten von Systemdiensten besitzen.

MSI (s) (F0:C4) [12:34:43:813]: Note: 1: 2205 2:  3: Error
MSI (s) (F0:C4) [12:34:43:813]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1602
MSI (c) (DC:50) [12:34:43:816]: Note: 1: 2205 2:  3: Error
MSI (c) (DC:50) [12:34:43:816]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 2835
DEBUG: Error 2835:  The control ErrorIcon was not found on dialog ErrorDlg
Bei der Installation dieses Pakets ist ein unerwarteter Fehler
aufgetreten. Es liegt eventuell ein das Paket betreffendes Problem
vor. Der Fehlercode ist 2835. Argumente: ErrorIcon, ErrorDlg,
Sind Sie sicher, dass Sie den Vorgang abbrechen möchten?
Aktion beendet um 12:34:46: InstallFinalize. Rückgabewert 3.
MSI (s) (F0:C4) [12:34:46:169]: User policy value 'DisableRollback' is 0
MSI (s) (F0:C4) [12:34:46:169]: Machine policy value 'DisableRollback' is 0
MSI (s) (F0:C4) [12:34:46:172]: Executing op:
Header(Signature=1397708873,Version=500,Timestamp=976774067,LangId=1033,Platform=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
MSI (s) (F0:C4) [12:34:46:172]: Executing op: DialogInfo(Type=0,Argument=1033)
MSI (s) (F0:C4) [12:34:46:173]: Executing op:
DialogInfo(Type=1,Argument=PostgreSQL 8.3)
MSI (s) (F0:C4) [12:34:46:173]: Executing op:
RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Aktion wird
rückgängig 
gemacht:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Sicherungsdateien
werden entfernt,Cleanup

Re: [GENERAL] very long update gin index troubles back?

2009-01-24 Thread Oleg Bartunov

On Fri, 23 Jan 2009, Ivan Sergio Borgonovo wrote:


I've a table that contain a tsvector that is indexed (gin) and
triggers to update the tsvector that should then update the index.

This gin index has always been problematic. Recreation and updates
were very slow.

Now I had to update 1M rows of that table but for columns
that doesn't involve the tsvector
I dropped the trigger to update the tsvector so that when rows get
updated the trigger won't be called so things should be faster...
but still it is taking forever.


all indexes will be updated, so if you might want to drop indexes and 
rebuild from the scratch.




begin;
   set constraints all deferred;

   select * from FT1IDX_trigger_drop();
   update catalog_items set
APrice=p.PrezzoA,
BPrice=p.PrezzoB
from import.catalog_prices p where
catalog_items.ItemID=p.id;
select * from FT1IDX_trigger_create();
commit;

function are used since I've 2 triggers actually that I drop and
create.

Is there anything wrong in the above to make this update so slow on
a 2x Xeon 3.2GHz 4GbRAM and a RAID1 [sic] I know it is slow on write.





Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: o...@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] very long update gin index troubles back?

2009-01-24 Thread Teodor Sigaev
GIN index is slow for update by its construction. When you update the rows with 
or without columns indexed by GIN, postgres (in most cases) will insert new 
records, so index insertion will occur. So, for large updates it's much cheaper 
to drop and create index.


That was a one of reasons to develop fast_insert_gin patch which now in review 
process.


Ivan Sergio Borgonovo wrote:

I've a table that contain a tsvector that is indexed (gin) and
triggers to update the tsvector that should then update the index.



--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] dblink syntax question for remotely invoking void-returning procedures

2009-01-24 Thread Ian Sollars
Hello everyone,

I've got some questions about dblink that I couldn't find answers to in the
documentation. Any help would be much appreciated.

I need to invoke a function on a remote server that returns either void or
text, and I'm trying to find a nice way of doing it.

My test schema on the remote DB:

create table test (id serial, val text)
create or replace function inserttest() returns void as $$
begin
insert into test (val) values ('x');
end;
$$ language 'plpgsql'

First I create a dblink connection to the above DB, then I try to call
inserttest().

I've tried all the below queries in the console and in PL/pgSQL, two of
which work correctly and *then* throw an error, which I think may be a bug.

>From the console, this works:

select * from dblink('test', 'select inserttest()') as tmp(result text)

However, if I execute this within a PL/pgSQL procedure, the error message is

ERROR:  query has no destination for result data
HINT:  If you want to discard the results of a SELECT, use PERFORM instead.

Needless to say, I tried listening to hints and the perform doesn't work in
this case.

The only result I've come up with is to modify the above function to
"returns integer", always zero, and do this:

select result into junk from dblink('test', 'select inserttest()') as
tmp(result integer)

This isn't ideal because a) it needs a junk variable, b) it's verbose and c)
void methods must return useless information. Is there a better way to do
the above in PL/pgSQL?

Many thanks in advance,

 - Ian

(for completeness' sake, and to prove I read the manual :-), the things I
tried from the console and from procedures, and the results of each attempt
follows).

--WORKS, but throws error
select * from dblink('test', 'select inserttest()') as t1(test void);
 -> column "test" has pseudo-type void

--WORKS, but throws error
select * from dblink('test', 'select inserttest()') as t1(test text);
 -> query has no destination for result data

perform dblink('test', 'select inserttest()');
 -> function returning record called in context that cannot accept type
record

select dblink('test', 'select inserttest()');
 -> function returning record called in context that cannot accept type
record

select * from dblink('test', 'select inserttest()');
 -> a column definition list is required for functions returning "record"

select * from dblink('test', 'select inserttest()') as void;
 -> a column definition list is required for functions returning "record"

perform dblink_exec('test', 'select inserttest()');
 -> statement returning results not allowed

perform dblink('test', 'select inserttest()');
  -> ERROR:  function returning record called in context that cannot accept
type record
 -> CONTEXT:  SQL statement "SELECT  dblink('test', 'select inserttest()')"

perform dblink('test', 'perform inserttest()');
 -> ERROR:  sql error
 -> DETAIL:  ERROR:  syntax error at or near "perform"
 -> LINE 1: perform inserttest()

perform dblink('test', 'inserttest()');
 -> ERROR:  sql error
 -> DETAIL:  ERROR:  syntax error at or near "inserttest"
 -> LINE 1: inserttest()

select dblink_exec('test', 'perform inserttest()');
 -> ERROR: sql error
 -> SQL state: 42601
 -> Detail: ERROR:  syntax error at or near "perform"
 -> LINE 1: perform inserttest()


Re: [GENERAL] very long update gin index troubles back?

2009-01-24 Thread Ivan Sergio Borgonovo
On Sat, 24 Jan 2009 15:54:37 +0300
Teodor Sigaev  wrote:

> GIN index is slow for update by its construction. When you update
> the rows with or without columns indexed by GIN, postgres (in most
> cases) will insert new records, so index insertion will occur. So,
> for large updates it's much cheaper to drop and create index.
> 
> That was a one of reasons to develop fast_insert_gin patch which
> now in review process.

Somehow the update succeeded... but for better preparing to the
future...

I'm not sure I understood, so I'll provide more details.

I've something like:

create table t1(
 agg tsvector,
 a varchar(10),
 b varchar(10),
 c varchar(10),
 d int
);

then 2 triggers that for every update to t1 fill up agg.

agg:=tsvactor(coalesce(a,'')) || tsvactor(coalesce(b,'')) ||
  tsvactor(coalesce(c,''));

and I have a gin index on agg.

No matter if I drop the trigger that update agg content and the fact
that I'm just updating d, postgresql will update the index?

Right?

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] conditional execution of insert/update-s

2009-01-24 Thread Jasen Betts
On 2009-01-22, Dmitry Teslenko  wrote:
> Hello!
> Question is what's the easiest way to implement conditional execution
> of insert/update-s via psql interface?
>
> As far as I know there's following options:

> 1) create function in procedural language (plpgsql, for example);
> then call that function

> 2) update ... where ;
 insert ... (select ... where );

> not sure here if  can be unrelated to the table being modified
> by update/insert statement;

they can be unrelated

> Are there alternatives?

here's one but it's messy when the condition is false.

 BEGIN;
 
 SELECT expression_which_causes_an_exception_when_condition_fails;

 statements...;
 
 COMMIT;


the advantage of this is that it can be used with DDL statements.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] difference between current_timestamp and now() in quotes

2009-01-24 Thread Jasen Betts
On 2009-01-22, Adrian Klaver  wrote:
> On Thursday 22 January 2009 8:16:46 am Alvaro Herrera wrote:
>> Grzegorz Jaśkiewicz escribió:
>> > test2=# insert into dupa(a) select 'current_timestamp' from
>> > generate_series(1,100);
>> > ERROR:  date/time value "current" is no longer supported
>> > LINE 1: insert into dupa(a) select 'current_timestamp' from generate...
>> >^
>> > test2=# insert into dupa(a) select 'now()' from generate_series(1,100);
>> > INSERT 0 100
>> >
>> >
>> > Any ideas why the difference ?
>>
>> The parser handles CURRENT_TIMESTAMP (and others) specially, and doesn't
>> recognize it in quotes.  I don't know why 'now()' works; I think it is a
>> literal of type unknown.  I guess it's expanded to the actual value in
>> later parsing stages.
>>
>> --
>> Alvaro Herrerahttp://www.CommandPrompt.com/
>> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> At least on 8.2  'now()' does not work either at least not in the way I think 
> you want. I get:
>
> test=# SELECT 'now()';
>  ?column?
> --
>  now()
> (1 row)

 'now' is a string which can be translated to timestamp 
 now() is a function that returns the current timestamp
 current_timestamp is a constant that does the same




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] Re: how to implement a foreign key type constraint against a not unique column

2009-01-24 Thread Jasen Betts
On 2009-01-21, Brent Wood  wrote:
> Hi,
>
> I have a table with a column of ID's (integer), these are unique
> except where they = -1 (column 1) 

> I have a partial unique index where the value is not -1 to enforce this.

> I want to use this column as a foreign key on a column in another table 
> (column 2), but cannot without a full unique index. 

a full unique index is easy use an expression that's null for -1.

create unique index foobar on foo( ( case fee when -1 then null else fee end ) 
);

> Is there any way to add an equivalent constraint to a foreign key which 
> restricts entries in column 2 to values in column 1?

unfortunately expressions don't seem to be allowed for foreign key constraints 

you could add an auxillary column and create a rule, or trigger to keep
it updated.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] problem converting database to UTF-8

2009-01-24 Thread Jasen Betts
On 2009-01-22, David Goodenough  wrote:
> I have a database which was created as LATIN1 (the machine has the
> wrong locales installed when I set up  PG).  It is running 8.3.
>
> So I found various places which said the way to do this was to do
> a pg_dumpall -f dump_file, get rid of the entire database, init_db -E UTF-8, 
> and then psql -f dumpfile.
>
> But the psql fails saying:-
>
> psql:dumpfile:49: ERROR:  encoding LATIN1 does not match server's locale 
> en_GB.UTF-8
> DETAIL:  The server's LC_CTYPE setting requires encoding UTF8.
>
> I have en_GB.UTF-8 now as my primary locale, and en_GB.ISO8859-1 is
> also generated.
>
> So I looked around again and found people saying I needed to use iconv,
> but that does not help, I get the same error.

> Is there a definative HOWTO that I can follow, if not does someone
> have a set of instructions that will work?

simplest best way is to dump the individual databases and then restore
them individually.

else you need to go theough the dump file and doctor the
CREATE DATABASE lines to use UTF-8 (or not specify an encoding)
whilst making sure that CLIENT_ENCODING remains set to LATIN1
(so that the data from the dump file remains intelligible)

alternately you may be able to use iconv to convert the whole file to
UTF8 and also all ocurrances of LATIN1 in commands with UTF8

The frst thing I'd do is look in the dump file and see what's on line
49.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general