>> * Tom Lane ([EMAIL PROTECTED]) wrote:
>
>> Yeah, I wouldn't want one per second. Do we already track how long
>> we've been waiting?
>
> No, because we're *asleep*. You'd have to add an additional
> timeout-interrupt reason. Plus there's a ton of interesting questions
> about what's safe to
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> Incidentally in looking at this I found that the "early deadlock detection"
> never seems to fire. Reading the source it seems it ought to be firing
> whenever we have a simple two-process deadlock. But instead I only get the
> timeout-based detection.
Gregory Stark <[EMAIL PROTECTED]> writes:
> Ok, I understand now that early deadlock detection only kicks in when doing
> something like LOCK TABLE and even then only if you're deadlocking because
> you're upgrading a lock. So this works as intended though it's much less
> useful than I thought.
Y
Gregory Stark <[EMAIL PROTECTED]> writes:
> Attached is a patch which moves the messages to ProcSleep(). To do this I had
> to move the semaphore signal to unconditionally be signalled whenever
> CheckDeadLock() is called regardless of whether it finds a hard deadlock. I'm
> not 100% sure that's co
Gregory Stark <[EMAIL PROTECTED]> writes:
> Attached is a patch which moves the messages to ProcSleep().
BTW, with the messages moved out of the ISR it would be safe to make it
identify the specific lock being waited on (in the same terms used in
the existing deadlock messages). Is there a reason
Gregory Stark <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> In fact, I am scandalized to see that someone has inserted a boatload
>> of elog calls into CheckDeadLock since 8.2 --- that seems entirely
>> unsafe. [ checks revision history... ]
> Attached is a patch which mo
On Tue, 2007-06-19 at 16:24 -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > * Tom Lane ([EMAIL PROTECTED]) wrote:
> >> In fact, I am scandalized to see that someone has inserted a boatload
> >> of elog calls into CheckDeadLock since 8.2 --- that seems entirely
> >> unsafe. [
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> related TODO items:
> - add a WAIT n clause in same SQL locations as NOWAIT
> - add a lock_wait_timeout (USERSET), default = 0 (unlimited waiting)
>
> to provide better control over lock waits.
I havn't had a chance to look over the commit yet, sorry, bu
Stephen Frost <[EMAIL PROTECTED]> writes:
> I havn't had a chance to look over the commit yet, sorry, but it sounds
> like it's only logging to the log file? Was hoping to get a NOTICE back
> out to the user for at least the 'still waiting on lock x' log, after
> the deadlock detection.
It's elog
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Applied with some further revisions to improve the usefulness of the log
> messages. There's now one issued when the deadlock timeout elapses, and
> another when the lock is finally obtained:
>
> LOG: process 14945 still waiting for AccessExclusiveLock on
Gregory Stark <[EMAIL PROTECTED]> writes:
> Is it possible for unlocking the semaphore to wake another process other than
> our own? In which case checking log_lock_waits before signalling the semaphore
> arguably locks us into having log_lock_waits be PGC_POSTMASTER.
How you figure that?
> Curre
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Is it possible for unlocking the semaphore to wake another process other than
>> our own? In which case checking log_lock_waits before signalling the
>> semaphore
>> arguably locks us into having log_lock_waits
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> How you figure that?
> Well I'm not clear exactly what's going on with the semaphores here. If it's
> possible for to be printing the messages only as a result of another backend
> unlocking the semaphore then ma
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> How you figure that?
>
>> Well I'm not clear exactly what's going on with the semaphores here. If it's
>> possible for to be printing the messages only as a result of an
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I don't see how you arrive at that conclusion. The message is printed
>> by the backend that is waiting for (or just obtained) a lock, dependent
>> on its own local setting of log_lock_waits, and not dependent on
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Which is always the same process:
> PGSemaphoreUnlock(&MyProc->sem);
Aaah! I just grokked what's going on with the semaphores here. It all makes a
lot more sense now. Nevermind.
--
Gregory Stark
EnterpriseDB http://www.enterpr
On 6/19/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> related TODO items:
> - add a WAIT n clause in same SQL locations as NOWAIT
> - add a lock_wait_timeout (USERSET), default = 0 (unlimited waiting)
>
> to provide better control over lock waits.
>
are these actual TODO items? i can't find them
On Sat, 2007-09-22 at 23:49 -0500, Jaime Casanova wrote:
> On 6/19/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > related TODO items:
> > - add a WAIT n clause in same SQL locations as NOWAIT
> > - add a lock_wait_timeout (USERSET), default = 0 (unlimited waiting)
> >
> > to provide better cont
On 9/24/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-09-22 at 23:49 -0500, Jaime Casanova wrote:
> > On 6/19/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > >
> > > related TODO items:
> > > - add a WAIT n clause in same SQL locations as NOWAIT
> > > - add a lock_wait_timeout (USERSET),
On Mon, 2007-09-24 at 21:26 -0500, Jaime Casanova wrote:
> On 9/24/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-09-22 at 23:49 -0500, Jaime Casanova wrote:
> > > On 6/19/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > > >
> > > > related TODO items:
> > > > - add a WAIT n clause in sa
Simon Riggs <[EMAIL PROTECTED]> writes:
> SQLServer and DB2 have more need of this than PostgreSQL, but we do
> still need it.
Why? What does it do that statement_timeout doesn't do better?
regards, tom lane
---(end of broadcast)--
On Tue, 2007-09-25 at 09:16 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > SQLServer and DB2 have more need of this than PostgreSQL, but we do
> > still need it.
>
> Why? What does it do that statement_timeout doesn't do better?
If the execution time is negligible, then set
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Tue, 2007-09-25 at 09:16 -0400, Tom Lane wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>> > SQLServer and DB2 have more need of this than PostgreSQL, but we do
>> > still need it.
>>
>> Why? What does it do that statement_timeout doesn't do bett
On 9/25/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-25 at 09:16 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > SQLServer and DB2 have more need of this than PostgreSQL, but we do
> > > still need it.
> >
> > Why? What does it do that statement_timeout doe
24 matches
Mail list logo
