* Bruce Momjian <[EMAIL PROTECTED]> [010321 21:14] wrote:
> > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > and most times, those have to be merged into the source tree due to
> > > extensive changes anyway ... maybe we should just get rid of the use of
> > > pgindent altogether?
> >
> > I
> You're reading this wrong. What this means is:
> "If you're working on GCC, do not ever think of enabling -ffast-math
> implicitly by any -Ox level [since most other -fxxx options are grouped
> under some -Ox], since programs that might want optimization could still
> depend on correct IEEE mat
> - fields defined as TIMESTAMP DEFAULT CURRENT_TIMESTAMP sometimes generate
> invalid format of the date, for instance:
> 2001-02-10 13:11:60.00+01
You are running the Mandrake RPMs? Or have otherwise compiled using the
-ffast-math compiler flag?
- Thomas
---
At 00:35 22/03/01 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> This is a problem, I agree - but a procedural one. We need to make
>> registering messages easy. To do this, rather than having a central message
>> file, perhaps do the following:
>
>> - allow multiple message
I know pgindent has risks. Unfortunately, if we don't run pgindent, or
run it at a different time, we have other problems. Either the code is
not consistent for new developers, or patches supplied against the most
recent release do not patch cleanly.
Both seem worse to me than taking the risk o
I have finished pgindent. We also had many old comments of the format:
/* --
* comment
* --
*/
These are now the more concise:
/*
* comment
*/
Also, comments with dashes are not wrapped nicely by pgindent. Some
comments nee
On Thu, Mar 22, 2001 at 11:33:16AM +1030, Steven Vajdic wrote:
>
> 1. I've been running RedHat6.2 and its pgSQL 6.5xx, PHP3.0 counterparts
You should definitely upgrade to PG 7.1.
> 2. I am thinking about Debian (my preferred option - good/easy for
> "automatic" WEB upgrades) or
> Mandr
On Thu, Mar 22, 2001 at 12:31:03PM +1200, Franck Martin wrote:
> I see nobody did a test of 7.1 on Linux 2.4.x ?
>
> Would be nice to certify it is running on kernel 2.4.x as they claim this
> is entreprise strength kernel...
I've been running the 7.1 betas on 2.4 for weeks without any p
Philip Warner <[EMAIL PROTECTED]> writes:
> This is a problem, I agree - but a procedural one. We need to make
> registering messages easy. To do this, rather than having a central message
> file, perhaps do the following:
> - allow multiple message files (which can be processed to produce .h
> f
At 23:24 21/03/01 -0500, Tom Lane wrote:
>I've pretty much got to agree with Peter on both of these points.
Damn.
>Philip Warner <[EMAIL PROTECTED]> writes:
>> At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
> elogc(ERROR, PGERR_FUNCNOTYPE, ...)
>>>
>>> This is going to be a disaster for
> > The problem is that the small ones don't apply cleanly if they don't
> > match the indenting in the source.
>
> but ... if they are small, manually merging isn't that big of a deal ...
> and if anyone else has been working in that code since release, there is a
> chance it won't mergef cleanl
On Thu, 22 Mar 2001, Bruce Momjian wrote:
> > > > and most times, those have to be merged into the source tree due to
> > > > extensive changes anyway ... maybe we should just get rid of the use of
> > > > pgindent altogether? its not something that I've ever seen required on
> > > > other proje
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > and most times, those have to be merged into the source tree due to
> > extensive changes anyway ... maybe we should just get rid of the use of
> > pgindent altogether?
>
> I think pgindent is a good thing; the style of different parts of the
>
> > > and most times, those have to be merged into the source tree due to
> > > extensive changes anyway ... maybe we should just get rid of the use of
> > > pgindent altogether? its not something that I've ever seen required on
> > > other projects I've worked on ... in general, most projects se
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> and most times, those have to be merged into the source tree due to
> extensive changes anyway ... maybe we should just get rid of the use of
> pgindent altogether?
I think pgindent is a good thing; the style of different parts of the
code would var
On Wed, 21 Mar 2001, Bruce Momjian wrote:
> > and most times, those have to be merged into the source tree due to
> > extensive changes anyway ... maybe we should just get rid of the use of
> > pgindent altogether? its not something that I've ever seen required on
> > other projects I've worked
Works fine here.
> Since I am playing with StarOffice, I figured I'd try --with-odbc,
> current sources, except for the big Bruce commit I just saw :-)
>
>
> UX:tsort: INFO: psqlodbc.o
> UX:tsort: INFO: dlg_specific.o
> UX:tsort: INFO: convert.o
> UX:tsort: WARNING: Cycle in
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can we use (long long) rather than LL?
>>
>> No.
> Can I ask how 0LL is different from (long long)0?
The former is a long-long-int constant ab initio. The latter is an int
constant that is subsequently cas
Justin Clift <[EMAIL PROTECTED]> writes:
>> So, I'm still looking for the best way to add a compile flag while
>> making it clear that it is for one distro only.
Since this is only an RPM problem, it should be solved in the RPM spec
file, not by hacking the configure script. We had at least one
> and most times, those have to be merged into the source tree due to
> extensive changes anyway ... maybe we should just get rid of the use of
> pgindent altogether? its not something that I've ever seen required on
> other projects I've worked on ... in general, most projects seem to
> require
On Wed, 21 Mar 2001, Bruce Momjian wrote:
> > > If people can get their patches in all at one time, that would work.
> > > The only problem there is that people who supply patches against 7.1
> > > will not match the 7.2 tree, and we get those patches from people for
> > > months.
> >
> > and tho
On Wed, 21 Mar 2001, Bruce Momjian wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Hey, I am open to whatever people want to do. Just remember that we
> > > accumulate lots of patches/development during the slow time before
> > > development, and those patches become harder to apply.
> > If people can get their patches in all at one time, that would work.
> > The only problem there is that people who supply patches against 7.1
> > will not match the 7.2 tree, and we get those patches from people for
> > months.
>
> and those patches should only be applied to the v7.1 branch .
At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
>
>This is going to be a disaster for the coder. Every time you look at an
>elog you don't know what it does? Is the first arg a %s or a %d? What's
>the first %s, what the second?
FWIW, I did a quick scan for elog in PG and found:
- 6856 calls (
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Can we use (long long) rather than LL?
>
> No.
Can I ask how 0LL is different from (long long)0?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Hey, I am open to whatever people want to do. Just remember that we
> > accumulate lots of patches/development during the slow time before
> > development, and those patches become harder to apply. Peter E has some
> > already.
>
> Why not start a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can we use (long long) rather than LL?
No.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Hey, I am open to whatever people want to do. Just remember that we
> accumulate lots of patches/development during the slow time before
> development, and those patches become harder to apply. Peter E has some
> already.
Why not start a devel cycle b
I've pretty much got to agree with Peter on both of these points.
Philip Warner <[EMAIL PROTECTED]> writes:
> At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
elogc(ERROR, PGERR_FUNCNOTYPE, ...)
>>
>> This is going to be a disaster for the coder. Every time you look at an
>> elog you don't
On Wed, 21 Mar 2001, Bruce Momjian wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >> With RC1 nearing, when should I run pgindent? This is usually the time
> > >> I do it.
> >
> > > Does the silence mean I should pick a date to run this?
> >
> > If you're going to do it before the rele
* Bruce Momjian <[EMAIL PROTECTED]> [010321 22:11]:
> > >> Are there any severely mis-indented files?
> >
> > There are some new contrib modules that are nowhere close to our
> > indent conventions; also a good deal of foreign-key-related stuff
> > in the parser that needs to be cleaned up. So w
> >> Are there any severely mis-indented files?
>
> There are some new contrib modules that are nowhere close to our
> indent conventions; also a good deal of foreign-key-related stuff
> in the parser that needs to be cleaned up. So we should run it.
>
> I've always felt that it'd be smarter to
>> Are there any severely mis-indented files?
There are some new contrib modules that are nowhere close to our
indent conventions; also a good deal of foreign-key-related stuff
in the parser that needs to be cleaned up. So we should run it.
I've always felt that it'd be smarter to run pgindent
Since I am playing with StarOffice, I figured I'd try --with-odbc,
current sources, except for the big Bruce commit I just saw :-)
UX:tsort: INFO: psqlodbc.o
UX:tsort: INFO: dlg_specific.o
UX:tsort: INFO: convert.o
UX:tsort: WARNING: Cycle in data
UX:tsort: INFO:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> With RC1 nearing, when should I run pgindent? This is usually the time
> >> I do it.
>
> > Does the silence mean I should pick a date to run this?
>
> If you're going to do it before the release, I think you should do it
> *before* we wrap RC1.
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> With RC1 nearing, when should I run pgindent? This is usually the time
>> I do it.
> Does the silence mean I should pick a date to run this?
If you're going to do it before the release, I think you should do it
*before* we wrap RC1. I've said before
> > Tom, since you appear to be able to recreate the bug, can you comment on
> > this, as to whether we are okay now?
>
> Sorry for the delay --- I was down in Norfolk all day, and am just now
> catching up on email. I will pull Vadim's update and run the test some
> more. However, last night I
okay, baring you bein able to recreate the bug between now and, say,
13:00AST tomorrow, I'll wrap up RC1 and get her out the door ...
On Wed, 21 Mar 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Tom, since you appear to be able to recreate the bug, can you comment on
Can we use (long long) rather than LL?
> > Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > > Recent changes in pg_crc.c (64 bit CRC) introduced non portable constants of the
>form:
> >
> > > -c -o pg_crc.o pg_crc.c
> > > 287 | 0x, 0x42F0E1EBA9EA3693,
> >
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > Recent changes in pg_crc.c (64 bit CRC) introduced non portable constants of the
>form:
>
> > -c -o pg_crc.o pg_crc.c
> > 287 | 0x, 0x42F0E1EBA9EA3693,
> > a..
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Tom, since you appear to be able to recreate the bug, can you comment on
> this, as to whether we are okay now?
Sorry for the delay --- I was down in Norfolk all day, and am just now
catching up on email. I will pull Vadim's update and run the test
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> For integers (optional sign and all digits), the code in
> src/backend/parser/scan.l uses strtol() to read the string, then checks
> for failure. If it fails, the number is interpreted as a double float on
> the assumption that if it could hold more di
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory
> ! pqReadData() -- backend closed the channel unexpectedly.
>>
>> Is it possible you ran out of disk space?
> Probably not.
The reason
* Tom Lane <[EMAIL PROTECTED]> [010321 21:29]:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory
> > ! pqReadData() -- backend closed the channel unexpectedly.
> >>
> >> Is it possib
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> #define ELOG(ARGS) (elog_setloc(__FILE__, __LINE__), elog ARGS)
> Would the first function save the data in global variables?
Yes, that's what I was envisioning. Not a super clean solution,
but workable, and better than requiri
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't think it's the answer either. The patch assumes that int64 ==
> long long. The ugly solution might have to be:
> #if
> #define L64 L
> #else
> #define L64 LL
> #endif
> const uint64 crc_table[256] = {
> 0x##L64, 0x42F0
okay, this was the only one I was waiting to hear on ... the fix committed
this afternoon for the regression test, did/does it fix the problem? are
we safe on a proper RC1 now?
On Wed, 21 Mar 2001, Tom Lane wrote:
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > Recent changes in pg_c
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Recent changes in pg_crc.c (64 bit CRC) introduced non portable constants of the
>form:
> -c -o pg_crc.o pg_crc.c
> 287 | 0x, 0x42F0E1EBA9EA3693,
> a..
> a
At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
>Philip Warner writes:
>
>> If the motivation behind this is to alloy easy translation to SQL error
>> codes, then I suggest we have an error definition file with explicit
>> translation:
>>
>> Code SQL Text
>> PGERR_TYPALREXI 02xxx "
> On Wed, 21 Mar 2001, Bruce Momjian wrote:
>
> >
> > OK, I am going to have dinner and then get started on the pgindent run.
> >
> > I have also noticed we have some comments like:
> >
> > /*
> > * one word
> > *
> > */
> >
> > that look funny in a few pl
Dear experts,
Some advice would be greatly appreciated:
1. I've been running RedHat6.2 and its pgSQL 6.5xx, PHP3.0 counterparts
for 10
months, not having time to upgrade and being afraid to upgrade due to
"regular problems" that go along.
2. I am thinking about Debian (my preferred option - goo
Franck Martin <[EMAIL PROTECTED]> writes:
> Would be nice to certify it is running on kernel 2.4.x as they claim this
> is entreprise strength kernel...
Lamar, if you send me your SRPM I can do that...
--
Trond Eivind Glomsrød
Red Hat, Inc.
---(end of broadcast)---
Justin Clift <[EMAIL PROTECTED]> writes:
> It's not "Mandrake" that will be broken. Mandrake is also often used by
> new Linux users who wouldn't have the slightest idea about setting GCC
> options. It'll be THEM that have broken installations if we take this
> approach (as an aside, that means
I see nobody did a test of 7.1 on Linux 2.4.x ?
Would be nice to certify it is running on kernel 2.4.x as they claim this
is entreprise strength kernel...
Cheers.
Thomas Lockhart wrote:
>
>
> AIX 4.3.2 RS6000 7.0 2000-04-05, Andreas Zeugswetter
> Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew
Is the right approach for the ./configure script to check for the
existence of the /etc/mandrake-release file as at least an initial
indicator that the compile is happening on Mandrake?
Regards and best wishes,
Justin Clift
Thomas Lockhart wrote:
>
> > If Mandrake wants to be broken, let them
NO!
It's not "Mandrake" that will be broken. Mandrake is also often used by
new Linux users who wouldn't have the slightest idea about setting GCC
options. It'll be THEM that have broken installations if we take this
approach (as an aside, that means that WE will be probably also be
answering m
On Wed, 21 Mar 2001, Bruce Momjian wrote:
>
> OK, I am going to have dinner and then get started on the pgindent run.
>
> I have also noticed we have some comments like:
>
> /*
> * one word
> *
> */
>
> that look funny in a few places. I propose:
>
>
OK, I am going to have dinner and then get started on the pgindent run.
I have also noticed we have some comments like:
/*
* one word
*
*/
that look funny in a few places. I propose:
/* one word */
to be consistent.
> With RC1 nearing,
$ uname -a
OpenBSD mizer 2.8 a#0 i386
P3, default 2.8 install. Problems w/ TCL, but I think it's a local
problem.
System needs kernel changes as noted at www.crimelabs.net. (shared mem
stuff).
OBSD-sparc comming soon.
- b
b. palmer, [EMAIL PROTECTED]
pgp: www.crimelabs.net/bpalmer.pgp5
I have created a new web page that contains all unapplied patches that
are either waiting for approval or waiting for new development to begin.
People can use this page to know that their patches have not been lost,
and I may ask people to review this page for patch approval.
The page is:
HPUX 9.07 with GCC 2.8.1 fails the regression tests. I will look into
this later. I would NOT hold anything up because of this
Jim
> Time to speak up, I have a HPUX 9.07 system and will test today.
>
> Jim
>
> > Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > >> HPUX 10.20 (HP-PA
Philip Warner writes:
> If the motivation behind this is to alloy easy translation to SQL error
> codes, then I suggest we have an error definition file with explicit
> translation:
>
> Code SQL Text
> PGERR_TYPALREXI 02xxx "type %s cannot be created because it already exists"
> PG
> Bruce Momjian writes:
>
> > Peter, this is the optimial time to do it because no one has any
> > outstanding patches at this point. Seems this is the only good time.
>
> Actually, I have quite a few outstanding patches. I got screwed by this
> last time around as well. But I understand that
Tom Lane writes:
> Sure it is, it just requires a marginal increase in ugliness, namely
> double parentheses:
>
> ELOG((level, format, arg1, arg2, ...))
>
> which might work like
>
> #define ELOG(ARGS) (elog_setloc(__FILE__, __LINE__), elog ARGS)
Would the first function save the data in
Bruce Momjian writes:
> Peter, this is the optimial time to do it because no one has any
> outstanding patches at this point. Seems this is the only good time.
Actually, I have quite a few outstanding patches. I got screwed by this
last time around as well. But I understand that this might be
Zeugswetter Andreas SB writes:
>
> Recent changes in pg_crc.c (64 bit CRC) introduced non portable constants of the
>form:
>
> -c -o pg_crc.o pg_crc.c
> 287 | 0x, 0x42F0E1EBA9EA3693,
> a..
> a - 1506-207 (W) I
> On Wed, 21 Mar 2001, Bruce Momjian wrote:
>
> > > With RC1 nearing, when should I run pgindent? This is usually the time
> > > I do it.
> >
> > Does the silence mean I should pick a date to run this?
>
> Since I'm going to end up re-rolling RC1, do a run tonight on her, so that
> any problems
Bruce Momjian writes:
> With RC1 nearing, when should I run pgindent? This is usually the time
> I do it.
Are there any severely mis-indented files?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)-
On Wed, Mar 21, 2001 at 10:51:03AM -0500, Bruce Momjian wrote:
> Added to TODO:
>
> * Add BETWEEN [ASYMMETRIC|SYMMETRIC]
>
> Ross did a patch for this but some wanted it implemented differently so
> I just added it to the TODO list.
Hmm, have I been coding in my sleep? I think I perhaps c
On Wed, 21 Mar 2001, Bruce Momjian wrote:
> > With RC1 nearing, when should I run pgindent? This is usually the time
> > I do it.
>
> Does the silence mean I should pick a date to run this?
Since I'm going to end up re-rolling RC1, do a run tonight on her, so that
any problems that arise from p
> Bruce Momjian writes:
>
> > With RC1 nearing, when should I run pgindent? This is usually the time
> > I do it.
>
> Are there any severely mis-indented files?
Not sure. I think there are some. It doesn't do anything unless there
is mis-indenting, so it is pretty safe and has always been do
> On Wed, Mar 21, 2001 at 10:51:03AM -0500, Bruce Momjian wrote:
> > Added to TODO:
> >
> > * Add BETWEEN [ASYMMETRIC|SYMMETRIC]
> >
> > Ross did a patch for this but some wanted it implemented differently so
> > I just added it to the TODO list.
>
> Hmm, have I been coding in my sleep? I t
Time to speak up, I have a HPUX 9.07 system and will test today.
Jim
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> >> HPUX 10.20 (HP-PA architecture)
>
> > Time to drop 9.2 from the list?
>
> I don't have it running here anymore. Is there anyone on the list
> who can test on HPUX 9?
>
Hi,
I am currently testing beta6 on AIX 4.3.3 on a RS6000 H80 with 4 cpu and 4
Go RAM
I use :
./configure
--with-CC=/usr/local/bin/gcc
--with-includes=/usr/local/include
--with-libraries=/usr/local/lib
All seem to be ok, There just the geometry failure in regression tes
> With RC1 nearing, when should I run pgindent? This is usually the time
> I do it.
Does the silence mean I should pick a date to run this?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive
> On Wed, 21 Mar 2001, Bruce Momjian wrote:
>
> > I have created an FTP file containing all ourstanding patches. It is
> > at:
> >
> > ftp://candle.pha.pa.us/pub/postgresql/patches.mbox
> >
> > I will keep this updated so people know their patches are in the queue
> > and have not been forgo
Hello;
I installed postgresql. I compiled it and started the server successfully
but when I'm trying to connect to database I get this message:
Could not load the JDBC driver. org.postgresql.Driver reason: The backend
has broken the connection. Possibly the action you have attempted has caused
it
On Mon, Mar 19, 2001 at 11:00:20AM -, Peter Galbavy wrote:
> 1. One "writer", many "reader" PostgreSQL servers. We will want to write
> provisioning / configuration information centrally and can tolerate a
> "writer" failuer for a time.
> 2. Consitency at the transaction level. All changes to
On Wed, 21 Mar 2001, Bruce Momjian wrote:
> I have created an FTP file containing all ourstanding patches. It is
> at:
>
> ftp://candle.pha.pa.us/pub/postgresql/patches.mbox
>
> I will keep this updated so people know their patches are in the queue
> and have not been forgotten. I may als
Tom, since you appear to be able to recreate the bug, can you comment on
this, as to whether we are okay now?
On Wed, 21 Mar 2001, Vadim Mikheev wrote:
> Just committed changes in bufmgr.c
> Regress tests passed but need more specific tests,
> as usually. Descr as in CVS:
>
> > Check bufHdr->cn
Thomas Lockhart writes:
> Mandrake (as of 7.2) still does a brain-dead mix of "-O3" and
> "-ffast-math", which is a risky and unnecessary combination according to
> the gcc folks (and which kills some of our date/time rounding). From the
> man page for gcc:
>
> -ffast-math
> This option should
Hi,
I reported Linux RedHat 6.2 - 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST
2000 i686
2 cpu - 1Go RAM
Gilles DAROLD
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Thomas Lockhart writes:
> > SCO OpenServer 5 x86...
>
> OK, I see that Billy Allie recently updated FAQ_SCO to indicate
> demonstrated (?) support for OpenServer. I will reflect that in the
> platform support info.
The last FAQ_SCO update was by me, and it was rather the consequence of
some impl
Tatsuo Ishii writes:
> > > Tatsuo, I have a separate listing for "mklinux" for the 7.0 release. Is
> > > that distro still valid and unique? Or is there a better way to
> > > represent the PPC options under Linux?
> >
> > mklinux is older Motorola 68k-based systems
>
> No. MkLinux runs on Power P
Thomas Lockhart writes:
> > HPUX 10.20 (HP-PA architecture)
>
> Time to drop 9.2 from the list?
>
> > Linux/PPC (LinuxPPC 2000 Q4 distro tested here; 2.2.18 kernel I think)
>
> What processor? Tatsuo had tested on a 603...
Given that we list "x86", I think we wouldn't care.
--
Peter
Recent changes in pg_crc.c (64 bit CRC) introduced non portable constants of the form:
-c -o pg_crc.o pg_crc.c
287 | 0x, 0x42F0E1EBA9EA3693,
a..
a - 1506-207 (W) Integer constant 0x42F0E1EBA9EA3693 out of rang
Hello,
During repopulation of the database (using the results of the pg_dump
program), I spot two strange things:
- fields defined as TIMESTAMP DEFAULT CURRENT_TIMESTAMP sometimes generate
invalid format of the date, for instance:
2001-02-10 13:11:60.00+01 - which follows the records
> I'm been running one backend doing repeated iterations of
>
> CREATE TABLE temptest(col int);
> INSERT INTO temptest VALUES (1);
>
> CREATE TEMP TABLE temptest(col int);
> INSERT INTO temptest VALUES (2);
> SELECT * FROM temptest;
> DROP TABLE temptest;
>
> SELECT * FROM temptest;
> DROP TABL
> On Wed, Mar 21, 2001 at 10:54:46AM -0500, Bruce Momjian wrote:
> >
> > Can someone suggest a nice web frontend CGI script to a mbox file, one
> > that shows sender/subject/date, etc? I don't need to search or modify
> > the messages, just display them.
>
> Run mhonarc on the mbox. It wi
> Anyway, either strtol() thinks it *should* be able to read a 64 bit
> integer, or your machine is silently overflowing. I used to have a bunch
> of these boxes, and I recall spending quite a bit of time discovering
> that Alphas have some explicit flags which can be set at compile time
> which a
On Wed, Mar 21, 2001 at 10:54:46AM -0500, Bruce Momjian wrote:
>
> Can someone suggest a nice web frontend CGI script to a mbox file, one
> that shows sender/subject/date, etc? I don't need to search or modify
> the messages, just display them.
Run mhonarc on the mbox. It will create HT
> If Mandrake wants to be broken, let them - and tell them.
They know ;) But just as with RH, they build ~1500 packages, so it is
probably not realistic to get them to change their build standards over
one misbehavior in one package.
The goal here is to get PostgreSQL to work well for as many pl
I have created an FTP file containing all ourstanding patches. It is
at:
ftp://candle.pha.pa.us/pub/postgresql/patches.mbox
I will keep this updated so people know their patches are in the queue
and have not been forgotten. I may also use this to ask people for
patch review.
Can someo
> For integers (optional sign and all digits), the code in
> src/backend/parser/scan.l uses strtol() to read the string, then checks
> for failure. If it fails, the number is interpreted as a double float on
> the assumption that if it could hold more digits it would succeed!
>
> Anyway, either s
Added to TODO:
* Add BETWEEN [ASYMMETRIC|SYMMETRIC]
Ross did a patch for this but some wanted it implemented differently so
I just added it to the TODO list.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If
> > How are you doing the inserts? If you aren't coercing the "2" to be an
> > int8, then (afaik) the math will be done in int4, then upconverted. So,
> > can you confirm that your inserts look like:
> > insert into lint values ('9223372036854775807');
> OK, that was it. I inserted without quotes
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > It's a good start to test with for the purposes for which I think you want to
> > test for. (and I'm an English teacher by night -- argh).
>
> :)
>
> Mandrake (as of 7.2) still does a brain-dead mix of "-O3" and
> "-ffast-math", which is a risky
Quoting Tatsuo Ishii <[EMAIL PROTECTED]>:
> [Cced: to PostgreSQL hackers list]
>
> Alexander,
>
> I believe this problem was fixed in the latest JDBC driver, that is
> supposed to be shipped with 7.1. It asks your database which encoding
> is used for particular database while connecting to the
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory
> > ! pqReadData() -- backend closed the channel unexpectedly.
>
> Is it possible you ran out of disk space?
Probably not.
--
Tatsuo Ishii
---(end of br
> > > BTW, I've got ~320tps with 50 clients inserting (int4, text[1-256])
> > > records into 50 tables (-B 16384, wal_buffers = 256) on Ultra10
> > > with 512Mb RAM, IDE (clients run on the same host as server).
> >
> > Not bad. What were you getting before these recent changes?
>
> As I alread
1 - 100 of 110 matches
Mail list logo
