Hi Alvaro,
I've also seen there is an experimental embed sapi which could already
be what you need (--enable-embed).
Interesting. I'll explore this. Is this available in PHP5 only?
I found it while checking the available SAPIs in PHP4. Looking to the
cvs repository, it seems to be
Hi,
I have built the libpq from $Postgres/src/interfaces/libpq on the windows plateform for 8.1.0.To build i had to comment a function call ShGetFolderPath from the fe-connect.c file, i gave its dependency shfolder.lib
but it was not working so i commented that function call. Doing that i got
Simon Riggs wrote:
On Tue, 2005-11-29 at 18:51 -0500, Bruce Momjian wrote:
Please let me back up and ask a more simplistic question. I understand
the idea of allowing COPY to insert rows with less locking, but I am
wondering about the NOLOGGING idea. On commit, we must guarantee that
No, it's all right. In fact, I believe my boss spoke to Bruce about
this idea in August. But I have permission to discuss the algorithm. I
may even be able to get the code, but to be honest, it isn't that much;
it would probably be just as easy for it to be re-written as it would be
to fit it
Yes. The O_DIRECT issue is my biggest concern about Linux at the moment.
That being said, the plan is to only pre-fetch the next N blocks, where N
32, and to read them into the local buffer cache. In a situation where
space in the cache low (and prefetched pages might be pushed out before we
Qingqing Zhou wrote:
[also with reply to Gavin] look up dictionary for gut-rot, got it ... Uh,
this behavior is intended - I try to push enough requests shortly to kernel
so that it understands that I am doing sequential scan, so it would pull the
data from disk to file system cache more
Matteo Beccati wrote:
Hi Alvaro,
I've also seen there is an experimental embed sapi which could
already be what you need (--enable-embed).
Interesting. I'll explore this. Is this available in PHP5 only?
I found it while checking the available SAPIs in PHP4. Looking to the
cvs
It's been about a month since 8.1.0 was released, and we've found about
the usual number of bugs for a new release, so it seems like it's time
for 8.1.1. The core committee has tentatively agreed to plan a release
for Tuesday Dec 6 (which means wrapping tarballs Monday). We will
at the same time
Tom Lane wrote:
We will
at the same time be making new dot-releases in the 7.3, 7.4, and 8.0
branches, principally to fix the SLRU race condition reported by Jim
Nasby and Robert Creager.
Was there a conclusion out of the recent discussion on EOL policy? The
consensus seemed to be
On Sun, Nov 27, 2005 at 11:27:54AM -0700, Michael Fuhr wrote:
On Sun, Nov 27, 2005 at 08:45:18AM -0700, Michael Fuhr wrote:
Looks like the value is stuck at 2^31 - 1 seconds:
I see this behavior back to at least 7.3. I'd guess it's because
strtol() indicates overflow by returning LONG_MAX
Michael Fuhr [EMAIL PROTECTED] writes:
I see this behavior back to at least 7.3. I'd guess it's because
strtol() indicates overflow by returning LONG_MAX and setting errno
to ERANGE, but the code doesn't check for that.
Is this worth looking at for the upcoming dot releases?
Sure, send a
Andrew Dunstan [EMAIL PROTECTED] writes:
Have we actually officially stopped supporting the 7.2 series?
Yeah, we have. It reached the too difficult to support point already
(the VACUUM/ctid bug back in August --- the patch used in the later
branches wouldn't apply at all, IIRC).
All this
On Wednesday 30 November 2005 11:40, Tom Lane wrote:
Personally I expect to keep supporting 7.3 for a long while, because Red
Hat pays me to ;-) ... and the EOL date for RHEL3 is a long way away yet.
The PG community may stop bothering with 7.3 releases before that. But
I think Marc and Bruce
On Wed, Nov 30, 2005 at 12:37:40PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I see this behavior back to at least 7.3. I'd guess it's because
strtol() indicates overflow by returning LONG_MAX and setting errno
to ERANGE, but the code doesn't check for that.
Is this
Done, as well as moved all but the last two of each version after ...
On Wed, 30 Nov 2005, Robert Treat wrote:
On Wednesday 30 November 2005 11:40, Tom Lane wrote:
Personally I expect to keep supporting 7.3 for a long while, because Red
Hat pays me to ;-) ... and the EOL date for RHEL3 is a
Someone suggested earlier that we should drop the binaries for
nonsupported versions completely from the ftp site. Thoughts on this?
If not, they should at least go into OLD as well. But personally, I'm
for dropping them completely. If you're on something that old (heck, we
have 7.0 binaries..),
'k, moved it all into OLD as well ... haven't removed anything until more
opt in on this ... I do agree that if you really want that old, you can
build from scratch, but I'm also not the one that went to the trouble of
building the binaries :)
On Wed, 30 Nov 2005, Magnus Hagander wrote:
I've been fooling around with a test case Rob Creager sent me, which is
able to drive PG into a context-switch storm caused by contention for
the SubtransControlLock. Rob asked for the test case not to be posted
publicly (it's part of some proprietary code), but I found that you can
cause some of
On Wed, 2005-11-30 at 13:33, Magnus Hagander wrote:
Someone suggested earlier that we should drop the binaries for
nonsupported versions completely from the ftp site. Thoughts on this?
If not, they should at least go into OLD as well. But personally, I'm
for dropping them completely. If
Michael Fuhr [EMAIL PROTECTED] writes:
On Wed, Nov 30, 2005 at 12:37:40PM -0500, Tom Lane wrote:
Sure, send a patch ...
Any preferences on an approach? The simplest and easiest to verify
would be to raise an error for just this particular case; a TODO
item might be to change how the string
On Tue, Nov 29, 2005 at 01:35:09PM +0100, Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sun, Nov 27, 2005 at 07:44:55PM +, Simon Riggs wrote:
not have any unique indexes or row triggers. It should be possible to
take advantage of this
On Wed, 30 Nov 2005, Kevin Grittner wrote:
I checked with out DBAs, and they are willing to test it.
Thanks, that's very nice!
By they way, they found that they were getting this on a pg_dump,
too. We will test both failure cases. If the test goes OK, we would
be happy to leave it in
On Wed, Nov 30, 2005 at 02:01:46PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Any preferences on an approach? The simplest and easiest to verify
would be to raise an error for just this particular case; a TODO
item might be to change how the string is parsed to allow
Michael Fuhr wrote:
Agreed. I'm thinking about rewriting strtol() calls in datetime.c
to look like this:
errno = 0;
val = strtol(field[i], cp, 10);
if (errno == ERANGE)
return DTERR_FIELD_OVERFLOW;
Hmm, why not check both the return value _and_ errno:
val = strtol(field[i],
On Wed, Nov 30, 2005 at 07:06:42PM -0300, Alvaro Herrera wrote:
Hmm, why not check both the return value _and_ errno:
val = strtol(field[i], cp, 10);
if (val == LONG_MAX errno == ERANGE)
return DTERR_FIELD_OVERFLOW;
I usually check both in my own code but I noticed several places
Michael Fuhr [EMAIL PROTECTED] writes:
errno = 0;
val = strtol(field[i], cp, 10);
if (errno == ERANGE)
return DTERR_FIELD_OVERFLOW;
Does that look okay? Or would you rather raise an error with ereport()?
Looks fine to me, at least in the routines that are for datetime stuff.
Michael Fuhr [EMAIL PROTECTED] writes:
I usually check both in my own code but I noticed several places
where PostgreSQL doesn't, so I kept that style. I'll check both
if that's preferred.
I'd say not --- it's more code and it makes a possibly unwarranted
assumption about strtol's behavior.
On Wed, Nov 30, 2005 at 05:20:54PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I'm looking at all the strtol() calls in datetime.c right now; I
haven't looked anywhere else yet. Should I bother checking values
that will be range checked later anyway? Time zone
Michael Fuhr [EMAIL PROTECTED] writes:
I suppose if we check for LONG_MAX then we should also check
for LONG_MIN.
s/should/must/, which makes the code even more complicated, in order to
buy what exactly?
I don't know if any systems might set ERANGE in a non-error situation.
The SUS saith
On Wed, Nov 30, 2005 at 05:23:23PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I usually check both in my own code but I noticed several places
where PostgreSQL doesn't, so I kept that style. I'll check both
if that's preferred.
I'd say not --- it's more code and it
On Wed, Nov 30, 2005 at 05:49:53PM -0500, Tom Lane wrote:
The SUS saith
http://www.opengroup.org/onlinepubs/007908799/xsh/strtol.html
The strtol() function will not change the setting of errno if
successful.
Perhaps more to the point, we've been doing it that way (errno test
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I suppose if we check for LONG_MAX then we should also check
for LONG_MIN.
s/should/must/, which makes the code even more complicated, in order to
buy what exactly?
I don't know if any systems might set ERANGE in a
On Wed, Nov 30, 2005 at 06:00:07PM -0500, Andrew Dunstan wrote:
LONG_MIN/LONG_MAX might be the actual values provided, too, mightn't
they? checking for ERANGE seems like the only viable test.
Errno needs to be checked in any case for just that reason; the
question was whether checking *only*
Hmmm...is this something else that needs fixing? The doc says dates
range from 4713 BC to 32767 AD.
test= select '11754179-08-04'::date;
date
11754179-08-04
(1 row)
test= select '11754179-08-05'::date;
date
---
4801-01-01 BC
(1 row)
--
Tom Lane said:
We hashed all this out in the pghackers list back in August, but I
agree there ought to be something about it on the website.
The reason I asked again is that, notwithstanding the recent discussion, I
have observed confusion about the matter (including Jan telling me he didn't
Attached is a small test extract from the USDA nutrient database.
The problem is that the script won't load the COPY data correctly. This
is with CVS HEAD (and 8.1).
It is the 4th column in the table that gives the problem (nutr_no
integer). Each of the 3 COPY rows has a different way of
On Wed, Nov 30, 2005 at 01:23:38PM -0500, Robert Treat wrote:
On Wednesday 30 November 2005 11:40, Tom Lane wrote:
Personally I expect to keep supporting 7.3 for a long while,
because Red Hat pays me to ;-) ... and the EOL date for RHEL3 is a
long way away yet. The PG community may stop
I come up with a patch to fix server-side problem. The basic idea is to
convert ERROR_NO_SYSTEM_RESOURCES to EINTR and add code to do retry unless
a new error encountered or successfully done. I tweak the FileRead() logic
on returnCode = 0 a little bit by separating it to 0 and ==0
parts. This is
On Wed, 30 Nov 2005, David Fetter wrote:
On Wed, Nov 30, 2005 at 01:23:38PM -0500, Robert Treat wrote:
On Wednesday 30 November 2005 11:40, Tom Lane wrote:
Personally I expect to keep supporting 7.3 for a long while,
because Red Hat pays me to ;-) ... and the EOL date for RHEL3 is a
long way
Christopher Kings-Lynne wrote:
Attached is a small test extract from the USDA nutrient database.
The problem is that the script won't load the COPY data correctly.
This is with CVS HEAD (and 8.1).
It is the 4th column in the table that gives the problem (nutr_no
integer). Each of the 3
I see this as an excellent reason to draw a bright, sharp line between
what vendors support and what the community as a whole does,
especially where individual community members wear another hat.
So, if Sun, SRA, Pervasive, Command Prompt, etc were to submit a patch
for v7.2, we'd refuse
I mentioned yesterday that I'm looking at the problem of excessive
accesses to pg_subtrans when there is an old open transaction:
http://archives.postgresql.org/pgsql-hackers/2005-11/msg01547.php
I thought of a different approach to it, which is to make snapshot
checking take a hint from
Qingqing Zhou [EMAIL PROTECTED] writes:
! default:
! _dosmaperr(error);
! Assert(errno != EINTR);
What's the point of that ... didn't it already happen inside read()?
On Thu, 1 Dec 2005, Tom Lane wrote:
Qingqing Zhou [EMAIL PROTECTED] writes:
! default:
! _dosmaperr(error);
! Assert(errno != EINTR);
What's the point of that ... didn't it already happen
On Wed, Nov 30, 2005 at 11:56:33PM -0400, Marc G. Fournier wrote:
On Wed, 30 Nov 2005, David Fetter wrote:
On Wed, Nov 30, 2005 at 01:23:38PM -0500, Robert Treat wrote:
On Wednesday 30 November 2005 11:40, Tom Lane wrote:
Personally I expect to keep supporting 7.3 for a long while,
because
45 matches
Mail list logo
