On 07/04/2008, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Pavel Stehule escribió:
>
>
> > WARNING: problem in alloc set MessageContext: req size > alloc size
> > for chunk 0x8b6d1e0 in block 0x8b6bb50
> > WARNING: problem in alloc set MessageContext: req size > alloc size
> > for chunk 0x8b6
Pavel Stehule escribió:
> WARNING: problem in alloc set MessageContext: req size > alloc size
> for chunk 0x8b6d1e0 in block 0x8b6bb50
> WARNING: problem in alloc set MessageContext: req size > alloc size
> for chunk 0x8b6d1e0 in block 0x8b6bb50
I suggest you make distclean and rebuild the whol
On 07/04/2008, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Pavel Stehule wrote:
>
> > when I tested ptop, I found some problems
> >
>
> Which version are you running?
I am sorry, HEAD 8.4 today actualized
Pavel
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
Pavel Stehule wrote:
when I tested ptop, I found some problems
Which version are you running?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
Hello
when I tested ptop, I found some problems
this pgbench is very slow and when after getting table of locks from
ptop I got backend crash.
[EMAIL PROTECTED] ~]$ /usr/local/pgsql/bin/pgbench -c80 -t1000 postgres
starting vacuum...end.
WARNING: you don't own a lock of type ShareLock
WARNING:
Gregory Stark <[EMAIL PROTECTED]> writes:
> I think we should go ahead and print a LOG message in the case where a
> deadlock is detected.
After chewing on it some more, I liked this patch better ... but I found
a couple other issues, particularly with the soft-deadlock-recovery
messaging sequence
Gregory Stark <[EMAIL PROTECTED]> writes:
> I think we should go ahead and print a LOG message in the case where a
> deadlock is detected.
That seems reasonable, but I don't find any of these other changes to be
an improvement...
regards, tom lane
Well the problem with spurious waits for deadlocks turned out to be quite
mundane. The deadlocks were not so spurious after all... there were real
deadlocks which were being hidden by a plpgsql function that caught the
exception and didn't report the error.
I think this is still a minor problem t
Gregory Stark <[EMAIL PROTECTED]> writes:
> I'm debugging this problem with stalled transactions waiting on locks which
> have already been granted and I'm puzzled by something. What is this PGPROC
> entry from?
I seem to recall that there's a dummy sentinel header in proc lists ...
is that what y
Gregory Stark wrote:
>
> I'm debugging this problem with stalled transactions waiting on locks which
> have already been granted and I'm puzzled by something. What is this PGPROC
> entry from?
>
> It's not a real process (pid is 0) and it's not garbage either (prev and next
> both point to a rea
I'm debugging this problem with stalled transactions waiting on locks which
have already been granted and I'm puzzled by something. What is this PGPROC
entry from?
It's not a real process (pid is 0) and it's not garbage either (prev and next
both point to a real PGPROC entry, namely MyProc which
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> I switched the code over to the sysv_sema style api. It's gotten a bit grotty
>> and I would clean it up if it weren't a temporary test program. If we find a
>> real problem perhaps I should add a test case like this to the "
Gregory Stark wrote:
> I switched the code over to the sysv_sema style api. It's gotten a bit grotty
> and I would clean it up if it weren't a temporary test program. If we find a
> real problem perhaps I should add a test case like this to the "smoke test" in
> ipc_test.c so people can check thei
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> Seems to me this proves nothing much, since it doesn't use the same SysV
>>> semaphore API PG does.
>
>> I was trying to copy the semaphore API exactly assuming
>> USE_
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Seems to me this proves nothing much, since it doesn't use the same SysV
>> semaphore API PG does.
> I was trying to copy the semaphore API exactly assuming
> USE_NAMED_POSIX_SEMAPHORES was *not* defined. Accordi
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I've written a synthetic test program to check for lost semaphore wakeups.
>
> Seems to me this proves nothing much, since it doesn't use the same SysV
> semaphore API PG does. Please adjust so that it looks mor
Gregory Stark <[EMAIL PROTECTED]> writes:
> I've written a synthetic test program to check for lost semaphore wakeups.
Seems to me this proves nothing much, since it doesn't use the same SysV
semaphore API PG does. Please adjust so that it looks more like our
code --- in particular there should b
2007/8/12, Gregory Stark <[EMAIL PROTECTED]>:
> > "Gregory Stark" <[EMAIL PROTECTED]> writes:
> >
> >> "Tom Lane" <[EMAIL PROTECTED]> writes:
> >>
> >>> Gregory Stark <[EMAIL PROTECTED]> writes:
> We're seeing a problem where occasionally a process appears to be
> granted a
> lock b
Gregory Stark wrote:
> "Gregory Stark" <[EMAIL PROTECTED]> writes:
>
>> "Gregory Stark" <[EMAIL PROTECTED]> writes:
>>
>>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>>
Gregory Stark <[EMAIL PROTECTED]> writes:
> We're seeing a problem where occasionally a process appears to be granted
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Gregory Stark" <[EMAIL PROTECTED]> writes:
>
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>
>>> Gregory Stark <[EMAIL PROTECTED]> writes:
We're seeing a problem where occasionally a process appears to be granted a
lock but miss its semaphore
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
>> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> We're seeing a problem where occasionally a process appears to be granted a
>>> lock but miss its semaphore signal.
>>
>> Kernel bug maybe? What's the platform?
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> We're seeing a problem where occasionally a process appears to be granted a
>> lock but miss its semaphore signal.
>
> Kernel bug maybe? What's the platform?
It does sound like it given the way my description
Gregory Stark <[EMAIL PROTECTED]> writes:
> We're seeing a problem where occasionally a process appears to be granted a
> lock but miss its semaphore signal.
Kernel bug maybe? What's the platform?
regards, tom lane
---(end of broadcast)---
We're seeing a problem where occasionally a process appears to be granted a
lock but miss its semaphore signal. It eventually gets the 60s deadlock signal
and notices that it has been granted the lock and gets back to work.
I haven't gotten any further than this in the forensic analysis and it's
24 matches
Mail list logo
