Re: [HACKERS] Values list-of-targetlists patch for comments (was Re: [PATCHES]
On Aug 2, 2006, at 12:47 , Joe Conway wrote: regression=# create rule r2 as on update to src do insert into log values(old.*, 'old'), (new.*, 'new'); ERROR: VALUES must not contain OLD or NEW references Would it make sense to add a HINT as well, recommending the UNION construct Tom mentioned earlier? On Aug 2, 2006, at 11:52 , Tom Lane wrote: create rule r2 as on update to src do insert into log select old.*, 'old' union all new.*, 'new'; or just use two separate INSERT commands in the rule. Or is the general case too, uh, general for a HINT? Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] float8 regression failure (HEAD, cygwin)
On 01/08/06, Andrew Dunstan [EMAIL PROTECTED] wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Would this do the trick? I think Bruce changed the call convention for run_diff ... are you looking at CVS tip? Otherwise it looks reasonable. You're right. I had forgotten to do a cvs update. Fixed and committed. The cassowary farm member went green, for the first time in history :) Thanks guys, Adrian Maier ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Postgres Process in Kernel Mode?
moises wrote: Hello, I’m new in postgres SQL and I have some questions about the space where postgres process run. 1-Can any body say me what libs use postgres for make system calls, for example LIBC? 2-Can any body talk me if some postgres process can run in Linux kernel space? 3- Some body knows if exist some projects that ports postgres process on Linux kernel space. I was read some source code of postgres, like, Postgres.C and others… I was found C instructions like Printf, that’s prohibitive for Linux kernel applications, for example in kernel mode we use printk. I suppose that postgres are ported in a user space only. I’m Ok? Thanks Moises You can do it (e.g. http://www.yl.is.s.u-tokyo.ac.jp/~tosh/kml/) but why would you want to? PG runs fine in userspace and I can see no particular benefit to being in the kernel. What exactly are you trying to do with it? Are you trying to interface PG with some kernel facility? LL ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Bug with initDB under windows 2003
Hi All, On some windows 2003 machines the initDB process failed with the following error: Running in debug mode.The files belonging to this database system will be owned by user "V_MYUSER".This user must also own the server process. The database cluster will be initialized with locale English_United States.1252. fixing permissions on existing directory E:/Postgres\Data ... okcreating directory E:/Postgres\Data/global ... okcreating directory E:/Postgres\Data/pg_xlog ... okcreating directory E:/Postgres\Data/pg_xlog/archive_status ... okcreating directory E:/Postgres\Data/pg_clog ... okcreating directory E:/Postgres\Data/pg_subtrans ... okcreating directory E:/Postgres\Data/pg_twophase ... okcreating directory E:/Postgres\Data/pg_multixact/members ... okcreating directory E:/Postgres\Data/pg_multixact/offsets ... okcreating directory E:/Postgres\Data/base ... okcreating directory E:/Postgres\Data/base/1 ... okcreating directory E:/Postgres\Data/pg_tblspc ... okselecting default max_connections ... Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.10selecting default shared_buffers ... Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.Access is denied.50creating configuration files ... okcreating template1 database in E:/Postgres\Data/base/1 ... VERSION=8.1.4PGDATA=E:/Postgres\Datashare_path=E:/Program Files/postgres/Database/sharePGPATH=E:/Program Files/postgres/Database/binPOSTGRES_SUPERUSERNAME=V_MYUSERPOSTGRES_BKI=E:/Program Files/postgres/Database/share/postgres.bkiPOSTGRES_DESCR=E:/Program Files/postgres/Database/share/postgres.description The EnterpriseDB database which is based on postgress works fine. After short investigation, I found that this is not the first case this behavior was seen. It seems that the bug is some how connected toaccess permissionfor the'nul' device. The initDB.c trying to run something like: postgres.exe -boot -x0 -F -c shared_buffers=200 -c max_connections=40 template1 "/nul" After looking at EnterpiseDB and some other help I think the PostgreSQL sourceneed to be modifiedand re-direct the output from postgres.exe to a file and grants access (to the file) to the postgres service user. I am willing to contribute and do this fix and appreciate commentsfrom others who already familiar with this issue. Regards DrorWith MSN Spaces email straight to your blog. Upload jokes, photos and more. It's free! It's free!
[HACKERS] DROP/IF_P EXISTS in gram.y
Is there any reason why all DROP statements except DROP CAST have two rules, one with IF_P EXISTS and one without, while DROP CAST uses opt_if_exists? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] DROP/IF_P EXISTS in gram.y
Michael Meskes wrote: Is there any reason why all DROP statements except DROP CAST have two rules, one with IF_P EXISTS and one without, while DROP CAST uses opt_if_exists? With all the others that was the only way to stop getting a grammar conflict, IIRC. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Replication Documentation
Hi, Bruce Momjian wrote: The idea being to define issues like multi/single master, async vs, sync, and mention the projects which are in each category. You could even add shared-nothing vs. shared-disk nodes. Generally I'd say it makes sense to 'educate' people, but does it really make sense to explain all that if there is no replication solution for most of these combinations? I'd vote for an external (not in the documentation) information site about replication solutions. There we can put all the information we see fit (even 'journalistic' ones). I might change my mind once we have multiple replication solutions covering most situations. ;-) I like what and how Chris wrote [1] - an overview over existing and upcomming replication solutions. Regards Markus [1]: I can't find Chris' original message. My answer to it is in the archives, but not the original message. Why is that? (Thread view says 'message not available'). My answer contains Chris' text, though: http://archives.postgresql.org/pgsql-docs/2006-07/msg00019.php ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Hash indexes (was: On-disk bitmap index patch)
Kenneth Marshall wrote: On Fri, Jul 28, 2006 at 12:14:49PM -0500, Jim C. Nasby wrote: On Thu, Jul 27, 2006 at 01:46:01PM -0400, Alvaro Herrera wrote: Jim Nasby wrote: On Jul 25, 2006, at 3:31 PM, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: What would be the use-case for hash indexes ? And what should be done to make them faster than btree ? If we knew, we'd do it ;-) But no one's put enough effort into it to find out. Do they use the same hash algorithm as hash joins/aggregation? If so, wouldn't hash indexes be faster for those operations than regular indexes? The main problem doesn't seem to be in the hash algorithm (which I understand to mean the hashing function), but in the protocol for concurrent access of index pages, and the distribution of keys in pages of a single hash key. This is described in a README file or a code comment somewhere in the hash AM code. Someone needs to do some profiling to find out what the bottleneck really is, and ideally find a way to fix it. What I'm getting at is that I've never seen any explanation for the theoretical use cases where a hash index would outperform a btree. If we knew what kind of problems hash indexes were supposed to solve, we could try and interest people who are solving those kinds of problems in fixing hash indexes. The big win for hash indexes is the idea that searching for a single value should only take 1 I/O operation in a perfect world. Btree can not do that. Hash indexes stored on disk still need a level of indirection -- you've got to look up what range of blocks contains your hash value. How big your table of ranges is depends on how big the hash index is and how big your ranges are. Almost always you can fit that table into a block cached in memory. But, the root of a BTree is often cached in memory too. So there's no advantage for a hash index over a BTree index until the BTree needs to grow to three levels deep, what is that, usually 10,000 or 100,000 records. Beyond that, you're right, the BTree slowly grows deeper while the hash index doesn't. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Values list-of-targetlists patch for comments (was Re:
Joe Conway wrote: Bruce Momjian wrote: Should we wait for someone to actually ask for this before adding it to the TODO list? Probably worth adding it to the TODO list so it doen't get lost. Added: o In rules, allow VALUES() to contain a mixture of 'old' and 'new' references -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Values list-of-targetlists patch for comments (was Re:
Michael Glaesemann wrote: On Aug 2, 2006, at 12:47 , Joe Conway wrote: regression=# create rule r2 as on update to src do insert into log values(old.*, 'old'), (new.*, 'new'); ERROR: VALUES must not contain OLD or NEW references Would it make sense to add a HINT as well, recommending the UNION construct Tom mentioned earlier? Agreed. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: 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] ecpg test suite
I'm in the process of committing the first version of the ecpg regression test suite to CVS. This is not exactly finished work, but it shows OK on all test on my machine and on Joachim's machine. The tests need to be tweaked some before it's finished, but I'd like to hear about what others are seeing soon enough to be able to fix bugs before 8.2. Just run make check in src/interfaces/ecpg and tell us if there is some test that fails. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_dump dumping entire system catalogs
Michael Fuhr wrote: pg_dump in HEAD is dumping the entire contents of system catalogs. New feature? :-( Yes, I see it. My testing didn't show the problem, but I see it now. I will find the cause. It is the new pg_dump flags added yesterday. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Values list-of-targetlists patch for comments (was Re:
Bruce Momjian [EMAIL PROTECTED] writes: Michael Glaesemann wrote: Would it make sense to add a HINT as well, recommending the UNION construct Tom mentioned earlier? Agreed. Done. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ecpg test suite
Michael Meskes wrote: I'm in the process of committing the first version of the ecpg regression test suite to CVS. This is not exactly finished work, but it shows OK on all test on my machine and on Joachim's machine. The tests need to be tweaked some before it's finished, but I'd like to hear about what others are seeing soon enough to be able to fix bugs before 8.2. Just run make check in src/interfaces/ecpg and tell us if there is some test that fails. This should be set up so that we can easily run it on the buildfarm automated setup - the simplest way would probably be with an installcheck target. Feel free to ping me if you need help in making it buildfarm friendly. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Replication Documentation
Peter Eisentraut wrote: Alvaro Herrera wrote: I don't think this sort of material belongs directly into the PostgreSQL documentation. Why not? PostgreSQL documentation (or any product documentation) should be factual: describe what the software does and give advice on its use. This should be mostly independent of the external circumstances, because people will still read that documentation three or four years from now. The proposed text is, at least partially, journalistic: it evaluates competing ideas, gives historical and anecdotal information, reports on current events, and makes speculations about the future. That is the sort of material that is published in periodicals or other volatile media. I can see value in documenting what replication systems are known to work (for some definition of work) with a given release in the documentation for that release. Five years down the road when I'm trying to implement replication for a client who's somehow locked into postgres 8.2 (for whatever reason), it would be very helpful to know that slony1.2 is an option. I don't know if this is sufficient justification. Including a separate page on the history of postgres replication to date also makes some sense, at least to me. It should be relatively easy to maintain. If we do talk about replicatoin, then including a probably separate and presumably quite static page on the taxonomy of replication seems necessary. As Chris notes, the term replication by it'self is can mean quite a number of things. At the summit, we resolved, for precisely these reasons, to keep the journalistic parts on the web site, for clear separation from the shipped product and for easier updates (and for easier reference as well, because the PostgreSQL documentation is not the single obvious place to look for it) and refer to it from the documentation. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Replication Documentation
Hi, Andrew Hammond wrote: I can see value in documenting what replication systems are known to work (for some definition of work) with a given release in the documentation for that release. Five years down the road when I'm trying to implement replication for a client who's somehow locked into postgres 8.2 (for whatever reason), it would be very helpful to know that slony1.2 is an option. I don't know if this is sufficient justification. Please keep in mind, that most replication solutions (that I know of) are quite independent from the PostgreSQL version used. Thus, documenting which version of PostgreSQL can be used with which version of a replication system should better be covered in the documentation of the replication system. Otherwise you would have to update the PostgreSQL documentation for new releases of your favorite replication system - which seems to lead to confusion. Including a separate page on the history of postgres replication to date also makes some sense, at least to me. It should be relatively easy to maintain. I agree that having such a 'replication guide for users of PostgreSQL' is a good thing to have. But I think not much of that should be part of the official PostgreSQL documentation - mainly because the replication solutions are not part of PostgreSQL. Regards Markus ---(end of broadcast)--- TIP 1: 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 bitmap index patch
Tom Lane wrote: Both of these pages say up front that they are considering read-only data. Can I assume read-mostly partitions could use the read-I/O efficient indexes on update-intensive partitions of the same table could use b-tree indexes? All of my larger (90GB+) tables can have partitions that are either almost read-only (spatial data updated one state/country at a time, about quarterly) or are totally read-only (previous months and years historical data). So one of the questions that has to be answered (and the submitters have been entirely mum about) is exactly how bad is the update performance? If it's really awful that's going to constrain the use cases quite a lot, whereas merely a bit slower than btree wouldn't be such a problem. Once we have easy-to-use partitioning, would it be the case that many larger tables will have near-read-only partitions that could use I/O friendlier indexes (GIN? Hash? Bitmap?)? Any examples of a large data set that can't be partitioned into hot areas and read-mostly areas? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Buildfarm failure - asp
Had a buildfarm failure on asp (AIX/gcc), because of an extra space in the Makefile.regress for ecpg. Attached is a patch to allow a clean compile. -rocco ecpg-test-Makefile.patch Description: ecpg-test-Makefile.patch ---(end of broadcast)--- TIP 1: 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] Buildfarm failure - asp
applied. thanks andrew Rocco Altier wrote: Had a buildfarm failure on asp (AIX/gcc), because of an extra space in the Makefile.regress for ecpg. Attached is a patch to allow a clean compile. ---(end of broadcast)--- TIP 1: 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] Standby Mode
Simon, How close do your PITR patches take us to Oracle's Standby Databases? I'm trying to decide whether it's a major features for PR purposes or not. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_dump dumping entire system catalogs
Fixed. Thanks for the report. Glad you thought it was a feature. ;-) --- Bruce Momjian wrote: Michael Fuhr wrote: pg_dump in HEAD is dumping the entire contents of system catalogs. New feature? :-( Yes, I see it. My testing didn't show the problem, but I see it now. I will find the cause. It is the new pg_dump flags added yesterday. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] 8.2 feature set
I am thinking we will portray 8.2 as a release focused on usability improvements. We do have a few large features, like perhaps bit-mapped indexes, but in general, the release has a lot of additions that make things easier to use, rather than adding new features or performance. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: 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] 8.2 feature set
Bruce, I am thinking we will portray 8.2 as a release focused on usability improvements. We do have a few large features, like perhaps bit-mapped indexes, but in general, the release has a lot of additions that make things easier to use, rather than adding new features or performance. This is a discussion for -Advocacy, so I'm crossing it over. If you reply to this, please do NOT cc -hackers. Thanks. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 1: 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] 8.2 feature set
Bruce Momjian wrote: I am thinking we will portray 8.2 as a release focused on usability improvements. We do have a few large features, like perhaps bit-mapped indexes, but in general, the release has a lot of additions that make things easier to use, rather than adding new features or performance. Hum, haven't we seen a lot of performance improvements committed? I'd say 8.2 is performance + usability :-) It's true that we don't have as many major features in 8.2 as compared to 8.1 or 8.0. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Standby Mode
On Wed, 2006-08-02 at 13:05 -0700, Josh Berkus wrote: How close do your PITR patches take us to Oracle's Standby Databases? I'm trying to decide whether it's a major features for PR purposes or not. That was pretty much the sweet spot I was aiming at. Many databases support such functionality. Oracle supports five gradations of functionality, of which we hit first two. There is a sixth level also, which we can hit using Hannu's ideas but thats a roll-your own for now. It would be fair to say that we may support Standby Databases with asynchronous log file shipping. [I have an outstanding question on how to include LWlock support into the archiver, required to flesh out the feature set, and of course assuming these patches being accepted.] -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Standby Mode
Simon Riggs [EMAIL PROTECTED] writes: [I have an outstanding question on how to include LWlock support into the archiver, required to flesh out the feature set, and of course assuming these patches being accepted.] The archiver is deliberately designed not to be connected to shared memory. If you want to change that you'll have to make a very strong case why we should give up the safety and security advantages of it. regards, tom lane ---(end of broadcast)--- TIP 1: 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] 8.2 feature set
Sorry if this is the wrong place for this but as far as I can tell there are only 2 features so far that I've seen discussed on hackers that are looking really good to me. I'm sure all the little changes will add up to a big win but these are the only two that would make me feel an urgent need to go through the hassle of upgrading. 1) Standby mode 2) Improvements to PITR making it easier to set up. If I could have asked for any two features to be implemented in postgres it would probably have been these two, so I am very curious. Are these two features definitely in, definitely out or still up in the air as far as 8.2 in concerned? On Aug 2, 2006, at 4:09 PM, Alvaro Herrera wrote: Bruce Momjian wrote: I am thinking we will portray 8.2 as a release focused on usability improvements. We do have a few large features, like perhaps bit- mapped indexes, but in general, the release has a lot of additions that make things easier to use, rather than adding new features or performance. Hum, haven't we seen a lot of performance improvements committed? I'd say 8.2 is performance + usability :-) It's true that we don't have as many major features in 8.2 as compared to 8.1 or 8.0. -- Alvaro Herrerahttp:// www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] VALUES clause memory optimization (was: Values list-of-targetlists patch...)
Tom Lane wrote: I think we could safely list_free the input list in transformInsertRow as your patch suggests, which would buy back the 144M part. But I don't believe it's safe at all to free the raw_parser output --- the grammar sometimes makes multiple links to the same subtree, eg in BETWEEN. In transformExpr the comment implies that it should be safe to reapply to an already transformed expression. What if we free the raw_parser expression list/cells/nodes and replace it with the as-transformed one? Joe ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] pg_terminate_backend
Since I have a stuck backend without client again, I'll have to kill -SIGTERM a backend. Fortunately, I do have console access to that machine and it's not win32 but a decent OS. For other cases I'd really really really appreciate if that function would make it into 8.2. utils/adt/misc.c says: #*ifdef* NOT_USED //* Disabled in 8.0 due to reliability concerns; FIXME someday *// Datum *pg_terminate_backend*(PG_FUNCTION_ARGS) Well, AFAIR there were no more issues raised about code paths that don't clean up correctly, so can we please remove that comment and make the function live finally? Regards, Andreas ---(end of broadcast)--- TIP 1: 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] pg_terminate_backend
Andreas Pflug wrote: Since I have a stuck backend without client again, I'll have to kill -SIGTERM a backend. Fortunately, I do have console access to that machine and it's not win32 but a decent OS. You do know that on Windows you can use pg_ctl to send a pseudo SIGTERM to a backend, don't you? cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 feature set
On Wednesday 02 August 2006 18:04, Bruce Momjian wrote:
I am thinking we will portray 8.2 as a release focused on usability
improvements. We do have a few large features, like perhaps bit-mapped
indexes, but in general, the release has a lot of additions that make
things easier to use, rather than adding new features or performance.
In theory I agree with you, though it would be nice to get an updated copy of
the release notes before we solidify that judgement. Any eta on when you plan
to do them up? (Yeah, I realize we haven't applied all patches yet)
On a side note... has the on-disk format changed for this release? I don't
recall seeing anything that changed it, but could have easily missed
something.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] 8.2 feature set
Robert Treat wrote: On Wednesday 02 August 2006 18:04, Bruce Momjian wrote: I am thinking we will portray 8.2 as a release focused on usability improvements. We do have a few large features, like perhaps bit-mapped indexes, but in general, the release has a lot of additions that make things easier to use, rather than adding new features or performance. In theory I agree with you, though it would be nice to get an updated copy of the release notes before we solidify that judgement. Any eta on when you plan to do them up? (Yeah, I realize we haven't applied all patches yet) On a side note... has the on-disk format changed for this release? I don't recall seeing anything that changed it, but could have easily missed something. Well if an initdb was not required, I think that would be a huge feature ;) (I know it may not work release over release) Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Rebuilding DB from broken hardrive.
I was trying postgres for about a year and the hard drive died. Using some block copy and other tools I was able to retrieve some data however it's missing directory names. Eventually, I was able to connect to my db. However, when I make a query. It comes back with following messages. WARNING: 4 attrdef record(s) missing dbname ERROR: could not open relation 1663/17230/17235: No such file. When I'm looking at my lost+found folder and recreating /var/lib/data/global and /var/lib/data/base/1. It would be nice to know how each directories are related to each other or at least a pointer to where I should look. Thanks, ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 feature set
Robert Treat wrote: On Wednesday 02 August 2006 18:04, Bruce Momjian wrote: I am thinking we will portray 8.2 as a release focused on usability improvements. We do have a few large features, like perhaps bit-mapped indexes, but in general, the release has a lot of additions that make things easier to use, rather than adding new features or performance. In theory I agree with you, though it would be nice to get an updated copy of the release notes before we solidify that judgement. Any eta on when you plan to do them up? (Yeah, I realize we haven't applied all patches yet) Usually 1-2 weeks before beta starts. On a side note... has the on-disk format changed for this release? I don't recall seeing anything that changed it, but could have easily missed something. I think only the inet data types changed on-disk. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
