At 11:51 PM 24/10/2002 -0400, Bruce Momjian wrote:
Your idea of using SEEK_SET is good, except I was concerned that the
checkSeek call will move the file pointer. Is that OK? It doesn't seem
appropriate.
The call is made just after the file is opened (or it should be!), so
SEEK_SET, 0 will no
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 somet
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 fpos_
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 FI
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
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:
> > > > >
> > > > > #ifd
"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 b
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
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. |--
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.255tr
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
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 broadcast)
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?
>
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
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
> > >
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:
> > >
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->ha
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
> #defi
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:
>
> #ifd
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.
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
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
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
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 car
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
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 thi
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 it?
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.
=?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 gen
> 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 avai
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 PROTECTE
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, COUNT(t_we
32 matches
Mail list logo
