Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...
> 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? HP haven't supported 9.X since the end of 1999 on servers, and since earlier than that on workstations. I doubt anyone will expect to see it listed on the PostgreSQL list of supported platforms for 7.1. Regards, Giles ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Stuck spins in current
> > 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 already reported - with O_DSYNC this test shows 30% better performance than with fsync. (BTW, seems in all my tests I was using -O0 flag...) Vadim ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Final Call: RC1 about to go out the door ...
Quoting The Hermit Hacker <[EMAIL PROTECTED]>: > > Okay folks ... > > We'd like to wrap up an RC1 and get this release happening this > year sometime :) Tom mentioned to me that he has no outstandings left > on his plate ... does anyone else have any *show stoppers* left that need > to be addressed, or can I package things up? Nothing that would stop RC1 (I've still got some testing which I'm doing later tonight). > Speak now, or forever hold your piece (where forever is the time > between now and RC1 is packaged) ... I'm surprised it hasn't been out already - being worked to death the last two weeks, I'm still catching up with developments :( ... Peter -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] int8 bug on Alpha
Hi, int8 is not handled correctly on Alpha. Inserting 2^63-1, 2^63-2 and 2^61 into create table lint (i int8); gives test=# select * from lint; i -1 -2 0 (3 rows) On linux it gives the correct values: test=# select * from lint; i - 9223372036854775807 9223372036854775806 2305843009213693952 (3 rows) This is postgres 7.1b4, compiled with native cc on Tru64 4.0G. I seem to recall running the regression tests, so perhaps this is not checked? (just looked at int8.sql, and it is not checked.) I'm swamped, so cannot look at it right now. If nobody else can look at it, I will get back to it in about a fortnight. Adriaan ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] BufferSync() & FlushRelationBuffers() conflict
Just committed changes in bufmgr.c Regress tests passed but need more specific tests, as usually. Descr as in CVS: > Check bufHdr->cntxDirty and call StartBufferIO in BufferSync() > *before* acquiring shlock on buffer context. This way we should be > protected against conflicts with FlushRelationBuffers. > (Seems we never do excl lock and then StartBufferIO for the same > buffer, so there should be no deadlock here, - but we'd better > check this very soon). Vadim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for platforms
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? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL-JDBC driver
Quoting sourabh dixit <[EMAIL PROTECTED]>:
>
>
> -
>
> Hi,
>
> I am trying to access PostGreSQL database running at the default port
> 5432
> using JDBC. But the application is giving error "Cannot find suitable
> driver". I have included JDBC driver JAR file in my CLASSPATH and
> Class.forName("org.postgresql.Driver") is loading driver successfully.
> Can anybody tell me how to go about to solve the problem?
Sounds like your URL is wrong. Make sure it begins with jdbc:postgresql:
Peter
--
Peter Mount [EMAIL PROTECTED]
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL-JDBC driver
Hello !
My program is given below and the errors which Iam getting on executing
the program is "ClassNotFoundException:org.postgresql.Driver
SQLException:No suitable driver".
Can you tell me what's wrong in my program?
Regards,
Sourabh
import java.sql.*;
public class DM
{
public static void main(String args[])
{
String url = "jdbc:postgresql:testdb";
Connection con;
String createString;
createString = "create MyInfo table "+"(INTERFACE_TYPE
INTEGER,"+"EQUIPMENT_TYPE INTEGER)";
Statement stmt;
try {
Class.forName("org.postgresql.Driver");
}
catch(java.lang.ClassNotFoundException e)
{
System.err.print("ClassNotFoundException:");
System.err.println(e.getMessage());
}
try {
con = DriverManager.getConnection(url,"sdixit","sdixit");
stmt = con.createStatement();
stmt.executeUpdate(createString);
stmt.close();
con.close();
} catch(SQLException ex)
{
System.err.println("SQLException:"+ex.getMessage());
}
}
- Original Message -
From: Peter T Mount <[EMAIL PROTECTED]>
Date: Wednesday, March 21, 2001 4:56 pm
Subject: Re: [HACKERS] PostgreSQL-JDBC driver
> Quoting sourabh dixit <[EMAIL PROTECTED]>:
>
> >
> >
> > -
> >
> > Hi,
> >
> > I am trying to access PostGreSQL database running at the default
> port> 5432
> > using JDBC. But the application is giving error "Cannot find
> suitable> driver". I have included JDBC driver JAR file in my
> CLASSPATH and
> > Class.forName("org.postgresql.Driver") is loading driver
> successfully.> Can anybody tell me how to go about to solve the
> problem?
> Sounds like your URL is wrong. Make sure it begins with
> jdbc:postgresql:
> Peter
>
> --
> Peter Mount [EMAIL PROTECTED]
> PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
> RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
>
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: int8 bug on Alpha
> int8 is not handled correctly on Alpha. Inserting 2^63-1, 2^63-2 and
> 2^61...
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');
or
insert into lint select (int8 '2') ^ 61;
- Thomas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: int8 bug on Alpha
Thomas Lockhart wrote:
>
> > int8 is not handled correctly on Alpha. Inserting 2^63-1, 2^63-2 and
> > 2^61...
>
> 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. If I insert the quotes it
works. So why does it work correctly on linux without quotes?
and
insert into lint values ('9223372036854775807'::int8);
works, but
insert into lint values (9223372036854775807::int8);
doesn't. I guess in the second case it converts it to an int4 and then
recasts to an int8?
Cheers,
Adriaan
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Stuck spins in current
> > > 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 already reported - with O_DSYNC this test shows 30% better > performance than with fsync. > > (BTW, seems in all my tests I was using -O0 flag...) Good data point. I could never understand why we would ever use the normal sync if we had a data-only sync option available. I can imagine the data-only being the same, but never slower. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Call for platforms
> 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 broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: PostgreSQL JDBC Unicode Support
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 database. So > you should be able to see "select getdatabaseencoding" if you turn on > a debugging option for postmaster. > > I also think the latest driver is compatible with 7.0.3, but I'm not > sure. Peter T? It should be at the basic level, but methods in DatabaseMetaData will fail as they are specific to 7.1's system table changes etc. Peter > -- > Tatsuo Ishii > > From: "Alexander Vaysman" <[EMAIL PROTECTED]> > Subject: PostgreSQL JDBC Unicode Support > Date: Thu, 15 Mar 2001 15:34:43 -0500 > Message-ID: <[EMAIL PROTECTED]> > > > Tatsuo, > > > > my name is Alex Vaysman, and I saw your numerous posts in the > newsgroups > > regarding Postgres and mutli-language support. I have a problem with > our > > Postgres database, and intensive searches on the Internet/newsgroups > didn't > > provide me with an answer. I was wondering if you would know the > answer or > > point me towards it. > > > > In the nutshell, we are trying to get Postgres DB running that > supports > > Unicode and interacts with clients via JDBC. We have PostgreSQL > version > > 7.0.3 installed. I have downloaded the latest JDBC driver from > > http://jdbc.postgresql.org. > > > > I have created a Unicode database (confirmed through \l command in > psql, > > reported encoding is 'UNICODE'). In that DB I've created a table with > two > > fields integer and varchar(64). Then I store a record into this table. > In my > > code I specify the string through Unicode escapes. After that I > retrieve > > this value and write it out. I don't get my value back but rather > ?. I'm > > attaching the code I use for reference. > > > > My Internet searches for the solution indicated that I need to apply > some > > patches to JDBC driver. However, I don't know how to do that. Do you > know > > where I may download the JDBC driver version with the appropriate > patches > > applied? If you're using one, would you be kind enough and e-mail it > to me. > > Also, having some experience with SQL Server, I know that if I wanted > to > > store Unicode values into some column I was creating that column as > nvarchar > > rather the varchar. Is anything like this required for Postgres? > > > > Your help is greatly appreciated. Thanks in advance, > > > > Alex Vaysman. > > ---(end of > broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] RPM building (was regression on RedHat)
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 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 never be turned on by any `-O' option > since it can result in incorrect output for programs which > depend on an exact implementation of IEEE or ANSI > rules/specifications for math functions. > > I'd like to get away from having to post a non-brain-dead /root/.rpmrc > file which omits the -ffast-math flag. Can you suggest mechanisms for > putting a "-fno-fast-math" into the spec file? Isn't there a mechanism > to mark things as "distro specific"? Suggestions? If Mandrake wants to be broken, let them - and tell them. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: int8 bug on Alpha
> > 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. If I insert the quotes it
> works. So why does it work correctly on linux without quotes?
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 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 affect run-time detection of floating point and (perhaps) integer
overflow behavior.
Can you check these possibilities? I'd look at strtol() first, then the
overflow/underflow flags second...
- Thomas
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[HACKERS] New TODO item
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 your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: int8 bug on Alpha
> 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 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 affect run-time detection of floating point and (perhaps) integer > overflow behavior. > > Can you check these possibilities? I'd look at strtol() first, then the > overflow/underflow flags second... Intersting that the lack of strtol() failure on Alpha is causing the problem. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Patch application
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 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. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] RPM building (was regression on RedHat)
> 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 platforms as possible. Heck, we even build for M$ ;) 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. Of course, it would be possible to just add it at the end of the flags, but it would be nice to do that only when necessary. Regards. - Thomas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Patch application
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 HTML files from it. Example (using the Debian lists-archives package) can be seen at http://fslc.usu.edu/archives -Roberto -- +| http://fslc.usu.edu USU Free Software & GNU/Linux Club|--+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Web Developer ONLINE? Hit for a quick I.Q. Test! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: int8 bug on Alpha
> 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 affect run-time detection of floating point and (perhaps) integer
> overflow behavior.
>
> Can you check these possibilities? I'd look at strtol() first, then the
> overflow/underflow flags second...
Hmm, I wrote a trivial programme parsing long ints and get the following
#include
main (int argc, char *argv[]) {
long int a = strtol(argv[1], (char **) 0, 10);
printf("input='%s' ld=%ld (errno %d)\n",argv[1],a,errno);
}
emily:~/Tmp/C++$ a.out 9223372036854775807
input='9223372036854775807' ld=9223372036854775807 (errno 0)
emily:~/Tmp/C++$ a.out 9223372036854775808
input='9223372036854775808' ld=9223372036854775807 (errno 34)
emily:~/Tmp/C++$ a.out 9223372036854775806
input='9223372036854775806' ld=9223372036854775806 (errno 0)
emily:~/Tmp/C++$ a.out -9223372036854775808
input='-9223372036854775808' ld=-9223372036854775808 (errno 0)
so that seems to work correctly. And I compiled with the same compiler
flags with which postgres was compiled. Apparently long is defined as
'long long int' on alpha, and I tried it with that and it works as well.
I'll have to debug this properly, but first I need to get Friday out of
the way ;-)
Adriaan
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Patch application
> 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 HTML files from it. Example > (using the Debian lists-archives package) can be seen at > http://fslc.usu.edu/archives Yes, I am looking at mhonarc right now. That is what I will use. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
RE: [HACKERS] Beta 6 Regression results on Redat 7.0.
> 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 TABLE temptest; > > and another one doing repeated CHECKPOINTs. I've already gotten a > couple occurrences of Lamar's failure. I wasn't able to reproduce failure with current sources. Vadim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Strange results of CURRENT_TIMESTAMP
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 2001-02-10 13:10:59.00+01 Which means, that the proper timestamp should look like: 2001-02-10 13:11:00.00+01 - I have a float4 field, which contains the value 3e-40 (approximately). I know it's there - the queries return it without any problem. Problem occurs again when I try to repopulate the table. Having such a value in a line generated by pg_dump (in form of COPY from stdin) I get the error: Bad float4 input format -- underflow. When I redefine the field as a float8 everything works fine. But why does it occur during repopulation - when in fact such a value did exist in the table before the table was drop. I'am running Postgresql 7.0.2 thanks for help Mark ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] RELEASE STOPPER? nonportable int64 constants in pg_crc.c
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 range. I guess this will show up on a lot of non gcc platforms ! It shows no diffs in the regression tests! From what I understand, failure would only show up after fast shutdown/crash. Attached is a patch, but I have no idea how portable that is. Andreas pg_crc.patch ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Final Call: RC1 about to go out the door ...
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 Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...
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 PC based system also. I believe there is a > x86 based MkLinux exists somewhere. mkLinux is "micro-kernel" Linux, on top of Mach. Consequentially, it is non-trivially different from any other Linux. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: Call for platforms
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 implementational developments and not a good indicator of any actually working platform. (I do have access to a Unixware box, but that was already reported.) -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for platforms
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
Re: [HACKERS] RPM building (was regression on RedHat)
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 never be turned on by any `-O' option > since it can result in incorrect output for programs which > depend on an exact implementation of IEEE or ANSI > rules/specifications for math functions. 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 math." In particular, Mandrake is not wrong to compile with -O3 and -ffast-math. The consequence would only be slightly incorrect math results, and that is what indeed happened. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] BufferSync() & FlushRelationBuffers() conflict
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->cntxDirty and call StartBufferIO in BufferSync()
> > *before* acquiring shlock on buffer context. This way we should be
> > protected against conflicts with FlushRelationBuffers.
> > (Seems we never do excl lock and then StartBufferIO for the same
> > buffer, so there should be no deadlock here, - but we'd better
> > check this very soon).
>
> Vadim
>
>
>
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch application
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 also use this to ask people for > patch review. > > 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. would could make a read-only to public, write only to you, mailbox on mail.postgresql.org that ppl could access with IMAP ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] FAQ: Current state of replication ?
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 the "writer" server > will be wrapped in transactions, and there will be foreign key consistency > checking in many tables. > 3. Delays from "writer" through to consistent state on "readers" can be > tolerated to within a few minutes or even more. All read-servers must be in > the same state when answering requests. > > Our objective is to acheive performance and some fault tolerance as the data > is going to be used for near-real time configuration of various other > backend systems in an almost traditional 'net environment. Your application sounds like a perfect fit for LDAP. In other words, keep your database in Postgres, but export views of it through for clients to query through LDAP. Rely on LDAP replication, since it has the model you need and works today. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS]
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 to close. What is the reason for this message? Esmat sedghi. Thanks ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Patch application
> 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 also use this to ask people for > > patch review. > > > > 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. > > would could make a read-only to public, write only to you, mailbox on > mail.postgresql.org that ppl could access with IMAP ... I actually finished. It is at: http://candle.pha.pa.us/cgi-bin/pgpatches This URL will reindex if I make any changes to the mailbox file. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pgindent run?
> 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, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for platforms
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 test (following the AIX FAQ it's normal ?) But when I configure with --with-perl I have the following error : make[4]: cc : Command not found Any idea ? Gilles DAROLD > 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...
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? > > >> Linux/PPC (LinuxPPC 2000 Q4 distro tested here; 2.2.18 kernel I think) > > > What processor? Tatsuo had tested on a 603... > > It's a Powerbook G3 (FireWire model), but I'm not sure which chip is > inside (and Apple's spec sheet isn't too helpful)... > > regards, tom lane > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New TODO item
> 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 commented on the > SQL'92 standard grammar for this (in reply to someone else's patch), > but I don't think I wrote anything. Unless it's another Ross (we're not > as common as Toms, but getting more so ;-) Sorry, got my R*'s mixed up: "Robert B. Easter" <[EMAIL PROTECTED]> -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgindent run?
> 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 done in the past. It obviously only affects new changes since the last run. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgindent run?
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 pgindent this time can be caught with those testing RC1 ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] New TODO item
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 commented on the SQL'92 standard grammar for this (in reply to someone else's patch), but I don't think I wrote anything. Unless it's another Ross (we're not as common as Toms, but getting more so ;-) Ross ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgindent run?
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)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgindent run?
> 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 pgindent this time can be caught with those > testing RC1 ... Good idea. It is well tested, but you never know. 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. Unless someone says otherwise, I will do the run tonight. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RELEASE STOPPER? nonportable int64 constants in pg_crc.c
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) Integer constant 0x42F0E1EBA9EA3693 out of range.
>
> I guess this will show up on a lot of non gcc platforms !
> It shows no diffs in the regression tests! From what I understand,
> failure would only show up after fast shutdown/crash.
>
> Attached is a patch, but I have no idea how portable that is.
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, 0x42F0E1EBA9EA3693##L64,
0x85E1C3D753D46D26##L64, 0xC711223CFA3E5BB5##L64,
...
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] pgindent run?
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 the best time. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] elog with automatic file, line, and function
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 global variables? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pgindent run?
> 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 the best > time. That you are holding? Yes, I have a few to at my new Unapplied Patches web page: http://candle.pha.pa.us/cgi-bin/pgpatches The good news is that these will apply fine to 7.2 unless they touch an area that needed indenting. The problem of not doing it is that the code starts to look different after a while and takes on a chaotic feel. This is probably the time when there are the fewest oustanding patches, I guess. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] More on elog and error codes
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" > PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't > exist" > > and if we want a generic 'type does not exist', then: > > PGERR_NOSUCHTYPE 02xxx "type %s does not exist - %s" > > where the %s might contain 'it can't be used as a function argument'. > > the we just have > > elogc(ERROR, PGERR_TYPALEXI, ...) > > /* elsewhere... */ > > elogc(ERROR, PGERR_FUNCNOTYPE, ...) 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? How can this be checked against bugs? (I know GCC can be pretty helpful here, but does it catch all problems?) Conversely, when you look at the error message you don't know from what contexts it's called. The error messages will degrade rapidly in quality because changing one will become a major project. > Creating central message files/objects has the added advantage of a much > simpler locale support - they're just resource files, and they're NOT > embedded throughout the code. Actually, the fact that the messages are in the code, where they're used, and not in a catalog file is a reason why gettext is so popular and catgets gets laughed at. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...
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 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? > > > > >> Linux/PPC (LinuxPPC 2000 Q4 distro tested here; 2.2.18 kernel > I think) > > > > > What processor? Tatsuo had tested on a 603... > > > > It's a Powerbook G3 (FireWire model), but I'm not sure which chip is > > inside (and Apple's spec sheet isn't too helpful)... > > > > regards, tom lane > > > > ---(end of > broadcast)--- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to [EMAIL PROTECTED] so that your > > message can get through to the mailing list cleanly > > > > > > > > ---(end of broadcast)- -- > TIP 4: Don't 'kill -9' the postmaster > > ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...
$ 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pgindent run?
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, when should I run pgindent? This is usually the time > I do it. > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgindent run?
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:
>
> /* one word */
>
> to be consistent.
to be consistent with what ... ? isn't:
/* --
* comment
* --
*/
the standard?
>
>
> > With RC1 nearing, when should I run pgindent? This is usually the time
> > I do it.
> >
> > --
> > Bruce Momjian| http://candle.pha.pa.us
> > [EMAIL PROTECTED] | (610) 853-3000
> > + If your life is a hard drive, | 830 Blythe Avenue
> > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
> >
> > ---(end of broadcast)---
> > TIP 6: Have you searched our list archives?
> >
> > http://www.postgresql.org/search.mpl
> >
>
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RPM building (was regression on RedHat)
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 more questions about PostgreSQL being broken on Mandrake systems). Isn't it better that PostgreSQL works with what it's got on a system AND ALSO that someone notifies the Mandrake people regarding the problem? Regards and best wishes, Justin Clift Trond Eivind Glomsrød wrote: > > > If Mandrake wants to be broken, let them - and tell them. > > -- > Trond Eivind Glomsrød > Red Hat, Inc. > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RPM building (was regression on RedHat)
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 - 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 platforms as > possible. Heck, we even build for M$ ;) > > 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. Of course, it would be > possible to just add it at the end of the flags, but it would be nice to > do that only when necessary. > > Regards. > > - Thomas > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for platforms (linux 2.4.x ?)
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 McMurry > IRIX 6.5.6f MIPS 6.5.3 2000-02-18, Kevin Wheatley > Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox > Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii > mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii > NetBSD 1.4 arm32 7.0 2000-04-08, Patrick Welche > NetBSD 1.4U x867.0 2000-03-26, Patrick Welche > NetBSD m68k7.0 2000-04-10, Henry B. Hotz > NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo > QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos > SCO OpenServer 5 x86 6.5 1999-05-25, Andrew Merrill > Solaris x867.0 2000-04-12, Marc Fournier > Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut > SunOS 4.1.4 Sparc 7.0 2000-04-13, Tatsuo Ishii > Windows/Win32 x86 7.0 2000-04-02, Magnus Hagander (clients only) > WinNT/Cygwin x86 7.0 2000-03-30, Daniel Horak > > BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter > BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian > FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber > HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane > IBMS/390 7.1 2000-11-17, Neale Ferguson > Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick > Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart > Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick > LinuxPPC G37.1 2001-03-19, Tom Lane > SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman > MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] RPM building (was regression on RedHat)
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 that WE will be probably also be > answering more questions about PostgreSQL being broken on Mandrake > systems). > > Isn't it better that PostgreSQL works with what it's got on a system AND > ALSO that someone notifies the Mandrake people regarding the problem? Most people will use what the vendor ship - a vendor (like us) look into the benefits (stability, performance, compatiblity) of different packages, and make a selection. If they've done a choice of which options are used in their distribution, they are obviously fine with the consequences. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Call for platforms (linux 2.4.x ?)
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)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Migration - Linux/pgSQL/PHP (type,version)
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 - good/easy for "automatic" WEB upgrades) or Mandrake or Suse/professional (best ranking in some PC magazines). Strange: The rankings (No 1 Mandrake, No 2 Suse) did not test Debian - accidentally or deliberately? 3. RedHat 7xx has been characterised - unstable!!! Any "objective" Pros/Cons for Linux type/version in terms of pgSQL use - my order of preferences Debian, Mandrake, Suse, RedHat. Much obliged, Steven. -- * Steven Vajdic (BSc/Hon, MSc) Senior Software Engineer Motorola Australia Software Centre (MASC) 2 Second Avenue, Technology Park Adelaide, South Australia 5095 WORK email: [EMAIL PROTECTED] WORK email: [EMAIL PROTECTED] phone (work): +61-8-8168-3435 Fax (work):+61-8-8168-3501 Front Office (ph): +61-8-8168-3500 mobile: +61 (0)419 860 903 HOME email: [EMAIL PROTECTED] * ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pgindent run?
> 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: > > > > /* one word */ > > > > to be consistent. > > to be consistent with what ... ? isn't: > > /* -- > * comment > * -- > */ > > the standard? Sorry. It has been a while since I studied this. The issue is the dashes, not the block comments. /* --- is needed for multi-line comment where you want to preserve the layout, but in other cases, it prevents comment layout and looks kind of heavy. I eyeball each change to make sure it is clean so: /* --- * test * --- */ becomes the cleaner: /* * test */ This makes the comment easier to read. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] More on elog and error codes
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 "type %s cannot be created because it already exists" >> PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't >> exist" >> >> and if we want a generic 'type does not exist', then: >> >> PGERR_NOSUCHTYPE 02xxx "type %s does not exist - %s" >> >> where the %s might contain 'it can't be used as a function argument'. >> >> the we just have >> >> elogc(ERROR, PGERR_TYPALEXI, ...) >> >> /* elsewhere... */ >> >> elogc(ERROR, PGERR_FUNCNOTYPE, ...) > >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? >From experience using this sort of system, probably 80% of errors in new code are new; if you don't know the format of your own errors, then you have a larger problem. Secondly, most errors have obvious parameters, and it only ever gets confusing when they have more than one parameter, and even then it's pretty obvious. This concern was often raised by people new to the system, but generally turned out to be more FUD than fact. >How can this be checked against bugs? >Conversely, when you look at the error message you don't know from what >contexts it's called. Am I missing something here? The user gets a message like: TYPALREXI: Specified type 'fred' already exists. then we do glimpse TYPALREXI It is actually a lot easier than the plain text search we already have to do, when we have to guess at the words that have been substituted into the message. Besides, in *both* proposed systems, if we have done things properly, then the postgres log also contains the module name & line #. >The error messages will degrade rapidly in quality >because changing one will become a major project. Changing one will be a major project only if it is used everywhere. Most will be relatively localized. And, with glimpse 'XYZ', it's not really that big a task. Finally, you would need to ask why it was being changed - would a new message work better? Tell me where the degradation in quality is in comparison with text-in-the-source versions, with umpteen dozen slightly different versions of essentially the same error messages? >> Creating central message files/objects has the added advantage of a much >> simpler locale support - they're just resource files, and they're NOT >> embedded throughout the code. > >Actually, the fact that the messages are in the code, where they're used, >and not in a catalog file is a reason why gettext is so popular and >catgets gets laughed at. Is there a URL for a getcats vs. gettext debate would help me understand the reason for the laughter? I can understand laughing at code that looks like: elog(ERROR, 123456, typename); but elog(ERROR, TYPALREXI, typename); is a whole lot more readable. Also, you failed to address the two points below: >#define PGERR_TYPE 1854 > >/* somewhere... */ > >elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already exists", ...) > >/* elsewhere... */ > >elogc(ERROR, PGERR_TYPE, "type %s used as argument %d of function %s doesn't exist", ...) > In the specific example above, returning the same error code is not going to help the client. What if they want to handle "type %s used as argument %d of function %s doesn't exist" by creating the type, and silently ignore "type %s cannot be created because it already exists"? How do you handle "type %s can not be used as a function return type"? Is this PGERR_FUNC or PGERR_TYPE? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.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 - 1506-207 (W) Integer constant 0x42F0E1EBA9EA3693 out of range. Please observe that this is a warning, not an error. Your proposed fix is considerably worse than the disease, because it will break on compilers that do not recognize "LL" constants, to say nothing of machines where L is correct and LL is some yet wider datatype. I'm aware that some compilers will produce warnings about these constants, but there should not be any that fail completely, since (a) we won't be compiling this code unless we've proven that the compiler supports a 64-bit-int datatype, and (b) the C standard forbids a compiler from requiring width suffixes (cf. 6.4.4.1 in C99). I don't think it's a good tradeoff to risk breaking some platforms in order to suppress warnings from overly anal-retentive compilers. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RELEASE STOPPER? nonportable int64 constants inpg_crc.c
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_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 range.
>
> Please observe that this is a warning, not an error. Your proposed
> fix is considerably worse than the disease, because it will break on
> compilers that do not recognize "LL" constants, to say nothing of
> machines where L is correct and LL is some yet wider datatype.
>
> I'm aware that some compilers will produce warnings about these
> constants, but there should not be any that fail completely, since
> (a) we won't be compiling this code unless we've proven that the
> compiler supports a 64-bit-int datatype, and (b) the C standard
> forbids a compiler from requiring width suffixes (cf. 6.4.4.1 in C99).
>
> I don't think it's a good tradeoff to risk breaking some platforms in
> order to suppress warnings from overly anal-retentive compilers.
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RELEASE STOPPER? nonportable int64 constants in pg_crc.c
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, 0x42F0E1EBA9EA3693##L64,
> 0x85E1C3D753D46D26##L64, 0xC711223CFA3E5BB5##L64,
Hmm ... how portable is that likely to be? I don't want to suppress
warnings on a few boxes at the cost of breaking even one platform
that would otherwise work. See my reply to Andreas.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] elog with automatic file, line, and function
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 requiring varargs macros. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for platforms
* 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 possible you ran out of disk space? > > > Probably not. > > The reason I was speculating that was that it seems pretty unlikely > that a write() call could return ENOENT, as the above appears to > suggest. I think that the errno = ENOENT value was not set by write(), > but is leftover from the expected failure of BasicOpenFile earlier in > XLogFileInit. Probably write() returned some value less than BLCKSZ > but more than zero, and so did not set errno. > > Offhand the only reason I can think of for a write to a disk file > to terminate after a partial transfer is a full disk. What do you > think? What about hitting a quota? LER > > regards, tom lane > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Call for platforms
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 I was speculating that was that it seems pretty unlikely that a write() call could return ENOENT, as the above appears to suggest. I think that the errno = ENOENT value was not set by write(), but is leftover from the expected failure of BasicOpenFile earlier in XLogFileInit. Probably write() returned some value less than BLCKSZ but more than zero, and so did not set errno. Offhand the only reason I can think of for a write to a disk file to terminate after a partial transfer is a full disk. What do you think? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: int8 bug on Alpha
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 digits it would succeed! O This is an Alpha, remember? long *is* 64 bits on that machine, therefore strtol is correct to accept the number. Unfortunately, later in the parser we assign the datatype int4, not int8, to the "integer" constant, and so it gets truncated. make_const is making an unwarranted assumption that T_Integer is the same as int4 --- or, if you prefer, make_const is OK and scan.l is erroneous to use node type T_Integer for ints that exceed 32 bits. This is a portability bug, no question. But I'd expect it to fail like that on all Alpha-based platforms. Adriaan, when you say it works on Linux, are you talking about Linux/Alpha or some other hardware? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] BufferSync() & FlushRelationBuffers() conflict
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 some more. However, last night I only saw the failure once in about an hour's worth of testing, so it's not that easy to reproduce anyway... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.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 - 1506-207 (W) Integer constant 0x42F0E1EBA9EA3693 out of range. > > Please observe that this is a warning, not an error. Your proposed > fix is considerably worse than the disease, because it will break on > compilers that do not recognize "LL" constants, to say nothing of > machines where L is correct and LL is some yet wider datatype. I am seeing the same warnings with gcc 2.7.2.1 -Wall on BSDi i386: pg_crc.c:353: warning: integer constant out of range pg_crc.c:353: warning: integer constant out of range pg_crc.c:354: warning: integer constant out of range pg_crc.c:354: warning: integer constant out of range pg_crc.c:355: warning: integer constant out of range pg_crc.c:355: warning: integer constant out of range pg_crc.c:356: warning: integer constant out of range -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c
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, > > > a.. > > > a - 1506-207 (W) Integer constant 0x42F0E1EBA9EA3693 out of range. > > > > Please observe that this is a warning, not an error. Your proposed > > fix is considerably worse than the disease, because it will break on > > compilers that do not recognize "LL" constants, to say nothing of > > machines where L is correct and LL is some yet wider datatype. > > I am seeing the same warnings with gcc 2.7.2.1 -Wall on BSDi i386: > > pg_crc.c:353: warning: integer constant out of range > pg_crc.c:353: warning: integer constant out of range > pg_crc.c:354: warning: integer constant out of range > pg_crc.c:354: warning: integer constant out of range > pg_crc.c:355: warning: integer constant out of range > pg_crc.c:355: warning: integer constant out of range > pg_crc.c:356: warning: integer constant out of range > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] BufferSync() & FlushRelationBuffers() conflict
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
> > 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 only saw the failure once in about an
> hour's worth of testing, so it's not that easy to reproduce anyway...
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] BufferSync() & FlushRelationBuffers() conflict
> > 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 only saw the failure once in about an > hour's worth of testing, so it's not that easy to reproduce anyway... I saw >~ 10 failures with -B 32 in ~ 3 minutes of testing. With old code, of course -:) Vadim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgindent run?
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 and will say again that I think it's utter folly to run pgindent at the conclusion of the test cycle. I've been around this project for three major release cycles and we have seen errors introduced by pgindent in two of them. I don't trust pgindent to be bug-free and I don't believe you should either. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pgindent run?
> 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 and will say again that I think > it's utter folly to run pgindent at the conclusion of the test cycle. > I've been around this project for three major release cycles and we have > seen errors introduced by pgindent in two of them. I don't trust > pgindent to be bug-free and I don't believe you should either. OK, running now. Should I run it at another time or never? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] odbc/UnixWare 7.1.1: No Go.
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: psqlodbc.o UX:tsort: INFO: dlg_specific.o UX:tsort: INFO: misc.o UX:tsort: WARNING: Cycle in data UX:tsort: INFO: dlg_specific.o UX:tsort: INFO: psqlodbc.o : libpsqlodbc.a cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26 UX:ld: ERROR: psqlodbc.o: symbol: '_fini' multiply defined; also in file /usr/ccs/lib/crti.o gmake[3]: *** [libpsqlodbc.so.0.26] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces/odbc' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' gmake: *** [all] Error 2 Why do WE define _fini? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgindent run?
>> 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 at the start of a development cycle, not the end, but I've been unable to convince Bruce of that ... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgindent run?
> >> 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 at the start > of a development cycle, not the end, but I've been unable to convince > Bruce of that ... 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. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgindent run?
* 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 we should run it. > > > > I've always felt that it'd be smarter to run pgindent at the start > > of a development cycle, not the end, but I've been unable to convince > > Bruce of that ... > > 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. How about: 1) just AFTER release 2) just BEFORE Beta LER > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pgindent run?
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 release, I think you should do it > > *before* we wrap RC1. I've said before and will say again that I think > > it's utter folly to run pgindent at the conclusion of the test cycle. > > I've been around this project for three major release cycles and we have > > seen errors introduced by pgindent in two of them. I don't trust > > pgindent to be bug-free and I don't believe you should either. > > OK, running now. Should I run it at another time or never? I'll put my vote on Tom's side of things ... run if after the release, right at the start of the next development cycle, so that any bugs that crop up aren't just as we are trying to release ... Hell, maybe once then and once *just* as we are going into first beta of a release ... Tom? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] More on elog and error codes
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 know what it does? Is the first arg a %s or a %d? What's >> the first %s, what the second? >> From experience using this sort of system, probably 80% of errors in new > code are new; if you don't know the format of your own errors, then you > have a larger problem. Secondly, most errors have obvious parameters, and > it only ever gets confusing when they have more than one parameter, and > even then it's pretty obvious. The general set of parameters might be pretty obvious, but the exact type that the format string expects them to be is not so obvious. We have enough ints, longs, unsigned longs, etc etc running around the system that care is required. If you look at the existing elog calls you'll find quite a lot of explicit casts to make certain that the right thing will happen. If the format strings are not directly visible to the guy writing an elog call, then errors of that kind will creep in more easily. >> The error messages will degrade rapidly in quality >> because changing one will become a major project. > Changing one will be a major project only if it is used everywhere. I agree with Peter on this one too. Even having to edit a separate file will create enough friction that people will tend to use an existing string if it's even marginally appropriate. What I fear even more is that people will simply not code error checks, especially for "can't happen" cases, because it's too much of a pain in the neck to register the appropriate message. We must not raise the cost of adding error checks significantly, or we will lose the marginal checks that sometimes save our bacon by revealing bugs. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgindent run?
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 by (a) branching the tree, (b) applying all held-over patches, and then (c) running pgindent? I'd probably wait a week or so between (a) and (c) to let people push in whatever they have pending. But in general it seems a lot safer to pgindent at the front end of the cycle not the back end. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c
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 to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgindent run?
> 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 by (a) branching the tree, (b) applying > all held-over patches, and then (c) running pgindent? 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. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c
> 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 drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] More on elog and error codes
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 (may include commented-out calls) - 2528 unique messages - 1248 have no parameters - 859 have exactly one argument - 285 have exactly 2 args - 136 have 3 or more args so 83% have one or no arguments, which is probably not going to be very confusing. Looking at the actual messages, there is also a great deal of opportunity to standardize and simplify since many of the messages only differ by their prefixed function name. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgindent run?
> > 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 ... we are > suggesting (or, at least, I am) is that you pgindent *HEAD* after we've > branched off v7.1 ... > > ... that way, we go into the new dev cycle "clean", but we doon't mess up > the *STABLE* tree ... But we get patches from 7.0.X now that get applied to 7.1. All our developers are not working on CVS trees. Many use their main trees and send in the occasional patch. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pgindent run?
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. Peter E has some > > > already. > > > > Why not start a devel cycle by (a) branching the tree, (b) applying > > all held-over patches, and then (c) running pgindent? > > 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 ... we are suggesting (or, at least, I am) is that you pgindent *HEAD* after we've branched off v7.1 ... ... that way, we go into the new dev cycle "clean", but we doon't mess up the *STABLE* tree ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pgindent run?
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 those patches should only be applied to the v7.1 branch ... we are > > suggesting (or, at least, I am) is that you pgindent *HEAD* after we've > > branched off v7.1 ... > > > > ... that way, we go into the new dev cycle "clean", but we doon't mess up > > the *STABLE* tree ... > > But we get patches from 7.0.X now that get applied to 7.1. All our > developers are not working on CVS trees. Many use their main trees and > send in the occasional patch. 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 that a submit'd patch from an older release be at least tested on the newest CVS, and with nightly snapshots being created as it is, I really don't see why such a requirement is a bad thing ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgindent run?
> 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 that a submit'd patch from an older release be at least tested on > the newest CVS, and with nightly snapshots being created as it is, I > really don't see why such a requirement is a bad thing ... In an ideal world, people would test on CVS but in reality, the patches are usually pretty small and if they fix the problem, we apply them. Seems like a lot of work just to avoid pgindent. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RPM building (was regression on RedHat)
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 similar patch in the 7.0 spec file (for -fsigned-char stupidity in the RPM configuration on LinuxPPC). That's not needed anymore, but couldn't you fix Mandrake the same way? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
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 data > UX:tsort: INFO: psqlodbc.o > UX:tsort: INFO: dlg_specific.o > UX:tsort: INFO: misc.o > UX:tsort: WARNING: Cycle in data > UX:tsort: INFO: dlg_specific.o > UX:tsort: INFO: psqlodbc.o > : libpsqlodbc.a > cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o >connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o >pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o >tuplelist.o dlg_specific.o -lm -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26 > UX:ld: ERROR: psqlodbc.o: symbol: '_fini' multiply defined; also in file >/usr/ccs/lib/crti.o > gmake[3]: *** [libpsqlodbc.so.0.26] Error 1 > gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces/odbc' > gmake[2]: *** [all] Error 2 > gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces' > gmake[1]: *** [all] Error 2 > gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' > gmake: *** [all] Error 2 > > Why do WE define _fini? > > LER > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgindent run?
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 on ... in general, most projects seem to > > require that a submit'd patch from an older release be at least tested on > > the newest CVS, and with nightly snapshots being created as it is, I > > really don't see why such a requirement is a bad thing ... > > In an ideal world, people would test on CVS but in reality, the patches > are usually pretty small and if they fix the problem, we apply them. > > Seems like a lot of work just to avoid pgindent. If they are small, then why is pgindent required? And if they are large, is it too much to ask that the person submitting tests the patch to make sure its even applicable in the newest snapshot? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c
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 casted to long long. If you write (long long) 12345678901234567890 I'd expect a compiler that warns about larger-than-int constants to produce a warning anyway, since the warning is only looking at the constant and not its context of use. (If the warning had that much intelligence, it'd not be complaining now.) regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgindent run?
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 vary too much without it. I'm only unhappy about the risk issues of running it at this late stage of the release cycle. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgindent run?
> > > 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 that a submit'd patch from an older release be at least tested on > > > the newest CVS, and with nightly snapshots being created as it is, I > > > really don't see why such a requirement is a bad thing ... > > > > In an ideal world, people would test on CVS but in reality, the patches > > are usually pretty small and if they fix the problem, we apply them. > > > > Seems like a lot of work just to avoid pgindent. > > If they are small, then why is pgindent required? And if they are large, > is it too much to ask that the person submitting tests the patch to make > sure its even applicable in the newest snapshot? The problem is that the small ones don't apply cleanly if they don't match the indenting in the source. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgindent run?
> 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 vary too much without it. I'm only unhappy about the risk > issues of running it at this late stage of the release cycle. This is the usual discussion. Some like it, some don't like the risk, some don't like the timing. I don't think we ever came up with a better time than before RC, though I think we could do it a little earlier in beta if people were not holding patches during that period. It is the beta patching folks that we have the most control over. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pgindent run?
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 projects I've worked on ... in general, most projects seem to > > > > require that a submit'd patch from an older release be at least tested on > > > > the newest CVS, and with nightly snapshots being created as it is, I > > > > really don't see why such a requirement is a bad thing ... > > > > > > In an ideal world, people would test on CVS but in reality, the patches > > > are usually pretty small and if they fix the problem, we apply them. > > > > > > Seems like a lot of work just to avoid pgindent. > > > > If they are small, then why is pgindent required? And if they are large, > > is it too much to ask that the person submitting tests the patch to make > > sure its even applicable in the newest snapshot? > > 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 cleanly ... Quite frankly, I'm for pgindent after branch and before beta ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgindent run?
> > 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 cleanly ... Yes, they can be manually merged, but that is much more error-prone than pgindent itself, at least with me patching them. :-) Yes, I agree there is a risk. I was quite scared the first time I ran it on the tree and did the commit. At this point, there are very few changes to it, so I feel a little better, and the stuff gets caught somehow if there is a problem. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] More on elog and error codes
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 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? > >>> From experience using this sort of system, probably 80% of errors in new >> code are new; if you don't know the format of your own errors, then you >> have a larger problem. Secondly, most errors have obvious parameters, and >> it only ever gets confusing when they have more than one parameter, and >> even then it's pretty obvious. > >The general set of parameters might be pretty obvious, but the exact >type that the format string expects them to be is not so obvious. We >have enough ints, longs, unsigned longs, etc etc running around the >system that care is required. If you look at the existing elog calls >you'll find quite a lot of explicit casts to make certain that the right >thing will happen. If the format strings are not directly visible to >the guy writing an elog call, then errors of that kind will creep in >more easily. I agree it's more likely, but most (all?) cases can be caught by the compiler. It's not ideal, but neither is having eight different versions of the same message. >>> The error messages will degrade rapidly in quality >>> because changing one will become a major project. > >> Changing one will be a major project only if it is used everywhere. > >I agree with Peter on this one too. Even having to edit a separate >file will create enough friction that people will tend to use an >existing string if it's even marginally appropriate. What I fear even >more is that people will simply not code error checks, especially for >"can't happen" cases, because it's too much of a pain in the neck to >register the appropriate message. > >We must not raise the cost of adding error checks significantly, or we >will lose the marginal checks that sometimes save our bacon by revealing >bugs. 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 files). eg. pg_dump would have it's own pg_dump_messages.xxx file. - define a message that will assume it's first arg is really a format string for use in the "can't happen" classes, and which has the SQLCODE for 'internal error'. We do need some central control, but by creating module-based message files we can allocate number ranges easily, and we at least take a step down the path towards a both easy locale handling and a 'big book of error codes'. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
