Please, let's revisit this, and not postpone it without further
discussion. I never knew about the correctness issues in div_var(), but
since I know about it, I feel I am just waiting until that problem will
hit me or anyone else.
So can you, Tom, please describe in what situations the old code
Michael Paesold [EMAIL PROTECTED] writes:
Please, let's revisit this, and not postpone it without further
discussion. I never knew about the correctness issues in div_var(), but
since I know about it, I feel I am just waiting until that problem will
hit me or anyone else.
Yeah. I was
Stephan Szabo [EMAIL PROTECTED] writes:
On Sun, 15 Jul 2007, Tom Lane wrote:
I don't think this is right. If the original tuple was inserted by a
subtransaction of our transaction, it will have been checked at
subtransaction subcommit, no?
I don't think the subtransaction subcommit will do
Tom Lane [EMAIL PROTECTED] writes:
Michael Paesold [EMAIL PROTECTED] writes:
Please, let's revisit this, and not postpone it without further
discussion. I never knew about the correctness issues in div_var(), but
since I know about it, I feel I am just waiting until that problem will
hit
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Yeah. I was basically waiting to see if anyone could come up with a
faster solution. Since no one seems to have an idea how to do it
better, I'm inclined to apply the patch for 8.3.
My only reservation is that I
OK, that's what I get for opining before checking the code ;-).
Your *cerebral call graph visits* have a knack of being spot on, way
more than often. :-)
Will apply.
Thanks, Tom. We're also back-patching this, right?
--
Affan Salman
EnterpriseDB Corporation
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Yeah. I was basically waiting to see if anyone could come up with a
faster solution. Since no one seems to have an idea how to do it
better, I'm inclined to apply the patch for
Affan Salman [EMAIL PROTECTED] writes:
Thanks, Tom. We're also back-patching this, right?
Yeah, working on that now.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
I used to have a different patch from Andrew that did part of this, and
more, and conflicted rather badly with it. However, I never got around
to applying that one, and I can't seem to find it anymore.
Andrew -do you recall if you had all this in yours, and is it still
something you want in, or
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Well, this doesn't take a lot of numerical methods background: the
fundamental problem is that the existing code generates an *approximate*
answer, whereas people who are doing div and mod on large integers tend
to
On Tue, 2007-07-17 at 01:28 -0400, Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Tom Lane [EMAIL PROTECTED] writes:
No, my proposed patch doesn't change that. It might be that we should
provide an integer division operator for NUMERIC, so that you can get
at the exact result of trunc(x/y).
I was also thinking that if the denominator had only factors of 2 and 5 we
could
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
I am fighting some fires in my day job.
My pesonal TODO list for pg up to beta is:
. fix chunking muddle (see recent emails)
. complete CSV logs patch
. harden MSVC builds
I'll get to this when I can. I can dig up the patch I did if you want
it again.
cheers
andrew
Magnus Hagander
I have applied the attached patch that documents the age() behavior,
plus fixes the mismatch sign for seconds by using part of Tom's earlier
patch.
I agree we want to keep the symmetry we have. We can call this item
closed.
Alvaro Herrera wrote:
Stefan Kaltenbrunner just let me know via Jabber that there's a warning
in pg_regress.c:
pg_regress.c: In function `spawn_process':
pg_regress.c:914: warning: missing sentinel in function call
This small patch would seem to fix it, according to
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gavin M. Roy wrote:
This is the patch I proposed on hackers to make pg_dump optionally ignore
tablespaces. The
Patch applied. Thanks. Your documentation changes can be viewed in
five minutes using links on the developer's page,
http://www.postgresql.org/developer/testing.
---
ITAGAKI Takahiro wrote:
I reported an incorrect
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
pg_regress.c: In function `spawn_process':
pg_regress.c:914: warning: missing sentinel in function call
You can apply this, but it sure seems like a compiler/include file bug
to me, even with the 64-bit explaination.
There are
Bruce Momjian [EMAIL PROTECTED] writes:
-is compared to the total number of tuples inserted, updated, or deleted
+is compared to the total number of tuples inserted or updated
As best I can tell, this description is even further away from the
actual CVS HEAD behavior than the previous
Bruce Momjian [EMAIL PROTECTED] wrote:
Patch applied. Thanks. Your documentation changes can be viewed in
five minutes using links on the developer's page,
http://www.postgresql.org/developer/testing.
Thanks. Don't we need to backport it to 8.1 and 8.2?
It was changed at the integration of
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
-is compared to the total number of tuples inserted, updated, or
deleted
+is compared to the total number of tuples inserted or updated
As best I can tell, this description is even further away from the
actual CVS HEAD
Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
-is compared to the total number of tuples inserted, updated, or
deleted
+is compared to the total number of tuples inserted or updated
As best I can tell, this description is even further away from the
24 matches
Mail list logo