Re: [BUGS] BUG #4447: install failed to start; libintl3.dll was not found
We had the same problem last week when installing PG 8.3.5/8.3.4 on two machine running Win2k3 Server sr2 belonging to one of our customers. After some hours of trial and error we found out that this error only occurred when not installing to the system drive. If we chose the system drive for installation everything worked fine. We couldn't reproduce the error on our own machines though (real Win2k3 Server, and some VMs with various versions of W2k3 installed). Our customer's machines are used for development and software evaluation so there might be some third party software involved or it's a broken w2k3 installation. But we couldn't investigate any further. We used the MSI-Package for installation. As a workaround we installed postgres without running initdb and initialized the database manually. Marc Magnus Hagander wrote: > Jen McCann wrote: > >> The following bug has been logged online: >> >> Bug reference: 4447 >> Logged by: Jen McCann >> Email address: [EMAIL PROTECTED] >> PostgreSQL version: 8.3.4 >> Operating system: Win2k3 server sp1 >> Description:install failed to start; libintl3.dll was not found >> Details: >> >> I have attempted to install postgreSQL 8.3.4. on my win2k3 server sp1 >> (enterprise edition) machine, and it has failed with the following error: >> >> initdb.exe - Unable to Locate Component >> this application has failed to start because libintl3.dll was not found. >> Re-installing the application max fix this problem. >> >> Note: the libintl3.dll was indeed present on in the PostgreSQL 8.3\bin >> folder. >> >> I have been able to install version 8.2 without issue. >> However, the same issue was observed when attempting to install v8.3.3 >> > > Strange. You are using the MSI installer from our ftp site? Or are you > using the binaries-no-installer? > > Also, please verify using "depends.exe" that all the DLL files that > libintl3.dll requires are also present. > > //Magnus > > > -- click:ware Informationstechnik GmbH i. A. Marc Schablewski Hausanschrift: Kamekestraße 19 50672 Köln Postanschrift: Postfach 10 04 22 50444 Köln Tel: (+49) 0221 139988-0 Fax: (+49) 0221 139988-79 Geschäftsführer: Dipl.-Ing. Thomas Goerner Handelsregisternr: HRB 31438 ( Amtsgericht Köln ) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] could not read block 77 of relation 1663/16385/388818775
Yes, of course. After we started up the copied database, the system runs withour error for two days. That means some recordsets has been inserted sucessfully already. Gregory Stark schrieb: Alexandra Nitzschke <[EMAIL PROTECTED]> writes: This monday I updated postgres to 8.3.5 on the standby server. After that I intialized the database ( copy once the database from the primary system: removing data/* on stand-by, setting the database on primary in backup-modus and then copy the database files ) Uhm, just to be sure. You did pg_start_backup() on the primary *before* you started copying the data files across, right? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] could not read block 77 of relation 1663/16385/388818775
Hi, first of all I would like to thank you for all your efforts. > We really need a test case. unfortunately this kind of bugs tend to be non-reproducable. I assume that there is a race condition which is only hit in rare cases, under heavy load and when mars and venus are exactly aligned... ;-) I do not think it is possible to construct a test case that reliably reproduces the bug. However, we would be glad to incorporate any patches, additional logging code etc. in our installation of postgres that might help you to track the bug. Since we always build postgres on the production machine this would not be any problem. Unfortunately we handle very sensitive data in our databases, so we cannot give you direct access to our machines. As a last resort I would propose the following (provided that our customer agrees): We set up another machine and feed it with obfuscated data, putting it under the same load as our production machine. We could then give you root access to that machine and you could do whatever patching, monitoring, testing etc. might be helpful to track the problem. Do you think this might help? BTW... how about a block checksum that is checked just before writing a block and just after reading it? I know this would degrade performance, but I think we can afford that. Would it be possible to incorporate such code without having to do too much patching? Thanks in advance Alexandra Nitzschke Thomas Goerner Tom Lane schrieb: Alexandra Nitzschke <[EMAIL PROTECTED]> writes: Yes, its a btree. Well, the btree code is sufficiently well tested/debugged that I think there's zero chance of finding such a bug in it just on the suspicion that there might be one there. We really need a test case. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Postmaster keeps file references to deleted files
Bug reference: 4543 Logged by: Tzvi R. Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.5 Operating system: Linux (kernel 2.6.18) Description:File references are still held to deleted files Details: Hi, We frequently create large work tables that span across multiple files (though not using the "create temporary table" syntax). I noticed a few days ago that some transactions are about to fill the mount completely with those work tables, so I started canceling those queries and then dropped the tables, however, not all space has been reclaimed afterwards. Investigating further (using lsof) showed that postmaster still holds the deleted files open, whereas I would expect it to close them prior to deleting them (the database was completely idle, there were no running transactions/rollbacks at that time). Disk space was eventually reclaimed when the relevant process got terminated. Effectively, this prevents from the space being freed and results in leaks that cannot be reclaimed for other uses. Here's a quick list of what we've got from lsof showing this behavior: ERROR postmaste 10103 postgres 249u REG 120,81 0 524289 /db/pg_sys/data/base/30784/5953625 (deleted) ERROR postmaste 10103 postgres 250u REG 120,81 1073741824 524290 /db/pg_sys/data/base/30784/5953625.1 (deleted) ERROR postmaste 10103 postgres 251u REG 120,81 1073741824 524293 /db/pg_sys/data/base/30784/5953625.2 (deleted) ERROR postmaste 10103 postgres 252u REG 120,81 1073741824 524294 /db/pg_sys/data/base/30784/5953625.3 (deleted) ERROR postmaste 10103 postgres 255u REG 120,81 1073741824 524295 /db/pg_sys/data/base/30784/5953625.4 (deleted) ERROR postmaste 10103 postgres 257u REG 120,81 1073741824 524296 /db/pg_sys/data/base/30784/5953625.5 (deleted) ERROR postmaste 10103 postgres 258u REG 120,81 1073741824 524297 /db/pg_sys/data/base/30784/5953625.6 (deleted) ERROR postmaste 10103 postgres 259u REG 120,81 1073741824 524298 /db/pg_sys/data/base/30784/5953625.7 (deleted) ERROR postmaste 10103 postgres 260u REG 120,81 1073741824 524301 /db/pg_sys/data/base/30784/5953625.8 (deleted) ERROR postmaste 10103 postgres 261u REG 120,81 1073741824 524311 /db/pg_sys/data/base/30784/5953625.9 (deleted) ERROR postmaste 10103 postgres 262u REG 120,81 1073741824 524312 /db/pg_sys/data/base/30784/5953625.10 (deleted) ERROR postmaste 10103 postgres 263u REG 120,81 1073741824 524313 /db/pg_sys/data/base/30784/5953625.11 (deleted) ERROR postmaste 13308 postgres 196u REG 120,81 0 524289 /db/pg_sys/data/base/30784/5953625 (deleted) ERROR postmaste 13308 postgres 198u REG 120,81 1073741824 524290 /db/pg_sys/data/base/30784/5953625.1 (deleted) ERROR postmaste 13308 postgres 199u REG 120,81 1073741824 524295 /db/pg_sys/data/base/30784/5953625.4 (deleted) ERROR postmaste 13308 postgres 200u REG 120,81 1073741824 524296 /db/pg_sys/data/base/30784/5953625.5 (deleted) ERROR postmaste 13308 postgres 201u REG 120,81 1073741824 524297 /db/pg_sys/data/base/30784/5953625.6 (deleted) ERROR postmaste 13308 postgres 203u REG 120,81 1073741824 524298 /db/pg_sys/data/base/30784/5953625.7 (deleted) ERROR postmaste 13308 postgres 204u REG 120,81 1073741824 524301 /db/pg_sys/data/base/30784/5953625.8 (deleted) ERROR postmaste 13308 postgres 205u REG 120,81 1073741824 524311 /db/pg_sys/data/base/30784/5953625.9 (deleted) ERROR postmaste 13308 postgres 206u REG 120,81 1073741824 524293 /db/pg_sys/data/base/30784/5953625.2 (deleted) ERROR postmaste 13308 postgres 207u REG 120,81 1073741824 524294 /db/pg_sys/data/base/30784/5953625.3 (deleted) ERROR postmaste 13308 postgres 208u REG 120,81 1073741824 524312 /db/pg_sys/data/base/30784/5953625.10 (deleted) ERROR postmaste 13308 postgres 209u REG 120,81 1073741824 524313 /db/pg_sys/data/base/30784/5953625.11 (deleted) ERROR postmaste 14583 postgres 78u REG 120,81 0 3751985 /db/pg_sys/data/base/31294/5953974 (deleted) ERROR postmaste 14583 postgres 79u REG 120,81 1073741824 3751983 /db/pg_sys/data/base/31294/5953974.1 (deleted) ERROR postmaste 14583 postgres 80u REG 120,81 1073741824 3751994 /db/pg_sys/data/base/31294/5953974.2 (deleted) ERROR postmaste 14583 postgres 81u REG 120,81 1073741824 3752005 /db/pg_sys/data/base/31294/5953974.3 (deleted) ERROR postmaste 14583 postgres 82u REG 120,81 1073741824 3751995 /db/pg_sys/data/base/31294/5953974.4 (deleted) ERROR postmaste 14583 postgres 83u REG
Re: [BUGS] could not read block 77 of relation 1663/16385/388818775
Alexandra Nitzschke wrote: BTW... how about a block checksum that is checked just before writing a block and just after reading it? I know this would degrade performance, but I think we can afford that. Would it be possible to incorporate such code without having to do too much patching? oracle has had an option for some time that uses read/only page protection for each page of the shared buffer area... when oracle knows it wants to modify a page, it un-protects it via a system call. this catches any wild writes into the shared buffer area as a memory protection fault. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4548: Documentation Contradiction for 8.3
The following bug has been logged online: Bug reference: 4548 Logged by: Barry Reddy Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3 Operating system: Linux 2.6.24-19-server i686 RHEL5 Description:Documentation Contradiction for 8.3 Details: I’ve been going over the PostgreSQL documentation for pg_archiving, And have been struck by an apparent contradiction, which I’m hoping To clarify…not sure if you have any thoughts, or can refer this to any Contacts for a clarification, if so, feel free to forward. http://www.postgresql.org/docs/8.3/interactive/backup-file.html 1. The database server must be shut down in order to get a usable backup. Half-way measures such as disallowing all connections will not work (in part because tar and similar tools do not take an atomic snapshot of the state of the file system, but also because of internal buffering within the server). Information about stopping the server can be found in Section 17.5. Needless to say that you also need to shut down the server before restoring the data. http://www.postgresql.org/docs/8.3/interactive/continuous-archiving.html#BAC KUP-BASE-BACKUP 3. Perform the backup, using any convenient file-system-backup tool such as tar or cpio. It is neither necessary nor desirable to stop normal operation of the database while you do this. Can anyone clarify if this apparent contradiction is an oversight ? Old documentation with new archiving documentation patched on, with no attention paid to the seeming contradiction on guidelines for filesystem backups of a running PG database ? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4548: Documentation Contradiction for 8.3
In response to "Barry Reddy" <[EMAIL PROTECTED]>: > > The following bug has been logged online: > > Bug reference: 4548 > Logged by: Barry Reddy > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3.3 > Operating system: Linux 2.6.24-19-server i686 RHEL5 > Description:Documentation Contradiction for 8.3 > Details: > > I’ve been going over the PostgreSQL documentation for pg_archiving, > And have been struck by an apparent contradiction, which I’m hoping > To clarify…not sure if you have any thoughts, or can refer this to any > Contacts for a clarification, if so, feel free to forward. > > http://www.postgresql.org/docs/8.3/interactive/backup-file.html > > 1.The database server must be shut down in order to get a usable backup. > Half-way measures such as disallowing all connections will not work (in part > because tar and similar tools do not take an atomic snapshot of the state of > the file system, but also because of internal buffering within the server). > Information about stopping the server can be found in Section 17.5. Needless > to say that you also need to shut down the server before restoring the > data. > > http://www.postgresql.org/docs/8.3/interactive/continuous-archiving.html#BAC > KUP-BASE-BACKUP > > 3.Perform the backup, using any convenient file-system-backup tool such as > tar or cpio. It is neither necessary nor desirable to stop normal operation > of the database while you do this. > > Can anyone clarify if this apparent contradiction is an oversight ? Old > documentation with new archiving documentation patched on, with no attention > paid to the seeming contradiction on guidelines for filesystem backups of a > running PG database ? The data is correct and non-contradictory. The problem is that you're reading two different documents on two different methods of making backups. The methods have different rules that must be followed to get a good backup. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4548: Documentation Contradiction for 8.3
On Monday 24 November 2008 23:37:02 Barry Reddy wrote: > Can anyone clarify if this apparent contradiction is an oversight ? Old > documentation with new archiving documentation patched on, with no > attention paid to the seeming contradiction on guidelines for filesystem > backups of a running PG database ? It is not trivial to understand the difference. Perhaps the documentation doesn't make that entirely clear. When you do a base backup with archiving on, that backup is only usable together with the WAL segments that were written while the backup mode was active. So you can either make a backup: shutdown, tar, start And then recover with: shutdown, untar, start Or make a backup: pg_start_backup, tar, pg_stop_backup And then recover with: shutdown, untar, recovery In particular, it will *not* work to do: Backup: pg_start_backup, tar, pg_stop_backup Restore: shutdown, untar, start So if you read both sections separately, they are correct. It is only the partial overlap in the otherwise diffferent procedures that is confusing. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
