[BUGS] BUG #2879: RPM: wrong quoting of error message about old database format after upgrading
The following bug has been logged online: Bug reference: 2879 Logged by: Meetesh Karia Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.10 Operating system: Centos-4.2 Description:RPM: wrong quoting of error message about old database format after upgrading Details: There appears to be a regression in this issue: http://archives.postgresql.org/pgsql-bugs/2005-02/msg00197.php using the redhat RPMs. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] Patch for LISTEN/NOTIFY race condition?
Hi all, After upgrading to 8.3 and Slony 1.2.13, one of our import processes started constantly failing because of deadlock. Our import process (pl/pgsql function) just uses COPY FROM to populate a temp table and then inserts from that (without any special locks, etc). And, the deadlock error showed that the import process was waiting on sl_event and a slon process was waiting on pg_listener. I found the following thread in the archives: http://archives.postgresql.org/pgsql-bugs/2008-03/msg00117.php and it seemed like it could be the cause of the problem. Is the patch available anywhere? Also, if it will be available in 8.3.2, is there any information on when that will be released? Thanks and sorry if I missed this information posted somewhere, Meetesh
Re: [BUGS] Patch for LISTEN/NOTIFY race condition?
Thanks all ... I'm going to do some more digging and see if I can isolate the problem. Meetesh Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: Meetesh Karia wrote: After upgrading to 8.3 and Slony 1.2.13, one of our import processes started constantly failing because of deadlock. Our import process (pl/pgsql function) just uses COPY FROM to populate a temp table and then inserts from that (without any special locks, etc). And, the deadlock error showed that the import process was waiting on sl_event and a slon process was waiting on pg_listener. I found the following thread in the archives: http://archives.postgresql.org/pgsql-bugs/2008-03/msg00117.php and it seemed like it could be the cause of the problem. Is the patch available anywhere? Also, if it will be available in 8.3.2, is there any information on when that will be released? Hmm, AFAICS the patch should be present on 8.3.1, because it was tagged on March 14th and the patch was committed on March 12. Yes, but in any case (a) that's about a race condition not a deadlock, and (b) the issue has been there since forever, so it is unlikely to explain or fix a problem that you weren't seeing before 8.3. regards, tom lane
[BUGS] UUIDs generated using ossp-uuid on windows not unique
Hi all, This may not be the appropriate list to discuss this on (since it looks like the bug is in the underlying library), but as the win32 port was done because of postgresql (as far as I can tell), I wanted to see if anyone had run into this and/or had any workarounds: As best as I can tell, the problem is caused because generation of v1 UUIDs uses GetSystemTimeAsFileTime which is stated to have a resolution of 100 nanoseconds but in practice has a resolution of around 15ms (http://www.ddj.com/showArticle.jhtml?documentID=win0305a&pgno=17). Here's a snippet from log of id creation from a java app using Hibernate on 32-bit Windows Vista Home Premium: 17:59:50,007 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 400770c0-3bbd-11dd-9dcb-bfe9e8f8c4e3 17:59:50,016 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 4008d050-3bbd-11dd-bcfd-efd9d1bca81a 17:59:50,017 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 4008f760-3bbd-11dd-86d8-3b7fffcb1fd0 17:59:50,018 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 40091e70-3bbd-11dd-a129-c3ff008d4230 17:59:50,019 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 40094580-3bbd-11dd-91d4-3f3c34e3d932 17:59:50,020 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 40094580-3bbd-11dd-91d4-3f3c34e3d932 17:59:50,101 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 4015a190-3bbd-11dd-9639-9b73321c2f74 17:59:50,109 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 4016da10-3bbd-11dd-91d7-df8cd7608cfc 17:59:50,118 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 401860b0-3bbd-11dd-8ff9-5f0d982e530e 17:59:50,129 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 4019e750-3bbd-11dd-8e23-2315e240bab8 17:59:50,130 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 401a3570-3bbd-11dd-9af2-8350eef5ace8 17:59:50,131 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 401a5c80-3bbd-11dd-b91d-1fb0760aeab8 17:59:50,132 DEBUG [main][org.hibernate.id.GUIDGenerator] GUID identifier generated: 401a5c80-3bbd-11dd-b91d-1fb0760aeab8 Thoughts? Has anyone run into this before? Worked around it? Thanks, Meetesh
Re: [BUGS] UUIDs generated using ossp-uuid on windows not unique
Using the dll from the link that Hiroshi posted actually fixed v1 in my case (though perhaps it's just an unrelated side-effect caused by using a different random number generator which might be slower???). Thanks! Anyhow, I would have expected v1 to work fine in this case too as the ossp-uuid implementation has provisions for preventing overlapping ids when they're generated in rapid succession. And, as I was only generating about 1 uuid/ms, I didn't think that would be pushing the limits of the algorithm. Thanks again everyone, Meetesh Tom Lane wrote: Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: Tom Lane wrote: Perhaps the v4 generation method would work better for you? actually this has been reported before and seems to be an issue in the windows port of the ossp-uuid library: http://archives.postgresql.org/pgsql-bugs/2008-05/msg00059.php Oh, so that doesn't work either :-(. However, at least it's been fixed upstream: http://archives.postgresql.org/pgsql-bugs/2008-05/msg00070.php http://cvs.ossp.org/pkg/lib/uuid/ChangeLog regards, tom lane
