"Tom Lane" <[EMAIL PROTECTED]> writes:
> Yeah, my proposed patch is schoolbook division. I don't think I'd trust
> Newton's method to give anything but a close approximation, which is
> what we have in HEAD already.
Well unless we start storing rational numbers it'll always be a limited to a
fi
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> So your complaint about the existing code boils down to not having any
> rigorous way to know when to stop. I don't think Newton's method has that
> problem, at least not for simple polynomials. Any digits which don't change
> from one iteration to the
>> * 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
On May 30, 2007, at 3:40 PM, Neil Conway wrote:
On Wed, 2007-30-05 at 21:23 +0200, Peter Eisentraut wrote:
I'm not sure what your rationale was for creating lower-case words
instead of upper case, except for it looks nicer. Is there a
technical
reason?
There's no real technical reason: the
On Jun 17, 2007, at 4:39 AM, Simon Riggs wrote:
pg_start_backup() should be a normal checkpoint I think. No need for
backup to be an intrusive process.
Good point. A spread out checkpoint can take a long time to finish,
though. Is there risk for running into a timeout or something if it
takes s
Jim Nasby wrote:
On Jun 17, 2007, at 4:39 AM, Simon Riggs wrote:
pg_start_backup() should be a normal checkpoint I think. No need for
backup to be an intrusive process.
Good point. A spread out checkpoint can take a long time to finish,
though. Is there risk for running into a timeout or somet
"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.
On Sun, May 20, 2007 at 01:28:40AM -0700, Henry B. Hotz wrote:
> I finally got to testing that updated patch. It's fine per-se, but
> was missing the updated README.GSSAPI file. Herewith fixed.
>
I've been reviewing and updating this patch, for a while now.I've changed
quite a bit around, and
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Yeah, my proposed patch is schoolbook division. I don't think I'd trust
>> Newton's method to give anything but a close approximation, which is
>> what we have in HEAD already.
> Well unless we start storing rat
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
Tom Lane wrote:
I wrote:
...
Now it's unlikely that real-world applications are going to be as
dependent on the speed of div_var for long inputs as numeric_big is.
And getting the right answer has to take priority over speed anyway.
Still this is a bit annoying. Anyone see a way to speed it up
I attach a patch to fix some issues in the autovac process handling
code. Mainly, instead of rechecking periodically in the launcher
whether a worker was able to start or not, what we do is signal it from
the postmaster when it fails.
In order to do this I had to make the postmaster set a flag in
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
Alvaro Herrera wrote:
> One problem with the patch is this (new code):
>
> bn = (Backend *) malloc(sizeof(Backend));
> ! if (bn)
> {
> ! bn->pid = StartAutoVacWorker();
> ! bn->is_autovacuum = true;
> ! /* we don't need a cancel key */
>
> ! if (bn->pid > 0)
>
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
Alvaro Herrera wrote:
> One problem with the patch is this (new code):
>
> bn = (Backend *) malloc(sizeof(Backend));
> ! if (bn)
> {
> ! bn->pid = StartAutoVacWorker();
> ! bn->is_autovacuum = true;
> ! /* we don't need a cancel key */
>
> ! if (bn->pid > 0)
>
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
Such timing!
I just spent most of yesterday stepping though the gssapi sample
app's in Java 1.4 with someone here at work. Was thinking I needed
to get back to the JDBC client and do what I promised. Also finished
filtering the PG lists for stuff just before seeing this email.
On Jun 19
Here is a patch that cancels autovacuum workers conflicting with
DROP TABLE, TRUNCATE and CLUSTER. It was discussed here:
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00556.php
Before backends drop a table, they search autovacuum workers that
are running on the table. If found, they sen
22 matches
Mail list logo
