Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298
Marcin Waldowski wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>
>>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>>
No, it's definitly the right primitive. But we're creating it with a
max
count of 1.
>>> That's definitely wrong. There are at least three reasons for a PG
>>> process's semaphore to be signaled (heavyweight lock release, LWLock
>>> release, pin count waiter), and at least two of them can occur
>>> concurrently (eg, if deadlock checker fires, it will need to take
>>> LWLocks, but there's nothing saying that the original lock won't be
>>> released while it waits for an LWLock).
>>>
>>> The effective max count on Unixen is typically in the thousands,
>>> and I'd suggest the same on Windows unless there's some efficiency
>>> reason to keep it small (in which case, maybe ten would do).
>>>
>>
>> AFAIK there's no problem with huge numbers (it takes an int32, and the
>> documentation says nothing about a limit - I'm sure it's just a 32-bit
>> counter in the kernel). I'll give that a shot.
>>
>
> Magnus, Tom, thank you for finding what causes the problem :) I hope
> that was also a reason why other transactions were hung (because that is
> a prior, I think).
>
>> Marcin - can you test a source patch? Or should I try to build you a
>> binary for testing? It'd be good if you can confirm that it works before
>> we commit anything, I think.
>>
>
> Of course I will check fix :) I will be able to do tests on monday. I
> think source path should be enought, despite I've newer build PostgreSQL
> on Windows (I definitely should try). If i have problems then I will ask
> you for binary.
Great, please try the attached trivial patch.
//Magnus
Index: src/backend/port/win32_sema.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/port/win32_sema.c,v
retrieving revision 1.4
diff -c -r1.4 win32_sema.c
*** src/backend/port/win32_sema.c 5 Jan 2007 22:19:35 - 1.4
--- src/backend/port/win32_sema.c 22 Apr 2007 18:19:13 -
***
*** 82,88
sec_attrs.bInheritHandle = TRUE;
/* We don't need a named semaphore */
! cur_handle = CreateSemaphore(&sec_attrs, 1, 1, NULL);
if (cur_handle)
{
/* Successfully done */
--- 82,88
sec_attrs.bInheritHandle = TRUE;
/* We don't need a named semaphore */
! cur_handle = CreateSemaphore(&sec_attrs, 1, 32767, NULL);
if (cur_handle)
{
/* Successfully done */
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared loc k ob ject
Tom Lane wrote: "Dorochevsky,Michel" <[EMAIL PROTECTED]> writes: The failing transaction is visible in the database after restart, I have checked three of the last inserts, e.g. Good, at least we're not losing data ;-). But I expected that because this PANIC must be occurring after the RecordTransactionCommitPrepared step. I have no leftover file in $PGDATA/pg_twophase, it is empty. [ digs in code some more... ] Oh, I see how that happens: the 2PC state file is removed when the XLOG_XACT_COMMIT_PREPARED xlog entry is replayed, so the various code paths that might emit a warning won't be reached. Heikki, have you been paying attention to this thread? You have any idea what's happening? The whole thing seems pretty unexplainable to me, especially since Michel's log shows this happening without any concurrent activity that might confuse matters. I confess bafflement. Oh, no I wasn't. I'm up to speed now. I can't see any way that can happen either. There's some other transactions running, but not at the time of prepare or commit. And there's no other errors or unusual activity in the logs. The only thing I can think of is that a lock is released between the calls to AtPrepare_Locks and PostPrepare_Locks. But I don't see how that could happen. I think we need to see more debug-information. Is there a debug- and assertion-enabled binary available for Windows? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared loc k ob ject
Heikki Linnakangas wrote: > I think we need to see more debug-information. Is there a debug- and > assertion-enabled binary available for Windows? Unfortunately no - 95% of the time we've found that Mingw/gdb on windows simply doesn't work. That's one of the major reasons why we're working on moving to VC++. I can build one tomorrow if you want to try for the 5%. What version was this? Regards, Dave. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared loc k ob ject
Dave Page <[EMAIL PROTECTED]> writes: > Heikki Linnakangas wrote: >> I think we need to see more debug-information. Is there a debug- and >> assertion-enabled binary available for Windows? > Unfortunately no - 95% of the time we've found that Mingw/gdb on windows > simply doesn't work. That's one of the major reasons why we're working > on moving to VC++. > I can build one tomorrow if you want to try for the 5%. What version was > this? Having assertions turned on would be useful regardless of debug support. What I was going to suggest was to add some detail printout to the PANIC message --- in particular, dump the fields of the problem LOCKTAG, so we can at least find out *what* lock is being lost. If you build a custom copy for Michel, please add this patch (untested but should work): *** src/backend/storage/lmgr/lock.c.origThu Feb 1 15:09:33 2007 --- src/backend/storage/lmgr/lock.c Sun Apr 22 16:17:01 2007 *** *** 2430,2437 HASH_FIND, NULL); if (!lock) ! elog(PANIC, "failed to re-find shared lock object"); ! /* * Re-find the proclock object (ditto). */ --- 2430,2443 HASH_FIND, NULL); if (!lock) ! elog(PANIC, "failed to re-find shared lock object: %u %u %u %u %u %u", !locktag->locktag_field1, !locktag->locktag_field2, !locktag->locktag_field3, !locktag->locktag_field4, !locktag->locktag_type, !locktag->locktag_lockmethodid); ! } /* * Re-find the proclock object (ditto). */ regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared loc k ob ject
Dave Page wrote: Heikki Linnakangas wrote: I think we need to see more debug-information. Is there a debug- and assertion-enabled binary available for Windows? Unfortunately no - 95% of the time we've found that Mingw/gdb on windows simply doesn't work. That's one of the major reasons why we're working on moving to VC++. I'm not so much interested in using gdb, but in having assertions enabled and getting the output of LOCK_DEBUG. I can build one tomorrow if you want to try for the 5%. What version was this? Thanks, it was 8.2.3. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3245: PANIC: failed to re-find shared loc k ob ject
Heikki Linnakangas wrote: I can build one tomorrow if you want to try for the 5%. What version was this? Thanks, it was 8.2.3. Actually, no reason this needs to wait until I'm in the office. Michel; I've uploaded an 8.2.3 postgres.exe to http://developer.pgadmin.org/~dpage/postgres-8.2.3-debug.zip. This is the same as the release version, but configured with --enable-debug --enable-cassert, and patched with Tom's patch. Regards, Dave. ---(end of broadcast)--- TIP 1: 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: [BUGS] BUG #3244: problem with PREPARE
"William Lawrance" <[EMAIL PROTECTED]> writes: > This program that does "PQprepare" and then > "PQexecPrepared" has worked previously, but doesn't > work now. > ... > strcpy(openStmt, "declare C1 cursor for select cola" >" from tprep" >" where cola = $1"); > res = PQprepare(conn, "stmtopen", openStmt, 0, 0); I looked into this a bit and found that the issue comes from my recent changes in support of plan caching. To simplify matters, I instituted a rule that utility statements don't have any interesting transformations done at parse analysis time; see this new comment in analyze.c: * For optimizable statements, we are careful to obtain a suitable lock on * each referenced table, and other modules of the backend preserve or * re-obtain these locks before depending on the results. It is therefore * okay to do significant semantic analysis of these statements. For * utility commands, no locks are obtained here (and if they were, we could * not be sure we'd still have them at execution). Hence the general rule * for utility commands is to just dump them into a Query node untransformed. * parse_analyze does do some purely syntactic transformations on CREATE TABLE * and ALTER TABLE, but that's about it. In cases where this module contains * mechanisms that are useful for utility statements, we provide separate * subroutines that should be called at the beginning of utility execution; * an example is analyzeIndexStmt. This means that "preparing" a DECLARE CURSOR is now effectively a no-op; it doesn't do much more than detect basic syntax errors that the Bison grammar can catch. If you run this program without having created the tprep table, the PQprepare doesn't fail! But the bigger problem, at least for Bill's complaint, is that we also don't notice, let alone assign datatypes to, any parameter symbols appearing in the query. I don't see any particular problem in this for the other command types that had their analyze-time processing removed; there's no value in a parameter in CREATE VIEW, for example. But evidently there's some interest in having parameters in prepared DECLARE CURSOR commands. The easiest answer I can think of at the moment is to run parse analysis for a DECLARE CURSOR and then throw away the result. To avoid this overhead in cases where it's useless, we could probably teach analyze.c to do it only if p_variableparams is true (which essentially would mean that the DECLARE CURSOR came in via PQprepare or equivalent, and not as a simply executable statement). Plan B would be to promote DECLARE CURSOR to an "optimizable statement" that is treated under the same rules as SELECT/UPDATE/etc, in particular that we assume locks obtained at analysis are held through to execution. This might be a cleaner answer overall, but I have no idea right now about the effort required or any possible downsides. Comments, better ideas? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
