I came across a quite interesting issue I don't really understand but
maybe Tom will know.
This happened rather accidentally.
I have a rather complex query which executes efficiently.
There is one interesting thing - let's have a look at the query:
SELECT t_struktur.id, t_text.code,
regression tests are tested and passed with IRIX 6.5.13 and 6.5.16 and
postgres from 7.1.3 to 7.2.2
there where previously passed tests with IRIX 6.5.5, but I don't know what
postgres versions
Regards
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
The question is *which* seek APIs we need to support. Are there any
besides fseeko() and fgetpos()?
On AIX we have
int fseeko64 (FILE* Stream, off64_t Offset, int Whence);
which is intended for large file access for programs that do NOT
#define _LARGE_FILES
It is functionality that is
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
I came across a quite interesting issue I don't really understand but
maybe Tom will know.
Interesting. We seem to recognize the fact that the extra clause is
redundant in nearly all places ... but not in indexscan plan
Hello,
In the docs it is mentioned for datistemplate that
If true then this database can be used in the TEMPLATE clause of
CREATE DATABASE to create the new database as a clone of this one.
However, one can create a database using as template another DB that has
datistemplate set to false.
In
I am wondering whether my recent hack in DetermineLocalTimeZone has
removed all need for NO_MKTIME_BEFORE_1970. I see that the AIX and
IRIX5 port headers define that symbol. Can anyone check regression
test results for 7.2.3 or 7.3betaN on these platforms to see whether
we could/should remove
In the docs it is mentioned for datistemplate that
If true then this database can be used in the TEMPLATE clause of
CREATE DATABASE to create the new database as a clone of this one.
However, one can create a database using as template another DB that has
datistemplate set to false.
In this
Alvaro Herrera [EMAIL PROTECTED] writes:
In the docs it is mentioned for datistemplate that
If true then this database can be used in the TEMPLATE clause of
CREATE DATABASE to create the new database as a clone of this one.
Right.
However, one can create a database using as template another
The world rejoiced as [EMAIL PROTECTED] (Andrew Sullivan) wrote:
Having undertaken the exercise, I really can say that it is a little
strange to think about what would happen to data I am in charge of in
case a fairly large US centre were completely blown off the map. But
with a little
On Thu, Oct 24, 2002 at 04:39:51PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
In the docs it is mentioned for datistemplate that
However, one can create a database using as template another DB that has
datistemplate set to false.
Only if one is owner of the source
Alvaro Herrera [EMAIL PROTECTED] writes:
On Thu, Oct 24, 2002 at 04:39:51PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
However, one can create a database using as template another DB that has
datistemplate set to false.
Only if one is owner of the source database (or
g'day ...
just went through the new config files for v7.3, to make sure, but
it doens't look like we have such ... has anyone looked at adding a 'idle
timeout' for a postgres process? Or am I missing something in the docs?
---(end of
On Wed, 2002-10-23 at 10:39, Greg Copeland wrote:
If you were using them that frequently, couldn't you just keep a
persistent connection? If it's not used that often, wouldn't the
overhead of preparing the query following a new connection become noise?
Especially by the time you add in the
Marc G. Fournier [EMAIL PROTECTED] writes:
just went through the new config files for v7.3, to make sure, but
it doens't look like we have such ... has anyone looked at adding a 'idle
timeout' for a postgres process? Or am I missing something in the docs?
Are you looking for the backend
On Thu, 24 Oct 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
just went through the new config files for v7.3, to make sure, but
it doens't look like we have such ... has anyone looked at adding a 'idle
timeout' for a postgres process? Or am I missing something in
On Wed, Oct 23, 2002 at 11:02:14AM -0400, Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
I wonder if there is a way to store a parsed/rewritten/planned query in
a table so that it can be loaded again.
The original version of the PREPARE patch used a
Bruce Momjian writes:
OK, NetBSD added.
Any other OS's need this? Is it safe for me to code something that
assumes fpos_t and off_t are identical? I can't think of a good way to
test if two data types are identical. I don't think sizeof is enough.
No, you can't assume that fpos_t and
Peter Eisentraut wrote:
Bruce Momjian writes:
OK, NetBSD added.
Any other OS's need this? Is it safe for me to code something that
assumes fpos_t and off_t are identical? I can't think of a good way to
test if two data types are identical. I don't think sizeof is enough.
No, you
Philip Warner wrote:
At 10:08 PM 23/10/2002 -0400, Bruce Momjian wrote:
Well, that certainly changes the functionality of the code. I thought
that fseeko test was done so that things that couldn't be seeked on were
detected.
You are quite correct. It should read:
#ifdef
Zeugswetter Andreas SB SD wrote:
The question is *which* seek APIs we need to support. Are there any
besides fseeko() and fgetpos()?
On AIX we have
int fseeko64 (FILE* Stream, off64_t Offset, int Whence);
which is intended for large file access for programs that do NOT
#define
The patch will not work. Please reread my quoted email.
At 09:32 PM 24/10/2002 -0400, Bruce Momjian wrote:
Philip Warner wrote:
You are quite correct. It should read:
#ifdef HAVE_FSEEKO
ctx-hasSeek = fseeko(...,SEEK_SET);
#else
ctx-hasSeek =
You are going to have to be more specific than that.
---
Philip Warner wrote:
The patch will not work. Please reread my quoted email.
At 09:32 PM 24/10/2002 -0400, Bruce Momjian wrote:
Philip Warner wrote:
You
At 09:56 PM 24/10/2002 -0400, Bruce Momjian wrote:
You are quite correct. It should read:
#ifdef HAVE_FSEEKO
ctx-hasSeek = fseeko(...,SEEK_SET);
^^
#else
ctx-hasSeek =
At 09:38 PM 24/10/2002 -0400, Bruce Momjian wrote:
OK, I am focusing on AIX now. I don't think we can go down the road of
saying where large file support is needed or not needed. I think for
each platform either we support large files or we don't.
Rather than having a different patch file for
This is excellent! Thanks so much!
-r
On Tue, 2002-10-22 at 04:07, Teodor Sigaev wrote:
regression=# select '{124,567,66}'::int[] + 345;
?column?
--
{124,567,66,345}
(1 row)
regression=# select '{124,567,66}'::int[] + '{345,1}'::int[];
?column?
I just reread the patch; is it valid to assume fseek and fseeko have the
same failure modes? Or does the call to 'fseek' actually call fseeko?
Philip Warner| __---_
Albatross Consulting Pty. Ltd.
This in many ways is a bogus argument in that 1) postgresql runs on more
then just Linux and 2) amount of memmory that can be addressed by a
process is tunable up to the point that it reaches a hardware limitation.
It also should be noted that when a process reaches such a size that it
better
OK, finally figured it out. I had used fseek instead of fseeko.
---
Philip Warner wrote:
At 09:56 PM 24/10/2002 -0400, Bruce Momjian wrote:
You are quite correct. It should read:
#ifdef HAVE_FSEEKO
Philip Warner wrote:
I just reread the patch; is it valid to assume fseek and fseeko have the
same failure modes? Or does the call to 'fseek' actually call fseeko?
The fseek was a typo. It should have been fseeko as you suggested.
CVS updated.
Your idea of using SEEK_SET is good, except I
Philip Warner wrote:
Rather than having a different patch file for each platform and refusing to
code fseek/tell because we can't do SEEK_CUR, why not check for FSEEKO64
and revert to a simple solution:
#ifdef HAVE_FSEEKO64
#define FSEEK fseeko64
#define FTELL ftello64
#define
At 12:07 AM 25/10/2002 -0400, Bruce Momjian wrote:
I don't think we can assume that off_t can be passed to fset/getpos
unless we know the platform supports it, unless people think fpos_t
being integral and the same size as fpos_t is enough.
We don't need to. We would #define FILE_OFFSET as
On Tue, 2002-10-22 at 12:12, Igor Georgiev wrote:
edit *pg_hba.conf *
# Allow any user on the local system to connect to any
# database under any username, but only via an IP connection:
host all 127.0.0.1 255.255.255.255trust
32 matches
Mail list logo
