Re: [ADMIN] 64 bit rpms for 7.4.7??
Hi, I've checked the mirrors and although there is a directory for x86 64 bit rpms, it's empty. Are there plans to build these any time soon? I should have built them. Sorry it took so long. Everything was delayed because of some problems at work adn at home. I will try to catch up with the RPM building tomorrow! Sorry for all this.. Sander. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [ADMIN] 64 bit rpms for 7.4.7??
Hi again, I've checked the mirrors and although there is a directory for x86 64 bit rpms, it's empty. Are there plans to build these any time soon? I should have built them. Sorry it took so long. Everything was delayed because of some problems at work adn at home. I will try to catch up with the RPM building tomorrow! I couldn't sleep anyway, and I felt very guilty about letting everyone down... I had to make some patches to python.m4 and the specfile to make everything compile, and the resulting (S)RPMs are at http://opensource.nederland.net/PostgreSQL/. Devrim: can you put them on the official FTP site? Again my apologies for letting everyone wait so long Sander. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[ADMIN] Less available diskspace after crashed CLUSTER
Hi, I was running a CLUSTER on a big database (approx. 8G) and I didn't anticipate the diskspace usage, so I ran out of diskspace. This is on PostgreSQL 7.4.6. The backend crashed with the following log messages: 2005-01-15 15:17:46 [30605] PANIC: PANIC: could not write to file /var/lib/pgsql/data/pg_xlog/xlogtemp.30605: Geen ruimte over op apparaat STATEMENT: CLUSTER; 2005-01-15 15:17:46 [11245] LOG: server process (PID 30605) was terminated by signal 6 2005-01-15 15:17:46 [11245] LOG: terminating any other active server processes 2005-01-15 15:17:46 [3378] WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. ... a lot more of the same messages from other backends ... 2005-01-15 15:17:46 [11245] LOG: all server processes terminated; reinitializing 2005-01-15 15:17:46 [3389] LOG: database system was interrupted at 2005-01-15 15:17:44 CET 2005-01-15 15:17:46 [3389] LOG: checkpoint record is at 12/9E2976B0 2005-01-15 15:17:46 [3389] LOG: redo record is at 12/9E00A790; undo record is at 0/0; shutdown FALSE 2005-01-15 15:17:46 [3389] LOG: next transaction ID: 13482165; next OID: 1694415 2005-01-15 15:17:46 [3389] LOG: database system was not properly shut down; automatic recovery in progress 2005-01-15 15:17:46 [3389] LOG: redo starts at 12/9E00A790 2005-01-15 15:18:03 [3389] LOG: could not open file /var/lib/pgsql/data/pg_xlog/001200BF (log file 18, segment 191): Onbekend bestand of map 2005-01-15 15:18:03 [3389] LOG: redo done at 12/BEFFD810 2005-01-15 15:18:13 [3389] LOG: recycled transaction log file 0012009B 2005-01-15 15:18:13 [3389] LOG: recycled transaction log file 0012009C 2005-01-15 15:18:13 [3389] LOG: recycled transaction log file 0012009D 2005-01-15 15:18:13 [3389] LOG: database system is ready Translations: Geen ruimte over op apparaat - No space left on device Onbekend bestand of map - Unknown file or directory The database is running nice again, but I have the feeling I lost some diskspace... I suspected a temp file, so I stopped the postmaster, looked in /var/lib/pgsql/data/base/17142/pgsql_tmp, found one file and deleted it. But now I still have 1G less available diskspace than before the CLUSTER. Where should I look next? I would like the diskspace back :-) Thanks, Sander. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [ADMIN] Less available diskspace after crashed CLUSTER
Hi Tom, 2005-01-15 15:17:46 [30605] PANIC: PANIC: could not write to file /var/lib/pgsql/data/pg_xlog/xlogtemp.30605: Geen ruimte over op apparaat STATEMENT: CLUSTER; Hmm. I wonder why we have XLogFileInit forcing a PANIC for this. At one time it was called only from critical sections and so the error would become a panic anyway, but that's not true anymore... I'll leave that part to you :-) I don't know much about PostgreSQL internals... The database is running nice again, but I have the feeling I lost some diskspace... I suspected a temp file, so I stopped the postmaster, looked in /var/lib/pgsql/data/base/17142/pgsql_tmp, found one file and deleted it. But now I still have 1G less available diskspace than before the CLUSTER. Where should I look next? I would like the diskspace back :-) I'm guessing that the new table/index files created during the CLUSTER didn't get released after the PANIC. Look for files that are not referenced by any relfilenode value in pg_class. Don't forget that there may be multiple sections (filenode.1, etc). See http://developer.postgresql.org/docs/postgres/storage.html (which is for 8.0, but everything except the material on tablespaces applies to 7.4). Using the oid2name tool I get this: # for x in *; do echo -n $x: ; oid2name -q -d abacus -o $x; done 1247: 1247 = pg_type 1249: 1249 = pg_attribute 1255: 1255 = pg_proc 1259: 1259 = pg_class 16384: 16384 = pg_attrdef 16386: 16386 = pg_constraint 16388: 16388 = pg_inherits 16390: 16390 = pg_index 16392: 16392 = pg_operator 16394: 16394 = pg_opclass 16396: 16396 = pg_am 16398: 16398 = pg_amop 16400: 16400 = pg_amproc 16402: 16402 = pg_language 16404: 16404 = pg_largeobject 16406: 16406 = pg_aggregate 16408: 16408 = pg_statistic 16410: 16410 = pg_rewrite 16412: 16412 = pg_trigger 16414: 16414 = pg_listener 16416: 16416 = pg_description 16418: 16418 = pg_cast 16595: 16595 = pg_namespace 16597: 16597 = pg_conversion 16599: 16599 = pg_depend 16601: 16601 = pg_aggregate_fnoid_index 16602: 16602 = pg_am_name_index 16603: 16603 = pg_am_oid_index 16604: 16604 = pg_amop_opr_opc_index 16605: 16605 = pg_amop_opc_strategy_index 16606: 16606 = pg_amproc_opc_procnum_index 16607: 16607 = pg_attrdef_adrelid_adnum_index 16608: 16608 = pg_attrdef_oid_index 16609: 16609 = pg_attribute_relid_attnam_index 16610: 16610 = pg_attribute_relid_attnum_index 16611: 16611 = pg_cast_oid_index 16612: 16612 = pg_cast_source_target_index 16613: 16613 = pg_class_oid_index 16614: 16614 = pg_class_relname_nsp_index 16615: 16615 = pg_constraint_conname_nsp_index 16616: 16616 = pg_constraint_conrelid_index 16617: 16617 = pg_constraint_contypid_index 16618: 16618 = pg_constraint_oid_index 16619: 16619 = pg_conversion_default_index 16620: 16620 = pg_conversion_name_nsp_index 16621: 16621 = pg_conversion_oid_index 16624: 16624 = pg_depend_depender_index 16625: 16625 = pg_depend_reference_index 16626: 16626 = pg_description_o_c_o_index 16629: 16629 = pg_index_indrelid_index 16630: 16630 = pg_index_indexrelid_index 16631: 16631 = pg_inherits_relid_seqno_index 16632: 16632 = pg_language_name_index 16633: 16633 = pg_language_oid_index 16634: 16634 = pg_largeobject_loid_pn_index 16635: 16635 = pg_namespace_nspname_index 16636: 16636 = pg_namespace_oid_index 16637: 16637 = pg_opclass_am_name_nsp_index 16638: 16638 = pg_opclass_oid_index 16639: 16639 = pg_operator_oid_index 16640: 16640 = pg_operator_oprname_l_r_n_index 16641: 16641 = pg_proc_oid_index 16642: 16642 = pg_proc_proname_args_nsp_index 16643: 16643 = pg_rewrite_oid_index 16644: 16644 = pg_rewrite_rel_rulename_index 16647: 16647 = pg_statistic_relid_att_index 16648: 16648 = pg_trigger_tgconstrname_index 16649: 16649 = pg_trigger_tgconstrrelid_index 16650: 16650 = pg_trigger_tgrelid_tgname_index 16651: 16651 = pg_trigger_oid_index 16652: 16652 = pg_type_oid_index 16653: 16653 = pg_type_typname_nsp_index 16656: 16656 = pg_toast_16384 16658: 16658 = pg_toast_16384_index 16659: 16659 = pg_toast_16386 16661: 16661 = pg_toast_16386_index 16665: 16665 = pg_toast_16416 16667: 16667 = pg_toast_16416_index 16671: 16671 = pg_toast_1255 16673: 16673 = pg_toast_1255_index 16674: 16674 = pg_toast_16410 16676: 16676 = pg_toast_16410_index 16680: 16680 = pg_toast_16408 16682: 16682 = pg_toast_16408_index 1688060: No tables with that oid found 1688062: 1688062 = pg_toast_1688060 1688064: 1688064 = pg_toast_1688060_index 1688065: No tables with that oid found 1688066: No tables with that oid found 1688068: 1688068 = pg_toast_1688066 1688070: 1688070 = pg_toast_1688066_index 1688071: No tables with that oid found 1688072: No tables with that oid found 1688074: 1688074 = pg_toast_1688072 1688076: 1688076 = pg_toast_1688072_index 1688078: No tables with that oid found 1688079: No tables with that oid found 1688085: No tables with that oid found 1688086: No tables with that oid found 1688088: No tables with that oid found 1688089: No
Re: [ADMIN] Less available diskspace after crashed CLUSTER
Hi, Sorry for replying to myself, but I had to point out that: I'm guessing that the new table/index files created during the CLUSTER didn't get released after the PANIC. Look for files that are not referenced by any relfilenode value in pg_class. Using the oid2name tool I get this: [...] I suspect all the files with No tables with that oid found can be removed, but I don't know exactly how oid2name works, so I'll check them against pg_class before removing them. This is ofcourse not a good idea. There is quite a difference between the oid and the relfilenode. Comparing the output of: SELECT DISTINCT relfilenode FROM pg_class ORDER BY relfilenode; to the directory listing gave a much better result. The files I found in this way also had an atime which was the same as the time of the crash. Just to prevent someone else from making the mistake I made in my previous message... Thanks! Sander. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [ADMIN] These Lists Are Being Cut To FOUR
Hi, Hello. My name is Mike Cox. I am in charge of the changing of these postgresql lists. I have decided that we are going to drop most of the lists from the vote. We will only be making 4 lists into real Usenet newsgroups if we win the election. The rest of the lists are crap and they take up too much fucking room. Marc was an very offending language. Be sure to vote yes on all four of these lists or every list will be removed. Please grow up and learn to use decent language and arguments to make your point... Your support is most appreciated! Kicking this guy off the lists would be very much appreciated... Sander. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] RH-PostgreSQL version 7.3.4 is included RHEL 3
Hi, Sander Steffann [EMAIL PROTECTED] writes: I think there is some confusion about which PostgreSQL is included in RHEL3. I just checked and the following packages are in RHN channel Red Hat Enterprise Linux ES (v. 3 for x86): [snip] Right. Note the lack of any server-side packages. Only client-side support was included in RHEL3. Red Hat has now fixed things to the extent that you can download the server packages over RHN: http://kbase.redhat.com/faq/FAQ_47_632.shtm The new packages (including server) are in the Red Hat Enterprise Linux ES (v. 3 for x86) Extras channel. For the people without a RHEL subscription: The PostgreSQL related packages in the extras channel are: rh-postgresql-7.3.4-8 PostgreSQL client programs and libraries. rh-postgresql-contrib-7.3.4-8 Contributed source and binaries distributed with PostgreSQL rh-postgresql-devel-7.3.4-8PostgreSQL development header files and libraries. rh-postgresql-docs-7.3.4-8 Extra documentation for PostgreSQL rh-postgresql-jdbc-7.3.4-8 Files needed for Java programs to access a PostgreSQL database. rh-postgresql-libs-7.3.4-8 The shared libraries required for any PostgreSQL clients. rh-postgresql-pl-7.3.4-8 The PL procedural languages for PostgreSQL. rh-postgresql-python-7.3.4-8 Development module for Python code to access a PostgreSQL DB. rh-postgresql-server-7.3.4-8 The programs needed to create and run a PostgreSQL server. rh-postgresql-tcl-7.3.4-8 A Tcl client library for PostgreSQL. rh-postgresql-test-7.3.4-8 The test suite distributed with PostgreSQL. rhdb-admin-2.0-7 Administrator for PostgreSQL. rhdb-cc-1.0_Beta-2 Control Center for PostgreSQL - Red Hat Edition rhdb-docs-3.0-5HTML and PDF versions of the PostgreSQL - Red Hat Edition manuals. rhdb-explain-2.0-7 Visual Explain for PostgreSQL - Red Hat Edition rhdb-utils-2.0-1 Miscellaneous utilities for PostgreSQL - Red Hat Edition. Bye, Sander. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [ADMIN] Replicate PostgreSQL with rsync
Hi, I am trying to replicate a PostgreSQL database with rsync. Does anyone have a experience with that? We wanted to transfer a database to another machine with the minimum amount of downtime. We used rsync to make a copy of the database while PostgreSQL was running. this ofcourse is NOT a consistent copy. Then we shut down the database and we used rsync to copy all the differences from the first machine to the second, to make sure that the second machine had a consistent database. You'll have to shutdown the database to make the final transfer, but you can use rsync to do a lot of work while the database is still running. Good luck, Sander.
[ADMIN] RH-PostgreSQL version 7.3.4 is included RHEL 3
Hi, I think there is some confusion about which PostgreSQL is included in RHEL3. I just checked and the following packages are in RHN channel Red Hat Enterprise Linux ES (v. 3 for x86): postgresql-odbc-7.3-3 PostgreSQL ODBC driver. rh-postgresql-7.3.4-8 PostgreSQL client programs and libraries. rh-postgresql-contrib-7.3.4-8 Contributed source and binaries distributed with PostgreSQL rh-postgresql-devel-7.3.4-8 PostgreSQL development header files and libraries. rh-postgresql-docs-7.3.4-8Extra documentation for PostgreSQL rh-postgresql-jdbc-7.3.4-8Files needed for Java programs to access a PostgreSQL database. rh-postgresql-libs-7.3.4-8The shared libraries required for any PostgreSQL clients. rh-postgresql-python-7.3.4-8 Development module for Python code to access a PostgreSQL DB. rh-postgresql-tcl-7.3.4-8 A Tcl client library for PostgreSQL. I hope this answers some questions, Sander. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [ADMIN] RHEL
Hi,
Im currently on red hat 7.3
running postgres. Everything is running fine. Obviously, Im going
to have to upgrade to RHEL 3 in order to receive updates, etc. Does
anyone know of any problems with postgres running on RHEL 2.1 or RHEL
3?
We run PostgreSQL on a RHEL 2.1
system without any problems here. (Hardware is a Dell 2600 with Perc4/Di) We
also run PostgreSQL on our RedHat 9 development systems without problems
('Hardware' is a VMware ESX server running on a Dell 2600 with
Perc4/Di), and since RHEL 3 is bases on RH9 I
don't expect any problems there either.
Good luck!
Sander.
Re: [ADMIN] RHEL
Apologies for sending HTML mail to the list.
Here is a decent version of my message:
Hi,
Im currently on red hat 7.3 running postgres. Everything is running fine.
Obviously, Im going to have to upgrade to RHEL 3 in order to receive
updates, etc. Does anyone know of any problems with postgres running on
RHEL 2.1 or RHEL 3?
We run PostgreSQL on a RHEL 2.1 system without any problems here. (Hardware
is a Dell 2600 with Perc4/Di) We also run PostgreSQL on our RedHat 9
development systems without problems ('Hardware' is a VMware ESX server
running on a Dell 2600 with Perc4/Di), and since RHEL 3 is bases on RH9 I
don't expect any problems there either.
Good luck!
Sander.
---(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] H/W RAID 5 on slower disks versus no raid on faster HDDs
Hi, In a production environment I would always favor some kind of error protection. Either RAID 5 or RAID 1 (mirroring). A hardware RAID controller is faster than software RAID. Considering the speed of CPU's and busses these days, software RAID can be a lot faster than hardware RAID in many cases. I prefer hardware RAID myself because of the simplicity (the OS doesn't need to know about the RAID configuration), but I hear good results from people running on software RAID. Hope this helps you. Sander. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] multiple instances on one box?
I have seen one reason myself for this: running multiple versions of PostgreSQL on one machine. I have tried this once myself, to try out a new version while still providing our customers with the old version. Sander. - Original Message - From: Andrew Perrin [EMAIL PROTECTED] To: Tim Ellis [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 03, 2002 9:18 PM Subject: Re: [ADMIN] multiple instances on one box? What's the reason for doing this? Just use separate databases -- if necessary, with different users given permissions on each -- in the same postmaster instance. ap -- Andrew J Perrin - http://www.unc.edu/~aperrin Assistant Professor of Sociology, U of North Carolina, Chapel Hill [EMAIL PROTECTED] * andrew_perrin (at) unc.edu On Mon, 3 Jun 2002, Tim Ellis wrote: Hi, Hopefully not a FAQ, but I wonder, how do I start multiple Postgres instances on one computer? To elaborate, I want to start one Postgres listening on say 7000 for $DATA=/opt/pgdata1 and another Postgres listening on say 7100 for $DATA=/opt/pgdata2. Thanks, Tim Ellis DBA, Gamet ---(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 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 4: Don't 'kill -9' the postmaster
Re: [ADMIN] databases and RAID ...
On Sun, May 26, 2002 at 08:00:50AM -0700, Bill Cunningham wrote: No Raid 10 is Raid 1 + 0 its strong points are faster writes but slower reads. RAID 10 reads will actually be faster than RAID 5, but it will require more disks. (2n instead of n+1). There also seems to be a combination of RAID 5 + 0, called RAID 50. It performs faster than RAID 5, and slower than RAID 10. Disk usage is also between those two (n+2). Sander. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
