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 same SQL locations as
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
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 setting
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 better?
If the
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 doesn't do better?
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 control over lock
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), default = 0
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 the
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?
Currently
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 be
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 making the
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 who
woke
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
* 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 do from an
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.
Ok, I
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 correct
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 moves the
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. [ checks
20 matches
Mail list logo
