Re: [HACKERS] NUMERIC type efficiency problem
Tom Lane wrote: > Yawn ... given row overhead, alignment padding, etc, this is not nearly > as big a deal as you make it ... For a table with ten decimal columns with an average of 5 significant digits apiece, each row could be reduced from ~170 bytes to about ~90 bytes, which could be rather significant, I would think. (In Oracle such a row takes ~55 bytes.) By the way, is alignment padding really a good use of disk space? Surely storage efficiency trumps minor CPU overhead in any I/O bound database. Or are there other considerations? (like processor portability perhaps?) > I don't have any objection in principle to an additional datatype "small > numeric", or some such name, with a different representation. I do > object to emasculating the type we have. Surely we can't get rid of it, but it might be a good idea to make NUMERIC(p) map to multiple representations, given that it is a ANSI standard data-type. I suggest using a system like the FLOAT(p) -> float4 / float8 mapping. Columns declared with precisions higher than 16 or so could map to the current unrestricted representation, and columns with more typical precisions could map to a more efficient fixed length representation. > A more significant point is that you have presented no evidence to back > up your claim that this would be materially faster than the existing > type. I doubt that the extra pallocs are all that expensive. (I think > it'd be far more helpful to reimplement numeric using base-1 > representation --- four decimal digits per int16 --- and then eliminate > the distinction between storage format and computation format. See past > discussions in the pghackers archives.) That sounds like it would help a lot. I certainly don't have any hard evidence yet. Thanks for the pointer. - Mark Butler ---(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] ALTER TABLE MODIFY COLUMN
Tom Lane wrote: > > Mark Butler <[EMAIL PROTECTED]> writes: > > Surely if we have an write exclusive table lock we can rewrite tuples > > in place rather than creating new versions with its corresponding 2x > > space requirement. > > Nyet. Consider transaction rollback. Well, the first thing to consider would be to make this type of DDL operation un-abortable. If the database goes down while the table modification is in progress, the recovery process could continue the operation to completion before releasing the table for general access. The problem with the standard alternatives is that they waste space and are slow: Alt 1. create new version of tuples in new format like DROP COLUMN proposal Alt 2. rename column; add new column; copy column; drop (hide) old column Alt 3. rename indices; rename table; copy table; recreate indices; Now this probably only makes a difference in a data warehouse environment, where the speed of mass load / update operations is much more important than being able to roll them back. I suppose there are two really radical alternatives as well: Radical Alt 1: Use format versioning to allow multiple row formats to co-exist, lazy update to latest format Radical Alt 2: Delta compress different versions of the same row on the same page I can see that the conventional alternatives make sense for now, however. - Mark Butler ---(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: Hand written parsers
[EMAIL PROTECTED] (Nathan Myers) writes: > Yacc and yacc-like programs are most useful when the target grammar (or > your understanding of it) is not very stable. With Yacc you can make > sweeping changes much more easily; big changes can be a lot of work in > a hand-coded parser. And, in fact, this is precisely the killer reason why we will not switch to a handwritten parser anytime in the foreseeable future. Postgres' grammar is NOT stable. Compare the gram.y files for any two recent releases. I foresee changes at least as large in upcoming releases, btw, as we implement more of SQL92/99 and drop ancient PostQuel-isms. I have some interest in proposals to switch to a better parser-generator tool than yacc ... but yacc has the advantages of being widely available and widely understood. You'd need a pretty significant improvement over yacc to make it worth switching. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Dump/restore of views containing select distinct fails
=> create view testview as select relname, 'Constant'::text from pg_class; => \d testview View "testview" Attribute | Type | Modifier ---+--+-- relname | name | ?column? | text | View definition: SELECT DISTINCT pg_class.relname, 'Constant'::text FROM pg_class ORDER BY pg_class.relname, 'Constant'::text; Note how the order by clause is not valid SQL. You get ERROR: Non-integer constant in ORDER BY I suppose the ORDER BY clause appears because of some weird query parse tree hackery and is not easy to get rid of. Maybe using column numbers instead of spelling out the select list again would work? -- 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
[HACKERS] Re: Call for platforms
> Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's > patch should be applied? I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD seems to insist on calling every Intel processor a "i386". In this case, are you suggesting that this patch covers all NetBSD installations on every Intel processor from i386 + fpu forward to i486, i586, etc etc? Or is this specifically for the i386 with the 80387 coprocessor which is how any reasonable person would interpret "i386+fpu"? ;) - Thomas > > Index: src/test/regress/resultmap > > === > > RCS file: /home/projects/pgsql/cvsroot/pgsql/src/test/regress/resultmap,v > > retrieving revision 1.45 > > diff -u -r1.45 resultmap > > --- src/test/regress/resultmap2001/03/22 15:13:18 1.45 > > +++ src/test/regress/resultmap2001/03/22 17:29:49 > > @@ -17,6 +17,7 @@ > > geometry/.*-openbsd=geometry-positive-zeros-bsd > > geometry/.*-irix6=geometry-irix > > geometry/.*-netbsd=geometry-positive-zeros > > +geometry/i.86-.*-netbsdelf1.5=geometry-positive-zeros-bsd > > geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc > > geometry/.*-sysv5uw7.*:gcc=geometry-uw7-gcc > > geometry/alpha.*-dec-osf=geometry-alpha-precision ---(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] NUMERIC type efficiency problem
Mark Butler <[EMAIL PROTECTED]> writes:
> By the way, is alignment padding really a good use of disk space? Surely
> storage efficiency trumps minor CPU overhead in any I/O bound database.
Weren't you just complaining about excess palloc's ;-) ? Seriously,
I have no idea about the costs/benefits of aligning data on disk.
That decision was made way back in the Berkeley days, and hasn't been
questioned since then AFAIK. Feel free to experiment if you are
interested.
> I suggest using a system like the FLOAT(p) -> float4 / float8 mapping.
> Columns declared with precisions higher than 16 or so could map to the
> current unrestricted representation, and columns with more typical
> precisions could map to a more efficient fixed length representation.
Given that the "more efficient representation" would only be internal to
calculation subroutines, it seems easier to exploit preallocation at
runtime. This is already done in a number of places in Postgres.
It'd look something like
{
digit *tmp;
digittmpbuf[MAX_FIXED_DIGITS];
if (digits_needed > MAX_FIXED_DIGITS)
tmp = palloc(...);
else
tmp = tmpbuf;
// use tmp here
if (tmp != tmpbuf)
pfree(tmp);
}
Ugly, but most of the ugliness could be hidden inside a couple of
macros.
Again, though, I wouldn't bother with this until I had some profiles
proving that the palloc overhead is worth worrying about.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Yellow Dog Linux/PPC regression
Nat Irons <[EMAIL PROTECTED]> writes: > Regression tests for Yellow Dog Linux (PPC RedHat derivative) failed all > over the place with 7.0.3. Passed smoothly with 7.1RC3, though. Unsurprising if you compiled with any optimization level higher than -O0. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL v7.1 Release Candidate 4
Bruce Momjian <[EMAIL PROTECTED]> writes: > Can you give me specific text? I though 7.1 was a little better about > preserving the metadata. Not in the least --- 7.1's CLUSTER is just as bad as ever. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] timeout on lock feature
Bruce Momjian <[EMAIL PROTECTED]> writes: > I can imagine some people wanting this. However, 7.1 has new deadlock > detection code, so I would you make a 7.1 version and send it over. We > can get it into 7.2. I object strongly to any such "feature" in the low-level form that Henryk proposes, because it would affect *ALL* locking. Do you really want all your other transactions to go belly-up if, say, someone vacuums pg_class? A variant of LOCK TABLE that explicitly requests a timeout might make sense, though. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Btw., it would really seem like a neat feature if a given pg_dump suite > would also handle the respective previous version. Otherwise we're in a > situation like now where we've got a shiny new pg_dump but people that > want to upgrade are still stuck with the broken 7.0 incarnation. No more stuck than they were if they had needed to reload from their dump files into 7.0. I really doubt that it's worth going out of our way to try to keep pg_dump compatible with obsolete backends. If we had infinite manpower, then sure, but I think the time is better spent elsewhere. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Maybe a plpgsql bug?
Lehel Gyuro <[EMAIL PROTECTED]> writes: > I've tried to write a plpgsql function, and noticed the following > problem : (7.1RC2 rpm from postgresql.org) Perhaps this is a bug, but you have not given a complete example that would allow someone else to try to reproduce it. Please see the guidelines for bug reports. 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
[HACKERS] Re: Call for platforms
On Fri, Apr 13, 2001 at 01:25:45PM +, Thomas Lockhart wrote: > > Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's > > patch should be applied? > > I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD > seems to insist on calling every Intel processor a "i386". History ;-) > In this case, > are you suggesting that this patch covers all NetBSD installations on > every Intel processor from i386 + fpu forward to i486, i586, etc etc? Yes! It's simply, if the peecee type thing has a fpu (as in the sysctl machdep.fpu_present returns 1), then libm387.so is used, and you get differences in the (from memory 44th insignificant figure?) otherwise it just uses libm.so and you get what is currently correct in resultmap. Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] timeout on lock feature
I was thinking SET because UPDATE does an auto-lock. > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I can imagine some people wanting this. However, 7.1 has new deadlock > > detection code, so I would you make a 7.1 version and send it over. We > > can get it into 7.2. > > I object strongly to any such "feature" in the low-level form that > Henryk proposes, because it would affect *ALL* locking. Do you really > want all your other transactions to go belly-up if, say, someone vacuums > pg_class? > > A variant of LOCK TABLE that explicitly requests a timeout might make > sense, though. > > regards, tom lane > -- 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] timeout on lock feature
Bruce Momjian <[EMAIL PROTECTED]> writes: > I was thinking SET because UPDATE does an auto-lock. Not to mention a ton of implicit locks acquired on various system tables during parsing/planning. You really want auto timeout on all of those? I sure don't. The appropriate way to do this given a LOCK TABLE option would be like BEGIN; LOCK TABLE foo IN ROW EXCLUSIVE MODE WITH TIMEOUT n; UPDATE foo SET ...; COMMIT; which restricts the scope of the timeout behavior to just the specific lock that the user is thinking of, and doesn't risk breaking fundamental system operations. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Truncation of object names
On Fri, Apr 13, 2001 at 01:16:43AM -0400, Tom Lane wrote: > [EMAIL PROTECTED] (Nathan Myers) writes: > > We have noticed here also that object (e.g. table) names get truncated > > in some places and not others. If you create a table with a long name, > > PG truncates the name and creates a table with the shorter name; but > > if you refer to the table by the same long name, PG reports an error. > > Example please? This is clearly a bug. Sorry, false alarm. When I got the test case, it turned out to be the more familiar problem: create table foo_..._bar1 (id1 ...); [notice, "foo_..._bar1" truncated to "foo_..._bar"] create table foo_..._bar (id2 ...); [error, foo_..._bar already exists] create index foo_..._bar_ix on foo_..._bar(id2); [notice, "foo_..._bar_ix" truncated to "foo_..._bar"] [error, foo_..._bar already exists] [error, attribute "id2" not found] It would be more helpful for the first "create" to fail so we don't end up cluttered with objects that shouldn't exist, and which interfere with operations on objects which should. But I'm not proposing that for 7.1. Nathan Myers [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] pg_dump ordering problem (rc4)
Pascal Scheffers <[EMAIL PROTECTED]> writes: > Some five functions are used in views before their definitions. In the > original (7.0) dump they were in the correct order, but rc2/4 (the only > ones I tried) got it wrong. The original OIDs for the > functions in the 7.1 dump are lower than those of the views. I do not know > what is wrong. I can reproduce the results on another box. I have a copy > of the relevant dumps (both the initial 7.0.3 >> 7.1rc2 and the rc4 >> rc4 > dump), anyone interested may have them for testing. Please. Philip Warner would likely want to see them too. 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] timeout on lock feature
> The appropriate way to do this given a LOCK TABLE option would be like > > BEGIN; > LOCK TABLE foo IN ROW EXCLUSIVE MODE WITH TIMEOUT n; > UPDATE foo SET ...; > COMMIT; > > which restricts the scope of the timeout behavior to just the specific > lock that the user is thinking of, and doesn't risk breaking fundamental > system operations. This is pretty tough because the user has to know the proper lock type, right? -- 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] Truncation of object names
[EMAIL PROTECTED] (Nathan Myers) writes: > Sorry, false alarm. When I got the test case, it turned out to > be the more familiar problem: > create table foo_..._bar1 (id1 ...); > [notice, "foo_..._bar1" truncated to "foo_..._bar"] > create table foo_..._bar (id2 ...); > [error, foo_..._bar already exists] > create index foo_..._bar_ix on foo_..._bar(id2); > [notice, "foo_..._bar_ix" truncated to "foo_..._bar"] > [error, foo_..._bar already exists] > [error, attribute "id2" not found] > It would be more helpful for the first "create" to fail so we don't > end up cluttered with objects that shouldn't exist, and which interfere > with operations on objects which should. Seems to me that if you want a bunch of CREATEs to be mutually dependent, then you wrap them all in a BEGIN/END block. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Truncation of object names
On Fri, Apr 13, 2001 at 02:54:47PM -0400, Tom Lane wrote: > [EMAIL PROTECTED] (Nathan Myers) writes: > > Sorry, false alarm. When I got the test case, it turned out to > > be the more familiar problem: > > > create table foo_..._bar1 (id1 ...); > > [notice, "foo_..._bar1" truncated to "foo_..._bar"] > > create table foo_..._bar (id2 ...); > > [error, foo_..._bar already exists] > > create index foo_..._bar_ix on foo_..._bar(id2); > > [notice, "foo_..._bar_ix" truncated to "foo_..._bar"] > > [error, foo_..._bar already exists] > > [error, attribute "id2" not found] > > > It would be more helpful for the first "create" to fail so we don't > > end up cluttered with objects that shouldn't exist, and which interfere > > with operations on objects which should. > > Seems to me that if you want a bunch of CREATEs to be mutually > dependent, then you wrap them all in a BEGIN/END block. Yes, but... The second and third commands weren't supposed to be related to the first at all, never mind dependent on it. They were made dependent by PG crushing the names together. We are thinking about working around the name length limitation (encountered in migrating from other dbs) by allowing "foo.bar.baz" name syntax, as a sort of rudimentary namespace mechanism. It ain't schemas, but it's better than "foo__bar__baz". Nathan Myers [EMAIL PROTECTED] ---(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] Truncation of object names
[EMAIL PROTECTED] (Nathan Myers) writes: >> Seems to me that if you want a bunch of CREATEs to be mutually >> dependent, then you wrap them all in a BEGIN/END block. > Yes, but... The second and third commands weren't supposed to be > related to the first at all, never mind dependent on it. They were > made dependent by PG crushing the names together. Good point. > We are thinking about working around the name length limitation > (encountered in migrating from other dbs) by allowing "foo.bar.baz" > name syntax, as a sort of rudimentary namespace mechanism. Have you thought about simply increasing NAMEDATALEN in your installation? If you really are generating names that aren't unique in 31 characters, that seems like the way to go ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump ordering problem (rc4)
Tom, > > dump), anyone interested may have them for testing. > > Please. Philip Warner would likely want to see them too. I don't have his email address... but I am quite willing to send it. Pascal. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Truncation of object names
On Fri, 13 Apr 2001, Tom Lane wrote: > [EMAIL PROTECTED] (Nathan Myers) writes: > >> Seems to me that if you want a bunch of CREATEs to be mutually > >> dependent, then you wrap them all in a BEGIN/END block. > > > Yes, but... The second and third commands weren't supposed to be > > related to the first at all, never mind dependent on it. They were > > made dependent by PG crushing the names together. > > Good point. > > > We are thinking about working around the name length limitation > > (encountered in migrating from other dbs) by allowing "foo.bar.baz" > > name syntax, as a sort of rudimentary namespace mechanism. > > Have you thought about simply increasing NAMEDATALEN in your > installation? If you really are generating names that aren't unique > in 31 characters, that seems like the way to go ... Tom (or others) -- Other than (a) it wastes a bit of space in the pg_ tables, and (b) it may screw up postgresql utility programs (pgaccess, pgadmin, etc.), is there any reason to keep the default at 32? Are there performance limitations? (Will C-based triggers and client programs and such need to be modified?) I don't think that my tables are incredibly verbose, autogenerated sequence and index names often push the limit. The problem w/everyone compiling it at a higher number is that it makes it difficult to transparently move a PG database from one server to another. Thanks! -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Truncation of object names
On Fri, Apr 13, 2001 at 04:27:15PM -0400, Tom Lane wrote: > [EMAIL PROTECTED] (Nathan Myers) writes: > > We are thinking about working around the name length limitation > > (encountered in migrating from other dbs) by allowing "foo.bar.baz" > > name syntax, as a sort of rudimentary namespace mechanism. > > Have you thought about simply increasing NAMEDATALEN in your > installation? If you really are generating names that aren't unique > in 31 characters, that seems like the way to go ... We discussed that, and will probably do it (too). One problem is that, having translated "foo.bar.baz" to "foo_bar_baz", you have a problem when you encounter "foo.bar_baz" in subsequent code. I.e., a separate delimiter character helps, even when name length isn't an issue. Also, accepting the names as they appear in the source code already means the number of changes needed is much smaller, even when you don't have true schema support. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: Truncation of object names
Joel Burton <[EMAIL PROTECTED]> writes: >> Have you thought about simply increasing NAMEDATALEN in your >> installation? If you really are generating names that aren't unique >> in 31 characters, that seems like the way to go ... > Other than (a) it wastes a bit of space in the pg_ tables, and (b) it may > screw up postgresql utility programs (pgaccess, pgadmin, etc.), is there > any reason to keep the default at 32? Are there performance limitations? Those are pretty much the reasons, plus a compatibility issue: NAMEDATALEN *is* visible to clients (that's why it's in postgres_ext.h). So changing the default value would risk breaking clients that hadn't been recompiled. > (Will C-based triggers and client programs and such need to be modified?) Not if they've been properly coded (written in terms of NAMEDATALEN not a hard constant). Obviously, these objections are not strong enough to keep us from increasing the standard value of NAMEDATALEN if it seems that many people are running into the limit. But AFAICT relatively few people have such problems, and I'm hesitant to make everyone deal with a change for the benefit of a few. Count me as a weak vote for leaving it where it is ... 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
[HACKERS] pg_dump problem
Hi all, I've read pg_dump threads with great interest as I plan to upgrade from 703 to 71 on next monday if 71 final is out. Although I did'nt have any of the ploblems listed in threads durin my tests from 7.0.3 to 7.1betas and 7.1RCs. I have noticed that pg_dump and pg_dumpall could'nt generate correctly CREATE FUNCTION when function has been created using the form CREATE FUNCTION foo(x) RETURNS type AS '/foo.so','foo2' LANGUAGE C; pg_dumps "forgets" the 'foo2' part: that being a pain in the a... when reloading... Regards, -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Truncation of object names
On Fri, 13 Apr 2001, Tom Lane wrote: > Obviously, these objections are not strong enough to keep us from > increasing the standard value of NAMEDATALEN if it seems that many > people are running into the limit. But AFAICT relatively few people > have such problems, and I'm hesitant to make everyone deal with a change > for the benefit of a few. Count me as a weak vote for leaving it where > it is ... Hmm... Of course, it's Bad to break things if one doesn't have to. But (IMHO) its also bad to leave it at a setting that makes some group of people (~ 3%?) have to recompile it, and a larger group (~ 10%) wish they did/knew how to. (I, in general, share your hesistancy to break something for the benefit of the few, 'cept I'm one of the few this time. ;-) ) For some changes, one could just prewarn the world that This Is Coming, and they should anticipate it with 6 months notice or such. In this case, though, it would seem that knowing it was coming wouldn't help any -- you'd still have to recompile your client for the 32char names and the 64 (?) char names, during the 7.1 -> 7.2 (or 7.5 -> 8.0 or whatever) transition period. I'd like to see it longer -- is there any sane way of doing this with notice, or, as I fear, would it always be a pain, regardless of how much advance notice the world rec'd? Thanks, -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] NUMERIC type benchmarks
Tom Lane wrote:
> A more significant point is that you have presented no evidence to back
> up your claim that this would be materially faster than the existing
> type. I doubt that the extra pallocs are all that expensive. (I think
> it'd be far more helpful to reimplement numeric using base-1
> representation --- four decimal digits per int16 --- and then eliminate
> the distinction between storage format and computation format. See past
> discussions in the pghackers archives.)
I did several tests with functions designed to sum the number 12345 a million
times. The results are as follows (Pentium II 450, Redhat 6.2):
Postgres PL/PGSQL original numeric:14.8 seconds
Postgres PL/PGSQL modified numeric:11.0 seconds
Postgres PL/PGSQL float8: 10.7 seconds
GNU AWK:2.5 seconds
Oracle PL/SQL number: 2.0 seconds
The modified Postgres numeric type is the original source code modified to use
a 32 digit NumericVar attribute digit buffer that eliminates palloc()/pfree()
calls when ndigits < 32.
Surely those are performance differences worth considering...
- Mark Butler
Note: The functions are as follows, all called with 12345 as a parameter,
except for the awk program, which has it hard coded:
PostgreSQL
==
create function test_f1(float8) returns float8 as '
declare
i integer;
val float8;
begin
val := 0;
for i in 1 .. 100 loop
val := val + $1;
end loop;
return val;
end;'
language 'plpgsql';
create function test_f2(numeric) returns numeric as '
declare
i integer;
val numeric;
begin
val := 0;
for i in 1 .. 100 loop
val := val + $1;
end loop;
return val;
end;'
language 'plpgsql';
Awk
===
BEGIN {
val = 0;
p = 12345;
for(i = 1; i <= 100; i++)
{
val = val + p;
}
printf("%20f\n", val);
}
Oracle
==
create or replace function test_f2(p number) return number is
i number;
val number;
begin
val := 0;
for i in 1 .. 100 loop
val := val + p;
end loop;
return val;
end;
/
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump ordering problem (rc4)
I see the problem. Your 7.0.3 dump contains several instances of this
pattern:
CREATE TABLE "users_alertable" (
"user_id" int4,
"email" character varying(100),
"first_names" character varying(100),
"last_name" character varying(100),
"password" character varying(30)
);
...
CREATE FUNCTION "user_vacations_kludge" (int4 ) RETURNS int4 AS '
begin
return count(*)
from user_vacations v, users u
where u.user_id = $1 and v.user_id = u.user_id
and current_timestamp between v.start_date and v.end_date;
end;' LANGUAGE 'plpgsql';
...
CREATE RULE "_RETusers_alertable" AS ON SELECT TO users_alertable DO INSTEAD SELECT
u.user_id, u.email, u.first_names, u.last_name, u."password" FROM users u WHERE
(u.on_vacation_until ISNULL) OR (u.on_vacation_until < "timestamp"('now'::text)))
AND (u.user_state = 'authorized'::"varchar")) AND ((u.email_bouncing_p ISNULL) OR
(u.email_bouncing_p = 'f'::bpchar))) AND (user_vacations_kludge(u.user_id) = 0));
Although this works fine, 7.1 folds the table + rule down into a single
CREATE VIEW, which comes before the CREATE FUNCTION because that's what
the OID ordering suggests will work. Ugh.
A possible kluge answer is to make pg_dump's OID-ordering of views
depend on the OID of the view rule rather than the view relation.
I am not sure if that would break any cases that work now, however.
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] pg_dump problem
Olivier PRENANT <[EMAIL PROTECTED]> writes: > I have noticed that pg_dump and pg_dumpall could'nt generate correctly > CREATE FUNCTION when function has been created using the form > CREATE FUNCTION foo(x) RETURNS type AS '/foo.so','foo2' LANGUAGE C; > pg_dumps "forgets" the 'foo2' part: that being a pain in the a... when > reloading... This is fixed in 7.1 ... not a lot we can do about 7.0 at this point ... 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] Truncation of object names
[EMAIL PROTECTED] (Nathan Myers) writes: > On Fri, Apr 13, 2001 at 04:27:15PM -0400, Tom Lane wrote: >> Have you thought about simply increasing NAMEDATALEN in your >> installation? If you really are generating names that aren't unique >> in 31 characters, that seems like the way to go ... > We discussed that, and will probably do it (too). > One problem is that, having translated "foo.bar.baz" to "foo_bar_baz", > you have a problem when you encounter "foo.bar_baz" in subsequent code. So it's not really so much that NAMEDATALEN is too short for your individual names, it's that you are concatenating names as a workaround for the lack of schema support. FWIW, I believe schemas are very high on the priority list for 7.2 ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Tag'd, packaged and ready to go ...
Well folks, I just fixed the CVS tags (renamed REL7_1 to REL7_1_BETA and
moved REL7_1 to today) and packaged up the release ... this is it, any new
fixes go into v7.1.1 ... :)
I'm preparing a formal PR/Announce, and will send that out later on this
evening, but want to give some of the mirror sites a chance to update
before doing such ...
If anyone wants to grab a copy of this, make sure there are no outstanding
issues with the packaging itself, please do ...
There are no changes between rc4 and full release, except that D'Arcy
removed a 'beta' comment from the Python interface ... so if you are
running rc4 now, no need to upgrade ...
Unless any major disagreements, I'd like to scheduale v7.1.1 now, for May
1st, at which time I'll do our normal branch for v7.2 ... so, if you are
sitting on any *bug fixes* for v7.1, plesae start shoving them in
effective this email ...
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
[HACKERS] Anyone have any good addresses ... ?
Here is what we've always sent to to date ... anyone have any good ones
to add?
Addresses : [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[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 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] ORDER BY ????
hello everybody, Can you help me? I have POSTGRESQL 7.0.3, I try to create simple view by typing. create view "xx" as select "aa.yy", "bb.yy" from "yy" order by "bb.yy" the problem is that parameter order is not implemented with create view. so how can I create such simple query?? Best regards Marcin ---(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] Dump/restore of views containing select distinct fails
Peter Eisentraut <[EMAIL PROTECTED]> writes: > => create view testview as select relname, 'Constant'::text from pg_class; I assume you meant SELECT DISTINCT there... > => \d testview >View "testview" > Attribute | Type | Modifier > ---+--+-- > relname | name | > ?column? | text | > View definition: SELECT DISTINCT pg_class.relname, 'Constant'::text FROM > pg_class ORDER BY pg_class.relname, 'Constant'::text; > Note how the order by clause is not valid SQL. You get > ERROR: Non-integer constant in ORDER BY Ooops. > I suppose the ORDER BY clause appears because of some weird query parse > tree hackery and is not easy to get rid of. Not without parsetree changes to distinguish explicit from implicit sortlist items (yet another place where we shot ourselves in the foot by not keeping adequate info about the original form of a query...) > Maybe using column numbers > instead of spelling out the select list again would work? Yes, I think that's what we need to do. This particular case could perhaps be handled by allowing non-integer constants to fall through in findTargetlistEntry(), but that solution still fails for regression=# create view vv1 as select distinct f1, 42 from int4_tbl; CREATE regression=# \d vv1 View "vv1" Attribute | Type | Modifier ---+-+-- f1| integer | ?column? | integer | View definition: SELECT DISTINCT int4_tbl.f1, 42 FROM int4_tbl ORDER BY int4_tbl.f1, 42; Basically we should not let the rule decompiler emit any simple constant literally in ORDER BY --- it should emit the column number instead, turning this into SELECT DISTINCT int4_tbl.f1, 42 FROM int4_tbl ORDER BY int4_tbl.f1, 2; (I think we should do this only for literal constants, keeping the more-symbolic form whenever possible.) Will work on it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Anyone have any good addresses ... ?
The Hermit Hacker <[EMAIL PROTECTED]> writes: > Here is what we've always sent to to date ... anyone have any good ones > to add? > > > Addresses : [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED] Freshmeat, linuxtoday. If the release includes RPMs for Red Hat Linux, redhat-announce is also a suitable location. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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] Languages
Hello, everybody I have a new question to you. ;-))) 1. I wrote a database in access an I put there some Polish words like ±¶¿¼. 2. Migrate the base using PGADMIN to Postgresql.0.3 on Solaris 8. 3. What can I do to see that Polish words. Maybe set a codepage or any standard. I need help from you. Best regards. Marcin ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] cvs postgres doesn't compile with libreadline 4.2
debian unstable, i386. upgrade libreadline 4.2 postgres doesn't compile. gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/interfaces/libpq -I../../../src/include -c -o tab-complete.o tab-complete.c tab-complete.c: In function `initialize_readline': tab-complete.c:103: warning: assignment from incompatible pointer type tab-complete.c: In function `psql_completion': tab-complete.c:292: warning: implicit declaration of function `completion_matches' tab-complete.c:292: warning: assignment makes pointer from integer without a cast tab-complete.c:296: warning: assignment makes pointer from integer without a cast tab-complete.c:301: warning: assignment makes pointer from integer without a cast tab-complete.c:309: warning: assignment makes pointer from integer without a cast tab-complete.c:320: warning: assignment makes pointer from integer without a cast tab-complete.c:325: warning: assignment makes pointer from integer without a cast tab-complete.c:332: warning: assignment makes pointer from integer without a cast tab-complete.c:337: warning: assignment makes pointer from integer without a cast tab-complete.c:342: warning: assignment makes pointer from integer without a cast tab-complete.c:347: warning: assignment makes pointer from integer without a cast tab-complete.c:350: warning: assignment makes pointer from integer without a cast tab-complete.c:366: warning: assignment makes pointer from integer without a cast tab-complete.c:371: warning: assignment makes pointer from integer without a cast tab-complete.c:378: warning: assignment makes pointer from integer without a cast tab-complete.c:381: warning: assignment makes pointer from integer without a cast tab-complete.c:392: warning: assignment makes pointer from integer without a cast tab-complete.c:400: warning: assignment makes pointer from integer without a cast tab-complete.c:406: warning: assignment makes pointer from integer without a cast tab-complete.c:410: warning: assignment makes pointer from integer without a cast tab-complete.c:413: warning: assignment makes pointer from integer without a cast tab-complete.c:420: warning: assignment makes pointer from integer without a cast tab-complete.c:423: warning: assignment makes pointer from integer without a cast tab-complete.c:429: warning: assignment makes pointer from integer without a cast tab-complete.c:435: warning: assignment makes pointer from integer without a cast tab-complete.c:440: warning: assignment makes pointer from integer without a cast tab-complete.c:448: warning: assignment makes pointer from integer without a cast tab-complete.c:455: warning: assignment makes pointer from integer without a cast tab-complete.c:460: warning: assignment makes pointer from integer without a cast tab-complete.c:465: warning: assignment makes pointer from integer without a cast tab-complete.c:473: warning: assignment makes pointer from integer without a cast tab-complete.c:478: warning: assignment makes pointer from integer without a cast tab-complete.c:490: warning: assignment makes pointer from integer without a cast tab-complete.c:493: warning: assignment makes pointer from integer without a cast tab-complete.c:496: warning: assignment makes pointer from integer without a cast tab-complete.c:506: warning: assignment makes pointer from integer without a cast tab-complete.c:514: warning: assignment makes pointer from integer without a cast tab-complete.c:521: warning: assignment makes pointer from integer without a cast tab-complete.c:532: warning: assignment makes pointer from integer without a cast tab-complete.c:541: warning: assignment makes pointer from integer without a cast tab-complete.c:545: warning: assignment makes pointer from integer without a cast tab-complete.c:553: warning: assignment makes pointer from integer without a cast tab-complete.c:556: warning: assignment makes pointer from integer without a cast tab-complete.c:559: warning: assignment makes pointer from integer without a cast tab-complete.c:569: warning: assignment makes pointer from integer without a cast tab-complete.c:572: warning: assignment makes pointer from integer without a cast tab-complete.c:578: warning: assignment makes pointer from integer without a cast tab-complete.c:582: warning: assignment makes pointer from integer without a cast tab-complete.c:587: warning: assignment makes pointer from integer without a cast tab-complete.c:592: warning: assignment makes pointer from integer without a cast tab-complete.c:599: warning: assignment makes pointer from integer without a cast tab-complete.c:604: warning: assignment makes pointer from integer without a cast tab-complete.c:606: warning: assignment makes pointer from integer without a cast tab-complete.c:608: warning: assignment makes pointer from integer without a cast tab-complete.c:619: warning: assignment makes pointer from integer without a cast tab-complete.c:622: warning: assignment makes pointer from integer without a cast tab-compl
[HACKERS] 7.1 RPMs
Hi Lamar. What are the plans for RPMs? Do we have an "integrated RPM" which will work with Mandrake, or should I keep carrying along my patches to make the spec file work for now? How are you planning on packaging the hardcopy docs? They are not yet available, but will be Real Soon Now :( - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Anyone have any good addresses ... ?
On Fri, 13 Apr 2001, Bruce Momjian wrote: > > > > Here is what we've always sent to to date ... anyone have any good ones > > to add? > > > > > > Addresses : [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED] > > Do we do freshmeat? Yup ... just submit'd the update ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: [PATCHES] Re: Large Object problems (was Re: JDBC int8 hack)
On Wed, Apr 11, 2001 at 02:57:16AM +, Thomas Lockhart wrote:
> > Alright man, you've got me confused. Are you saying that despite the
> > existance of INT8 as a column type, and PreparedStatement.setLong(), that
> > these ought not be used? If so, there is a really big warning missing
> > from the documentation!
>
> Ah, it just dawned on me what might be happening: Peter, I'm guessing
> that you are thinking of "INT48" or some such, the pseudo-integer array
> type. Kyle is referring to the "int8" 8 byte integer type.
Yes!
> > I guess I'm asking this: I've got an enterprise database runnign 7.0.3
> > ready to go using INT8 primary keys and being accessed through my
> > re-touched JDBC driver. Am I screwed? Is it going to break? If so, I
> > need to fix this all very, very fast.
>
> btw, it might be better to use a syntax like
>
> ... where col = '1234';
>
> or
>
> ... where col = int8 '1234';
>
> If the former works, then that is a bit more generic that slapping a
> "::int8" onto the constant field.
It seems like a wash to me; either way gets the desired result. Tacking
on ::int8 was the quickest. It also seems neater than this:
set(parameterIndex, ("int8 '" + new Long(x)).toString() + "'");
in PreparedStatement.setLong().
> I'd imagine that this could also be coded into the app; if so that may
> be where it belongs since then the driver does not have to massage the
> queries as much and it will be easier for the *driver* to stay
> compatible with applications.
This seems to be the wrong idea to me. The idea is that JDBC allows you
to be a little bit "backend agnostic". It'd be pretty disappointing if
this wasn't true for even the base types. Application programmers should
just call setLong() they're dealing with an 8-byte (Long or long) integer.
It'd be a shame to have a PostgreSQL-specific call to setString("int8 '" +
x.toString() + "'") littering your code. That seems to fly in the face of
everything that JDBC/DBI/ODBC (etc) are about.
--
Kyle.
"I hate every ape I see, from chimpan-A to chimpan-Z" -- Troy McClure
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: New benchmark result
Mark Butler wrote: > I did several tests with functions designed to sum the number 12345 a million > times. The results are as follows (Pentium II 450, Redhat 6.2): > > Postgres PL/PGSQL original numeric:14.8 seconds > Postgres PL/PGSQL modified numeric:11.0 seconds > Postgres PL/PGSQL float8: 10.7 seconds > GNU AWK:2.5 seconds > Oracle PL/SQL number: 2.0 seconds I have a new result: Postgres PL/PGSQL integer: 7.5 seconds I do not know what to attribute the large difference between float8 and int to other than pg_alloc overhead used in the calling convention for float8. Commments? - Mark Butler ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Anyone have any good addresses ... ?
email added, thanks ...
On 13 Apr 2001, Matthew Rice wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Here is what we've always sent to to date ... anyone have any good ones
> > to add?
>
> I think that this is still the moderator's address for comp.os.linux.announce:
>
> [EMAIL PROTECTED]
> --
> matthew rice <[EMAIL PROTECTED]> starnix inc.
> tollfree: 1-87-pro-linuxthornhill, ontario, canada
> http://www.starnix.com professional linux services & products
>
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] Anyone have any good addresses ... ?
Freshmeat updated, Linuxtoday bookmarked ... thanks ;)
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
>
> > On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
> >
> > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > >
> > > > Here is what we've always sent to to date ... anyone have any good ones
> > > > to add?
> > > >
> > > >
> > > > Addresses : [EMAIL PROTECTED],
> > > > [EMAIL PROTECTED],
> > > > [EMAIL PROTECTED],
> > > > [EMAIL PROTECTED],
> > > > [EMAIL PROTECTED],
> > > > [EMAIL PROTECTED],
> > > > [EMAIL PROTECTED],
> > > > [EMAIL PROTECTED],
> > > > [EMAIL PROTECTED]
> > >
> > > Freshmeat, linuxtoday. If the release includes RPMs for Red Hat Linux,
> > > redhat-announce is also a suitable location.
> >
> > do you have email addresses fo freshmeat/linuxtoday? I have 6 web sites
> > that I have bookmarked for announces also, so if you have a good web URL,
> > I'll take those too ...
>
> Seems to be web based (painful):
>
> http://freshmeat.net/faq/view/20/
> http://linuxtoday.com/contribute.php3
>
>
> --
> Trond Eivind Glomsrød
> Red Hat, Inc.
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Anyone have any good addresses ... ?
On Fri, Apr 13, 2001 at 06:32:26PM -0400, Trond Eivind Glomsr?d wrote: > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > > Here is what we've always sent to to date ... anyone have any good ones > > to add? > > > > > > Addresses : [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED] > > Freshmeat, linuxtoday. If the release includes RPMs for Red Hat Linux, > redhat-announce is also a suitable location. Linux Journal: [EMAIL PROTECTED] Freshmeat: [EMAIL PROTECTED] LinuxToday: http://linuxtoday.com/contribute.php3 -- Nathan Myers [EMAIL PROTECTED] ---(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] Anyone have any good addresses ... ?
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote: > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > > Here is what we've always sent to to date ... anyone have any good ones > > to add? > > > > > > Addresses : [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED] > > Freshmeat, linuxtoday. If the release includes RPMs for Red Hat Linux, > redhat-announce is also a suitable location. do you have email addresses fo freshmeat/linuxtoday? I have 6 web sites that I have bookmarked for announces also, so if you have a good web URL, I'll take those too ... as for RPMs, will leave that for Lamar once he's got those ready :) ---(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] Anyone have any good addresses ... ?
The Hermit Hacker <[EMAIL PROTECTED]> writes: > On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote: > > > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > > > > Here is what we've always sent to to date ... anyone have any good ones > > > to add? > > > > > > > > > Addresses : [EMAIL PROTECTED], > > > [EMAIL PROTECTED], > > > [EMAIL PROTECTED], > > > [EMAIL PROTECTED], > > > [EMAIL PROTECTED], > > > [EMAIL PROTECTED], > > > [EMAIL PROTECTED], > > > [EMAIL PROTECTED], > > > [EMAIL PROTECTED] > > > > Freshmeat, linuxtoday. If the release includes RPMs for Red Hat Linux, > > redhat-announce is also a suitable location. > > do you have email addresses fo freshmeat/linuxtoday? I have 6 web sites > that I have bookmarked for announces also, so if you have a good web URL, > I'll take those too ... Seems to be web based (painful): http://freshmeat.net/faq/view/20/ http://linuxtoday.com/contribute.php3 -- Trond Eivind Glomsrød Red Hat, Inc. ---(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] Anyone have any good addresses ... ?
The Hermit Hacker <[EMAIL PROTECTED]> writes: > Here is what we've always sent to to date ... anyone have any good ones > to add? I think that this is still the moderator's address for comp.os.linux.announce: [EMAIL PROTECTED] -- matthew rice <[EMAIL PROTECTED]> starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services & products ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] pg_dump, formats & blobs
Hi
I've been experimenting with 7.1rc4 for a couple of hours. I was messing with
blobs, and the new toast setup worked quite nicely. One thing I especially
liked was the fact that by having pg_dump create a dumpfile in the custom or
tar format, I could also backup all blobs in one go.
Unfortunately, practice was a bit different. Which is why I would like to know
if these functions are intended for general use.
A small log:
sol2:~$ uname -srm
SunOS 5.8 sun4u
sol2:~$ createdb blaat
CREATE DATABASE
sol2:~$ psql -c 'create table test(a oid)' blaat
CREATE
sol2:~$ psql -c "insert into test values(lo_import('/etc/hosts'))" blaat
INSERT 18761 1
sol2:~$ pg_dump -b -Fc -f blaat.bk blaat
sol2:~$ pg_restore -l blaat.bk
;
; Archive created at Sat Apr 14 01:03:02 2001
; dbname: blaat
; TOC Entries: 4
; Compression: -1
; Dump Version: 1.5-2
; Format: CUSTOM
;
;
; Selected TOC Entries:
;
2; 18749 TABLE test mathijs
3; 18749 TABLE DATA test mathijs
4; 0 BLOBS BLOBS
sol2:~$ grep serv /etc/hosts
10.1.8.12 serv2.ilse.nl
10.1.8.10 serv0.ilse.nl
sol2:~$ grep serv blaat.bk
sol2:~$ pg_dump -b -Ft -f blaat.tar blaat
zsh: segmentation fault (core dumped) pg_dump -b -Ft -f blaat.tar blaat
sol2:~$ psql -c 'select version()' blaat
version
---
PostgreSQL 7.1rc4 on sparc-sun-solaris2.8, compiled by GCC 2.95.3
(1 row)
A backtrace reveals the following:
#0 0xff132e5c in strlen () from /usr/lib/libc.so.1
#1 0xff181890 in _doprnt () from /usr/lib/libc.so.1
#2 0xff183a04 in vsnprintf () from /usr/lib/libc.so.1
#3 0x2710c in ahprintf (AH=0x56cd0, fmt=0x430a8 "-- File: %s\n")
at pg_backup_archiver.c:1116
#4 0x2ee90 in _PrintExtraToc (AH=0x56cd0, te=0x5e838) at pg_backup_tar.c:305
#5 0x290e0 in _printTocEntry (AH=0x56cd0, te=0x5e838, ropt=0x681b0)
at pg_backup_archiver.c:1877
#6 0x25470 in RestoreArchive (AHX=0x56cd0, ropt=0x681b0)
at pg_backup_archiver.c:269
#7 0x2ffb8 in _CloseArchive (AH=0x56cd0) at pg_backup_tar.c:840
#8 0x24f68 in CloseArchive (AHX=0x56cd0) at pg_backup_archiver.c:136
#9 0x15128 in main (argc=6, argv=0xffbefcac) at pg_dump.c:1114
What happens is that in line 305 of pg_backup_tar.c, ahprintf is handed a NULL
pointer.
300 static void
301 _PrintExtraToc(ArchiveHandle *AH, TocEntry *te)
302 {
303 lclTocEntry *ctx = (lclTocEntry *) te->formatData;
304
305 ahprintf(AH, "-- File: %s\n", ctx->filename);
306 }
Could this be caused by the fact that IMHO blobs aren't dumped correctly?
Regards,
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
>> Lamar Owen writes: >> >> > One quick note -- since 'R' < 'b', the RC RPM's must be forced to >> > install with --oldpackage, as RPM does a simple strcmp of version >> > numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with >> > --oldpackage if you have a 7.1beta RPM already installed. Couldn't this be fixed (in future releases) with rcX and BetaX? I believe r > B. len morgan ---(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] Anyone have any good addresses ... ?
> > Here is what we've always sent to to date ... anyone have any good ones > to add? > > > Addresses : [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED] I think xshare is dead. -- 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] pg_dump ordering problem (rc4)
At 17:34 13/04/01 -0400, Tom Lane wrote: > >A possible kluge answer is to make pg_dump's OID-ordering of views >depend on the OID of the view rule rather than the view relation. >I am not sure if that would break any cases that work now, however. > This seems good to me; it should be based on the 'oid of the view', and AFAICT, the rule OID should be it. Should I do this? 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: Tag'd, packaged and ready to go ...
> Well folks, I just fixed the CVS tags (renamed REL7_1 to REL7_1_BETA and > moved REL7_1 to today) and packaged up the release ... this is it, any new > fixes go into v7.1.1 ... :) OK, I have some (small) patches for documentation, but afaicr it is not critical. Postscript docs should be completely done in the next few days, with some available almost immediately. The Reference Manual will take the longest, as the jade rtf output causes trouble in M$Word as well as in Applixware :( Did we get all of the ancillary plain text documents generated? - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ORDER BY ????
On Wed, 11 Apr 2001, Marcin Wasilewski wrote: > hello everybody, > Can you help me? > > I have POSTGRESQL 7.0.3, > I try to create simple view by typing. > > create view "xx" as select "aa.yy", "bb.yy" from "yy" order by "bb.yy" > > the problem is that parameter order is not implemented with create view. > so how can I create such simple query?? You probably want the order by on the select queries on "xx". I believe order bys are only legal on cursor creation and direct select statements. ---(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] pg_dump ordering problem (rc4)
> At 17:34 13/04/01 -0400, Tom Lane wrote: > > > >A possible kluge answer is to make pg_dump's OID-ordering of views > >depend on the OID of the view rule rather than the view relation. > >I am not sure if that would break any cases that work now, however. > > > > This seems good to me; it should be based on the 'oid of the view', and > AFAICT, the rule OID should be it. Should I do this? The view oid is certainly better than the base relation oid. -- 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] Anyone have any good addresses ... ?
> > Here is what we've always sent to to date ... anyone have any good ones > to add? > > > Addresses : [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED] Do we do freshmeat? -- 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
[HACKERS] Re: 7.1 RPMs
Thomas Lockhart wrote: > Hi Lamar. What are the plans for RPMs? Do we have an "integrated RPM" > which will work with Mandrake, or should I keep carrying along my > patches to make the spec file work for now? I haven't addressed that as yet. Is it safe to assume that -ffast-math should be Considered Harmful in the RPM_OPT_FLAGS? Is -ffast-math _ever_ a Good Thing for our routines? I can easily enough strip out -ffast-math from the flags for all cases (xarg -n 1 grep -v ffast-math|xargs is your friend). While I don't plan on following the Mandrake Way WRT repackaging our tarball with bzip2, the source RPM should use whatever compression for the man pages that the buildrootpolicy for that distribution supplies. > How are you planning on packaging the hardcopy docs? They are not yet > available, but will be Real Soon Now :( In the postgresql-docs subpackage, along with the SGML source. The html built docs made from the SGML source is still going into the main tarball, as they are nice and browseable in their standard location. If I release a -1 RPM without the hardcopy, I can release a -2 with I have a couple of patches from Trond to integrate, and a decision to make regarding the contribs: should all the contrib tree go into one big RPM (860KB or so),or should each contrib directory get its own RPM (reminiscent of the PM3 binary RPM monster)? One patch from Trond has been duplicated by Karl: which patch allows building as non-root again. There's also a question about the Python client -- it would be good if someone who has downloaded one of the RC RPM's could test that, as I'm not a snake charmer. :-) Also, I need either a standard way to build the java stuff (meaning my own JDK that is reasonably standard by consensus -- kaffe ships with RedHat 7.0 -- isthat an acceptable JDK-substitute?) or someone needs to package 7.1 JDBC jars for my packaging pleasure. I'm running low enough on disk space on my devel machines (one of which is a notebook) to make my own JDK a second choice. Oliver, what are doing with the JDBC client? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
NetBSD "Bad address" failure (was Re: [HACKERS] Third call for platform testing)
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>>
>> "Bad address"? That seems pretty bizarre.
> This is obviously something that shows up on _some_ NetBSD platforms.
> The above was on sparc64, but that same problem is the only one I see
> in the regression testing on NetBSD/vax that isn't just different
> floating point (the VAX doesn't have IEEE), different ordering of
> (unordered) collections or different wording of strerror() output.
> NetBSD/i386 doesn't have the "Bad address" problem.
After looking into it, I find that the problem is this: Postgres, or at
least the hash-index part of it, expects to be able to lseek() to a
position past the end of a file and then get a non-failure return from
read(). (This happens indirectly because it uses ReadBuffer for blocks
that it has never yet written.) Given the attached test program, I get
this result on my own machine:
$ touch z -- create an empty file
$ ./a.out z 0 -- read at offset 0
Read 0 bytes
$ ./a.out z 1 -- read at offset 8K
Read 0 bytes
Presumably, the same result appears everywhere else that the regress
tests pass. But NetBSD 1.5T gives
$ touch z
$ ./a.out z 0
Read 0 bytes
$ ./a.out z 1
read: Bad address
$ uname -a
NetBSD varg.i.eunet.no 1.5T NetBSD 1.5T (VARG) #4: Thu Apr 5 23:38:04 CEST 2001
[EMAIL PROTECTED]:/usr/src/sys/arch/vax/compile/VARG vax
I think this is indisputably a bug in (some versions of) NetBSD. If I
can seek past the end of file, read() shouldn't consider it a hard error
to read there --- and in any case, EFAULT isn't a very reasonable error
code to return. Since it seems not to be a widespread problem, I'm not
eager to change the hash code to try to avoid it.
regards, tom lane
#include
#include
#include
#include
int main (int argc, char** argv)
{
char *fname = argv[1];
int fd, readres;
long seekres;
char buf[8192];
fd = open(fname, O_RDONLY, 0);
if (fd < 0)
{
perror(fname);
exit(1);
}
seekres = lseek(fd, atoi(argv[2]) * 8192, SEEK_SET);
if (seekres < 0)
{
perror("seek");
exit(1);
}
readres = read(fd, buf, sizeof(buf));
if (readres < 0)
{
perror("read");
exit(1);
}
printf("Read %d bytes\n", readres);
exit(0);
}
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_dump ordering problem (rc4)
At 21:15 13/04/01 -0400, Bruce Momjian wrote: >> At 17:34 13/04/01 -0400, Tom Lane wrote: >> > >> >A possible kluge answer is to make pg_dump's OID-ordering of views >> >depend on the OID of the view rule rather than the view relation. >> >I am not sure if that would break any cases that work now, however. >> > >> >> This seems good to me; it should be based on the 'oid of the view', and >> AFAICT, the rule OID should be it. Should I do this? > >The view oid is certainly better than the base relation oid. > Since I'm in pg_dump at the moment, I'll make the change... 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump, formats & blobs
At 01:14 14/04/01 +0200, Mathijs Brands wrote: ... >sol2:~$ pg_dump -b -Fc -f blaat.bk blaat >sol2:~$ pg_restore -l blaat.bk ... >; >; Archive created at Sat Apr 14 01:03:02 2001 ... This all looks fine. >sol2:~$ pg_dump -b -Ft -f blaat.tar blaat >zsh: segmentation fault (core dumped) pg_dump -b -Ft -f blaat.tar blaat This is less good. It's caused by the final part of TAR output, which also dumps a plain SQL script for reference (not actually ever used by pg_restore). I will fix this in CVS; ctx->filename is set to null for this script, and my compiler outputs '(null)', which is very forgiving of it. > >Could this be caused by the fact that IMHO blobs aren't dumped correctly? > Is there some other problem with BLOBs that you did not mention? AFAICT, this is only a problem with TAR output (an will be fixed ASAP). 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Tag'd, packaged and ready to go ...
Thomas Lockhart writes: > Did we get all of the ancillary plain text documents generated? Yes, unless you have changes for the installation instructions, the release history, or the regression test procedure. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump, formats & blobs
On Sat, Apr 14, 2001 at 11:44:18AM +1000, Philip Warner allegedly wrote:
> At 01:14 14/04/01 +0200, Mathijs Brands wrote:
> ...
> >sol2:~$ pg_dump -b -Fc -f blaat.bk blaat
> >sol2:~$ pg_restore -l blaat.bk
> ...
> >;
> >; Archive created at Sat Apr 14 01:03:02 2001
> ...
>
> This all looks fine.
Hmm, I can only agree.
sol2:~$ cksum postgresql-7.1rc4.tar.gz
615403298088934 postgresql-7.1rc4.tar.gz
sol2:~$ dropdb blaat
DROP DATABASE
sol2:~$ createdb blaat
CREATE DATABASE
sol2:~$ psql -c 'create table test(a oid)' blaat
CREATE
sol2:~$ psql -c "insert into test
values(lo_import('/export/home/mathijs/postgresql-7.1rc4.tar.gz'))" blaat
INSERT 22753 1
sol2:~$ pg_dump -b -Fc -f blaat.bk blaat
sol2:~$ psql -c 'drop table test ; vacuum' blaat
VACUUM
sol2:~$ pg_restore -d blaat blaat.bk
sol2:~$ psql -c "select lo_export(test.a, '/export/home/mathijs/testfile') from test"
blaat
lo_export
---
1
(1 row)
sol2:~$ cksum testfile
61540329 8088934 testfile
sol2:~$ pg_restore -l blaat.bk
;
; Archive created at Sat Apr 14 03:59:02 2001
; dbname: blaat
; TOC Entries: 4
; Compression: -1
; Dump Version: 1.5-2
; Format: CUSTOM
;
;
; Selected TOC Entries:
;
2; 18792 TABLE test mathijs
3; 18792 TABLE DATA test mathijs
4; 0 BLOBS BLOBS
I couldn't get blobs to be restored correctly (must've been doing
something wrong). When something doesn't work, never question your
own methods ;)
> >sol2:~$ pg_dump -b -Ft -f blaat.tar blaat
> >zsh: segmentation fault (core dumped) pg_dump -b -Ft -f blaat.tar blaat
>
> This is less good. It's caused by the final part of TAR output, which also
> dumps a plain SQL script for reference (not actually ever used by
> pg_restore). I will fix this in CVS; ctx->filename is set to null for this
> script, and my compiler outputs '(null)', which is very forgiving of it.
It's more likely that your C library is more forgiving (ie. Open Source OS?).
> >Could this be caused by the fact that IMHO blobs aren't dumped correctly?
> >
>
> Is there some other problem with BLOBs that you did not mention? AFAICT,
> this is only a problem with TAR output (an will be fixed ASAP).
Yeah, they're not fool proof ;)
Sorry about the false alarm. I was convinced restoring blobs
didn't work correctly.
Regards,
Mathijs
--
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---(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: 7.1 RPMs
Lamar Owen writes: > In the postgresql-docs subpackage, along with the SGML source. Why would you want to ship the source? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: 7.1 RPMs
On Fri, 13 Apr 2001, Peter Eisentraut wrote: > Lamar Owen writes: > > In the postgresql-docs subpackage, along with the SGML source. > Why would you want to ship the source? For those with SGML tools and viewers, who might like to build hardcopy of their own. Frankly, it was an easy thing to do; had been done; and I saw no real reason to stop doing it. I _does_ take up a little space, however. The SGML source had been distributed as part of the main RPM, prior to 7.1. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: NetBSD "Bad address" failure (was Re: [HACKERS] Third call for platform testing)
I wrote: > I think this is indisputably a bug in (some versions of) NetBSD. If I > can seek past the end of file, read() shouldn't consider it a hard error > to read there --- and in any case, EFAULT isn't a very reasonable error > code to return. Since it seems not to be a widespread problem, I'm not > eager to change the hash code to try to avoid it. I forgot to mention a possible contributing factor: the files involved were NFS-mounted, in the case I was looking at. So this may be an NFS problem more than a NetBSD problem. Anyone want to try the given test case on NFS-mounted files on other systems? 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])
[HACKERS] Possible explanation for readline configuration problems
We've gotten several different reports lately of peculiar compilation errors and warnings involving readline in 7.1. They look like configure is actively doing the wrong thing --- for example, how could we see reports like this: tab-complete.c:734: `filename_completion_function' undeclared (first use in this function) tab-complete.c:734: (Each undeclared identifier is reported only once tab-complete.c:734: for each function it appears in.) when the code makes a point of providing a declaration for filename_completion_function if configure didn't see it in the headers? After eyeballing the code I think I have a theory. psql/input.h will preferentially include , not , if both HAVE_READLINE_READLINE_H and HAVE_READLINE_H are defined. But the tests in configure make the opposite choice! Maybe the people who are having trouble have two different versions of readline header files visible at those two names, leading to configure's results being wrong for the header file that input.h actually selects? In normal situations this still wouldn't matter because configure only defines one of the two symbols HAVE_READLINE_READLINE_H and HAVE_READLINE_H. BUT: suppose someone runs configure, then installs a newer libreadline and runs configure again? I think caching of configure results could lead to both symbols becoming defined, if both headers are out there. It's a bit of a reach, but I'm having a hard time seeing how configure could produce the wrong results otherwise. Thoughts? Andrea and Kevin, what do your src/include/config.h files have for these symbols? 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])
[HACKERS] Postmaster fatal defect - pl/pgsql return type conversion
Using the head branch, when I execute the following in psql on Redhat 6.2 i386, the postmaster process dies gives an error message about corrupted shared memory: --begin--- create function bug1(integer) returns numeric as ' begin return $1; end;' language 'plpgsql'; select bug1(5); ---end--- Any ideas? - Mark Butler ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Possible explanation for readline configuration problems
> We've gotten several different reports lately of peculiar compilation > errors and warnings involving readline in 7.1. They look like configure > is actively doing the wrong thing --- for example, how could we see > reports like this: > > tab-complete.c:734: `filename_completion_function' undeclared (first use in this >function) > tab-complete.c:734: (Each undeclared identifier is reported only once > tab-complete.c:734: for each function it appears in.) > > when the code makes a point of providing a declaration for > filename_completion_function if configure didn't see it in the headers? > > After eyeballing the code I think I have a theory. psql/input.h will > preferentially include , not , if both > HAVE_READLINE_READLINE_H and HAVE_READLINE_H are defined. But the tests > in configure make the opposite choice! Maybe the people who are having > trouble have two different versions of readline header files visible at > those two names, leading to configure's results being wrong for the > header file that input.h actually selects? This sounds like an excellent guess. Hard to imagine how readline has gotten such a bizarre list of configurations. -- 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])
[HACKERS] Re: Possible explanation for readline configuration problems
I wrote: > ... how could we see reports like this: > tab-complete.c:734: `filename_completion_function' undeclared (first use in this >function) > when the code makes a point of providing a declaration for > filename_completion_function if configure didn't see it in the headers? Never mind ... I pulled down readline 4.2, and the answer is depressingly clear: the Readline boys have decided to rename filename_completion_function to rl_filename_completion_function. This graphically illustrates the fundamental bogosity of AC_EGREP_HEADER: it still finds a match, blithely ignoring the fact that it matched only part of an identifier. Most of the other compiler warnings that we've been hearing about arise because the readline headers have been const-ified. Suppressing these warnings across both old and new readlines will be a pain in the neck :-( regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] 7.1-1 RPMset uploading...
Ok, the 7.1-1 RPMset for Red Hat 6.2 has been uploaded. The Source RPM is up, in RPM 3 format. Red Hat 7.0 RPMs are on their way. (whew). 28.8K is slow when uploading 8MB worth of binary RPMset -- as it was when downloading the source RPM from my 6.2 build machine, located at work and hung off a T1, to my 7.0 home machine. If you have any queasiness about installing binary RPM's -- then rebuild from the source RPM. You will need to review the new REBUILDING FROM SOURCE RPM section in README.rpm-dist, packaged in the src.rpm (as well as in the main binary RPM), then review the instructions and tags in the spec file. You are able to build the package with pieces not built -- things such as the tcl, tk, perl, odbcm python, and jdbc clients, as well as the test package, are optional. The main, libs, server, docs, ans contrib subpackages are not optional at this time. When 7.1 is officially announced, I'll put together an 'official' RPM announcement (unless you want to mention that as part of the main announcement, Marc) that I'll post on the various places as well. Regression passes with this RPMset on both RH 6.2 and RH 7.0 with no special options or environment variable (or locale sysconfig file) funniness. If you find obvious errors, please let me know so I can prep a '-2' set quickly -- however, it will need to be brought to my attention by tomorrow night, or on Monday, as I do not plan on doing any RPM work on Easter. Nor do I really plan on doing any RPM work tomorrow night -- but I will if need be. No hardcopy docs are included, and the contrib package is One Big Package at the moment. Please try various combinations of installations, as the dependencies in this set are new. NOTE TO LINUX DISTRIBUTION PEOPLE ON THIS LIST: I am in process of changing the focus of the PostgreSQL.org RPMset from a do-all-end-all-be-all RPM to a 'template' RPMset, that will work for most everyone but is meant as a foundation from which to build your distribution-specific RPMset for PostgreSQL. I would request that your distribution-specifc RPMset be flagged as such if it deviates from what is in this RPMset -- change the release number to associate it with your distro, such as the 'mdk' added to all Mandrake RPMs flag those RPM's as belonging to Mandrake. The source RPM should build as-is on any distribution that is reasonably close to LSB compliant and uses an RPM of at least version 3.0.4 -- 3.0.5 or greater is very much preferred. I will try to refrain from using RPM 4 specific features until my list of supported distributions no longer includes Red Hat 6.2, which has RPM 3.0.5 as its errata update release -- but you will NEED RPM 3.0.5 to rebuild, more than likely. I would also like to receive any patches to any files in the RPM that you modify in any way -- if those changes would be useful to the generic RPMset. Please read the README.rpm-dist file packaged in both the source RPM and the main package. For your convenience, that file is attached to this message. A minimal PostgreSQL server installation will need the main package, the libs subpackage, and the server subpackage to function. Client only installations may pick and choose -- eg, if you use the Python client exclusively, then you only need the libs and python subpackages. BIG NOTE: Before upgrading your previous PostgreSQL installation, be sure you understand how the upgrade process works. Make absolutely SURE that you have the previous version's RPMset to reinstall if you need to do so, and take a full ASCII pg_dumpall (or your preferred backup method, such as iterative pg_dumps as discussed on this list). The semi-automatic process, when it works, works well. It has been known to not work, as it is attempting to do a very hard thing. BE SURE YOU HAVE A KNOWN GOOD BACKUP. PLEASE -- for the sake of YOUR data. If you need large objects migrated, you need to compile the contributed pg_dumplo utility yourself for 7.0.x and dump those large objects FIRST. There are instances of data dumped with 7.0 not restoring properly with 7.1 (as documented on this list) -- have a copy of you BINARY tree stored offline so that you can go back to your previous version if the need arises. Otherwise, enjoy the RPMset :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 README.rpm-dist - Version 3.2, for PostgreSQL 7.1 Lamar Owen <[EMAIL PROTECTED]> Updated by [EMAIL PROTECTED] for 7.0.2 and to use FHS compliant doc paths Updated to 7.0.3 and to reflect more of a cross-distribution slant. Updated to 7.1 - Contents: 1.) Introduction, QuickStart, and credits 2.) PostgreSQL RPM packages and rationale 3.) Upgrading from an older version of PostgreSQL without losing data. 4.) Regression Testing 5.) Starting postmaster automatically on startup 6.) Grand Unified Configuration(GUC) File. 7.) Rebuilding
[HACKERS] Re: Postmaster fatal defect - False alarm
Mark Butler wrote: > > Using the head branch, when I execute the following in psql on Redhat 6.2 > i386, the postmaster process dies gives an error message about corrupted > shared memory: I just updated to REL7_1 and recompiled and the problem has gone away. - Mark Butler ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Postmaster fatal defect - pl/pgsql return type conversion
Mark Butler <[EMAIL PROTECTED]> writes: > Using the head branch, when I execute the following in psql on Redhat 6.2 > i386, the postmaster process dies gives an error message about corrupted > shared memory: Works for me ... when was your last update? 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] cvs postgres doesn't compile with libreadline 4.2
andrea gelmini <[EMAIL PROTECTED]> writes: > debian unstable, i386. > upgrade libreadline 4.2 > postgres doesn't compile. Seems strange. Did you re-run PG's configure after installing libreadline? Are you sure that the include (.h) files found by configure match the library (.a or .so) file? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
