Re: [HACKERS] On-disk Tuple Size
On Sat, 20 Apr 2002, Tom Lane wrote: Curt Sampson [EMAIL PROTECTED] writes: While we're at it, would someone have the time to explain to me how the on-disk CommandIds are used? To determine visibility of tuples for commands within a transaction. Just as you don't want your transaction's effects to become visible until you commit, you don't want an individual command's effects to become visible until you do CommandCounterIncrement. Among other things this solves the Halloween problem for us (how do you stop an UPDATE from trying to re-update the tuples it's already emitted, should it chance to hit them during its table scan). The command IDs aren't interesting anymore once the originating transaction is over, but I don't see a realistic way to recycle the space ... Ah, I see. So basically, it's exactly parallel to the transaction IDs except it's for commands instead of transactions? So this seems to imply to me that the insert command ID fields are of interest only to the transaction that did the insert. In other words, if your transaction ID is not the one listed in t_xmin, the t_cmin field is always ignored. And the same goes for t_cmax and t_xmax, right? If this is the case, would it be possible to number the commands per-transaction, rather than globally? Then the t_cmin for a particular tuple might be say, 7, but though there might be many transactions that have processed or will process command number 7, we would know which transaction this belongs to by the t_xmin field. Does this work for cursors, which currently seem to rely on a global command ID? If you keep track of the transaction ID as well, I think so, right? Having per-transaction command IDs might allow us to reduce the range of the t_cmin and t_cmax fields. Unfortunately, probably by not all that much, since one doesn't want to limit the number of commands within a single transaction to something as silly as 65536. But perhaps we don't need to increment the command ID for every command. If I do an insert, but I know that the previous command was also an insert, I know that there were no intervening reads in this transaction, so can I use the previous command's ID? Could it be that we need to increment the command ID only when we switch from writing to reading or vice versa? There could still be transactions that would run into problems, of course, but these might all be rather pathological cases. Or is everybody wishing they had some of whatever I'm smoking? :-) cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Documentation on page files
On Sat, 20 Apr 2002, Tom Lane wrote: Martijn van Oosterhout [EMAIL PROTECTED] writes: Chapter 7 of the Developers guide in about the Page Format on disk and it's a little out of date not to mention somewhat incomplete. Indeed, this seems to have very little relation to reality :-(. I dunno, it seems to be not too bad to me, though woefully incomplete. I too was considering writing an updated version of this. I'm not sure if the continuation mechanism it describes ever existed at all, but it sure hasn't been there since the code left Berkeley. Yeah, I was wondering about that. This has been replaced by TOAST, right? 2. If not, would patches be accepted to correct the situation? Go for it. Yes, please! I'd be happy to review and updated version. One thing that would be good, since this is a developers' guide, would be to include references to the source files and dates from which the information comes. That way one could see if updates are necessary by doing a diff on those files between the given date and the head, to see what changes have been made since the description was written. Also good would be to have the data structures explicitly named so that when one dives into the source, one already has a good idea of what one's looking at. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(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] On-disk Tuple Size
On Sat, 20 Apr 2002, Tom Lane wrote: I believe we do want to distinguish three states: live tuple, dead tuple, and empty space. Otherwise there will be cases where you're forced to move data immediately to collapse empty space, when there's not a good reason to except that your representation can't cope. I don't understand this. I thought more about this in the shower this morning, and realized the fundamental drawback of the scheme you are suggesting: it requires the line pointers and physical storage to be in the same order. ...But in any case line pointer order and physical storage order are tied together.) I thought that for a while too. As you point out, you want an list of line pointers ordered by address in the block to build your map of space after the free space in the middle of the page because you get the end of the current block from the start address of the next block. (We know where the free space in the middle is from the end of the line pointer array.) However, there's no reason it has to be stored in this order on the disk. You can build a sorted list of line pointers in a separate area of memory after you read the page. Yes, this uses a bit more CPU, but I think it's going to be a pretty trivial amount. It's a short list, and since you're touching the data anyway, it's going to be in the CPU cache. The real cost you'll pay is in the time to access the area of memory where you're storing the sorted list of line pointers. But the potential saving here is up to 5% in I/O costs (due to using less disk space). The three states of a line pointer that I referred to are live (pointing at a good tuple), dead (pointing at storage that used to contain a good tuple, doesn't anymore, but hasn't been compacted out yet), and empty (doesn't point at storage at all; the space it used to describe has been merged into the middle-of-the-page free pool). Right. I now realize that we still do still need the three states, which are in my case: live: points to tuple data in use free space: points to unused space in the page, i.e., a dead tuple. unused: a line pointer that doesn't point to anything at all. ISTM a pointers-only representation can handle the live and dead cases nicely, but the empty case is going to be a real headache. This doesn't need a separate flag, since we can just have the line pointer point to something obviously invalid, such as the page header. (0 seems quite convenient for this.) In the header, we need a count of the number of line pointers (line_id_count above), but we can drop the beginning/end of free space pointers, since we know that data space starts after the last line pointer, and ends at the beginnning of special space. So here's an example of a page layout. Sizes are arbitrary ones I picked for the sake of the example, except for the line_id sizes. Address SizeItem 0 24 page header (line_id_count = 6) 24 2 line_id: 7751 (free space 1) 26 2 line_id: 7800 (tuple 1) 28 2 line_id:0 (unused) 30 2 line_id: 7600 (tuple 2) 32 2 line_id: 8000 (tuple 3) 34 2 line_id: 7941 (free space 2) 36 7564free space in the middle of the page 7600150 tuple 2 775050 free space 1 7800100 tuple 1 794060 free space 2 800096 tuple 3 809696 special space Note above that the free space pointers have the LSB set to indicate that they point to free space, not tuples. So the first line_id actually points to 7750. When I do an insert, the first thing I do is scan for a free line pointer. Finding a free one at 28, I decide to re-use that. Then I look for the smallest block of free space that will hold the data that I need to insert. If it fits, exactly, I use it. If not, I need to extend the line pointer array by one and make that point to the remaining free space in the block of free space I used. If a big enough block of free space doesn't exist, I compact the page and try again. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(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] Documentation on page files
On Sun, Apr 21, 2002 at 03:46:07PM +0900, Curt Sampson wrote: On Sat, 20 Apr 2002, Tom Lane wrote: Martijn van Oosterhout [EMAIL PROTECTED] writes: 2. If not, would patches be accepted to correct the situation? Go for it. Yes, please! I'd be happy to review and updated version. Ok, my first attempt can be seen here: http://svana.org/kleptog/pgsql/page.sgml.txt I don't know whatever SGML format this is using, so the layout is not great, but the information should be accurate. I used it to create a program to dump the datafiles directly without the postmaster :). I'll submit a proper patch once we have something useful. One thing that would be good, since this is a developers' guide, would be to include references to the source files and dates from which the information comes. That way one could see if updates are necessary by doing a diff on those files between the given date and the head, to see what changes have been made since the description was written. Also good would be to have the data structures explicitly named so that when one dives into the source, one already has a good idea of what one's looking at. Well, I have included the names of the structures involved. Do you think it's worth adding filenames given that TAGS makes tracking them down easily enough? I can put in dates if you like. Issues to be dealt with: - Do I need to say more about TOAST? - Indexes? - Split into sections - How much detail is enough/too much? Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Canada, Mexico, and Australia form the Axis of Nations That Are Actually Quite Nice But Secretly Have Nasty Thoughts About America ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] On-disk Tuple Size
Having per-transaction command IDs might allow us to reduce the range of the t_cmin and t_cmax fields. Unfortunately, probably by not all that much, since one doesn't want to limit the number of commands within a single transaction to something as silly as 65536. If you can figure out how to make that roll over sure, but thats a very small number. Consider users who do most of their stuff via functions (one transaction). Now consider the function that builds reports, stats, etc. for some department. It's likley these work on a per account basis. We have a function making invoices that would wrap around that atleast 10x. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] On-disk Tuple Size
Curt Sampson [EMAIL PROTECTED] writes: If this is the case, would it be possible to number the commands per-transaction, rather than globally? They are. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] failed regression tests
I'm trying to (finally) get my rather extensive patches (mostly addressing int8 versions of date/time storage) applied but am now having trouble with the regression tests. I'm sure this has been on the list, but I'm not recalling the explanation or workaround. My guess is that it is related to collation troubles with the new locale-always-enabled feature. I've tended to never enable this stuff in the past. The first symptom is failures in the char regression test. An example diff is *** expected/char.out Tue Jun 5 07:20:01 2001 --- results/char.outSun Apr 21 10:04:08 2002 *** *** 63,74 WHERE c.f1 'a'; five | f1 --+ - | A | 1 | 2 | 3 | ! (5 rows) So the 'A' row is left out of the result on my machine. All other failures (there are 7 tests total which fail) are likely similar in nature. I've tried a make clean, a make distclean, and need a hint on what to try next. I'd *really* like to get these patches applied, and am almost certain that they are not related to these regression failures, but... Early help would be appreciated; I've got time in the next couple of hours to get this stuff finished!! :) - Thomas ---(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] failed regression tests
Thomas Lockhart writes: I'm sure this has been on the list, but I'm not recalling the explanation or workaround. My guess is that it is related to collation troubles with the new locale-always-enabled feature. I've tended to never enable this stuff in the past. The first symptom is failures in the char regression test. An example diff is initdb --no-locale I'm pondering ways to make the regression tests locale-aware, but it hasn't happened yet. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] failed regression tests
The first symptom is failures in the char regression test... initdb --no-locale Ooh. Thanks, that fixes it. Where would I have found this in the docs? I was looking in the wrong place (in configure/build) rather than at initdb. Should we have something in the release notes? I see (now that I look) that there is a one-liner, but istm that this may deserve a paragraph in the significant changes category. - Thomas ---(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] Foreign keys and indexes.
Rod Taylor [EMAIL PROTECTED] writes: Is everyone Ok with the above? Or do we go about making an pg_fkey type table for tracking this stuff? In general there ought to be a pg_constraint table that records all types of constraints (not only foreign keys). We blew it once already by making pg_relcheck (which only handles check constraints). Let's not miss the boat again. 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] Really annoying comments...
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 19 April 2002 19:54 To: Rod Taylor Cc: Hackers List Subject: Re: Really annoying comments... Rod Taylor [EMAIL PROTECTED] writes: COMMENT ON DATABASE db IS 'Comment'; Now switch databases. Comment is gone. Yeah, it's not very helpful. I'm not sure why we bothered to implement that in the first place. I suppose in order to add a comment field to pg_database it would need to be toasted or something (ton of work). Any other way to fix this? I'm more inclined to rip it out ;-). Eeep! pgAdmin handles comments coming from multiple pg_description tables and it works very well (IMHO) in the pgAdmin UI. By all means make them work more sensibly in whatever way seems most appropriate - I'll fix pgAdmin to handle it, but don't just rip them out please!! Regards, Dave. ---(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] Really annoying comments...
Dave Page [EMAIL PROTECTED] writes: I'm more inclined to rip it out ;-). Eeep! pgAdmin handles comments coming from multiple pg_description tables and it works very well (IMHO) in the pgAdmin UI. By all means make them work more sensibly in whatever way seems most appropriate - I'll fix pgAdmin to handle it, but don't just rip them out please!! Well, it would seem like the only sensible rule would be to allow COMMENT ON DATABASE only for the *current* database. Then at least you know which DB to look in. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Really annoying comments...
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 21 April 2002 19:45 To: Dave Page Cc: Rod Taylor; Hackers List Subject: Re: [HACKERS] Really annoying comments... Dave Page [EMAIL PROTECTED] writes: I'm more inclined to rip it out ;-). Eeep! pgAdmin handles comments coming from multiple pg_description tables and it works very well (IMHO) in the pgAdmin UI. By all means make them work more sensibly in whatever way seems most appropriate - I'll fix pgAdmin to handle it, but don't just rip them out please!! Well, it would seem like the only sensible rule would be to allow COMMENT ON DATABASE only for the *current* database. Then at least you know which DB to look in. That wouldn't cause me any pain - in pgAdmin the comment is just a property of a pgDatabase object - if you modify it, it will always be set through a connection to that database. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Schema (namespace) privilege details
On Sun, 21 Apr 2002, Sander Steffann wrote: At the moment all our DBs are on one partition. Not really, no. It's easy to put in a symlink to put a database on another partition. It's easy for any object, for that matter, so long as it's not the sort of thing that gets deleted and re-created by users. That is true, but when I look at how many of our customers actually use temp tables, I think this is not a very big problem (for us!) Oh, of course! I was still in SQL Server mode, thinking that sorts were done via temp tables. But of course Postgres doesn't do it this way. I don't know if there are any other places where a user can eat resources, but the more I think about it, the more complicated it gets. :-( Yeah, exactly. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] On-disk Tuple Size
Curt Sampson [EMAIL PROTECTED] writes: Yes, this uses a bit more CPU, but I think it's going to be a pretty trivial amount. It's a short list, and since you're touching the data anyway, it's going to be in the CPU cache. The real cost you'll pay is in the time to access the area of memory where you're storing the sorted list of line pointers. But the potential saving here is up to 5% in I/O costs (due to using less disk space). At this point you're essentially arguing that it's faster to recompute the list of item sizes than it is to read it off disk. Given that the recomputation would require sorting the list of item locations (with up to a couple hundred entries --- more than that if blocksize 8K) I'm not convinced of that. Another difficulty is that we'd lose the ability to record item sizes to the exact byte. What we'd reconstruct from the item locations are sizes rounded up to the next MAXALIGN boundary. I am not sure that this is a problem, but I'm not sure it's not either. The part of this idea that I actually like is overlapping the status bits with the low order part of the item location, using the assumption that MAXALIGN is at least 4. That would allow us to support BLCKSZ up to 64K, and probably save a cycle or two in fetching/storing the item fields as well. The larger BLCKSZ limit isn't nearly as desirable as it used to be, because of TOAST, and in fact it could be a net loser because of increased WAL traffic. But it'd be interesting to try it and see. 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] On-disk Tuple Size
On Sun, 21 Apr 2002, Tom Lane wrote: At this point you're essentially arguing that it's faster to recompute the list of item sizes than it is to read it off disk. Given that the recomputation would require sorting the list of item locations (with up to a couple hundred entries --- more than that if blocksize 8K) I'm not convinced of that. No, not at all. What I'm arguing is that the I/O savings gained from removing two bytes from the tuple overhead will more than compensate for having to do a little bit more computation after reading the block. How do I know? Well, I have very solid figures. I know because I pulled them straight out of myanyway. :-) Yeah, it's more or less instinct that says to me that this would be a win. If others don't agree, there's a pretty reasonable chance that I'm wrong here. But I think it might be worthwile spending a bit of effort to see what we can do to reduce our tuple overhead. After all, there is a good commerical DB that has much, much lower overhead, even if it's not really comparable because it doesn't use MVCC. The best thing really would be to see what other good MVCC databases do. I'm going to go to the bookshop in the next few days and try to find out what Oracle's physical layout is. Another difficulty is that we'd lose the ability to record item sizes to the exact byte. What we'd reconstruct from the item locations are sizes rounded up to the next MAXALIGN boundary. I am not sure that this is a problem, but I'm not sure it's not either. Well, I don't see any real problem with it, but yeah, I might well be missing something here. The larger BLCKSZ limit isn't nearly as desirable as it used to be, because of TOAST, and in fact it could be a net loser because of increased WAL traffic. But it'd be interesting to try it and see. Mmmm, I hadn't thought about the WAL side of things. In an ideal world, it wouldn't be a problem because WAL writes would be related only to tuple size, and would have nothing to do with block size. Or so it seems to me. But I have to go read the WAL code a bit before I care to make any real assertions there. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(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] Patches applied; initdb time!
I've applied patches to implement an int64-based data/time storage scheme. I've also accumulated some other minor fixes, which result in an initdb being required (sorry!). Note that the *default* timestamp type is now TIMESTAMP WITHOUT TIME ZONE. This is what we discussed previously for the transition to SQL9x compliance. Full cvs log entry is included below. - Thomas Support alternate storage scheme of 64-bit integer for date/time types. Use --enable-integer-datetimes in configuration to use this rather than the original float8 storage. I would recommend the integer-based storage for any platform on which it is available. We perhaps should make this the default for the production release. Change timezone(timestamptz) results to return timestamp rather than a character string. Formerly, we didn't have a way to represent timestamps with an explicit time zone other than freezing the info into a string. Now, we can reasonably omit the explicit time zone from the result and return a timestamp with values appropriate for the specified time zone. Much cleaner, and if you need the time zone in the result you can put it into a character string pretty easily anyway. Allow fractional seconds in date/time types even for dates prior to 1BC. Limit timestamp data types to 6 decimal places of precision. Just right for a micro-second storage of int8 date/time types, and reduces the number of places ad-hoc rounding was occuring for the float8-based types. Use lookup tables for precision/rounding calculations for timestamp and interval types. Formerly used pow() to calculate the desired value but with a more limited range there is no reason to not type in a lookup table. Should be *much* better performance, though formerly there were some optimizations to help minimize the number of times pow() was called. Define a HAVE_INT64_TIMESTAMP variable. Based on the configure option --enable-integer-datetimes and the existing internal INT64_IS_BUSTED. Add explicit date/interval operators and functions for addition and subtraction. Formerly relied on implicit type promotion from date to timestamp with time zone. Change timezone conversion functions for the timetz type from timetz() to timezone(). This is consistant with other time zone coersion functions for other types. Bump the catalog version to 200204201. Fix up regression tests to reflect changes in fractional seconds representation for date/times in BC eras. All regression tests pass on my Linux box. ---(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] Really annoying comments...
This makes the most sense. One could assume a user who doesn't have access to a particular database shouldn't know what it's for either. So making the comments global could be problematic in some cases. I'll enforce this and send in a patch. -- Rod - Original Message - From: Dave Page [EMAIL PROTECTED] To: 'Tom Lane' [EMAIL PROTECTED] Cc: Rod Taylor [EMAIL PROTECTED]; Hackers List [EMAIL PROTECTED] Sent: Sunday, April 21, 2002 2:49 PM Subject: RE: [HACKERS] Really annoying comments... -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 21 April 2002 19:45 To: Dave Page Cc: Rod Taylor; Hackers List Subject: Re: [HACKERS] Really annoying comments... Dave Page [EMAIL PROTECTED] writes: I'm more inclined to rip it out ;-). Eeep! pgAdmin handles comments coming from multiple pg_description tables and it works very well (IMHO) in the pgAdmin UI. By all means make them work more sensibly in whatever way seems most appropriate - I'll fix pgAdmin to handle it, but don't just rip them out please!! Well, it would seem like the only sensible rule would be to allow COMMENT ON DATABASE only for the *current* database. Then at least you know which DB to look in. That wouldn't cause me any pain - in pgAdmin the comment is just a property of a pgDatabase object - if you modify it, it will always be set through a connection to that database. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patches applied; initdb time!
btw, I've updated the regression tests and results for my platform, but other platforms (e.g. Solaris) will need their results files updated... - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Coster/planner and edge cases...
OK I know it's been beaten nearly to death, but no clear action has come of it quite yet. We all seem to agree that there is some non-optimal way in which the planner handles edge cases (cost wise). I don't believe that there are any fundamental type faults in any of the logic because we'd have much more major problems. Instead I'd like to investigate these edge cases where the planner chooses sub-optimal cases and see if there is anythign that can be done about it. No clue if I can cause any help or not yet, just something I'm going ot be looking into. The reason I'm writing though is I need data samples and queries that evoke the non-optimal responses (IE choosing the wrong plan) in order to look into it. Also I'd also like to know if there is a way to get the planner to burp out all the possible plans it considered before selecting a final plan or do I need to do a little surgery to get that done? TIA guys! Michael Loftis BTW I'm not masochistic, I'm just out of work and BORED :) ---(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] Patches applied; initdb time!
I'm seeing half a dozen gcc warnings as a result of these patches. Do you want to fix 'em, or shall I? 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] Patches applied; initdb time!
I'm seeing half a dozen gcc warnings as a result of these patches. Do you want to fix 'em, or shall I? Where are they? I haven't noticed anything in the files I have changes; are the warnings elsewhere? - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Patches applied; initdb time!
Thomas Lockhart [EMAIL PROTECTED] writes: I'm seeing half a dozen gcc warnings as a result of these patches. Do you want to fix 'em, or shall I? Where are they? With fairly vanilla configure options, I get make[3]: Entering directory `/home/postgres/pgsql/src/backend/parser' gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -I../../../src/include -c -o gram.o gram.c gram.y:6688: warning: `set_name_needs_quotes' defined but not used make[3]: Entering directory `/home/postgres/pgsql/src/backend/commands' gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -I../../../src/include -c -o sequence.o sequence.c In file included from sequence.c:25: ../../../src/include/utils/int8.h:33: warning: `INT64CONST' redefined ../../../src/include/utils/pg_crc.h:83: warning: this is the location of the previous definition gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -I../../../src/include -c -o variable.o variable.c variable.c: In function `parse_datestyle': variable.c:262: warning: `rstat' might be used uninitialized in this function variable.c:264: warning: `value' might be used uninitialized in this function make[4]: Entering directory `/home/postgres/pgsql/src/backend/utils/adt' gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -I../../../../src/include -c -o selfuncs.o selfuncs.c In file included from selfuncs.c:95: ../../../../src/include/utils/int8.h:33: warning: `INT64CONST' redefined ../../../../src/include/utils/pg_crc.h:83: warning: this is the location of the previous definition Seems not good to have INT64CONST separately defined in int8.h and pg_crc.h. Offhand I'd either move it into c.h, or else consider that int8.h is the Right Place for it and make pg_crc.h include int8.h. 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] Patches applied; initdb time!
I'm seeing half a dozen gcc warnings as a result of these patches. Where are they? More specifically, the *only* compiler warning I see (other than the usual yacc/lex symbol warnings) is that a routine in gram.y, set_name_needs_quotes(), is defined but not used. Don't know where that routine came from, and afaik I didn't accidentally remove a reference when trying to merge changes... - Thomas ---(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] Patches applied; initdb time!
With fairly vanilla configure options, I get... Please be specific on the options and platform. I do *not* see these warnings here with my fairly vanilla configure options ;) Can't fix what I can't see, and we should track down what interactions are happening to get these variables exposed... btw, the INT64CONST must be defined for int8 (which is where I get the definition for the date/time stuff); not sure why it appears in two separate places and not sure why my compiler (gcc-2.96.xxx) does not notice it. - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Patches applied; initdb time!
Thomas Lockhart [EMAIL PROTECTED] writes: btw, I've updated the regression tests and results for my platform, but other platforms (e.g. Solaris) will need their results files updated... I committed a fix for HPUX's horology file, and did some extrapolation to produce a Solaris version; someone please verify that it's OK. 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] Patches applied; initdb time!
Thomas Lockhart [EMAIL PROTECTED] writes: With fairly vanilla configure options, I get... Please be specific on the options and platform. HPUX 10.20, ./configure --with-CXX --with-tcl --enable-cassert 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] Patches applied; initdb time!
Thomas Lockhart wrote: With fairly vanilla configure options, I get... Please be specific on the options and platform. I do *not* see these warnings here with my fairly vanilla configure options ;) Can't fix what I can't see, and we should track down what interactions are happening to get these variables exposed... btw, the INT64CONST must be defined for int8 (which is where I get the definition for the date/time stuff); not sure why it appears in two separate places and not sure why my compiler (gcc-2.96.xxx) does not notice it. I just built from cvs tip using: ./configure --enable-integer-datetimes --enable-locale --enable-debug --enable-cassert --enable-multibyte --enable-syslog --enable-nls --enable-depend and got: gram.y:6688: warning: `set_name_needs_quotes' defined but not used variable.c: In function `parse_datestyle': variable.c:262: warning: `rstat' might be used uninitialized in this function variable.c:264: warning: `value' might be used uninitialized in this function -- and the usual lexer related warnings -- pgc.c: In function `yylex': pgc.c:1249: warning: label `find_rule' defined but not used pgc.l: At top level: pgc.c:3073: warning: `yy_flex_realloc' defined but not used and pl_scan.c: In function `plpgsql_base_yylex': pl_scan.c:1020: warning: label `find_rule' defined but not used scan.l: At top level: pl_scan.c:2321: warning: `yy_flex_realloc' defined but not used but did *not* get the INT64CONST warning that Tom did. I'm using an updated Red Hat 7.2 box. HTH, Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Patches applied; initdb time!
Thomas Lockhart [EMAIL PROTECTED] writes: More specifically, the *only* compiler warning I see (other than the usual yacc/lex symbol warnings) is that a routine in gram.y, set_name_needs_quotes(), is defined but not used. Don't know where that routine came from, and afaik I didn't accidentally remove a reference when trying to merge changes... Yeah, you did. However the routine could possibly go away now. It was a hack I put in recently to handle cases like regression=# create schema MySchema; CREATE regression=# create schema MyOtherSchema; CREATE regression=# set search_path TO MySchema, MyOtherSchema; ERROR: SET takes only one argument for this parameter Formerly gram.y merged the list items into a single string, and so it needed to double-quote mixed-case names to prevent case folding when the string got re-parsed later. This example worked last week, and probably would work again if the system were applying your new list-argument logic for search_path ... but I'm not sure where to look to learn about that. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patches applied; initdb time!
With fairly vanilla configure options, I get... Please be specific on the options and platform. HPUX 10.20, ./configure --with-CXX --with-tcl --enable-cassert Boy, how plain-vanilla. *My* configure line is all of ./configure --prefix=/home/thomas/local But I do override some parameters in my Makefile.custom: CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING CFLAGS+= -DCOPY_PARSE_PLAN_TREES Which gives me (except for the plan tree thing) something very similar. I've looked a bit more, and the set_name_needs_quotes() is probably obsoleted by my update, which generalizes parameter handling in SET variables. I'll rip it out unless we get a test case in the regression tests which demonstrates a problem. I'm pretty sure that it may have allowed SET key='par1 w space,par2'; but that would be handled now by SET key='par1 w space',par2; for cases in which key would accept multiple values. We now can allow single parameters with embedded commas *and* whitespace, which would have been impossible before. Not sure why white space is desirable however, so the new behavior seems adequate to me. I'm still not sure why the INT64CONST conflict does not show up as a warning on my machine, but looking at the code I'm not sure why we would ever have had two versions in the first place. Anyone want to take responsibility for consolidating it into The Right Place? If not, I'll go ahead and do it... - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patches applied; initdb time!
Joe Conway [EMAIL PROTECTED] writes: but did *not* get the INT64CONST warning that Tom did. I'm using an updated Red Hat 7.2 box. Probably it depends on compiler version? I'm using gcc 2.95.3. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patches applied; initdb time!
Thomas Lockhart [EMAIL PROTECTED] writes: I'm still not sure why the INT64CONST conflict does not show up as a warning on my machine, but looking at the code I'm not sure why we would ever have had two versions in the first place. Anyone want to take responsibility for consolidating it into The Right Place? If not, I'll go ahead and do it... I think it was originally needed only for the CRC code, so we put it there to begin with. Clearly should be in a more widely used place now. Do you have any opinion whether c.h or int8.h is the Right Place? I'm still dithering about that. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patches applied; initdb time!
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: but did *not* get the INT64CONST warning that Tom did. I'm using an updated Red Hat 7.2 box. Probably it depends on compiler version? I'm using gcc 2.95.3. could be: [postgres@jec-linux pgsql]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98) Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Patches applied; initdb time!
I think it was originally needed only for the CRC code, so we put it there to begin with. Clearly should be in a more widely used place now. Do you have any opinion whether c.h or int8.h is the Right Place? I'm still dithering about that. In looking at the code, istm that the versions should be merged with features from both. The generated constants should be surrounded in parens, but the explicit coersion to (int64) should be omitted at least with the LL version. I've got some other int64 pushups to worry about; let's try fixing those too (though afaict they may need to happen in different places). At the moment, we have INT64_IS_BUSTED as an amalgam of other conditions or undefined variables. I've also got a HAVE_INT64_TIMESTAMP which comes from a configured variable USE_INTEGER_DATETIMES and an undefined INT64_IS_BUSTED. This is now housed in c.h, but istm that we *should* check for conflicting settings in configure itself, and carry forward a consistant set of parameters from there. Anyway, at the moment some of this stuff is in c.h, and that is probably the right place to put the INT64CONST definitions, at least until things sort out differently. btw, I've updated gram.y and variable.c to suppress the reported warnings (which I *still* don't see here; that is very annoying). - Thomas ---(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] Patches applied; initdb time!
Thomas Lockhart wrote: btw, I've updated gram.y and variable.c to suppress the reported warnings (which I *still* don't see here; that is very annoying). FWIW, I'm still seeing: gram.y:99: warning: `set_name_needs_quotes' declared `static' but never defined Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] GUC vs variable.c (was Patches applied...)
[EMAIL PROTECTED] (Thomas Lockhart) writes: Log message: Remove the definition for set_name_needs_quotes() on the assumption that it is now obsolete. Need some regression test cases to prove otherwise... I agree that we don't want to reinstate that hack on the gram.y side. However, it seems to me way past time that we did what needs to be done with variable.c --- ie, get rid of it. All these special-cased variables should be folded into GUC. The code as committed has some problems beyond having broken support for search_path with a list: regression=# set seed to 1,2; server closed the connection unexpectedly (crash is due to assert failure) but really there's no point in worrying about that one case. What we need to do is figure out what needs to be done to GUC to let it support these variables, and then merge the variable.c code into that structure. Should we allow GUC stuff to take a list of A_Const as being the most general case, or is that overkill? 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] Patches applied; initdb time!
FWIW, I'm still seeing: gram.y:99: warning: `set_name_needs_quotes' declared `static' but never defined Ack. Sloppy patching. Should be fixed now... - Thomas ---(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] GUC vs variable.c (was Patches applied...)
I agree that we don't want to reinstate that hack on the gram.y side. However, it seems to me way past time that we did what needs to be done with variable.c --- ie, get rid of it. All these special-cased variables should be folded into GUC. Or in some cases into pg_database? We might want some of this to travel as database-specific properties adjustable using SQL or SET syntax. The code as committed has some problems beyond having broken support for search_path with a list: regression=# set seed to 1,2; server closed the connection unexpectedly OK. Would be nice to have a regression test covering this. And this is quite easy to fix of course. but really there's no point in worrying about that one case. What we need to do is figure out what needs to be done to GUC to let it support these variables, and then merge the variable.c code into that structure. Should we allow GUC stuff to take a list of A_Const as being the most general case, or is that overkill? Not sure. Peter would like to change the SET DATESTYLE support if I remember correctly. But I've gotten the impression, perhaps wrongly, that this extends to changing features in dates and times beyond style settings. If it is just the two-dimensional nature of the datestyle parameters (euro vs non-euro, and output format) then I'm sure that some other reasonable syntax could be arranged. I'm not sure what he would recommend wrt GUC in just the context of general capabilities for specifying parameters. - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patches applied; initdb time!
Thomas Lockhart writes: But I do override some parameters in my Makefile.custom: CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING If you use -O0 then you miss most of the interesting warnings. -- Peter Eisentraut [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] Patches applied; initdb time!
But I do override some parameters in my Makefile.custom: CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING If you use -O0 then you miss most of the interesting warnings. ?? Not in this case. afaik -O0 suppresses most optimizations (and hence does not reorder instructions, which is why I use it for debugging; I know, debuggers nowadays work pretty well even with instruction reordering, but...). Anyway, compiling with -O2 on variable.c still does not show the warnings with my 2.96.x compiler... - Thomas ---(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] Coster/planner and edge cases...
Michael Loftis [EMAIL PROTECTED] writes: Also I'd also like to know if there is a way to get the planner to burp out all the possible plans it considered before selecting a final plan or do I need to do a little surgery to get that done? You can define OPTIMIZER_DEBUG but the interface leaves a lot to be desired (output to backend stdout, no way to turn it on or off except recompile...) Also, I believe all you will see are the paths that survived the initial pruning done by add_path. This is about the right level of detail for examining join choices, but perhaps not very helpful for why-didn't-it-use-my-index choices; the paths you wanted to know about may not have got into the relation's candidate-path list in the first place. 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] Patches applied; initdb time!
Thomas Lockhart [EMAIL PROTECTED] writes: But I do override some parameters in my Makefile.custom: CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING If you use -O0 then you miss most of the interesting warnings. ?? Not in this case. afaik -O0 suppresses most optimizations In particular, you don't get unused variable and variable may not have been set before being used warnings at -O0, because the control-flow analysis needed to emit those warnings is not done at -O0. I generally use -O1 for development; it's sometimes a little hairy stepping through the generated code, but usually gcc works well enough at -O1, and I get the important warnings. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GUC vs variable.c (was Patches applied...)
Thomas Lockhart [EMAIL PROTECTED] writes: However, it seems to me way past time that we did what needs to be done with variable.c --- ie, get rid of it. All these special-cased variables should be folded into GUC. Or in some cases into pg_database? We might want some of this to travel as database-specific properties adjustable using SQL or SET syntax. Ah, but we *have* that ability right now; see Peter's recent changes to support per-database and per-user GUC settings. The functionality available for handling GUC-ified variables is now so far superior to plain SET that it's really foolish to consider having any parameters that are outside GUC control. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] GUC vs variable.c (was Patches applied...)
... Ah, but we *have* that ability right now; see Peter's recent changes to support per-database and per-user GUC settings. The functionality available for handling GUC-ified variables is now so far superior to plain SET that it's really foolish to consider having any parameters that are outside GUC control. istm that with the recent discussion of transaction-fying SET variables that table-fying some settable parameters may be appropriate. Leave out the foolish from the discussion please ;) - Thomas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Patches applied; initdb time!
Thomas Lockhart wrote: FWIW, I'm still seeing: gram.y:99: warning: `set_name_needs_quotes' declared `static' but never defined Ack. Sloppy patching. Should be fixed now... - Thomas Yup, did the trick. Thanks, Joe ---(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] Patches applied; initdb time!
... In particular, you don't get unused variable and variable may not have been set before being used warnings at -O0, because the control-flow analysis needed to emit those warnings is not done at -O0. Right. The point is that I don't get those (apparently) with -O2 either, with my particular compiler. Hmm. Actually, I *do* get those if I make sure that some of the other options are set too; my quick test added -O2 but left out some of the -w switches. OK, never mind... - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Coster/planner and edge cases...
Tom Lane wrote: Michael Loftis [EMAIL PROTECTED] writes: Also I'd also like to know if there is a way to get the planner to burp out all the possible plans it considered before selecting a final plan or do I need to do a little surgery to get that done? You can define OPTIMIZER_DEBUG but the interface leaves a lot to be desired (output to backend stdout, no way to turn it on or off except recompile...) Also, I believe all you will see are the paths that survived the initial pruning done by add_path. This is about the right level of detail for examining join choices, but perhaps not very helpful for why-didn't-it-use-my-index choices; the paths you wanted to know about may not have got into the relation's candidate-path list in the first place. Alright, that gives me some places to attack it at then anyway. Thanks very much Tom. Sounds like I'll probably be doing a little bit of work IE I'd like to have the information come back as say a notice or maybe as extra information for an EXPLAIN for my purposes, but unless there is interest, consensus on how it should be done, and a TODO item made of it, I won't be making a patch of that, no reason to clutter the backend with stuff that hopefully won't be needed for long :) Michael ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patches applied; initdb time!
Thomas Lockhart wrote: But I do override some parameters in my Makefile.custom: CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING If you use -O0 then you miss most of the interesting warnings. ?? Not in this case. afaik -O0 suppresses most optimizations (and hence does not reorder instructions, which is why I use it for debugging; I know, debuggers nowadays work pretty well even with instruction reordering, but...). Anyway, compiling with -O2 on variable.c still does not show the warnings with my 2.96.x compiler... It's actually the optimiser that allows a large number of the warnings to be uncovered. It generates extra code-path and coverage information, as well as other things, that are needed for the guts of GCC to squawk about a number of odd behaviours. ---(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] Coster/planner and edge cases...
Michael Loftis [EMAIL PROTECTED] writes: IE I'd like to have the information come back as say a notice or maybe as extra information for an EXPLAIN for my purposes, but unless there is interest, consensus on how it should be done, and a TODO item made of it, I won't be making a patch of that, no reason to clutter the backend with stuff that hopefully won't be needed for long :) I think it'd be useful to have, actually, as long as we're not talking about much code bloat. I tend to try to find a way to see what I want with EXPLAIN, because using OPTIMIZER_DEBUG is such a pain. But it's often difficult to force the plan I'm interested in to rise to the top. A nicer user interface for looking at the rejected alternatives would seem like a step forward to me, whether or not ordinary users have any need for it... 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] GUC vs variable.c (was Patches applied...)
... regression=# set seed to 1,2; server closed the connection unexpectedly (crash is due to assert failure) Now that I look, the assert is one I put in explicitly to catch multiple arguments! I wasn't sure what the behavior *should* be, though I could have done worse than simply checking for multiple arguments and throwing a more graceful elog(ERROR) with a message about having too many arguments to SET SEED... - Thomas ---(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] GUC vs variable.c (was Patches applied...)
Hmm. In looking at SET, why couldn't we develop this as an extendable capability a la pg_proc? If PostgreSQL knew how to link up the set keyword with a call to a subroutine, then we could go ahead and call that routine generically, right? Do the proposals on the table call for this kind of implementation, or are they all extra-tabular? We could make this extensible by defining a separate table, or by defining a convention for pg_proc as we do under different circumstances with type coersion. The side effects of the calls would still need some protection to be rolled back on transaction abort. Comments? - Thomas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] GUC vs variable.c (was Patches applied...)
Thomas Lockhart [EMAIL PROTECTED] writes: Hmm. In looking at SET, why couldn't we develop this as an extendable capability a la pg_proc? Well, my thoughts were along the line of providing specialized parsing subroutines tied to specific GUC variables. There already are parse_hook and assign_hook concepts in GUC, but possibly they need a little more generalization to cover what these variables need to do. If you're suggesting setting up an actual database table, I'm not sure I see the point. Any system parameter is going to have to be tied to backend code that knows what to do with the parameter, so it's not like you can expect to do anything useful purely by adding table entries. The C-code tables existing inside guc.c seem like enough flexibility to me. 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] GUC vs variable.c (was Patches applied...)
Thomas Lockhart writes: Not sure. Peter would like to change the SET DATESTYLE support if I remember correctly. But I've gotten the impression, perhaps wrongly, that this extends to changing features in dates and times beyond style settings. If it is just the two-dimensional nature of the datestyle parameters (euro vs non-euro, and output format) then I'm sure that some other reasonable syntax could be arranged. I'm not sure what he would recommend wrt GUC in just the context of general capabilities for specifying parameters. The only thing that I had suggested on occasion was that if nontrivial work were to be put into SET DATESTYLE, we might want to consider if a certain amount of cleanup could be done at the same time. For example, the particular date styles have somewhat unfortunate names, as does the european option. And the parameter could be separated into two. One doesn't have to agree with these suggestions, but without them the work is sufficiently complicated that no one has gotten around to it yet. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] GUC vs variable.c (was Patches applied...)
Peter Eisentraut [EMAIL PROTECTED] writes: The only thing that I had suggested on occasion was that if nontrivial work were to be put into SET DATESTYLE, we might want to consider if a certain amount of cleanup could be done at the same time. For example, the particular date styles have somewhat unfortunate names, as does the european option. And the parameter could be separated into two. One doesn't have to agree with these suggestions, but without them the work is sufficiently complicated that no one has gotten around to it yet. I think you were mainly concerned that we not define two interacting GUC variables (ie, setting one could have side-effects on the other)? I don't see any inherent reason that DATESTYLE couldn't be imported into GUC as-is. The semantics might be uglier than you'd like, but why would they be any worse than they are now? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GUC vs variable.c (was Patches applied...)
... If you're suggesting setting up an actual database table, I'm not sure I see the point. Any system parameter is going to have to be tied to backend code that knows what to do with the parameter, so it's not like you can expect to do anything useful purely by adding table entries. The C-code tables existing inside guc.c seem like enough flexibility to me. Ah, certainly not! (which is as close as I'll come to saying how foolish! :) You've done work on generalizing the extensibility features of PostgreSQL. A next step to take with that is to allow for a more generic package capability, where packages can be defined, and can have some initialization code run at the time the database starts up. This would allow packages to have their own internal state as extensions to the internal state of the core package. Having SET be extensible is another piece to the puzzle, allowing these kinds of parameters to also be extensible. I'm not sure that this should be considered a part of the GUC design (the parameters are designed to be available *outside* the database itself, to allow startup issues to be avoided, right?) but perhaps GUC should be considered a subset of the actual SET feature set. I got the strong feeling that Hiroshi was concerned that we were intending to lump all SET features into a single one-size-fits-all framework. This may be the flip side of it; just because we like SET to be used in lots of places doesn't mean we should always limit it to things built in to the core. And we should be wary of forcing all things SET to behave with transactional properties if that doesn't make sense. I've always been comfortable with the concept of out of band behavior, which I think is reflected, for example, with DDL vs DML aspects of the SQL language. Current SET behavior aside (where the parser is rejecting SET commands out of hand after errors within a transaction) we should put as few *designed in* restrictions on SET as possible, at least until we are willing to introduce a richer set of commands (that is, something in addition to SET) as alternatives. all imho of course :) - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] failed regression tests
The first symptom is failures in the char regression test... initdb --no-locale Ooh. Thanks, that fixes it. Where would I have found this in the docs? I was looking in the wrong place (in configure/build) rather than at initdb. Should we have something in the release notes? I see (now that I look) that there is a one-liner, but istm that this may deserve a paragraph in the significant changes category. Since once a user do initdb without knowing he is enabling the locale support, the only way to recover from it is doing initdb again. I suggest something like showing a message in the initdb time emphasizing he is enabling the local support. -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] How to know whether a table is locked ?
I read a thread about table lock timeout but don't know whether anything has been done about it. Here is what I'd like to do: I don't want my transactions to be on hold for too long so I'd like to use a syntax I use on INFORMIX already: SET LOCK MODE TO [WAIT [second] | NOT WAIT] I'm using ecpg and I think I'm up to make a patch to it to support the WAIT [second] with the asynchronous functions but I need a way to know whether a statement would lock from the back-end to implement the NOT WAIT. Is there a way?
Re: [HACKERS] commands subdirectory continued -code cleanup
snip and two macros: RECURSE_OVER_CHILDREN(relid); AlterTableDoSomething(childrel,...); RECURSE_OVER_CHILDREN_END; (this seems more straightforward than passing the text of the function call as a macro parameter). The above all looks fine. The other stuff I wouldn't really know about. Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patches applied; initdb time!
Right. The point is that I don't get those (apparently) with -O2 either, with my particular compiler. Hmm. Actually, I *do* get those if I make sure that some of the other options are set too; my quick test added -O2 but left out some of the -w switches. OK, never mind... btw, now that I've started using -O2, my geometry regression test now passes as though it were the standard linux result. It's been a *long* time since that test passed for me, which probably says that it has been quite a while since I didn't force a -O0... - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Schema (namespace) privilege details
Tom Lane writes: [ All the rest looks good to me. ] Databases have two grantable rights: CREATE allows creating new regular (permanent) schemas within the database, while TEMP allows creation of a temp schema (and thus temp tables). Couldn't the temp schema be permanent (and unremovable), and thus the privilege to create temp tables can be handled by GRANT CREATE ON SCHEMA temp. It seems to me that creating an extra type of privilege to be able to create one specific schema that exists by default anyway(?) is overkill. A new database will initially allow both these rights to world. Should it? Shouldn't the database owner have to give out schemas explicitly? This would be consistent with not being able to create subobjects in other people's schemas by default. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Schema (namespace) privilege details
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Databases have two grantable rights: CREATE allows creating new regular (permanent) schemas within the database, while TEMP allows creation of a temp schema (and thus temp tables). Couldn't the temp schema be permanent (and unremovable), and thus the privilege to create temp tables can be handled by GRANT CREATE ON SCHEMA temp. It seems to me that creating an extra type of privilege to be able to create one specific schema that exists by default anyway(?) is overkill. Well, it's not a single schema but a schema-per-backend. I suppose we could do it as you suggest if we invent a prototype pg_temp schema on which the rights can be stuck. But it doesn't seem obviously cleaner to do it that way than to attach the rights to the database. In particular, the idea of cloning a temp schema bothers me: if someone sticks some tables into the prototype schema, should we clone those too upon backend startup? If not, why not? A new database will initially allow both these rights to world. Should it? Shouldn't the database owner have to give out schemas explicitly? This would be consistent with not being able to create subobjects in other people's schemas by default. Well, I've been dithering about that. Zero public rights on creation would clearly be more compatible with the way we handle other kinds of rights. It would also clearly *not* be backwards-compatible with our historical behavior for new databases. It seems relevant here that existing pg_dumpall scripts will fail miserably if CREATE DATABASE does not allow connect/create rights to world by default. Unless you see a way around that, my inclination is to allow rights as I suggested. We could perhaps tighten this up in a release or three, after we've fixed pg_dumpall to do something appropriate. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] few probs with integer timestamps
On FreeBSD/Alpha, current CVS: gmake -C common SUBSYS.o gmake[4]: Entering directory `/home/chriskl/pgsql/src/backend/access/common' gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../.. /../src/include -c -o heaptuple.o heaptuple.c -MMD In file included from ../../../../src/include/utils/timestamp.h:24, from ../../../../src/include/utils/nabstime.h:21, from ../../../../src/include/access/xact.h:19, from ../../../../src/include/utils/tqual.h:19, from ../../../../src/include/access/relscan.h:17, from ../../../../src/include/access/heapam.h:18, from heaptuple.c:23: ../../../../src/include/utils/int8.h:35: warning: `INT64CONST' redefined ../../../../src/include/utils/pg_crc.h:85: warning: this is the location of the previous definition gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../.. /../src/include -c -o indextuple.o indextuple.c -MMD In file included from ../../../../src/include/utils/timestamp.h:24, from ../../../../src/include/utils/nabstime.h:21, from ../../../../src/include/access/xact.h:19, from ../../../../src/include/utils/tqual.h:19, from ../../../../src/include/access/relscan.h:17, from ../../../../src/include/access/heapam.h:18, from indextuple.c:19: ../../../../src/include/utils/int8.h:35: warning: `INT64CONST' redefined ../../../../src/include/utils/pg_crc.h:85: warning: this is the location of the previous definition gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../.. /../src/include -c -o indexvalid.o indexvalid.c -MMD In file included from ../../../../src/include/utils/timestamp.h:24, from ../../../../src/include/utils/nabstime.h:21, from ../../../../src/include/access/xact.h:19, from ../../../../src/include/utils/tqual.h:19, from ../../../../src/include/access/relscan.h:17, from ../../../../src/include/nodes/execnodes.h:17, from ../../../../src/include/nodes/plannodes.h:17, from ../../../../src/include/executor/execdesc.h:19, from ../../../../src/include/executor/executor.h:17, from ../../../../src/include/executor/execdebug.h:17, from indexvalid.c:19: ../../../../src/include/utils/int8.h:35: warning: `INT64CONST' redefined ../../../../src/include/utils/pg_crc.h:85: warning: this is the location of the previous definition ---(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] few probs with integer timestamps
On FreeBSD/Alpha, current CVS: ... ../../../../src/include/utils/int8.h:35: warning: `INT64CONST' redefined ../../../../src/include/utils/pg_crc.h:85: warning: this is the location of the previous definition afaict this is OK (that is, the compiled code should work) until we get the definitions moved around and cleaned up. I'm not sure why I didn't see that multiple definition on my machine... - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
