Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Greg Stark [EMAIL PROTECTED] writes: uh, since you asked. I think the logic is that, at least with gcc, -g is never harmful since you can compile with -O and -g and then strip later if necessary. Yeah, but ... Does it still default to -g with compilers that cannot do -O and -g together? *Yes*. This is exactly the problem, really. One could reasonably accuse the autoconf developers of FSF imperialism, because they have seen to it that autoconf-based configure scripts will choose non-optimal CFLAGS for non-gcc compilers. These same geeks would be screaming for Microsoft's blood if Microsoft tried comparable tactics, so I don't have a whole lot of sympathy. (Side note: I've been overriding this particular autoconf-ism in libjpeg's configure script since about 1995, so it's not like my antipathy to it is a new subject.) Also, RMS happens to think all binaries should be installed with symbols. I think he's seen far too many emacs bug reports where the user was unable to provide any useful bug report because the binary was stripped. I hear where he's coming from, believe me. But RPM builds generally strip the binaries anyway, so autoconf isn't really accomplishing anything with this that I can see. The mass market won't be providing stack traces with their bug reports, whether the binary has symbols or not. 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] postgres --help-config
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Agreed. I like --dump-config. Better to have the verb first. My only objection to that is that dump suggests you will get some kind of snapshot of current settings, which is not what this facility does. I think people will associate dump with pg_dump, meaning dump out the data. I don't think the snapshot idea will not occur to them. Copy has an in/out capability that doesn't match. --display-config might have the more accurate meaning you were looking for. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Still a few flaws in configure's default CFLAGS
Tom Lane writes: *Yes*. This is exactly the problem, really. One could reasonably accuse the autoconf developers of FSF imperialism, because they have seen to it that autoconf-based configure scripts will choose non-optimal CFLAGS for non-gcc compilers. These same geeks would be screaming for Microsoft's blood if Microsoft tried comparable tactics, so I don't have a whole lot of sympathy. The philosophy of the autotools is to give power to the experienced user (you can set your own CFLAGS) and to give portable defaults to everyone else (-O is technically not portable). Another contributing factor is that the default stems from a different era, one might say, and has been the same for a long time, and changing it now would probably upset as many people as it would please. In other news, if you don't like what autoconf does and you are confident about what your compiler can handle, you are free to set up a config.status file or set CFLAGS in your environment. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_autovacuum and VACUUM FREEZE
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Christopher
Kings-Lynne) transmitted:
Was just wondering if pg_autovacuum watches transaction ids and issues
a vacuum freeze before they roll over?
If not, is it hard to do?
It doesn't do a VACUUM FREEZE; it just does a VACUUM. VACUUM FREEZE
isn't forcibly necessary, although it would be an interesting idea to
do so.
/*
* FIXME: should probably do something better here so that we don't
* vacuum all the databases on the server at the same time. We have
* 500million xacts to work with so we should be able to spread the
* load of full database vacuums a bit
*/
if (dbi-age 15 )
{
PGresult *res = NULL;
res = send_query(VACUUM, dbi);
/* FIXME: Perhaps should add a check for PQ_COMMAND_OK */
PQclear(res);
return 1;
}
--
let name=cbbrowne and tld=acm.org in name ^ @ ^ tld;;
http://www3.sympatico.ca/cbbrowne/
They have finally found the most ultimately useless thing on the web...
Found at the Victoria's Secret website:
The online shop: Text Only Listing
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pg_autovacuum and VACUUM FREEZE
On Thu, 2003-10-16 at 01:34, Christopher Kings-Lynne wrote: Hi, Was just wondering if pg_autovacuum watches transaction ids and issues a vacuum freeze before they roll over? Yes pg_autovacuum monitors for xid wraparound, when it sees that you are getting close, then it issues a database wide vacuum. I intentionally chose not to do a vacuum freeze. The vacuum man page says, FREEZE is not recommnded for routine use. That was enough to keep me away. However if vacuum freeze was considerably lighter than normal database wide vacuums then there might be an advantage to using it. Especially since when pg_autovaccum decides it's time to deal with xid wraparound, it does it to all the databases, which could a several hours of vacuum on large clusters. Relevant section of man page below: FREEZE is a special-purpose option that causes tuples to be marked frozen as soon as possible, rather than waiting until they are quite old. If this is done when there are no other open transactions in the same database, then it is guaranteed that all tuples in the database are frozen and will not be subject to transaction ID wraparound problems, no matter how long the database is left un-vacu- umed. FREEZE is not recommended for routine use. Its only intended usage is in connection with preparation of user-defined template databases, or other databases that are completely read-only and will not receive routine maintenance VACUUM operations. See the Administra- tors Guide for details. Matthew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_autovacuum and VACUUM FREEZE
Matthew T. O'Connor [EMAIL PROTECTED] writes: The vacuum man page says, FREEZE is not recommnded for routine use. That was enough to keep me away. However if vacuum freeze was considerably lighter than normal database wide vacuums then there might be an advantage to using it. If anything it would be slower than normal vacuum (more pages touched). I concur with just using plain VACUUM to deal with impending wraparound. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Still a few flaws in configure's default CFLAGS
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: [ griping about autoconf's default choices for CFLAGS ] The philosophy of the autotools is to give power to the experienced user (you can set your own CFLAGS) and to give portable defaults to everyone else (-O is technically not portable). It'd be nicer if they had tried to give *useful* defaults to everyone else. The existing behavior is reasonable for people testing beta-quality software, but it's not a helpful choice for production code. It's great that someone who knows what they're doing can override it, but right now I'm concerned with the default build behavior for people who don't know. Another contributing factor is that the default stems from a different era, one might say, and has been the same for a long time, and changing it now would probably upset as many people as it would please. FWIW, I've been overriding the default CFLAGS to be -O for non-gcc in libjpeg's configure script since [...digs...] release 6b of March 1998. I've yet to hear any complaint about it, and that code is used on a much wider variety of systems than Postgres runs on. So my opinion is that -O is perfectly portable and unlikely to upset anyone for production code --- especially when configure advertises a switch to select -g instead. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] pg_autovacuum and VACUUM FREEZE
The vacuum man page says, FREEZE is not recommnded for routine use. That was enough to keep me away. However if vacuum freeze was considerably lighter than normal database wide vacuums then there might be an advantage to using it. Especially since when pg_autovaccum decides it's time to deal with xid wraparound, it does it to all the databases, which could a several hours of vacuum on large clusters. Each database has it's own last xid. Just because one database is about to go over the limit doesn't mean they all are. Why don't you treat each database independently in this regard (then they wouldn't necessarily all be kicked off at once). signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Database Kernels and O_DIRECT
[EMAIL PROTECTED] (Andrew Dunstan) writes:
Tom Lane wrote:
James Rogers [EMAIL PROTECTED] writes:
If we suddenly wanted to optimize Postgres for performance the way
Oracle does, we would be a lot more keen on the O_DIRECT approach.
This isn't ever going to happen, for the simple reason that we don't
have Oracle's manpower.
[snip - long and sensible elaboration of above statement]
I have wondered (somewhat fruitlessly) for several years about the
possibilities of special purpose lightweight file systems that could
relax some of the assumptions and checks used in general purpose file
systems. Such a thing might provide most of the benefits of a
database kernel without imposing anything extra on the database
application layer.
Just a thought - I have no resources to make any attack on such a project.
There is an exactly relevant project for this, namely Hans Reiser's
ReiserFS, on Linux.
http://www.namesys.com/whitepaper.html
In Version 4, they will be exporting an API that allows userspace
applications to control the use of transactional filesystem updates.
If someone were to directly build a database on top of this, one might
wind up with some sort of ReiserSQL, which would be relatively
analagous to the database kernel approach.
Of course, the task would be large, and it would likely take _years_
for it to stabilize to the point of being much more than a neat
hack.
The other neat approach that would be more relevant to PostgreSQL
would be to create a filesystem that stored data in pure blocks, with
pretty large block sizes, and low overhead for saving directory
metadata. There isn't too terribly much interest in {a,o,m}time...
--
output = reverse(ofni.smrytrebil @ enworbbc)
http://dev6.int.libertyrms.com/
Christopher Browne
(416) 646 3304 x124 (land)
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Dreaming About Redesigning SQL
[EMAIL PROTECTED] (Seun Osewa) wrote: [snip] Sometimes I wonder why its so important to model data in the rela- tional way, to think of data in form of sets of tuples rather than tables or lists or whatever. I mean, though its elegant and based on mathematical principles I would like to know why its the _right_ model to follow in designing a DBMS (or database). The way my mind sees it, should we not rather be interested in what works? How do you know it works? Without the theory and model, you really do not. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Question about debugger
Hello, I'm a student who use postgresql. I'd like to debug postgres source code.I tried to use ddd in linux. The thing what I want to do is debugging backend part.How can I do that. The commands that I used until now are following. 1. ddd postgres 2. In the ddd,I tried to attach pid. (but I can't find pid about backend) 3. When I tried to run program with break point,I met error like can't find 2003-10-15(that is the date and time when I run). So,I'm not sure how can I use ddd. Could let me know how can I use this? ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Some thoughts about i/o priorities and throttling vacuum
I think adding tunable delay per-page loop into VACUUM will help keep system responsive at all times. In many cases, especially for mostly read-only tables, plain VACUUM does not need to complete immediately (VACUUM FULL should complete immediately). I prefer that VACUUM takes its sweet time to run as long as it doesn't disrupt other queries. See my other post on VACUUM degrades performance significantly. Database becomes unusable! on pgsql-general mailing list. Regards, Stephen Tom Lane [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Greg Stark [EMAIL PROTECTED] writes: ... vacuum could throttle its own disk accesses by, say, reading 64k at a time then sleeping for a fraction of a second. ... Personally I think i/o priorities give much better leverage. Pie in the sky is great too ;-). But there is no such thing as i/o priorities, at least not in any portable sense. OTOH I was just musing to myself earlier today that putting a tunable delay into VACUUM's per-page loop might make it more friendly to competing processes. I dunno if it'd work or just be a waste of time, but it does seem worth experimenting with. Want to try it out and report back? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_autovacuum and VACUUM FREEZE
On Thu, 2003-10-16 at 10:16, Rod Taylor wrote: The vacuum man page says, FREEZE is not recommnded for routine use. That was enough to keep me away. However if vacuum freeze was considerably lighter than normal database wide vacuums then there might be an advantage to using it. Especially since when pg_autovaccum decides it's time to deal with xid wraparound, it does it to all the databases, which could a several hours of vacuum on large clusters. Each database has it's own last xid. Just because one database is about to go over the limit doesn't mean they all are. Why don't you treat each database independently in this regard (then they wouldn't necessarily all be kicked off at once). My choice of words above was poor, let me try again. pg_autovacuum does treat each database independently, however assuming that you never manually run vacuum (which is the eventual goal of pg_autovacuum), then database wide vacuums will have never been run on any table in any database, so all databases will approach xid wraparound at the same time. So, pg_autovacuum does deal with them separately, but doesn't make an effort to spread out the vacuums if all / multiple databases happen to need it at the same time. In practice, I don't see this as a big problem right now, but it should still be handled better by pg_autovacuum. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] elog tab indentation
I observe that the server log is now indenting DETAIL/HINT lines: LOG: server process (PID 8468) was terminated by signal 6 LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. LOG: all server processes terminated; reinitializing This is not the behavior I thought we agreed to. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] elog tab indentation
Tom Lane wrote: I observe that the server log is now indenting DETAIL/HINT lines: LOG: server process (PID 8468) was terminated by signal 6 LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. LOG: all server processes terminated; reinitializing This is not the behavior I thought we agreed to. I thought DETAIL/HINT would be separate elog calls, and hence start at the beginning of the line. Are they all in on big elog string? Sure looks like it from the output. Do we have to check the beginning of the string for [A-Z]*:? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg_autovacuum and VACUUM FREEZE
So, pg_autovacuum does deal with them separately, but doesn't make an effort to spread out the vacuums if all / multiple databases happen to need it at the same time. In practice, I don't see this as a big problem right now, but it should still be handled better by pg_autovacuum. I understand now, and yes, it does make sense to try to level off spikes in vacuum requests so that there is an even flow. signature.asc Description: This is a digitally signed message part
Re: [HACKERS] postgres --help-config
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Agreed. I like --dump-config. Better to have the verb first. My only objection to that is that dump suggests you will get some kind of snapshot of current settings, which is not what this facility does. I don't have an especially good alternative though ... --describe-config is the only thought that comes to mind right away. I just realized that --help-config doesn't output the contents of postgresql.conf at all, but just the internal server defaults. Does the admin tool read postgresql.conf too and parse that to get the runtime values, and how does it know if the postmaster is using the current postgresql.conf contents or it needs a SIGHUP? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Some thoughts about i/o priorities and throttling vacuum
Stephen wrote: I think adding tunable delay per-page loop into VACUUM will help keep system responsive at all times. In many cases, especially for mostly read-only tables, plain VACUUM does not need to complete immediately (VACUUM FULL should complete immediately). I prefer that VACUUM takes its sweet time to run as long as it doesn't disrupt other queries. See my other post on VACUUM degrades performance significantly. Database becomes unusable! on pgsql-general mailing list. Of course, this makes VACUUM run longer, and if you are waiting for it to finish, it would be worse, like if you are running it at night or something. I think the delay has to take into account the number of active transactions or something. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Tom Lane wrote: Greg Stark [EMAIL PROTECTED] writes: uh, since you asked. I think the logic is that, at least with gcc, -g is never harmful since you can compile with -O and -g and then strip later if necessary. Yeah, but ... Does it still default to -g with compilers that cannot do -O and -g together? *Yes*. This is exactly the problem, really. One could reasonably accuse the autoconf developers of FSF imperialism, because they have seen to it that autoconf-based configure scripts will choose non-optimal CFLAGS for non-gcc compilers. These same geeks would be screaming for Microsoft's blood if Microsoft tried comparable tactics, so I don't have a whole lot of sympathy. (Side note: I've been overriding this particular autoconf-ism in libjpeg's configure script since about 1995, so it's not like my antipathy to it is a new subject.) Also, RMS happens to think all binaries should be installed with symbols. I think he's seen far too many emacs bug reports where the user was unable to provide any useful bug report because the binary was stripped. I hear where he's coming from, believe me. But RPM builds generally strip the binaries anyway, so autoconf isn't really accomplishing anything with this that I can see. The mass market won't be providing stack traces with their bug reports, whether the binary has symbols or not. Also, -g is not the opposite of strip. A default compile adds function name symbols. -g adds debug symbols, strip removes all symbols, so a compile that uses -g and strip has fewer symbols than one that does a compile without -g and without strip. Also, I thought Peter advocated adding -g a few releases back. I didn't agree, but I lost the vote, so I thought it was done. Were we supresssing -g in older releases? Peter? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] elog tab indentation
Bruce Momjian [EMAIL PROTECTED] writes: I thought DETAIL/HINT would be separate elog calls, and hence start at the beginning of the line. Are they all in on big elog string? Yes --- that's to try to ensure that the whole mess gets written to the log atomically. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] postgres --help-config
Bruce Momjian [EMAIL PROTECTED] writes: I just realized that --help-config doesn't output the contents of postgresql.conf at all, but just the internal server defaults. Does the admin tool read postgresql.conf too and parse that to get the runtime values, and how does it know if the postmaster is using the current postgresql.conf contents or it needs a SIGHUP? The tool is using the output to help people create postgresql.conf. The postmaster isn't running. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian [EMAIL PROTECTED] writes: Also, I thought Peter advocated adding -g a few releases back. I didn't agree, but I lost the vote, so I thought it was done. Were we supresssing -g in older releases? Peter? I don't recall any such vote. Had we done that, we'd have removed --enable-debug, I'd think. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] elog tab indentation
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I thought DETAIL/HINT would be separate elog calls, and hence start at the beginning of the line. Are they all in on big elog string? Yes --- that's to try to ensure that the whole mess gets written to the log atomically. Oh, makes sense. How do you propose we split this up? Do I look for the words \nDETAIL and \nHINT and not tab in those cases? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Also, I thought Peter advocated adding -g a few releases back. I didn't agree, but I lost the vote, so I thought it was done. Were we supresssing -g in older releases? Peter? I don't recall any such vote. Had we done that, we'd have removed --enable-debug, I'd think. The vote was whether -g should be used for a default compile. Of course --enable-debug would continue using -g. Maybe we kept --enable-debug for backward compatibility or to force -g if you modified CFLAGS? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] elog tab indentation
Bruce Momjian [EMAIL PROTECTED] writes: Oh, makes sense. How do you propose we split this up? Do I look for the words \nDETAIL and \nHINT and not tab in those cases? That won't work. I think the tab-insertion has to be done while building the message string, earlier in send_message_to_server_log where we still know what's data and what's a keyword. I'll see what I can do with it. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian [EMAIL PROTECTED] writes: The vote was whether -g should be used for a default compile. Of course --enable-debug would continue using -g. Maybe we kept --enable-debug for backward compatibility or to force -g if you modified CFLAGS? I can't see why we would have kept --enable-debug if we intended to make -g be default anyway. Backwards compatibility is not an issue, because configure simply ignores --enable switches it doesn't recognize (another questionable autoconf design decision, but I digress). And if you are setting CFLAGS for yourself, you are surely capable of adding -g to it if you want; why would you type seven times as much to accomplish the same thing? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The vote was whether -g should be used for a default compile. Of course --enable-debug would continue using -g. Maybe we kept --enable-debug for backward compatibility or to force -g if you modified CFLAGS? I can't see why we would have kept --enable-debug if we intended to make -g be default anyway. Backwards compatibility is not an issue, because configure simply ignores --enable switches it doesn't recognize (another questionable autoconf design decision, but I digress). And if you are setting CFLAGS for yourself, you are surely capable of adding -g to it if you want; why would you type seven times as much to accomplish the same thing? The discussion mentions the problem with keeping --enable-debug: http://archives.postgresql.org/pgsql-hackers/2002-04/msg00281.php I am not sure that Peter actually implemented it, but when I started seeing -g flags in the compile, I assumed it had been done. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Also, I thought Peter advocated adding -g a few releases back. I didn't agree, but I lost the vote, so I thought it was done. Were we supresssing -g in older releases? Peter? I don't recall any such vote. Had we done that, we'd have removed --enable-debug, I'd think. The vote was whether -g should be used for a default compile. Of course --enable-debug would continue using -g. Maybe we kept --enable-debug for backward compatibility or to force -g if you modified CFLAGS? Here is the thread discussing the -g flag: http://archives.postgresql.org/pgsql-hackers/2002-04/msg00281.php -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Some thoughts about i/o priorities and throttling vacuum
Bruce Momjian [EMAIL PROTECTED] writes: Of course, this makes VACUUM run longer, and if you are waiting for it to finish, it would be worse, like if you are running it at night or something. My plan was that the time delay would be a parameter and pg_autovacuum would set it based on the observed rate at which free space is accumulating. Someone could manually specify a delay, but by default it would run with no delay when run on the command line. I think the delay has to take into account the number of active transactions or something. That's a possibility. That's actually what the linux-kernel folk suggested. Someone there suggested using aio to do carefully schedule i/o only when no i/o was pending from transactions. But vacuum has no way to judge whether those transactions are really doing much disk i/o or only reading cached blocks, or even whether the disk i/o they're doing is on the same disk. They could also be waiting on the client or on locks from other transactions. -- greg ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Bison 1.875 for SuSE Linux 8.1?
Folks, I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford to upgrade right now. Does such an animal exist? Help! -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Some thoughts about i/o priorities and throttling vacuum
On Thu, 2003-10-16 at 16:16, Greg Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: Of course, this makes VACUUM run longer, and if you are waiting for it to finish, it would be worse, like if you are running it at night or something. My plan was that the time delay would be a parameter and pg_autovacuum would set it based on the observed rate at which free space is accumulating. I don't know that pg_autovacuum is smart enough to make a good guess as to an appropriate parameter. I think the delay has to take into account the number of active transactions or something. I think this is a better plan than pg_autovacuum, this would also allow vacuum to have a different delay for each loop depending on the current number of transactions. But vacuum has no way to judge whether those transactions are really doing much disk i/o or only reading cached blocks, or even whether the disk i/o they're doing is on the same disk. They could also be waiting on the client or on locks from other transactions. True, it would be a rough estimate, but at least one based on something representative of system I/O load at that moment. ---(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] Bison 1.875 for SuSE Linux 8.1?
Josh Berkus writes: I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford to upgrade right now. Does such an animal exist? Help! Install it from source if you cannot find a package. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Peter Eisentraut wrote: Josh Berkus writes: I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford to upgrade right now. Does such an animal exist? Help! Install it from source if you cannot find a package. or build from an SRPM - the dependencies are quite modest, I believe cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] postgres --help-config
Tom Lane writes: The tool is using the output to help people create postgresql.conf. The postmaster isn't running. But how do you alter postgresql.conf it it already exists but you don't know the current values? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] postgres --help-config
Tom Lane writes: I don't have an especially good alternative though ... --describe-config is the only thought that comes to mind right away. I like that. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] postgres --help-config
Tom Lane writes: I think there are two ways this can be resolved: 1) Leave it this way, deal with it, but then we can put everything in one field and let the software parse out the first sentence automatically. True. 2) Make real separate short and long descriptions. We'd have to break the strings freeze to do that. How bad do you want it? I like the first option. But we'll have to break the string freeze either way. -- 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] Bison 1.875 for SuSE Linux 8.1?
Peter, I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford to upgrade right now. Does such an animal exist? Help! Install it from source if you cannot find a package. Hmmm ... still getting the Bison Too Old warning message. How can I tell where Postgres is looking for Bison? -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Peter, If you installed from source into /usr/local/bin and you have an older version in /usr/bin, you may need to run 'hash -r' or 'rehash' to make the shell forget about the old installation in the path. Yeah, that was it. Thanks! (I predict that we're going to get many more questions about Bison after we release 7.4, since many major Linux distros don't yet include 1.875) -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Some more information_schema issues
I looked through all the information_schema stuff, and found a few more nits. The CHECK_CONSTRAINTS view should use pg_get_constraintdef() function rather than consrc, for the same reasons as psql should (I haven't fixed the latter yet, but will soon). There are several views that display pg_type.typname directly. I wonder whether any of these ought to be using format_type() instead. It won't matter for the views that only show domains, but several could potentially show standard types. Don't we want the output to be character rather than bpchar? It would be a small efficiency boost to use UNION ALL rather than UNION where possible. READ COMMITED should be READ COMMITTED in sql_implementation_info. In sql_sizing, MAXIMUM COLUMNS IN SELECT should be 1664 (MaxTupleAttributeNumber). Several views get fixed pg_class OIDs like this: AND d.refclassid = (SELECT oid FROM pg_class WHERE relname = 'pg_class') This is unsafe --- suppose a user creates a table named pg_class in one of his own schemas? The SELECT would return multiple rows, causing a runtime error. What I would recommend is coding these like AND d.refclassid = 'pg_catalog.pg_class'::regclass which is schema-safe and also rather more efficient, since the planner will see this as a simple constant instead of a sub-query. The ELEMENT_TYPES view doesn't work --- it returns zero rows. After some fooling around I think it's a simple typo: the line AND (n.nspname, x.objname, x.objtype, x.objtypeid) IN should be AND (n.nspname, x.objname, x.objtype, x.objdtdid) IN regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
On Fri, 17 Oct 2003 09:43 am, Josh Berkus wrote: (I predict that we're going to get many more questions about Bison after we release 7.4, since many major Linux distros don't yet include 1.875) You only need bison if you are building from CVS - tarballs include the bison output files (AFAIK - correct me if I am mistaken anyone). Regards, Philip. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] postgres --help-config
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: The tool is using the output to help people create postgresql.conf. The postmaster isn't running. But how do you alter postgresql.conf it it already exists but you don't know the current values? You read postgresql.conf to extract the non-comment lines, and overlay those on the default values you got from --help-config. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] postgres --help-config
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: I think there are two ways this can be resolved: 1) Leave it this way, deal with it, but then we can put everything in one field and let the software parse out the first sentence automatically. True. I like the first option. But we'll have to break the string freeze either way. Fernando pointed out to me that the separate-fields approach does help make it obvious that the first sentence of the description has special status and needs to be able to stand on its own. If we merge the descriptions into one field, it'll be easier to make the kind of mistake I made with check_function_bodies. So I'm back to the opinion that the current setup is not broken, other than that the fields are misleadingly named, which we could fix easily. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Some thoughts about i/o priorities and throttling vacuum
Bruce Momjian [EMAIL PROTECTED] writes: Of course, this makes VACUUM run longer, and if you are waiting for it to finish, it would be worse, like if you are running it at night or something. I think the delay has to take into account the number of active transactions or something. I was just thinking of a GUC parameter: wait N milliseconds between pages, where N defaults to zero probably. A user who wants to run his vacuum as a background process could set N larger than zero. I don't believe we are anywhere near being able to automatically adjust the delay based on load, and even if we could, this would ignore the point you make above --- the user's intent has to matter as much as anything else. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Josh Berkus [EMAIL PROTECTED] writes: (I predict that we're going to get many more questions about Bison after we release 7.4, since many major Linux distros don't yet include 1.875) No, because it only matters to people who build from a CVS pull instead of using a tarball. I'd think most of the people in the first category have already dealt with the issue... 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] Bison 1.875 for SuSE Linux 8.1?
TOm, No, because it only matters to people who build from a CVS pull instead of using a tarball. I'd think most of the people in the first category have already dealt with the issue... Really? 'cause I got the warning from the Beta4 tarball. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Josh Berkus [EMAIL PROTECTED] writes: No, because it only matters to people who build from a CVS pull instead of using a tarball. I'd think most of the people in the first category have already dealt with the issue... Really? 'cause I got the warning from the Beta4 tarball. If you mean the configure warning, sure, but the build won't fail. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Some more information_schema issues
I looked through all the information_schema stuff, and found a few more nits. I notice that most of the references in the information_schema.sql are not schema-qualfied. eg: FROM (pg_namespace ncon INNER JOIN pg_constraint con ON ncon.oid Shouldn't that be: FROM (pg_catalog.pg_namespace ncon INNER JOIN pg_catalog.pg_constraint .. Because what I'm concerned about is that if my personal schema (chriskl) has a table called 'pg_catalog' or a function called '_pg_keysequal', then if I go 'SELECT * FROM INFORMATIONS_SCHEMA.someview', then it will break? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Some more information_schema issues
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I notice that most of the references in the information_schema.sql are not schema-qualfied. They don't need to be, because the references will be resolved when the views are parsed during initdb. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Some more information_schema issues
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I notice that most of the references in the information_schema.sql are not schema-qualfied. They don't need to be, because the references will be resolved when the views are parsed during initdb. On second thought, you do have a point with regard to those newly-added SQL functions. Names used within the texts of those functions need to be fully qualified for safety. 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] Question about debugger
On Wed, 2003-10-15 at 11:43, [EMAIL PROTECTED] wrote: Hello, I'm a student who use postgresql. I'd like to debug postgres source code.I tried to use ddd in linux. The thing what I want to do is debugging backend part.How can I do that. The commands that I used until now are following. 1. ddd postgres 2. In the ddd,I tried to attach pid. (but I can't find pid about backend) 3. When I tried to run program with break point,I met error like can't find 2003-10-15(that is the date and time when I run). So,I'm not sure how can I use ddd. Could let me know how can I use this? If you'd like info on using ddd, read the ddd docs or ask on their mailing list -- there shouldn't be anything particularly unique about using ddd on PostgreSQL rather than any other program that uses fork(). In any case, it's pretty straightforward to use gdb. I do the following: 1. build PostgreSQL with --enable-debug. Also, debugging is less painful if you use CFLAGS='-O0'. 2. start up PostgreSQL and connect to it 3. find the PID of the postgres backend using ps or some equivalent 4. run 'gdb -p xxx', where xxx is the PID of the postgres backend process -- then set breakpoints, and all that jazz. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
