The following bug has been logged online:
Bug reference: 3242
Logged by: Marcin Waldowski
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.3 and 8.2.1
Operating system: Windows XP SP2
Description:FATAL: could not unlock semaphore: error code 298
Details:
> 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.
Dave,
Thanks a lot. You can downloa
Dorochevsky,Michel wrote:
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.
Dave,
Thanks a lo
Heikki Linnakangas wrote:
Dave, could you do another build with LOCK_DEBUG enabled? Michel, could
you please add trace_locks=on to postgresql.conf, and run the test one
more time with the LOCK_DEBUG-enabled build. That should give us a much
better picture of what's happening. (be warned, it can
"Dorochevsky,Michel" <[EMAIL PROTECTED]> writes:
> Thanks a lot. You can download the results at
> www.dorochevsky.de/infos/postgresql-2007-04-23_130939.zip
> run with the debug version of postgres you provided.
So, which of your tables has OID 417227? Easiest way to check is
select 4
> Von: Tom Lane [mailto:[EMAIL PROTECTED]
> So, which of your tables has OID 417227? Easiest way to check is
> select 417227::regclass
>
Tom,
Currently a table with name
requireditemtypes_mill7b7c7621
has the object id 417227.
I did restart the DB server in the meantime several times.
I
"Dorochevsky,Michel" <[EMAIL PROTECTED]> writes:
>> Von: Tom Lane [mailto:[EMAIL PROTECTED]
>> So, which of your tables has OID 417227? Easiest way to check is
>> select 417227::regclass
> Currently a table with name
> requireditemtypes_mill7b7c7621
> has the object id 417227.
Okay, and that t
Michel, could you show us all the non-default entries in your
postgresql.conf? Just wondering if there might be something relevant...
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will
> From: Dave Page [mailto:[EMAIL PROTECTED]
> Heikki Linnakangas wrote:
> > Dave, could you do another build with LOCK_DEBUG enabled? Michel, could
> > you please add trace_locks=on to postgresql.conf, and run the test one
> > more time with the LOCK_DEBUG-enabled build. That should give us a mu
Marcin Waldowski wrote:
>
>> The following bug has been logged online:
>>
>> Bug reference: 3242
>> Logged by: Marcin Waldowski
>> Email address: [EMAIL PROTECTED]
>> PostgreSQL version: 8.2.3 and 8.2.1
>> Operating system: Windows XP SP2
>> Description:FATAL: could no
"Dorochevsky,Michel" <[EMAIL PROTECTED]> writes:
> Here are two panic runs with the Heikki's LOCK_DEBUG patched postgres:
>www.dorochevsky.de/infos/PostgresPanicProblem-2007-04-23.zip
Ok, this does provide a new clue: the problem table is being locked
twice (under two different lock types) in
-Ursprüngliche Nachricht-
> Von: Tom Lane [mailto:[EMAIL PROTECTED]
> > "Dorochevsky,Michel" <[EMAIL PROTECTED]> writes:
> > Here are two panic runs with the Heikki's LOCK_DEBUG patched postgres:
> >www.dorochevsky.de/infos/PostgresPanicProblem-2007-04-23.zip
>
> Ok, this does provide
"Dorochevsky,Michel" <[EMAIL PROTECTED]> writes:
> I am not used to the command line tools. So I made a backup
> using the pgadmin GUI. I selected options 'PLAIN format', 'with OIDs' and
> 'schema only'. See
> www.dorochevsky.de/infos/TestSchema.txt
> I hope that is what you needed.
Yeah, this
> --- Original Message ---
> From: Tom Lane <[EMAIL PROTECTED]>
> To: "Dorochevsky,Michel" <[EMAIL PROTECTED]>
> Sent: 23/04/07, 19:51:51
> Subject: Re: [BUGS] BUG #3245: PANIC: failed to re-find shared loc k o b j ect
>
> "Dorochevsky,Michel" <[EMAIL PROTECTED]> writes:
> > I am not use
I wrote:
>> Yeah, this is great, particularly since it includes the OIDs. However,
>> the OIDs don't seem to entirely match up with the LOCK_DEBUG output.
>> I'm wondering if somehow we're locking the wrong OIDs?
This may be a false alarm --- I had forgotten that relation locks are
taken at Parse
Tom Lane wrote:
"Dorochevsky,Michel" <[EMAIL PROTECTED]> writes:
I am not used to the command line tools. So I made a backup
using the pgadmin GUI. I selected options 'PLAIN format', 'with OIDs' and
'schema only'. See
www.dorochevsky.de/infos/TestSchema.txt
I hope that is what you needed.
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Locking the same lock twice is usually handled correctly, I don't
> understand why it fails in this case. I'm thinking that the locallock
> structs somehow get out of sync with the lock structs in shared memory.
> The twophase-records are created
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Locking the same lock twice is usually handled correctly, I don't
understand why it fails in this case. I'm thinking that the locallock
structs somehow get out of sync with the lock structs in shared memory.
The twophase-records ar
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Dave, would you please create a new binary with the attached patch? And
> LOCK_DEBUG and assertions and debug enabled.
Also, it would be worth adding "lockmode" to the set of things printed
by the panic message in the patch I sent earlier. Heikki
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm. I was just noticing this comment in PostPrepare_Locks:
>>
>> * We do this separately because we may have multiple locallock entries
>> * pointing to the same proclock, and we daren't end up with any dangling
>> * pointers.
>
I wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Dave, would you please create a new binary with the attached patch? And
>> LOCK_DEBUG and assertions and debug enabled.
> Also, it would be worth adding "lockmode" to the set of things printed
> by the panic message in the patch I sent
Tom Lane wrote:
I wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Dave, would you please create a new binary with the attached patch? And
LOCK_DEBUG and assertions and debug enabled.
Also, it would be worth adding "lockmode" to the set of things printed
by the panic message in the patc
Hello,
using a database with utf8 encoding and utf8 locale, accented letters are
not properly compared.
Test to reproduce: it converts a lowercase letter (the sequence '\xc3\xa8'
is the utf8 encoding of the unicode 'LATIN SMALL LETTER E WITH GRAVE') into
uppercase and then compares the two letter
Well hot dang, I managed to reproduce this:
$ ./followlog "dbname = tschema" http://www.postgresql.org/docs/faq
I wrote:
> Now to start debugging.
It looks to me like the problem is that AtPrepare_Locks invokes
LockTagIsTemp, and that goes and reads various system catalogs, which
can result in new entries in the LOCALLOCK hash table, which might
result in a bucket split in same, which would result in some e
Magnus,
I have applied your patch on 8.2.3 source and built it in mingw
environment (with default settings). After 3 hours of performance test
nothing happened, log is clear :) In previous test error occur always
within first hour (most often within first 20 minutes), so I can
initialy conf
Marcin Waldowski <[EMAIL PROTECTED]> writes:
> Ok, that's the end of the story :) My workmate has confirmed that during
> night test PostgreSQL worked perfectly :)
That fix was Obviously Necessary even without testing -- you're being
too conservative about not applying it, Magnus.
27 matches
Mail list logo
