[ADMIN] News group
No new messages on the newsgroup! Somethink wrong ? Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [ADMIN] Delete accident
On Tue, 30 Sep 2003, Anna Kanevsky wrote: > This is an almost embarrassing question, but I managed to delete all rows > out of one of the tables by making a little typo in the WHERE statement. > Is there any way to restore these? the db was NOT vacuumed after that. but > then, it wasn't backed up before either. Potentially, if vacuum wasn't run, you may be able to go back, find the transaction that did the delete and mark it as having rolled back, but I don't really know the details necessary to make that work. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [ADMIN] Question about DB VACUUM
Tom, You were right, 1 or 2 of the large objects weren't actually getting removed from the table, each cycle. I wasn't running on a completely empty database when I first started, so I didn't notice the undeleted objects. The program which interfaces to the database uses the JDBC method LargeObject.delete() to delete the large object associated to the entry in the users data table. Plus every night I have a program which goes through the database and checks for and removes large objects which are no longer being referenced by any table. I am now trying to find out why the occasion entry doesn't get deleted. Chris -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 3:46 PM To: [EMAIL PROTECTED] Cc: 'Robert Treat'; [EMAIL PROTECTED] Subject: Re: [ADMIN] Question about DB VACUUM "Chris White (cjwhite)" <[EMAIL PROTECTED]> writes: > The index has grown by 4 pages and the table has grown by 10 pages. > BTW, what is a page size? Why is this happening as this is the table > that I am theoretically keeping the same size by adding/deleting the > same objects from. Kinda looks like you aren't doing anything to remove no-longer-referenced large objects. An LO is not a BLOB; it has an independent existence. You may care to look into contrib/lo and/or contrib/vacuumlo. Or possibly you should be using wide text or bytea fields, not large objects at all... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [ADMIN] Delete accident
Anna Kanevsky wrote: This is an almost embarrassing question, but I managed to delete all rows out of one of the tables by making a little typo in the WHERE statement. When you do update or delete is good do it inside a transaction, I guess you didn't ! I think that your datas are lost. Gaetano ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [ADMIN] Question about DB VACUUM
"Chris White (cjwhite)" <[EMAIL PROTECTED]> writes: > The index has grown by 4 pages and the table has grown by 10 pages. BTW, > what is a page size? Why is this happening as this is the table that I > am theoretically keeping the same size by adding/deleting the same > objects from. Kinda looks like you aren't doing anything to remove no-longer-referenced large objects. An LO is not a BLOB; it has an independent existence. You may care to look into contrib/lo and/or contrib/vacuumlo. Or possibly you should be using wide text or bytea fields, not large objects at all... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] Question about DB VACUUM
I made the changes you suggested and the usage was about the same
Initial after vacuum full
bash-2.05b# du -s -b /data/sql
57729024/data/sql
After 1st iteration
bash-2.05b# du -s -b /data/sql
57978880/data/sql
249856 byte increase
After 2nd iteration
bash-2.05b# du -s -b /data/sql
58052608/data/sql
73728 byte increase
After 3rd iteration
bash-2.05b# du -s -b /data/sql
58101760/data/sql
49152 byte increase
After 4th iteration
bash-2.05b# du -s -b /data/sql
58126336/data/sql
24576 byte increase
However what I am seeing is the pg_largeobject table is growing.
Vacuum info after 1st iteration
NOTICE: --Relation pg_largeobject--
NOTICE: Index pg_largeobject_loid_pn_index: Pages 157; Tuples 2564:
Deleted 168.CPU 0.02s/0.01u sec elapsed 0.04 sec.
NOTICE: Removed 168 tuples in 28 pages.
CPU 0.01s/0.00u sec elapsed 0.01 sec.
NOTICE: Pages 61: Changed 61, Empty 0; Tup 2564: Vac 168, Keep 458,
UnUsed 360.
Total CPU 0.03s/0.02u sec elapsed 0.06 sec.
Vacuum info after 4th iteration
NOTICE: --Relation pg_largeobject--
NOTICE: Index pg_largeobject_loid_pn_index: Pages 161; Tuples 2576:
Deleted 629.CPU 0.00s/0.03u sec elapsed 0.05 sec.
NOTICE: Removed 629 tuples in 68 pages.
CPU 0.02s/0.04u sec elapsed 0.06 sec.
NOTICE: Pages 71: Changed 55, Empty 0; Tup 2576: Vac 629, Keep 464,
UnUsed 635.
Total CPU 0.03s/0.07u sec elapsed 0.13 sec.
The index has grown by 4 pages and the table has grown by 10 pages. BTW,
what is a page size? Why is this happening as this is the table that I
am theoretically keeping the same size by adding/deleting the same
objects from.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Treat
Sent: Thursday, October 02, 2003 2:09 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
As a starting point, check your free space map settings in the
postgresql.conf. They are low by default in 7.2.x.
free_space_relations* can safely be bumped to 1000. free_space_pages*
should probably be bumped to something like 5, though you might be
able to determine a better amount be seeing how many pages are used up
after each add/delete/vacuum cycle. One other thing to check on is if
you have an indexes involved in the process, you may get some index
growth issues that will require periodic indexing. HTH,
Robert Treat
* I'm pretty sure those aren't the exact names, but their similar so you
should be able to find them.
On Thu, 2003-10-02 at 14:39, Chris White (cjwhite) wrote:
> Hi,
>
> I am using a Postgres 7.2.1 db to store binary data as large objects
> which users can add or delete as they need. I have found that without
> frequent vacuums of the database the disk space used by the database
> grows very quickly, as users on average add and delete binary objects
> of about 160K at a time. So I was trying to determine how often I
> should do a vacuum in order to keep the database from growing too
> quickly. So I ran a test where I did a full vacuum of the database to
> compact the tables, then I added and deleted 12 large objects of 80K
> each and then did a vacuum, not a full vacuum. I did this
> add/delete/vacuum process 4 times in a row. I thought that by adding
> and deleting the same objects and then vacuuming, the database
> shouldn't grow, as the new inserts would reuse the space taken up by
> the deleted objects after the vacuum. However, I was seeing the
> database grow each time. Here are the disk usage values after each
> step:
>
> After initial vacuum full:
> bash-2.05b# du -b -s /data/sql
> 56664064 /data/sql
>
> After first add/delete/vacuum:
> bash-2.05b# du -b -s /data/sql
> 56987648 /data/sql
>
> 323584 byte increase
>
> After second add/delete/vacuum:
> bash-2.05b# du -b -s /data/sql
> 57012224 /data/sql
>
> 24576 byte increase
>
> After third add/delete/vacuum:
> bash-2.05b# du -b -s /data/sql
> 57061376 /data/sql
>
> 49152 byte increase
>
> After fourth add/delete/vacuum:
> bash-2.05b# du -b -s /data/sql
> 57085952 /data/sql
>
> 24576 byte increase
>
> Is this expected behavior? As at some point in time, if I carry on
> repeating this test, I would have to do a vacuum full to retrieve disk
> space, even though the actual contents of the database has not
> increased from the initial starting point.
>
> Chris White
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailA
Re: [ADMIN] pg_restore fails - postgres 7.3.4
"Rob Long" <[EMAIL PROTECTED]> writes:
>>> Trying to dump and restore a production database with no success.
>>>
>>> pg_restore: [archiver (db)] could not execute query: ERROR: data type
>>> integer has no default operator class for access method "gist"
>>
>> Hm, this is probably a matter of incorrect object restoration order ...
>> could we see the output of "pg_restore -l" for this dump file?
After playing around with this I realize that it's a bug associated with
schemas --- if you have an operator class that's not in pg_catalog, the
opclass name has to be explicitly qualified in pg_dump's output, or it
won't restore correctly. I'm surprised no one reported this before,
since it affects all the contrib operator classes.
Attached is a patch against 7.3.4, in case it helps.
regards, tom lane
Index: src/backend/utils/adt/ruleutils.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/adt/ruleutils.c,v
retrieving revision 1.124.2.1
diff -c -r1.124.2.1 ruleutils.c
*** src/backend/utils/adt/ruleutils.c 8 Jan 2003 22:54:36 - 1.124.2.1
--- src/backend/utils/adt/ruleutils.c 2 Oct 2003 22:21:03 -
***
*** 2951,2956
--- 2951,2957
Form_pg_opclass opcrec;
char *opcname;
char *nspname;
+ boolisvisible;
/* Domains use their base type's default opclass */
if (OidIsValid(actual_datatype))
***
*** 2962,2972
if (!HeapTupleIsValid(ht_opc))
elog(ERROR, "cache lookup failed for opclass %u", opclass);
opcrec = (Form_pg_opclass) GETSTRUCT(ht_opc);
! if (actual_datatype != opcrec->opcintype || !opcrec->opcdefault)
{
/* Okay, we need the opclass name. Do we need to qualify it? */
opcname = NameStr(opcrec->opcname);
! if (OpclassIsVisible(opclass))
appendStringInfo(buf, " %s", quote_identifier(opcname));
else
{
--- 2963,2978
if (!HeapTupleIsValid(ht_opc))
elog(ERROR, "cache lookup failed for opclass %u", opclass);
opcrec = (Form_pg_opclass) GETSTRUCT(ht_opc);
!
! /* Must force use of opclass name if not in search path */
! isvisible = OpclassIsVisible(opclass);
!
! if (actual_datatype != opcrec->opcintype || !opcrec->opcdefault ||
! !isvisible)
{
/* Okay, we need the opclass name. Do we need to qualify it? */
opcname = NameStr(opcrec->opcname);
! if (isvisible)
appendStringInfo(buf, " %s", quote_identifier(opcname));
else
{
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [ADMIN] Current Computer Name
On Thu, 2003-10-02 at 22:47, Marvin wrote: > Because I would like to store in my table the name of the computer > where the user saves the information. > > Whe have already into a MSSQL table the following definition: > > Field name TypeDefault > IngUsernamenvarchar(50) (suser_sname()) > IngDate datetime (getdate()) > IngPCName nvarchar(50) (host_name()) > > So, I need to emulate this in order to make > the migration transparent to the application. > > > Thank you for any suggestions. > > You could write a function in C or PL/Perl... -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Set your affection on things above, not on things on the earth." Colossians 3:2 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] Question about DB VACUUM
As a starting point, check your free space map settings in the
postgresql.conf. They are low by default in 7.2.x.
free_space_relations* can safely be bumped to 1000. free_space_pages*
should probably be bumped to something like 5, though you might be
able to determine a better amount be seeing how many pages are used up
after each add/delete/vacuum cycle. One other thing to check on is if
you have an indexes involved in the process, you may get some index
growth issues that will require periodic indexing. HTH,
Robert Treat
* I'm pretty sure those aren't the exact names, but their similar so you
should be able to find them.
On Thu, 2003-10-02 at 14:39, Chris White (cjwhite) wrote:
> Hi,
>
> I am using a Postgres 7.2.1 db to store binary data as large objects
> which users can add or delete as they need. I have found that without
> frequent vacuums of the database the disk space used by the database
> grows very quickly, as users on average add and delete binary objects of
> about 160K at a time. So I was trying to determine how often I should do
> a vacuum in order to keep the database from growing too quickly. So I
> ran a test where I did a full vacuum of the database to compact the
> tables, then I added and deleted 12 large objects of 80K each and then
> did a vacuum, not a full vacuum. I did this add/delete/vacuum process 4
> times in a row. I thought that by adding and deleting the same objects
> and then vacuuming, the database shouldn't grow, as the new inserts
> would reuse the space taken up by the deleted objects after the vacuum.
> However, I was seeing the database grow each time. Here are the disk
> usage values after each step:
>
> After initial vacuum full:
> bash-2.05b# du -b -s /data/sql
> 56664064 /data/sql
>
> After first add/delete/vacuum:
> bash-2.05b# du -b -s /data/sql
> 56987648 /data/sql
>
> 323584 byte increase
>
> After second add/delete/vacuum:
> bash-2.05b# du -b -s /data/sql
> 57012224 /data/sql
>
> 24576 byte increase
>
> After third add/delete/vacuum:
> bash-2.05b# du -b -s /data/sql
> 57061376 /data/sql
>
> 49152 byte increase
>
> After fourth add/delete/vacuum:
> bash-2.05b# du -b -s /data/sql
> 57085952 /data/sql
>
> 24576 byte increase
>
> Is this expected behavior? As at some point in time, if I carry on
> repeating this test, I would have to do a vacuum full to retrieve disk
> space, even though the actual contents of the database has not increased
> from the initial starting point.
>
> Chris White
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [ADMIN] pg_restore fails - postgres 7.3.4
Attached. The previously posted index failure stated: CREATE INDEX idx_disc_loc ON order_items USING gist (disc, loc); However in this list it is: CREATE INDEX idx_item_loc ON content_items USING gist (disclosuer, loc); Rob Tom Lane wrote: > "Rob Long" <[EMAIL PROTECTED]> writes: > > Trying to dump and restore a production database with no success. > > > pg_restore: [archiver (db)] could not execute query: ERROR: data type > > integer has no default operator class for access method "gist" > > Hm, this is probably a matter of incorrect object restoration order ... > could we see the output of "pg_restore -l" for this dump file? > > regards, tom lane > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly ; ; Archive created at Wed Oct 1 15:14:39 2003 ; dbname: servdb ; TOC Entries: 270 ; Compression: -1 ; Dump Version: 1.7-0 ; Format: CUSTOM ; Integer: 4 bytes ; Offset: 4 bytes ; ; ; Selected TOC Entries: ; 2; 95388961 SCHEMA map_1 postgres 3; 95523966 SCHEMA map_2 postgres 4; 95524214 SCHEMA map_3 postgres 135; 78537297 FUNCTION plpgsql_call_handler () postgres 134; 78537298 PROCEDURAL LANGUAGE plpgsql 136; 78537299 FUNCTION database_size (name) postgres 137; 78537300 FUNCTION relation_size (text) postgres 138; 78537302 FUNCTION int4key_in (cstring) postgres 139; 78537303 FUNCTION int4key_out (int4key) postgres 5; 78537301 TYPE int4key postgres 140; 78537305 FUNCTION gint4_consistent (internal, integer, smallint) postgres 141; 78537306 FUNCTION gint4_compress (internal) postgres 142; 78537307 FUNCTION btree_decompress (internal) postgres 143; 78537308 FUNCTION gint4_penalty (internal, internal, internal) postgres 144; 78537309 FUNCTION gint4_picksplit (internal, internal) postgres 145; 78537310 FUNCTION gint4_union (bytea, internal) postgres 146; 78537311 FUNCTION gint4_same (internal, internal, internal) postgres 170; 78537312 OPERATOR CLASS gist_int4_ops postgres 147; 78537314 FUNCTION tskey_in (cstring) postgres 148; 78537315 FUNCTION tskey_out (tskey) postgres 6; 78537313 TYPE tskey postgres 149; 78537317 FUNCTION gts_consistent (internal, timestamp without time zone, smallint) postgres 150; 78537318 FUNCTION gts_compress (internal) postgres 151; 78537319 FUNCTION gts_penalty (internal, internal, internal) postgres 152; 78537320 FUNCTION gts_picksplit (internal, internal) postgres 153; 78537321 FUNCTION gts_union (bytea, internal) postgres 154; 78537322 FUNCTION gts_same (internal, internal, internal) postgres 171; 78537323 OPERATOR CLASS gist_timestamp_ops postgres 155; 78537324 FUNCTION gbox_consistent (internal, box, integer) postgres 156; 78537325 FUNCTION gbox_compress (internal) postgres 157; 78537326 FUNCTION rtree_decompress (internal) postgres 158; 78537327 FUNCTION gbox_penalty (internal, internal, internal) postgres 159; 78537328 FUNCTION gbox_picksplit (internal, internal) postgres 160; 78537329 FUNCTION gbox_union (bytea, internal) postgres 161; 78537330 FUNCTION gbox_same (box, box, internal) postgres 172; 78537331 OPERATOR CLASS gist_box_ops postgres 162; 78537332 FUNCTION gpoly_consistent (internal, polygon, integer) postgres 163; 78537333 FUNCTION gpoly_compress (internal) postgres 173; 78537334 OPERATOR CLASS gist_poly_ops postgres 7; 78537335 SEQUENCE seq_mapid postgres 9; 78537337 TABLE maps postgres 10; 78537346 TABLE content postgres 164; 78537362 FUNCTION delete_map_trigger () postgres 11; 78537364 TABLE attr_types postgres 12; 78537368 TABLE label_types postgres 165; 78537381 FUNCTION new_map_trigger () postgres 166; 78537383 FUNCTION build_map_schema (integer, boolean, boolean) postgres 167; 78537385 FUNCTION setmap (integer) postgres 168; 78537386 FUNCTION after_update_content () postgres 169; 78537389 FUNCTION copymap (character varying, character varying, boolean) postgres 13; 95388963 TABLE content_items postgres 14; 95388968 TABLE attributes postgres 15; 95388971 TABLE item_text_attribs postgres 16; 95388976 TABLE item_date_attribs postgres 17; 95388978 TABLE item_dbl_attribs postgres 18; 95388980 TABLE item_int_attribs postgres 19; 95388984 VIEW item_attribs postgres 20; 95388985 TABLE documents postgres 21; 95388990 TABLE contours postgres 22; 95388995 TABLE queries postgres 23; 95389000 TABLE groups postgres 24; 95389005 TABLE timeslices postgres 25; 95389010 TABLE syn_units postgres 26; 95389015 TABLE labels postgres 27; 95389020 TABLE sem_units postgres 28; 95389025 TABLE params postgres 29; 95523968 TABLE content_items postgres 30; 95523973 TABLE attributes postgres 31; 95523976 TABLE item_text_attribs postgres 32; 95523981 TABLE item_date_attribs postgres 33; 95523983 TABLE item_dbl_attribs postgres 34; 95523985 TABLE item_int_attribs postgres 35; 95523989 VIEW item_attribs postgres 36; 95523
Re: [ADMIN] pg_restore fails - postgres 7.3.4
"Rob Long" <[EMAIL PROTECTED]> writes: > Trying to dump and restore a production database with no success. > pg_restore: [archiver (db)] could not execute query: ERROR: data type > integer has no default operator class for access method "gist" Hm, this is probably a matter of incorrect object restoration order ... could we see the output of "pg_restore -l" for this dump file? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[ADMIN] pg_restore fails - postgres 7.3.4
Trying to dump and restore a production database with no success. pg_dump database using the following: pg_dump -v -b -C -Fc -U postgres -f servdb.tar.gz servdb pg_restore with with following: pg_restore -v -C -D template1 -Fc -U postgres servdb.tar.gz restore fails with: pg_restore: [archiver (db)] could not execute query: ERROR: data type integer has no default operator class for access method "gist" You must specify an operator class for the index or define a default operator class for the data type pg_restore: ***aborted because of error >From the documentation the following query illustrates that I have four gist acc_methods available: select am.amname as acc_method, opc.opcname as ops_name from pg_am am, pg_opclass opc where opc.opcamid = am.oid order by acc_method, ops_name; acc_method | ops_name - gist | gist_box_ops gist | gist_int4_ops gist | gist_poly_ops gist | gist_timestamp_ops The create index statement that is failing the restore: CREATE INDEX idx_disc_loc ON order_items USING gist (disc, loc); Has anyone battled this one before? Is there a problem with dumping/restoring with blobs? Thanks, Rob ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[ADMIN] Question about DB VACUUM
Hi, I am using a Postgres 7.2.1 db to store binary data as large objects which users can add or delete as they need. I have found that without frequent vacuums of the database the disk space used by the database grows very quickly, as users on average add and delete binary objects of about 160K at a time. So I was trying to determine how often I should do a vacuum in order to keep the database from growing too quickly. So I ran a test where I did a full vacuum of the database to compact the tables, then I added and deleted 12 large objects of 80K each and then did a vacuum, not a full vacuum. I did this add/delete/vacuum process 4 times in a row. I thought that by adding and deleting the same objects and then vacuuming, the database shouldn't grow, as the new inserts would reuse the space taken up by the deleted objects after the vacuum. However, I was seeing the database grow each time. Here are the disk usage values after each step: After initial vacuum full: bash-2.05b# du -b -s /data/sql 56664064 /data/sql After first add/delete/vacuum: bash-2.05b# du -b -s /data/sql 56987648 /data/sql 323584 byte increase After second add/delete/vacuum: bash-2.05b# du -b -s /data/sql 57012224 /data/sql 24576 byte increase After third add/delete/vacuum: bash-2.05b# du -b -s /data/sql 57061376 /data/sql 49152 byte increase After fourth add/delete/vacuum: bash-2.05b# du -b -s /data/sql 57085952 /data/sql 24576 byte increase Is this expected behavior? As at some point in time, if I carry on repeating this test, I would have to do a vacuum full to retrieve disk space, even though the actual contents of the database has not increased from the initial starting point. Chris White ---(end of broadcast)--- TIP 8: explain analyze is your friend
[ADMIN] Current Computer Name
Hi, I would like to know how could I do to get the host name from postgres. Something like "CURRENT_HOSTNAME". Thanx, MAGO -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[ADMIN] Machine name
Hi, I would like to know how could I do to get the host name from postgres. Something like "CURRENT_HOSTNAME". Thanx, MAGO _ IncrediMail - El E-mail ha evolucionado finalmente - Haga clic aquí
Re: [ADMIN] PostgreSQL & cygwin
On Thu, 2 Oct 2003, Kerv wrote: > Hello, > > Is any performance degree if I run PostgreSQL from cygwin on a Windows > XP machine? Postgresql is known for poor performance in that situation. But it's plenty good enough for pre-deployment testing and development. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[ADMIN] Concurrent Connections - User only allowed one connection
(Running PG 7.3.4 on Sparc Solaris 9) I have a Java application (which connects to Postgres using JDBC) which I run from the Solaris box, but which I develop from my desktop PC. When my application connects to Postgres, it can only obtain one connection. i.e. if the server app is running, then my PC cannot connect, but if my PC version is running, then the server cannot connect. I am certain this is not a problem with the application, as when I try and connect with other tools, I get the same problem. Is this a bug, feature or just good old human error (on my part) ? Thanks, GTG Gordon Ross, Network Manager/Rheolwr Rhydwaith Countryside Council for Wales/Cyngor Cefn Gwlad Cymru ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [ADMIN] initdb error on windows - urgent, please
Jarek Lubczyn'ski wrote: Hi, everybody, Please help me with an urgent problem. I have PostgreSQL version: 7.3.1Alfa1 for Windows (the only Win version available) I am training installation of ProgreSQL on various PC's WinNT, 2K, XP and 2003 installed. In some cases I've got such a problem (till now on W2K and W2003) When I try to initialize dbspace using initdb, for example: . initdb -D /cygdrive/d/database/postgres --username=myuser -W -E LATIN2 . (of course specified path exists and is owned by "myuser") I will get such information: The files belonging to this database system will be owned by user "myuser". This user must also own the server process. The database cluster will be initialized with locale C. Fixing permissions on existing directory /cygdrive/d/database/postgres... ok creating directory /cygdrive/d/database/postgres/base... ok creating directory /cygdrive/d/database/postgres/global... ok creating directory /cygdrive/d/database/postgres/pg_xlog... ok creating directory /cygdrive/d/database/postgres/pg_clog... ok creating template1 database in /cygdrive/d/database/postgres/base/1... IpcSemaphoreCreate: semget(key=1, num=17, 03600) failed: Function not implemented initdb failed. User "myuser" belongs to the administator group of course. Any set of initdb options causes the same result (even initdb with no parameters) What is happening? How can I avoid such a problem? Why this seems to occur only on: some Win2k installations (two of tested five or six), Win2003(first attempt passed through, second one on the other machine failed) and never (so far) on WinNT (I've tried one) nor WinXP (four or five cases). All Windows (except of WinNT) were Polish edition I have thought it's a matter of service pack installed, but today I installed PostgreSQL on one machine with W2003 SE PL and everything went OK, but on other machine with the same W2003 initdb failed. I need an urgent help. Thanks in advance. Hi, You need the IPC support for cygwin. Find it and download the cygipc package for cygwin. For set up and running PostgreSQL for cygwin please read postgresql-...README from ...cygwin\usr\doc\Cygwin Regards, Kerv ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[ADMIN] PostgreSQL & cygwin
Hello, Is any performance degree if I run PostgreSQL from cygwin on a Windows XP machine? thanks. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
