[HACKERS] Re: OID unsigned long long
Tom Lane wrote: mlw [EMAIL PROTECTED] writes: Aside from adding %llu to all the %u everywhere an OID is used in a printf, and any other warnings, are there any other things I should be specially concerned about? FE/BE protocol, a/k/a client/server interoperability. Flagging a database so that a backend with the wrong OID size won't try to run in it. Alignment --- on machines where long long has to be 8-byte aligned, TOAST references as presently constituted will crash, because varlena datatypes in general are only 4-byte aligned. There are more, but that will do for starters. I will have to look at that, thanks. BTW, I think #ifdef would be a totally unworkable way to attack the format-string problem. The code clutter of #ifdef'ing everyplace that presently uses %u would be a nightmare; the impact on internationalization files would be worse. And don't forget that %llu would be the right thing on only some machines; others like %qu, and DEC Alphas think %lu is just fine. What do you think of making two entries in the various printf strings, and using macros to split up an OID, as: printf(OID: %u:%u, HIGHOID(od) LOWOID(oid)) That may satisfy your concern for #ifdef's everywhere, and it could mean I could submit my patches back without breaking any code, so PostgreSQL could be closer to a 64 bit OID. The only workable answer I can see is for the individual messages to use some special code, maybe %O for Oid. The problem is then (a) translating this to the right platform-dependent thing, and (b) persuading gcc to somehow type-check the elog calls anyway. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 5-4-3-2-1 Thunderbirds are GO! http://www.mohawksoft.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Surviving transaction-ID wraparound, take 2
Tom Lane wrote: Horst Herb [EMAIL PROTECTED] writes: On Tuesday 14 August 2001 02:25, you wrote: I still think that expanding transaction IDs (XIDs) to 8 bytes is no help. But what about all of us who need to establish a true long term audit trail? For us, still the most elegant solution would be a quasi unlimited supply of unique row identifiers. 64 bit would be a huge help (and will be ubiquitous in a few years time anyway). Uh, that has nothing to do with transaction identifiers ... And he who needs that kind of long term row identifiers would be better off with 8-byte sequences anyway - IMNSVHO. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Help with Vacuum Failure
Hello, I'm having a problem vacuum a table and I didn't see an answer using
the fts engine.
I have two questions:
1) Is this a big problem, can it be fixed, do I have to dump / restore this
table?
2) I found this problem from my nightly cron driven vacuum -a -z. When it
hits this error the entire vacuumdb process stops immediately thus skipping
any remaining databases. Should it do this? Or should it continue on and
vacuum the other databases?
Here is the error:
cms_beau=# vacuum hits; (It works without the analyze phase of backup.)
VACUUM
cms_beau=# VACUUM verbose analyze hits;
NOTICE: --Relation hits--
NOTICE: Pages 8389: Changed 0, reaped 2, Empty 0, New 0; Tup 834575: Vac 0,
Keep/VTL 4/4, Crash 0, UnUsed 6, MinLen 52, MaxLen 121; Re-using:
Free/Avail. Space 376/64; EndEmpty/Avail. Pages 0/1. CPU 0.34s/0.05u sec.
NOTICE: Index hits_id_key: Pages 1831; Tuples 834575: Deleted 0. CPU
0.11s/0.56u sec.
NOTICE: Rel hits: Pages: 8389 -- 8389; Tuple(s) moved: 0. CPU 0.00s/0.00u
sec.
NOTICE: --Relation pg_toast_6742393--
NOTICE: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0,
Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail.
Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec.
NOTICE: Index pg_toast_6742393_idx: Pages 1; Tuples 0. CPU 0.00s/0.00u sec.
NOTICE: Analyzing...
ERROR: MemoryContextAlloc: invalid request size 4294079565
cms_beau=#
Additional information:
sort_mem = 16384
shared_buffers = 8192
cms_beau=# select version();
version
-
PostgreSQL 7.1.2 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)
cms_beau=# \d hits
Table hits
Attribute | Type | Modifier
-+--+---
id | integer | not null default
nextval('hits_id_seq'::text)
operator_id | integer |
connected | timestamp with time zone | default 'now'
page| text |
Index: hits_id_key
cms_beau=# select count(*) from hits;
count
834539
(1 row)
Please let me know if there is any other information you need.
Thank you much,
Matt O'Connor
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] To be 7.1.3 or not to be 7.1.3?
Oleg Bartunov [EMAIL PROTECTED] writes: If we decide to release 7.1.3 I'd like to see our patch for contrib/intarray too. Which one? 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] int8 sequences --- small implementation problem
Jan Wieck [EMAIL PROTECTED] writes:
And he who needs that kind of long term row identifiers would
be better off with 8-byte sequences anyway - IMNSVHO.
Indeed. I've been looking at switching sequences to be int8, and I see
just one little problem, which is to uphold the promise that they'll
still work as if int4 on a machine that has no int64 C datatype.
The difficulty is that sequence.h has
typedef struct FormData_pg_sequence
{
NameDatasequence_name;
int32 last_value;
int32 increment_by;
int32 max_value;
int32 min_value;
int32 cache_value;
int32 log_cnt;
charis_cycled;
charis_called;
} FormData_pg_sequence;
If I just change int32 to int64 here, all is well on machines where
sizeof(int64) is 8. But if there's no 64-bit C datatype, int64 is
typedef'd as long int, so sizeof(int64) is only 4. Result: the struct
declaration won't agree with the heaptuple layout --- since the tuple
routines will believe that the datatype of these columns has size 8.
What I need is a way to pad the struct declaration so that it leaves
8 bytes per int64 column, no matter what. I thought of
typedef struct FormData_pg_sequence
{
NameDatasequence_name;
int64 last_value;
#ifdef INT64_IS_BUSTED
int32 pad1;
#endif
int64 increment_by;
#ifdef INT64_IS_BUSTED
int32 pad2;
#endif
int64 max_value;
#ifdef INT64_IS_BUSTED
int32 pad3;
#endif
int64 min_value;
#ifdef INT64_IS_BUSTED
int32 pad4;
#endif
int64 cache_value;
#ifdef INT64_IS_BUSTED
int32 pad5;
#endif
int64 log_cnt;
#ifdef INT64_IS_BUSTED
int32 pad6;
#endif
charis_cycled;
charis_called;
} FormData_pg_sequence;
This would work, I think, but my goodness it's an ugly solution.
Has any hacker got a better one?
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: Use int8 for int4/int2 aggregate accumulators?
Peter Eisentraut [EMAIL PROTECTED] writes: create function rtest_viewfunc1(int4) returns int4 as 'select count(*) from rtest_view2 where a = $1' language 'sql'; + ERROR: return type mismatch in function: declared to return integer, returns bigint Maybe instead of testing for strict equality of the types, test for compatibility. We could try to force-convert the result of an SQL function to the right thing, I suppose, but I'm worried that that might mask programmer errors more than it helps. On the other hand, the equivalent forced conversion happens already in plpgsql functions; it's only SQL-language functions that are so picky. Maybe your idea is good. Anyone else have an opinion? 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] Rename config.h to pg_config.h?
Bruce Momjian [EMAIL PROTECTED] writes: I vote for ignore. Don't tons of projects have a config.h file? That's exactly why there's a problem. We are presently part of the problem, not part of the solution. But we only search our source and other includes. Who installs a config.h into publicly-readable /include directory? Oh, I see we do. Yes, I guess we should change 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] RFC: Inserting multiple values via INSERT ... VALUES ...
There are currently a bunch of items on the Todo relating to SQL INSERT statements, one of which is allowing INSERTs of the following form: INSERT INTO tab [(c1, c2, ...)] VALUES (x1, y1, ...), (x2, y2, ...), ... I had written a quick 'n dirty patch that accomplished this by splitting an INSERT of multiple tuples into multiple individual INSERT statements. However, this approach was not the right way to go, and so I would like to propose the following as a plan for getting implementing the feature: Coming out of the parser (modified to handle the new syntax), an InsertStmt variable will hold a list of lists of ResTargets. These lists of ResTargets will be transformed one by one into lists of TargetEntry's. The transformed lists would be kept in the Query node that represents the INSERT statement in a new structure member. With the Result node, PostgreSQL currently has support in the executor for retrieving a single tuple that is not stored in any base relation. When doing an INSERT of a single tuple via VALUES, the current scheme suffices. However, for inserting multiple tuples via INSERT, the use of the Result node doesn't work, AFAICS. While it should be possible to modify the Result node to handle multiple tuples, I would rather not use Result as Result is also used for constant qualifications. It seems cleaner to have a seperate node structure that deals with tuples that have no real base relation; there would be no need to deal with extra cruft in Result-related functions. I would like to add a new executor node called Values (suggestions for a better name are welcome -- there is already a Value node) that would replace the use of Result for insert statements. A tuple would just be a List of TargetEntry's (like what Result currently does). The Values node would just keep a List of those and when asked for a tuple, would return the next element on the List. It would return NULL when done. The planner would need to know when to create one -- that can be done query_planner() as a call to a make_values() function if query-valuesList is not null. Also, at some point, it would be nice to put together a new statement node type that represents the SQL query expression. This node would be used everywhere that a query expression could be used, hiding the complexity of having to deal with either a SELECT statement or a VALUES clause. For example, the parser rule for INSERT statements would be simplified as well as the transformInsertStmt function. I haven't thought about this much though. I would like to get multiple insertion working first before looking at simplification. Comments? Liam -- Liam Stewart :: Red Hat Canada, Ltd. :: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RFC: Inserting multiple values via INSERT ... VALUES ...
Liam Stewart [EMAIL PROTECTED] writes: While it should be possible to modify the Result node to handle multiple tuples, I would rather not use Result as Result is also used for constant qualifications. If you don't want to extend Result, I'd suggest generating a plan that is an Append of Result nodes. There's no need to add a new node type. Personally I wouldn't have a problem with allowing Result to handle a list of targetlists, though. It's already capable of returning multiple rows (when there's a function-returning-set in the targetlist) so I don't find multiple targetlists to be that much of an uglification. Also, at some point, it would be nice to put together a new statement node type that represents the SQL query expression. This node would be used everywhere that a query expression could be used, hiding the complexity of having to deal with either a SELECT statement or a VALUES clause. For example, the parser rule for INSERT statements would be simplified as well as the transformInsertStmt function. The present handling of INSERT/SELECT is really really ugly. The whole querytree structure desperately needs to be rethought, actually. You can find some theorizing about what to do in the mail list archives, but we're still far from having a detailed plan. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Fwd: PostgreSQL Bugzilla
[Forward to pgsql-announce if appropriate. --Dave] Alright, I have gone ahead and posted what I have to date regarding the port of Bugzilla to PostgreSQL that I have been working on. Give it a try and let me know what I can improve on and what you think. It is dependent on version 7.1.2 of PostgreSQL which is the latest version available from www.postgresql.org. There is a README.postgresql file that gives a little info on how to get it going and some changes that had to be made to get it to work so far. One note, buglist.cgi is still not fully operation but will do some simple queries. I am working on getting that working in the next few days. I will also make a release available in the next few weeks that has some of the look and feel changes incorporated in similar to the redhat version of Bugzilla for any interested. ftp://people.redhat.com/dkl/pgzilla-latest.tar.gz Thanks -- --- David Lawrence [EMAIL PROTECTED] Red Hat Quality Assurance --- www.redhat.com ftp.redhat.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] int8 sequences --- small implementation problem
Tom Lane wrote:
[clip]
This would work, I think, but my goodness it's an ugly solution.
Has any hacker got a better one?
regards, tom lane
How about:
#ifdef INT64_IS_BUSTED
#define int64aligned(name) int32 name##_; int64 name
#else
#define int64aligned(name) int64 name
#endif
typedef struct FormData_pg_sequence
{
NameDatasequence_name;
int64aligned(last_value);
int64aligned(increment_by);
int64aligned(max_value);
int64aligned(min_value);
int64aligned(cache_value);
int64aligned(log_cnt);
charis_cycled;
charis_called;
} FormData_pg_sequence;
Neil
--
Neil Padgett
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300,
Toronto, ON M4P 2C9
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] int8 sequences --- small implementation problem
Joe Conway [EMAIL PROTECTED] writes: What I need is a way to pad the struct declaration so that it leaves 8 bytes per int64 column, no matter what. I thought of What if you defined int64 as a union made up of one long int member and one 8 byte char member, and then always refer to the long int? Well, that'd remove the notational ugliness from the struct definition, at the cost of adding it to the code that uses the struct. I think I'd prefer to uglify the struct and keep the code simple. But it's a good thought. 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] int8 sequences --- small implementation problem
Serguei Mokhov [EMAIL PROTECTED] writes: This would work, I think, but my goodness it's an ugly solution. Is anything wrong with just having two int32 per value for this case? Well, we do want it to be int64 on machines where int64 is properly defined. Or are you suggesting #ifdef INT64_IS_BUSTED int32 last_value; int32 pad1; #else int64 last_value; #endif That does seem marginally more robust, now that you mention it... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Forcing GiST index to be used
I have a custom datatype (the PostGIS geometry type), which I have indexed using a GiST index. The problem is, its difficult to get PostgreSQL to actually use the GiST index. The only way I can get it to be used is by 'set enable_seqscan = off', which seems a bit cheezy. What am I missing? Do I have to make some sort of amcostestimate() function or something? thanks, dave ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] int8 sequences --- small implementation problem
On Tue, 14 Aug 2001, Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: And he who needs that kind of long term row identifiers would be better off with 8-byte sequences anyway - IMNSVHO. What I need is a way to pad the struct declaration so that it leaves 8 bytes per int64 column, no matter what. I thought of This would work, I think, but my goodness it's an ugly solution. Has any hacker got a better one? The only thing I could think of is using a struct to hide the padding details instead of directly using int64, but then you'd have to add a '.value' or something to the references. I'm not sure that's really any cleaner. ---(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] To be 7.1.3 or not to be 7.1.3?
let me know once you are complete, and i'll wrap her up ... On Tue, 14 Aug 2001, Bruce Momjian wrote: I will get on this today. [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: That's a couple of days ago now... anything happening? Bruce is evidently waiting on Hiroshi's confirmation that he's done applying his back-patches. I believe he is, though; he did apply what I thought was the patch he had in mind. Bruce, have you finished the documentation updates, or is that still open? You could probably get that done while waiting for Hiroshi's answer... 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]) -- 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] To be 7.1.3 or not to be 7.1.3?
On Tuesday 07 August 2001 14:56, Tom Lane wrote: Ok. This is the second time I have seen this message -- but this one is delayed by a week. Marc? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] int8 sequences --- small implementation problem
typedef struct FormData_pg_sequence
{
NameData sequence_name;
int32 last_value;
int32 increment_by;
int32 max_value;
int32 min_value;
int32 cache_value;
int32 log_cnt;
char is_cycled;
char is_called;
} FormData_pg_sequence;
If I just change int32 to int64 here, all is well on machines where
sizeof(int64) is 8. But if there's no 64-bit C datatype, int64 is
typedef'd as long int, so sizeof(int64) is only 4. Result: the struct
declaration won't agree with the heaptuple layout --- since the tuple
routines will believe that the datatype of these columns has size 8.
What I need is a way to pad the struct declaration so that it leaves
8 bytes per int64 column, no matter what. I thought of
What if you defined int64 as a union made up of one long int member and
one 8 byte char member, and then always refer to the long int?
-- Joe
---(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: [gnue-geas] Re: Proposal: [HACKERS] OID wraparound: summary and proposal
Neil Tiffin wrote: I have not even considered multiple database servers running different database, which is our design goal. In this case we would like to have a slimmed down (and blazingly fast) PostgreSQL server in which we manage the uid in our middleware. This is because the uid must be unique accross all servers and database vendors. (I don't claim to be a database guru, so if we are all wet here please feel free to help correct our misunderstandings.) I am not 100% sure, but I would believe that the oid/uid/whatever_we_call_it only has to be unique within the table. At least as long as you don't exchange data between different databases. As soon as you transfer data from db a to db b, it's good to have an object id that is unique in the world. -- Reinhard Mueller GNU Enterprise project http://www.gnue.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] int8 sequences --- small implementation problem
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
Sent: Tuesday, August 14, 2001 10:09 AM
typedef struct FormData_pg_sequence
{
NameData sequence_name;
int64 last_value;
#ifdef INT64_IS_BUSTED
int32 pad1;
[snip]
} FormData_pg_sequence;
This would work, I think, but my goodness it's an ugly solution.
Is anything wrong with just having two int32 per value for this case?
typedef struct FormData_pg_sequence
{
int32 last_value;
int32 pad1;
...
} FormData_pg_sequence;
S.
---(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: Use int8 for int4/int2 aggregate accumulators?
Peter Eisentraut [EMAIL PROTECTED] writes: create function rtest_viewfunc1(int4) returns int4 as 'select count(*) from rtest_view2 where a = $1' language 'sql'; + ERROR: return type mismatch in function: declared to return integer, returns bigint Maybe instead of testing for strict equality of the types, test for compatibility. We could try to force-convert the result of an SQL function to the right thing, I suppose, but I'm worried that that might mask programmer errors more than it helps. On the other hand, the equivalent forced conversion happens already in plpgsql functions; it's only SQL-language functions that are so picky. Maybe your idea is good. Anyone else have an opinion? I don't know. Doing a force for SQL functions and not for others seems kind of confusing. -- 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] Forcing GiST index to be used
Dave Blasby [EMAIL PROTECTED] writes: I have a custom datatype (the PostGIS geometry type), which I have indexed using a GiST index. The problem is, its difficult to get PostgreSQL to actually use the GiST index. The only way I can get it to be used is by 'set enable_seqscan = off', which seems a bit cheezy. What am I missing? Do I have to make some sort of amcostestimate() function or something? What sort of selectivity estimator (oprrest entry) do you have attached to the indexable operator? If there's no estimator, the default selectivity is something like 0.5 --- way too high to cause an index to be used. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Re: [HACKERS] PostGIS spatial extensions
Paul Ramsey writes: Perhaps we could back up at this point and revisit 'contrib' ... at what point in the size/licence/redundace spectrum do we become reasonable candidates for 'contrib', if ever? The current tenor seems to be that at 600K/GPL/point-line-polygon we are too big/too restrictive and/or too free/overlapping. Would moving on any of those axes be sufficient, or do we have to address all three (practically speaking, I not think there is anything to be done about size). Historically, contrib was the place for small pieces of code that a) could/would/should not go into the core for some reason, b) were unreasonable to distribute otherwise (too small, not general enough), and c) served as examples of how to use the type/functione extension features. You satisfy a), you do not satisfy b), and I doubt that c) is still applicable. Projects that are as organized, professional, and value-adding as yours is can surely stand on their own. I compare this to the recently released OpenFTS. If we start including projects of this size we'd explode in size and maintenance overhead. I don't want to make the impression that I don't like you guys. It's just that we have to realize that there is a *lot* of coding using PostgreSQL these days, and it's unreasonable to include all of this in our distribution, while at the other end people are crying about removing the documentation from the tarball because it's too big already. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Use int8 for int4/int2 aggregate accumulators?
Peter Eisentraut [EMAIL PROTECTED] writes: What I had in mind was to allow type conversion between the same TypeCategory(). The SQL function analyzer is extraordinarily picky: I just finished looking at that. It'd be possible (and probably reasonable) to accept a binary-compatible datatype rather than requiring exact equality; this would fix your varchar-vs-text example. However, inserting any runtime type conversion would require a significant amount of code added. We couldn't do it just by inserting the conversion function call into the SELECT querytree, because that'd alter the SELECT semantics, if not actively crash it --- an example of a likely crash is create function mymax() returns int4 as ' select int8col from tab order by int8col desc limit 1' language sql; Here, the prepared parsetree is already set up to apply int8 sorting to the first column of its result. If we try to insert a cast-to-int4, we will end up sorting int4 data with int8 operators -- instant coredump. So the conversion function application would have to be done at runtime in the SQL function manager, which is more code than I care to take on at the moment. Note also that there is code in there to figure out whether a targetlist satisfies a tuple return datatype; should we also apply automatic type conversion to elements of such a list? It's getting to be more of a stretch to say that this is being helpful rather than masking programmer error. But binary compatibility is easy. Shall we do 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] Re: Use int8 for int4/int2 aggregate accumulators?
Tom Lane writes:
We could try to force-convert the result of an SQL function to the right
thing, I suppose, but I'm worried that that might mask programmer errors
more than it helps.
What I had in mind was to allow type conversion between the same
TypeCategory(). The SQL function analyzer is extraordinarily picky:
create function test(int) returns varchar as '
select substring(''PostgreSQL'' from $1);
' language sql;
ERROR: return type mismatch in function: declared to return character
varying, returns text
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] int8 sequences --- small implementation problem
Jan Wieck [EMAIL PROTECTED] writes: What I'm asking myself all the time is which platforms do we support that doesn't have 8-byte integers?. Could someone enlighten me please? Release a version that doesn't work without 8-byte ints, and I'm sure we'll find out soon enough ;-). QNX and MIPS SysVR4 are documented not to have int8 support in our supported platforms list, but we've not heard from anyone still using 'em for awhile. Basically, my feeling about it is that it's not ANSI C, and we shouldn't yet be *requiring* C99 support to build Postgres. And what does int8 do on these platforms? Acts like int4, except for taking up 8 bytes anyway (because pg_type says so, not because sizeof() says so). See c.h. 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] Retriving users from group ?...
Hello all!!! I need to retrieve all the users from a group, for my Delphi Interface for PostgreSQL. The problem is, I can't accomplish a query that does it, since the users belonging from a group are all stored in an array field (pg_group.groulist). Does anyone have a solution for this ? Using contrib array functions is certainly not a good idea, because it would require ALL users of the interface to compile and install it. I still don't understand anyway why there is not a regular catalog relating users and groups, like: CREATE TABLE pg_groupusers(grosysid integer, usesysid integer); That makes much more sense for me, unless at least the contrib array functions get implemented as builtins, so that we can test user groupship. Can that be added to the TODO least ?... Best Regards, Steve Howe ---(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] int8 sequences --- small implementation problem
Stephan Szabo wrote: On Tue, 14 Aug 2001, Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: And he who needs that kind of long term row identifiers would be better off with 8-byte sequences anyway - IMNSVHO. What I need is a way to pad the struct declaration so that it leaves 8 bytes per int64 column, no matter what. I thought of This would work, I think, but my goodness it's an ugly solution. Has any hacker got a better one? The only thing I could think of is using a struct to hide the padding details instead of directly using int64, but then you'd have to add a '.value' or something to the references. I'm not sure that's really any cleaner. What I'm asking myself all the time is which platforms do we support that doesn't have 8-byte integers?. Could someone enlighten me please? And what does int8 do on these platforms? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Rename config.h to pg_config.h?
Tom Lane writes: This is true in theory, but in practice we've not seen very many complaints about it; perhaps that's because there's a fair amount of standardization of Autoconf usage. (HAVE_FOO_H probably gets set the same way by every package that might use it, for example.) Agreed in general. But consider things like USE_LOCALE. 2. Then we can install the above set of headers directly into $includedir (e.g., /usr/include), since they're relatively clearly named. This has been one of my pet peeves: right now we are forced to install in a subdirectory of /usr[/local]/include because of this conflict, which requires plain-old libpq programs to add an explicit -I compile flag, which is not nice. Wouldn't renaming config.h be sufficient to accomplish that? At least os.h needs to be considered as well for that. Perhaps we could have config.h not include os.h and instead let c.h do that (should still work for libpq++). Or rename os.h as well. Putting the server side includes in the main path isn't ever going to happen, I think, given the random set of names that give no indication which package they belong to. I will see if the idea of putting them in a separate directory than the client side can be made to work smoothly. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(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: Use int8 for int4/int2 aggregate accumulators?
Tom Lane writes: I started working on this, and immediately got a pile of regression test failures arising from: create function rtest_viewfunc1(int4) returns int4 as 'select count(*) from rtest_view2 where a = $1' language 'sql'; + ERROR: return type mismatch in function: declared to return integer, returns bigint Maybe instead of testing for strict equality of the types, test for compatibility. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] OID unsigned long long
mlw writes: I am thinking about embarking on changing the typedef of OID to unsigned long long. Aside from adding %llu to all the %u everywhere an OID is used in a printf, and any other warnings, are there any other things I should be specially concerned about? You can start with my patch at http://www.ca.postgresql.org/~petere/oid8.html See the comments on that page and the other responses. It ain't pretty. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] int8 sequences --- small implementation problem
- Original Message - From: Tom Lane [EMAIL PROTECTED] Sent: Tuesday, August 14, 2001 11:28 AM Serguei Mokhov [EMAIL PROTECTED] writes: This would work, I think, but my goodness it's an ugly solution. Is anything wrong with just having two int32 per value for this case? Well, we do want it to be int64 on machines where int64 is properly defined. Or are you suggesting #ifdef INT64_IS_BUSTED int32 last_value; int32 pad1; #else int64 last_value; #endif That does seem marginally more robust, now that you mention it... Yes, this version is more robust, but you till have to cope with all those #ifdef INT64_IS_BUSTED #else #endif. I guess if you want explicitly int64 type in here for those platforms that do support it, then there is no other way maybe. What I was thinking (for this particular struct only!) is just jave padded int32's for every value, which will always be correct and no marginal problems. And the accessor functions using the struct just employ int64 whatever it means. S. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Help with Vacuum Failure
Matthew T. O'Connor [EMAIL PROTECTED] writes: cms_beau=# vacuum hits; (It works without the analyze phase of backup.) VACUUM cms_beau=# VACUUM verbose analyze hits; NOTICE: --Relation hits-- NOTICE: Pages 8389: Changed 0, reaped 2, Empty 0, New 0; Tup 834575: Vac 0, Keep/VTL 4/4, Crash 0, UnUsed 6, MinLen 52, MaxLen 121; Re-using: Free/Avail. Space 376/64; EndEmpty/Avail. Pages 0/1. CPU 0.34s/0.05u sec. NOTICE: Index hits_id_key: Pages 1831; Tuples 834575: Deleted 0. CPU 0.11s/0.56u sec. NOTICE: Rel hits: Pages: 8389 -- 8389; Tuple(s) moved: 0. CPU 0.00s/0.00u sec. NOTICE: --Relation pg_toast_6742393-- NOTICE: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec. NOTICE: Index pg_toast_6742393_idx: Pages 1; Tuples 0. CPU 0.00s/0.00u sec. NOTICE: Analyzing... ERROR: MemoryContextAlloc: invalid request size 4294079565 cms_beau=# This looks like you have corrupted data in your table --- specifically, a variable-length value with a bogus length word. If so, you'll get a similar error during any attempt to access the particular value or row that's corrupted. A quick check of this theory is to try to pg_dump the table --- if it fails with the same sort of error, then you have a problem. PostgreSQL 7.1.2 on i686-pc-linux-gnu, compiled by GCC 2.96 2.96? AFAICT 2.95.3 is the latest official release of GCC. 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] To be 7.1.3 or not to be 7.1.3?
I will get on this today. [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: That's a couple of days ago now... anything happening? Bruce is evidently waiting on Hiroshi's confirmation that he's done applying his back-patches. I believe he is, though; he did apply what I thought was the patch he had in mind. Bruce, have you finished the documentation updates, or is that still open? You could probably get that done while waiting for Hiroshi's answer... 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]) -- 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
[HACKERS] Re: [PATCHES] Makefile.PL for Pg.so
Larry Rosenman writes: I made the following patch, and it works for MY platform. Peter, Can we do something similar for the distribution to set the RUNPATH for Pg.so? This is an interesting idea. I'd rather rip out MakeMaker completely, but this might be a good start. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: To be 7.1.3 or not to be 7.1.3?
I have to fix my old fault in TID handling. I am able to have a cvs access now and would commit the fix to 7.1 branch. Hiroshi, are you done with changes you want in 7.1.3? Oops I missed your mail sorry. Unfortunately my mail server is down and I could access pgsql-hackers only by the news server. My answer is Yes. OK, 7.1.3 is packaged and ready to go, date stamped Auguest 15. Can people with cvs 7.1 branches review 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: [BUGS] pg_regress fails at point test
On 30 Jul 2001 Tom Lane wrote: [EMAIL PROTECTED] writes: gcc2.95; hppa2.0-hp-hpux10.20, postgresql 7.1.2 make check checks the first group all right (tests check out ok and a process postgres: shows up in the process list. When make check displays parallel group (18 tests): point lseg the postgres: process disappears from the process list and the test does not complete. Or, rather, not until I lose patience (15min). Incidentally the shell process that make started keeps running and eats up all the CPU time. Known bug in HPUX's Bourne shell --- evidently it can't cope with so many children in parallel. It works if you do gmake SHELL=/bin/ksh check or if you run the non-parallel installcheck. See FAQ_HPUX. If I still had a support contract in force with HP, I'd file a bug report... I reduced the pg_regress script to a test case and submitted a CR: JAGad84609 /usr/bin/sh hang on PostgreSQL regression test The defect is filed against HP-UX 11i, but I noted that the defect is present on 11.00 and 10.20 as well. Regards, Giles ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: [PATCHES] Makefile.PL for Pg.so
* Peter Eisentraut [EMAIL PROTECTED] [010814 16:58]: Larry Rosenman writes: I made the following patch, and it works for MY platform. Peter, Can we do something similar for the distribution to set the RUNPATH for Pg.so? This is an interesting idea. I'd rather rip out MakeMaker completely, but this might be a good start. I'm not familiar enough with the config / autoconf stuff to do a portable patch. Can you help in this area? LER -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter -- 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] Re: Use int8 for int4/int2 aggregate accumulators?
Note also that there is code in there to figure out whether a targetlist satisfies a tuple return datatype; should we also apply automatic type conversion to elements of such a list? It's getting to be more of a stretch to say that this is being helpful rather than masking programmer error. But binary compatibility is easy. Shall we do that? If we don't do binary compatible already, we certainly should. -- 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] PostGIS spatial extensions
Peter Eisentraut wrote: Projects that are as organized, professional, and value-adding as yours is can surely stand on their own. I compare this to the recently released OpenFTS. If we start including projects of this size we'd explode in size and maintenance overhead. Fair enough... perhaps we should turn then to some kind of discussion on packaging standards for postgresql extensions? - One of the things we have run up against is that for most linux distributions, the postgresql-devel package does not include postgres.h in the header package. This is not necessary for client-side programs, but it is for server-side extensions. So people cannot compile our extension without jettisoning their RPM version of postgresql and moving to the tarball. - Compile our own RPM you say? Yes and no. We could provide a SRPM, but then we have the same problem: absent a complete postgresql source tree, we cannot compile. And even if we *do* provide our own RPM... - Where should extensions be installed by default? The RPM package has some rules, the tarball has some other rules. Should extensions spread themselves out over the postgresql tree (libs under lib, docs under doc, etc) or should they be self-contained (postgis/lib postgis/doc) under some other location? In order to provide a rational RPM source package I ended up having to provide a complete SRPM of postgresql with the postgis stuff bundled in. You must build the whole package in order to get the postgis component. The issue of the extensions dependance on the core is pretty important. -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] MS interview
The Register has an interesting interview with the vp of Microsoft's SQL Server team: http://www.theregister.co.uk/content/53/21003.html Near the end he gets specifically asked about Red Hat Database as a competitive threat, and he responds that he doesn't think anyone can match their investment of 800 professionals to work on SQL Server. Now I'm sure he didn't mean it to sound this way, but what I conclude from that is that you fellows are all an order of magnitude or two more productive than anyone at Microsoft :-). Tim -- --- Tim Allen [EMAIL PROTECTED] Proximity Pty Ltd http://www.proximity.com.au/ http://www4.tpg.com.au/users/rita_tim/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] MS interview
I'm sure that 800 professionals equates to something like 4 developers, 1 tester (part-time), 2 documentation specialist, and 792 marketing, sales, administration, legal staff and others required to justify its cost, and 1 CEO who has his fingers into everything at MS. Tim Allen wrote: The Register has an interesting interview with the vp of Microsoft's SQL Server team: http://www.theregister.co.uk/content/53/21003.html Near the end he gets specifically asked about Red Hat Database as a competitive threat, and he responds that he doesn't think anyone can match their investment of 800 professionals to work on SQL Server. Now I'm sure he didn't mean it to sound this way, but what I conclude from that is that you fellows are all an order of magnitude or two more productive than anyone at Microsoft :-). Tim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] MS interview
Tim Allen [EMAIL PROTECTED] writes: Near the end he gets specifically asked about Red Hat Database as a competitive threat, and he responds that he doesn't think anyone can match their investment of 800 professionals to work on SQL Server. ROTFL ... The longer that Oracle, MS, et al don't believe we're a threat, the better. But I wonder how they *really* see us. This article was too obviously a pile of marketing BS to be taken seriously by anyone. What's their real internal perception of us, do you think? 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] MS interview
What is OLAP and why is it so good? (According to MS) Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Allen Sent: Wednesday, 15 August 2001 8:50 AM To: [EMAIL PROTECTED] Subject: [HACKERS] MS interview The Register has an interesting interview with the vp of Microsoft's SQL Server team: http://www.theregister.co.uk/content/53/21003.html Near the end he gets specifically asked about Red Hat Database as a competitive threat, and he responds that he doesn't think anyone can match their investment of 800 professionals to work on SQL Server. Now I'm sure he didn't mean it to sound this way, but what I conclude from that is that you fellows are all an order of magnitude or two more productive than anyone at Microsoft :-). Tim -- --- Tim Allen [EMAIL PROTECTED] Proximity Pty Ltd http://www.proximity.com.au/ http://www4.tpg.com.au/users/rita_tim/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(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] MS interview
OLAP Council White Paper Introduction The purpose of the paper that follows is to define On-Line Analytical Processing (OLAP), who uses it and why, and to review the key features required for OLAP software as referenced in the OLAP Council benchmark specification. http://www.olapcouncil.org/research/whtpapco.htm And Data Warehousing and OLAP A Research-Oriented Bibliography (in progress) Alberto Mendelzon University of Toronto http://www.cs.toronto.edu/~mendel/dwbib.html Seems like a fairly large amount of talk about stuff which should be taken care of internally by corporations who have such interests. Gavin On Wed, 15 Aug 2001, Christopher Kings-Lynne wrote: What is OLAP and why is it so good? (According to MS) Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Allen Sent: Wednesday, 15 August 2001 8:50 AM To: [EMAIL PROTECTED] Subject: [HACKERS] MS interview The Register has an interesting interview with the vp of Microsoft's SQL Server team: http://www.theregister.co.uk/content/53/21003.html Near the end he gets specifically asked about Red Hat Database as a competitive threat, and he responds that he doesn't think anyone can match their investment of 800 professionals to work on SQL Server. Now I'm sure he didn't mean it to sound this way, but what I conclude from that is that you fellows are all an order of magnitude or two more productive than anyone at Microsoft :-). Tim -- --- Tim Allen [EMAIL PROTECTED] Proximity Pty Ltd http://www.proximity.com.au/ http://www4.tpg.com.au/users/rita_tim/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] MS interview
The longer that Oracle, MS, et al don't believe we're a threat, the better. But I wonder how they *really* see us. This article was too obviously a pile of marketing BS to be taken seriously by anyone. Not necessarily - business guys are incredibly naive when it comes to technology options. I had to fight tooth and nail to use PostgreSQL/Linux on a recent project. The business didn't care about feature comparisons, they cared about two things: 1) Putting Oracle+Solaris logos on our technology page 2) Support I got it through by arguing about the cost difference and the fact that RedHat is on board (they knew who RedHat was from Business Review Weekly *sigh*). I forwarded that article to them, and their response to the quote of ...Open source systems are a great way for our future customers to learn about relational databases, says Bob Shimp, Oracle's senior director of database marketing was that makes sense, after all Oracle has many more features than PostgreSQL. So, I guess the point I am trying to make is that image is everything - 800 people working on MS SQL Server is much more impressive to a business guy than a couple of dozen people all over the world. Remember, these are the people that still believe that all programmers are alike and can just be swapped around on projects without any impact. Hopefully, RedHat's involvement will boost the mindshare and image of PostgreSQL and I don't have to keep doing Oracle admin :) Mark Pritchard Senior Technical Architect Tangent Systems Australia -- email [EMAIL PROTECTED] ph +61 3 9809 1311 fax+61 3 9809 1322 mob0411 402 034 -- The central task of a natural science is to make the wonderful commonplace: to show that complexity, correctly viewed, is only a mask for simplicity; to find pattern hidden in apparent chaos. Herb Simon ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] MS interview
Hopefully, RedHat's involvement will boost the mindshare and image of PostgreSQL and I don't have to keep doing Oracle admin :) We had four articles in one day today. That shows some major momentum. -- 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
