Re: [HACKERS] [JDBC] V3 protocol + DECLARE problems
Tom Lane wrote:
BTW, rather than hacking the parameter list of ProcessUtility,
I'd be inclined to just look at ActivePortal-portalParams in
PerformCursorOpen. (Come to think of it, we could also copy
ActivePortal's sourceText at the PortalDefineQuery step.)
I've done this and it seems to work fine for the V3 protocol case.
However there are some callers of ProcessUtility that do not set
ActivePortal: SPI and the SQL function code. These suffer from
essentially the same problem as with the V3 protocol, for example:
test=# create function f1(text) returns void as $$
test$# declare c cursor for select * from pg_type where typname like $1;
test$# $$ language sql;
CREATE FUNCTION
test=# begin;
BEGIN
test=# select f1('%');
f1
(1 row)
test=# fetch all from c;
ERROR: no value found for parameter 1
SPI has a similar path via SPI_execp - _SPI_execute_plan.
So it looks like I'll have to go back to passing a parameter list to
ProcessUtility; even if we don't need to support the SPI/SQL function
cases, it seems that ActivePortal is not guaranteed to point to the
right parameter values.
-O
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] resowner.c $PostgreSQL$
Is it just me or the resowner.c file does not have $PostgreSQL$ expanded? May it be related to the fact that I'm using CVSup? However I have the line tag=PostgreSQL=CVSHeader in CVSROOT/options ... Also I see that in all files, the $PostgreSQL$ tag shows a version number that's one less than the actual version number of the file (shown with cvs log). Can this be a local config error or something strange is happenning? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Los románticos son seres que mueren de deseos de vida ---(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] Planning for beta (was Re: Sketch of extending error handling
On Sun, 2004-07-25 at 04:22, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Other than the spectacular lack of documentation, I don't think we are in bad shape at all. OK, that helps. Alvaro had a number of items floating around and I wasn't sure where he was on them. Same with PITR. Once the number of open items for a project is over about six, I get lost. Is there a sense you and the patch authors have identified them all and are working on them so I don't have to worry about them? I don't care if they aren't done as much as I don't want them to be forgotten. I think we know what we have to do. Alvaro, Simon, do you feel that we are on track for beta at the end of the month? Could you post your current to-do lists for NT and PITR? Yes, I feel we are on track for beta. All known/reported bugs located and solved. Issue that Create Database doesn't generate redo not addressed, but lower priority issue. The TODO list below is about a third of what it was about 8 days ago. All the refactoring I'd thought about is done, some error pockets cleaned up - as well as a few investigations that I hadn't had time for. I'm personally expecting to deliver these before Beta... 1. today (not in SGML) 2. design posted today PITR TODO for 7.5 = HIGH 1. Documentation (sr) (now) - Backup and Recovery chapter - WAL chapter MEDIUM 2. Start/End Backup: Parameter value sanity, e.g. - is recoveryTargetTime last checkpoint time - is recoveryTargetTime backup end time - is recoveryTargetXid last checkpoint xid - is recoveryTargetXid backup end txnid 3. Full test plan - same status as regression tests - allow re-test of functionality - confirm viability on all ports - re-write example scenarios into more of a test plan, so people can see what's been tested and what to test their port against - test scripts - test server against those 4. Off-line log inspector (sr) (aug/sept) - Locate a potential recovery point - Confirm that the logs have the potential for recovery (to that point) 5. Write logging/redo for resource managers/action types - Create Database (aug/sept?) - any others? LOWER 6. Performance testing OTHER - related to WAL, but not PITR 7. PreallocXlogFiles Comments, suggestions and additions welcome. All assistance in completing the above is most welcome, -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.5 release notes
On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote: I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. Looks good. These take time and effort, much appreciated. Forward-looking phrases === Overall, I'd ask that we don't refer back to what earlier releases didn't do, or whatever limitations they were thought to have. If a release has new feature X, everybody can work out it wasn't there in the last release. The phrasing is delicate so you describe the new thing without running down the old. e.g. (1) Previous releases required the Unix emulation toolkit Cygwin for Win32 support. to The server no longer relies upon Cygwin for Unix emulation under win32. e.g. (2) Prior release had no such capability; there was no way to recover from a statement failure in a transaction. to Should a statement fail inside a transaction, there is now a way to handle this error and continue processing. (Of course, somebody will let me know about my Brit-style passive voice, I'm sure...) Migration = These release notes refer to GUCs, whereas the previous release notes and the manual refers to server configuration parameters. I understand the former, but prefer the latter description for these user-focused notes. Also, it might be worth mentioning that pg_dump itself has also been substantially improved, and now provides an improved upgrade path for existing users. Here's my attempt at a short paragraph for PITR... Point-In-Time Recovery enhances Data Resilience PostgreSQL can now recover from total disk failure using backups and transaction log archives. Recovery can be controlled to stop at a specified point in time or at some transaction in the past. Transaction log archiving is automated and calls a user-supplied external program to allow integration with external backup devices and related software. Do people want a big-picture paragraph at the top talking about the release? Some releases get them, some don't, but this one could if folks want it. Yes, thats a good idea. Best Regards, Simon Riggs ---(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] 7.5 release notes
Bruce Momjian said: I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. I presume we can also just make some comments ;-) this item: Add new GUC parameter to report useful information at the start of each log line should probably read Add new GUC parameter log_line_prefix . I think this item belongs to me, or me and Tom: Replace the virtual_host and tcpip_socket parameters with a unified listen_addresses parameter. Conversely, Tom deserves joint billing for dollar quoting, as most of what I did was based on his work. David Fetter should be mentioned under the dollar quoting and plperl items, as he did documentation for both. Tom's implementation of a new flex-based lexer for psql is a significant source code change which should be mentioned. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] pg_ctl and failing postmaster
When postmaster fails to run due to e.g. datadir being set to 755, 'pg_ctl start' incorrectly reports postmaster successfully started. I'm not sure how to fix this though. Do a [shorter] wait for 'start' mode by default? Install a child handler (can you even do that with shell script?) This is postgresql 7.4.3 on Linux. -- dave ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] postmaster.opts, moving datadir around, and pg_ctl
I had datadir in /dir1 and I started postmaster with: postmaster -D /dir1 this recorded -D /dir1 in /dir1/postmaster.opts. Then I stopped postmaster and moved /dir1 to /dir2. I then started postmaster with: PG_DATA=/dir2 pg_ctl start It worked normally. But: PG_DATA=/dir2 pg_ctl restart failed when starting postmaster because it used datadir from postmaster.opts (/dir1). This worked though: pg_ctl restart -D /dir2 So there's a slight inconsistency between the start and restart command. Would it be nicer if postmaster doesn't record -D in postmaster.opts, or if pg_ctl strips it? Or is it entirely my fault for not adjusting postmaster.opts when I move datadir around? IMO it would be nice if datadir is portable (i.e. it doesn't contain its own full path). Also pardon my ignorance, but what is the purpose of having postmaster.opts inside datadir? This is postgresql 7.4.3 on Linux. -- dave ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [DOCS] 7.5 release notes
On Sun, Jul 25, 2004 at 00:25:43 -0400, Bruce Momjian [EMAIL PROTECTED] wrote: I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. There is a typo (transaction is misspelled) in the following line: Prior release had no such capability; there was no way to recover from a statement failure in a transation. This match exactly at the end of the following appears to be spurious: Before this change some queries would not use an index if the data types did not exactly match. This improvement makes index usage more intuitive and consistent. match exactly In the following paragraph there appear to be two typos. I think optimizer make should be optimizer makes and that lose-source should be closed-source. It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustments to the logic used to select indexes, join methods, and join order. They are difficult to explain, but the result is that the optimizer make quicker and better choices in how to execute queries, resulting in improved performance. The close relationship between our developers and users reporting problems allows us to make rapid and complex optimizer improvements that would be very difficult for lose-source companies to emulate. ---(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] Planning for beta (was Re: Sketch of extending error
On Sun, 25 Jul 2004, Simon Riggs wrote: HIGH 1. Documentation (sr) (now) - Backup and Recovery chapter - WAL chapter Docs, as always, can be delivered/improved throughout beta ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] 7.5 release notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote: |I have completed the 7.5 release notes. You can view them in HTML on |the developer web page. I have marked a few items with question marks |that need to be addressed. I am looking for improvements, even minor |ones. Either send in a patch or committers can modify the file |directly. Did you forget to insert the autovacuum integrated ? Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBA+cZ7UpzwH2SGd4RAgQwAKD11vpcxmsjkwdJABDMEpe27NS0HQCg1DVq qnZ1ZENnFUVD0nl358vpxj4= =WE9n -END PGP SIGNATURE- ---(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] resowner.c $PostgreSQL$
Alvaro Herrera [EMAIL PROTECTED] writes: Is it just me or the resowner.c file does not have $PostgreSQL$ expanded? I see *$PostgreSQL: pgsql-server/src/backend/utils/resowner/resowner.c,v 1.1 2004/07/17 03:30:10 tgl Exp $ May it be related to the fact that I'm using CVSup? Probably. It sure sounds like *something* in your setup doesn't know that that's a keyword. Also I see that in all files, the $PostgreSQL$ tag shows a version number that's one less than the actual version number of the file (shown with cvs log). Can this be a local config error or something strange is happenning? This is exactly what I'd expect with a setup unaware of the keyword. AIUI, the keyword substitution is done during checkout. When you check in, you are supplying a file with what is about to become the former value of the keyword string, and since cvs commit doesn't really treat keywords specially, that value is what is actually in the cvs database's new version of the file. You can see similar things happening in our cvsweb interface, since Marc still hasn't fixed it to know about $PostgreSQL$ :-(. For instance go to http://developer.postgresql.org/cvsweb.cgi/pgsql-server/GNUmakefile.in.diff?r1=1.38r2=1.39 and take a close look at the reported diff in $PostgreSQL$ lines. 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] [DOCS] 7.5 release notes
Bruno Wolff III [EMAIL PROTECTED] writes: In the following paragraph there appear to be two typos. I think optimizer make should be optimizer makes and that lose-source should be closed-source. It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustments to the logic used to select indexes, join methods, and join order. They are difficult to explain, but the result is that the optimizer make quicker and better choices in how to execute queries, resulting in improved performance. The close relationship between our developers and users reporting problems allows us to make rapid and complex optimizer improvements that would be very difficult for lose-source companies to emulate. I'd suggest removing the paragraph entirely, on the grounds that it is content-free fluff. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.5 release notes
Bruce Momjian wrote: I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. In E.1.1 Overview: ... This release supports Windows NT 4 and all later releases. It does not support earlier releases like Windows 95, 98, or ME because ... Win98 and WinME is released _after_ NT4. See http://www.computerhope.com/history/windows.htm Perhaps it's better to say: We only support NT-based Windows such as NT4, Win2k/XP/2003/later. Old 9x-based Windows versions such as Win95/98/Me are not supported because ... Btw, can 7.5 run on WinCE/XP Media Center/XP SP2/etc? -- dave ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [DOCS] [HACKERS] 7.5 release notes
Btw, can 7.5 run on WinCE No. /XP Media Center/ Probably, but AFAIK not tested. XP SP2 Yes (haven't tested with the very latest versions of the SP, but it works with the earlier ones) /etc? Works fine on the PDC build of Longhorn... //Magnus ---(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] PITR COPY Failure (was Point in Time Recovery)
Looks good to me. Log file numbering scheme seems to have changed - is that part of the fix too?. Tom Lane wrote: This is done in CVS tip. Mark, could you retest to verify it's fixed? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PITR COPY Failure (was Point in Time Recovery)
Mark Kirkwood [EMAIL PROTECTED] writes: Looks good to me. Log file numbering scheme seems to have changed - is that part of the fix too?. That's for timelines ... it's not directly related but I thought I should put in both changes at once to avoid forcing an extra initdb. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] storage engine , mysql syntax CREATE TABLE t (i INT) ENGINE = INNODB|BDB
In mysql, we can wrote a create table like CREATE TABLE t (i INT) ENGINE = INNODB||BDB|; where the storage engine is the innodb one. This allow to have differents kind of storage format, and allow to easly implements memory table or remote table. I try to make the same thing for postgresql but i do not understand where the logical storage engine is in the source code. May i have somme help to find it . Thank you. pierre ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Dumb question about parser vs. parse analyzer
At the top of backend/parser/gram.y there's a big comment that says don't do any database access during the parse phase, just in case we're in the middle of an aborted transaction. I don't get it. Why would database access fail during an aborted transaction? Any changes have to be thrown away at the end of the transaction anyway, right? Or is it that changes are invalidated as soon as an error occurs? Is the parser just trying to avoid per-statement triggers after an error occurs? Can anyone explain? I've done some simple testing (just out of curiosity) but I can't seem to get anything to break if I always force IsAbortedTransactionBlockState() to return false. TIA. -- Murphy
[HACKERS] Postgres jobs Toronto
Hi everyone...my name is Mike MacEachern. I work with a technical search firm in Toronto - ARES Consulting A client of mine in Toronto is utilizing Linux technology to drive their business forward. The company is keen to hire two solid Postgres DBA's --they're very hard to find! These are in production 7/24 applications --previous experience in a production environment is required. If you're looking for a solid technical company committed to building a state of the art Linux infrastructure then please give me a call. Thanks. To discuss these positions further please contact Mike MacEachern at 416-480-2700 ext. 258 or by e-mail at [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] psql support for DSNs
I just had a thought; was looking at a script where I'd rather invoke using psql than using a Perl module (since Pg/DBD that might very well not be available on AIX, HP/UX, Solaris, or such). What would be very nice would be for there to be a psql command option that would accept a DSN as opposed to having to parse it all out into pieces. Thus: psql --dsn=host=george port=5434 dbname=testing That way, I can use the very same DSNs that I have already put together for use for numerous other purposes... I can certainly work around this for my current purpose, but I still think it would be a slick option to have. If I find Round Tuits, I'll see about a patch... -- output = reverse(moc.enworbbc @ enworbbc) http://cbbrowne.com/info/oses.html This must be Thursday. I never could get the hang of Thursdays. - Arthur Dent ---(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 7.4.3 optimizer choosing sequential scan. Why?
* The table contains one index: P1_NRN_ROAD_V (v, sobjid) (The index includes the column sobjid because the query projects this col, and its inclusion in the index allows it to be serviced without accessing the underlying table) Now, for the queries: QUERY 2: select sobjid from p1_nrn_road where v = 1 The plan is Seq Scan on p1_nrn_road (cost=0.00..22158.54 rows=2 width=8) That is puzzling. However, if you are only going to make a selection criteria for 'v', why the multi-column index? Setting an index on only 'v' should produce better results... -Barry ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PITR COPY Failure (was Point in Time Recovery)
Simon Riggs [EMAIL PROTECTED] writes: On Tue, 2004-07-20 at 15:00, Tom Lane wrote: Yeah, but the WASTED_SPACE/FILE_HEADER stuff is already pretty ugly, and adding two more warts to the code to support it is sticking in my craw. I'm thinking it would be cleaner to treat the extra labeling information as an extension of the WAL page header. Sounds like a better solution than scrabbling around at the end of file with too many edge cases to test properly This is done in CVS tip. Mark, could you retest to verify it's fixed? 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] Dumb question about parser vs. parse analyzer
murphy pope [EMAIL PROTECTED] writes: I don't get it. Why would database access fail during an aborted transaction? Because we've already aborted the transaction (released its locks, for instance). In a real sense you don't have a transaction at all anymore. Can anyone explain? I've done some simple testing (just out of curiosity) but I can't seem to get anything to break if I always force IsAbortedTransactionBlockState() to return false. IIRC the symptoms are relatively subtle. You might find locks that never get released, for example. Or maybe it was locks that don't get honored. Consider the following: begin; select * from foo; -- takes an AccessShare on foo select 1/0; -- abort, releases txn's locks select * from foo; If we allowed parse analysis to run on the third select, it would need to take out an AccessShare on foo (mainly to forestall the possibility of someone dropping the table or altering its schema while we are looking at it). Now suppose someone else actually does try to drop or alter foo concurrently with the third select. There are two possibilities: 1. The aborted transaction is still able to block the other guy. 2. The aborted transaction is not able to block the other guy, and soon crashes because the table schema is changing under it. Neither of these are appealing. I forget which way the lock code actually behaves at the moment, but it's very possible that it's #2, because the aborted transaction is not going to be seen as running anymore. The comment you are looking at is of relatively recent vintage --- we went for a long time without recognizing the risks here. 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] storage engine , mysql syntax CREATE TABLE t (i INT)
Pierre Emmanuel Gros wrote: In mysql, we can wrote a create table like CREATE TABLE t (i INT) ENGINE = INNODB||BDB|; where the storage engine is the innodb one. MySQL needs this because they have a weird understanding of RDBMS. There's absolutely no sense in trying to transfer this stuff into PostgreSQL. Use it as designed, and you'll never miss this MySQL feature. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] storage engine , mysql syntax CREATE TABLE t (i INT) ENGINE
Pierre Emmanuel Gros wrote: In mysql, we can wrote a create table like CREATE TABLE t (i INT) ENGINE = INNODB||BDB|; where the storage engine is the innodb one. This allow to have differents kind of storage format, and allow to easly implements memory table or remote table. I try to make the same thing for postgresql but i do not understand where the logical storage engine is in the source code. May i have somme help to find it . We only have one table type, full transactions, full storage support. We don't plan to support any sub-optimial storage systems. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] PITR Backup state validity checking
Problem Summary (from previous posts) The archive recovery must stop AFTER the end of the backup which the recovery used as its starting point. If not, incorrect database states are likely. In general, this is a small window for error and procedures should exist to return to the prior backup. Nonetheless, this check should be made i.e. stop time/point backup end time Solution Design: Before a backup is taken, write a file to data directory that identifies which backup this is. When the backup is taken this file will be copied with the backup, and later restored when the backup is restored. When backup completes write a file to xlog directory that contains the start backup identifier and the end time. When recovery occurs the backup identifier can be used to find the end backup file and read this to find the end backup time. Additional aspects: - Can't assume that archive allows direct access, so anything written to log must be read in sequential order it was written. - Backup may be taken when postmaster is down, so solution must not rely on postmaster being up. - It *is* posssible to do incremental backups, as long as the backup checks each file's change data against files already archived (or on write-once media). The previously backed-up files are thus able to be considered as being part of *this* backup as well as the one in which the backup took place. (So we still write start now and end shortly afterwards). - We want to offer the user an interface now, so that when later changes occur, we will not be requiring them to change again. Implementation Options: User Interface Two user interfaces have been suggested: - Write a server function which can be called from anywhere... - Write an external program External program will still work when postmaster is down, so is the option suggested in further detail here... - Call Sequence It has been suggested that there should be an API call issued before and after the backup. That requires the user to issue 3 calls in sequence to get a correct backup. - For full backups taken all at once, a single call is desirable, ensuring that no API call was missed. Implementation Design -- Implement an external program, called pg_backup. (I guess there's some historical baggage there, but may be time to leave that behind now) pg_backup will do: 1. If postmaster is up, issue a manual CHECKPOINT 2. Write a file called backup_start_backupid.info where backupid is the time when backup starts contains: systemid, time(now) 3. Remove all previous backup_start*.info files 4. Issue the users backup_command via system(3) 5. Write a second file called backup_end_backupid to pg_xlog AND write a backup_end_backupid.ready to archive_status. backup_end_backupid contains: systemid, time of backup end backup_end_backupid.ready is empty Other changes: - Alter archiver to always archive backup_end* files first, so they are written to archive in time sequence order. - Alter recovery so that it requests backup_end_backupid first. We then read the time in this file and compare with our end time, if there is one. If there is and we fail the test, we stop. If no target time exists, we rollforward though can still fail the test at our selected stopping point (an Xid). - If recovery ends at an Xid, but when this is reached we are still less than backup end time, then we alter our target to being the backup end time (inclusive) and continue to roll forward. WARNING issued. - If recovery ends before it has read the backup_end* file then we issue a WARNING error saying recovery using incomplete backup, HINT:you will need to start recovery from the next earliest backup. (Later change this to an ERROR and add an option to override and ignore it, for when you're really up to your neck in it) pg_backup -opts [BACKUP COMMAND] opts: -D data directory (defaults to PGDATA) usage examples: pg_backup tar zcvhf /dev/rmt0 $PGDATA uses PGDATA to identify data directory, then creates a tape archive on the default tape device pg_backup write_to_BAR_system p1 p2 p3 Not hugely happy with the above. I'm sure someone will come up with a few streamlining comments, eh? I'd certainly prefer a solution that involved writing WAL records to indicate start and end, which seems cleaner and more integrated. However, we need to be able to cater for cold/offline backups. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] CVS web interface error
CVS web interface has not been working for a few days. Not important right now, but something to fix soon-ish. Best Regards, Simon Riggs = Error Error: Unexpected output from cvs co: cvs [checkout aborted]: Absolute module reference invalid: `/pgsql-server/COPYRIGHT' Check whether the directory /cvsroot//CVSROOT exists and the script has write-access to the CVSROOT/history file if it exists. The script needs to place lock files in the directory the file is in as well. === ---(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] storage engine , mysql syntax CREATE TABLE t (i INT)
Andreas Pflug wrote: Pierre Emmanuel Gros wrote: In mysql, we can wrote a create table like CREATE TABLE t (i INT) ENGINE = INNODB||BDB|; where the storage engine is the innodb one. MySQL needs this because they have a weird understanding of RDBMS. This could be true, but the answer doesn't make sense, at least it's in a perfect mysql people style. Isn't ? We don't need transactions, we don't needs store procedure and so on... There's absolutely no sense in trying to transfer this stuff into PostgreSQL. Use it as designed, and you'll never miss this MySQL feature. Another mysql people style answer. We have only one engine: the full transactional one. If the OP need to have for example the MEMORY one the he can easily create a RAM disk and with the tablespaces support he can create tables or index or whatever objects in memory. Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Planning for beta (was Re: Sketch of extending error handling
Marc G. Fournier wrote: On Sun, 25 Jul 2004, Simon Riggs wrote: HIGH 1. Documentation (sr) (now) - Backup and Recovery chapter - WAL chapter Docs, as always, can be delivered/improved throughout beta ... Yes, but without PITR docs there is no way to test the feature. Many of our docs don't require docs for testing, but PITR does. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Improvements to PostgreSQL
I am forwarding this to hackers on behalf of some people who want to improve PostgreSQL in India. I suggest you read the developers FAQ on the developers page: http://developers.postgresql.org then subscribe to hackers to discuss feature additions. Thanks. --- Suresh Tri wrote: Hi all, We are a bunch(about 10)of enthusiastic software engineers from Bangalore who strongly believe in opensource. We are currently looking at the prospect of improving the PostgreSQL to the enterprise level. At first we would like to take PostgreSQL atleast to the level of Oracle 7i or 8i. We already have the difflist of features differences between Oracle 8i and the current PostgreSQL(7.4). But we are finding it hard to prioritize the features. What do you think are the important features that are present in Oracle 8i but absent in the current PostgreSQL ehich the enterprises look at. It would be of the great help if you can tell us about these featues and also the way in which we can contribute to the PostgreSQL development. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.5 release notes
Gaetano Mendola wrote: [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote: |I have completed the 7.5 release notes. You can view them in HTML on |the developer web page. I have marked a few items with question marks |that need to be addressed. I am looking for improvements, even minor |ones. Either send in a patch or committers can modify the file |directly. Did you forget to insert the autovacuum integrated ? It isn't applied yet. -- 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] Sketch of extending error handling for subtransactions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane wrote: | Bruce Momjian [EMAIL PROTECTED] writes: | |So it allows functions to use subtransactions and recover from errors. |I thought that was more than we could do for 7.5 and in fact the release |notes now saw that will be done in a future release. | | | I think there's only a day or two's work between here and there, and it | would be foolish not to have the feature if we can get it. | | As I see it, we need: | | 1. The elog.c factoring described in this thread. | | 2. An extension to the SPI API to allow execution of commands within |a subtransaction, with catching of errors. | | 3. A bit of work on plpgsql to support some kind of EXCEPTION syntax. | | I might decide to forget about SPI and trap errors directly in plpgsql, | but in any case it doesn't seem out of reach. | | I was just looking around the net to see exactly what Oracle's PL/SQL | syntax is. It doesn't seem too unreasonable syntax-wise: | | BEGIN | ... controlled statements ... | EXCEPTION | WHEN exception_name THEN | ... error handling statements ... | WHEN exception_name THEN | ... error handling statements ... | ... | WHEN OTHERS THEN | ... error handling statements ... | END; Is this sintax SQL standard driven ? If not I'd prefere this one: ~TRY ~... controlled statements ... ~CATCH INTEGER THEN ~ ... error handling statements ... ~CATCH VARCHAR THEN ~... error handling statements ... ~ ... ~CATCH OTHERS THEN ... error handling statements ... ~END; and of course who trhow the exception: ~THROW 3::INTEGER; in this way who throw the exception can also transfer informations on what is going on. Am I may be not understanding what are you trying to do ? Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBBCsu7UpzwH2SGd4RAo1aAKDUX+afgx+RjBdCtG9sdGp9eT6j1QCfasdq hcm4Vt2RLsoN5cSvIfbgGiw= =iJgV -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] storage engine , mysql syntax CREATE TABLE t (i INT)
Gaetano Mendola wrote: We have only one engine: the full transactional one. If the OP need to have for example the MEMORY one the he can easily create a RAM disk and with the tablespaces support he can create tables or index or whatever objects in memory. Well, it certainly could make sense to have different storage engines for different access patterns. (Not for different degrees of implementation correctness, mind you.) So let's just say we don't have them. Postgres was, however, one of the systems that in fact pioneered pluggable storage managers. So we could say we're already one generation ahead of everyone else: we had switchable storage managers, realized we didn't need them, and got rid of them. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 7.5 release notes
Simon Riggs wrote: On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote: I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. Looks good. These take time and effort, much appreciated. Forward-looking phrases === Overall, I'd ask that we don't refer back to what earlier releases didn't do, or whatever limitations they were thought to have. If a release has new feature X, everybody can work out it wasn't there in the last release. The phrasing is delicate so you describe the new thing without running down the old. e.g. (1) Previous releases required the Unix emulation toolkit Cygwin for Win32 support. to The server no longer relies upon Cygwin for Unix emulation under win32. e.g. (2) Prior release had no such capability; there was no way to recover from a statement failure in a transaction. to Should a statement fail inside a transaction, there is now a way to handle this error and continue processing. (Of course, somebody will let me know about my Brit-style passive voice, I'm sure...) I understand your reason for making these changes. However, I am unsure if your new wording is as clear as the previous one. Our reliance on Cygwin and inability to prevent an error from aborting a transaction were limitation and it seems clearer to just state that we have fixed them rather than try to sugar-code our previous limitations. Marketing-wise, I think you are right, but from an honesty/clarity perspective, I think the current wording is better. What I could do is remove some of the later references where we were talking updating the system catalog to do various things. I am not sure it is needed. Comments? Migration = These release notes refer to GUCs, whereas the previous release notes and the manual refers to server configuration parameters. I understand the former, but prefer the latter description for these user-focused notes. Updated. Also, it might be worth mentioning that pg_dump itself has also been substantially improved, and now provides an improved upgrade path for existing users. It is mentioned as the top item in the pg_dump section. It doesn't seem like a migration issue to me though. Is it a major feature? Here's my attempt at a short paragraph for PITR... Point-In-Time Recovery enhances Data Resilience PostgreSQL can now recover from total disk failure using backups and transaction log archives. Recovery can be controlled to stop at a specified point in time or at some transaction in the past. Transaction log archiving is automated and calls a user-supplied external program to allow integration with external backup devices and related software. We can improve the wording, but if the motivation is to reduced saying bad things about our previous functionality, let me explain my perspective. Basically, my goal with these release notes is to make it as clear as possible why this new feature would be valuable to the reader. If it makes our previous release look bad, so be it. For me, clarity and candor gain a lot more credibility than trying to cover over missing functionality in the past. I am not saying we have to be so honest that we bash PostgreSQL, but in cases where we adjust wording to try to prevent ourselves from looking bad, it is best to be honest and clear about our limitations. I think in the long run it gains us lots of credibility (and ultimately volunteers). Do people want a big-picture paragraph at the top talking about the release? Some releases get them, some don't, but this one could if folks want it. Yes, thats a good idea. OK. -- 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] PITR Backup state validity checking
Simon Riggs [EMAIL PROTECTED] writes: Solution Design: Before a backup is taken, write a file to data directory that identifies which backup this is. When the backup is taken this file will be copied with the backup, and later restored when the backup is restored. When backup completes write a file to xlog directory that contains the start backup identifier and the end time. End WAL offset, please. Let's not waste our time with imprecise thinking. (If you want to throw in the time too, as an aid to the DBA, fine, but the correctness check wants the WAL position.) - Backup may be taken when postmaster is down, so solution must not rely on postmaster being up. Sure it can. If postmaster is not up then the whole problem is immaterial, as the WAL state isn't changing relative to the database state. (It might be a good idea to try to have some kind of interlock that prevents someone from trying to start the postmaster while such a backup is in progress.) I'm not convinced that we need expend a whole lot of effort on the point, though, as surely people will prefer to keep their postmasters running while they take backups. - It *is* posssible to do incremental backups, as long as the backup checks each file's change data against files already archived (or on write-once media). Hmmm ... if you trust file change dates I suppose this would work, but it feels shaky ... Implement an external program, called pg_backup. I'd prefer to keep this inside the postmaster, as a separate program offers a whole new set of failure modes (wrong version, wrong idea about where PGDATA is, etc etc). - Alter archiver to always archive backup_end* files first, so they are written to archive in time sequence order. We cannot use an archive technique that does not support requests for arbitrary files, so your concern about write ordering seems quite pointless. These backup ID files will have roles similar to timeline ID files, which already require random access. I'd certainly prefer a solution that involved writing WAL records to indicate start and end, which seems cleaner and more integrated. But harder to use. The DBA would find it much more convenient to have those items of info out in easily readable text files. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.5 release notes
All added. Thanks. --- Andrew Dunstan wrote: Bruce Momjian said: I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. I presume we can also just make some comments ;-) this item: Add new GUC parameter to report useful information at the start of each log line should probably read Add new GUC parameter log_line_prefix . I think this item belongs to me, or me and Tom: Replace the virtual_host and tcpip_socket parameters with a unified listen_addresses parameter. Conversely, Tom deserves joint billing for dollar quoting, as most of what I did was based on his work. David Fetter should be mentioned under the dollar quoting and plperl items, as he did documentation for both. Tom's implementation of a new flex-based lexer for psql is a significant source code change which should be mentioned. cheers andrew -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.5 release notes
Adjustment made: http://pgfoundry.org/projects/pginstaller/ulink. This release supports NT-based Windows releases like NT4, Win2k, XP, Win2003. Older releases like Windows 95, 98, and ME are not supported because these operating systems do not have the infrastructure to support PostgreSQL. --- David Garamond wrote: Bruce Momjian wrote: I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. In E.1.1 Overview: ... This release supports Windows NT 4 and all later releases. It does not support earlier releases like Windows 95, 98, or ME because ... Win98 and WinME is released _after_ NT4. See http://www.computerhope.com/history/windows.htm Perhaps it's better to say: We only support NT-based Windows such as NT4, Win2k/XP/2003/later. Old 9x-based Windows versions such as Win95/98/Me are not supported because ... Btw, can 7.5 run on WinCE/XP Media Center/XP SP2/etc? -- dave ---(end of broadcast)--- TIP 8: explain analyze is your friend -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [DOCS] 7.5 release notes
Bruno Wolff III wrote: On Sun, Jul 25, 2004 at 00:25:43 -0400, Bruce Momjian [EMAIL PROTECTED] wrote: I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. There is a typo (transaction is misspelled) in the following line: Prior release had no such capability; there was no way to recover from a statement failure in a transation. This match exactly at the end of the following appears to be spurious: Yes, removed. Before this change some queries would not use an index if the data types did not exactly match. This improvement makes index usage more intuitive and consistent. match exactly In the following paragraph there appear to be two typos. I think optimizer make should be optimizer makes and that lose-source should be closed-source. It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustments to the logic used to select indexes, join methods, and join order. They are difficult to explain, but the result is that the optimizer make quicker and better choices in how to execute queries, resulting in improved performance. The close relationship between our developers and users reporting problems allows us to make rapid and complex optimizer improvements that would be very difficult for lose-source companies to emulate. Fixed. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [DOCS] 7.5 release notes
\Tom Lane wrote: Bruno Wolff III [EMAIL PROTECTED] writes: In the following paragraph there appear to be two typos. I think optimizer make should be optimizer makes and that lose-source should be closed-source. It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustments to the logic used to select indexes, join methods, and join order. They are difficult to explain, but the result is that the optimizer make quicker and better choices in how to execute queries, resulting in improved performance. The close relationship between our developers and users reporting problems allows us to make rapid and complex optimizer improvements that would be very difficult for lose-source companies to emulate. I'd suggest removing the paragraph entirely, on the grounds that it is content-free fluff. Hey, that's your content-free fluff. :-) You make major optimizer improvements in every release, but they are so complex it is impossible to explain them to people. This paragraph tries to address that. However, since you don't like it, I will remove it entirely. If you change your mind we can re-add it. -- 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] Planning for beta (was Re: Sketch of extending error
On Sun, 25 Jul 2004, Bruce Momjian wrote: Marc G. Fournier wrote: On Sun, 25 Jul 2004, Simon Riggs wrote: HIGH 1. Documentation (sr) (now) - Backup and Recovery chapter - WAL chapter Docs, as always, can be delivered/improved throughout beta ... Yes, but without PITR docs there is no way to test the feature. Many of our docs don't require docs for testing, but PITR does. Shouldn't there be regression tests for doing that anyway? Or isn't that possible to do in the regression tests? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Planning for beta (was Re: Sketch of extending error handling
Marc G. Fournier wrote: On Sun, 25 Jul 2004, Bruce Momjian wrote: Marc G. Fournier wrote: On Sun, 25 Jul 2004, Simon Riggs wrote: HIGH 1. Documentation (sr) (now) - Backup and Recovery chapter - WAL chapter Docs, as always, can be delivered/improved throughout beta ... Yes, but without PITR docs there is no way to test the feature. Many of our docs don't require docs for testing, but PITR does. Shouldn't there be regression tests for doing that anyway? Or isn't that possible to do in the regression tests? Good question. Simon wants to build a test suite. It appeared on his TODO list. However, I think it would be separate from the regression tests. Also, we need manual testing because people will do goofy things that the test will not try, I am sure. :-) -- 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] [DOCS] 7.5 release notes
All fixed. Thanks. --- Bruno Wolff III wrote: On Sun, Jul 25, 2004 at 00:25:43 -0400, Bruce Momjian [EMAIL PROTECTED] wrote: I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. There is a typo (transaction is misspelled) in the following line: Prior release had no such capability; there was no way to recover from a statement failure in a transation. This match exactly at the end of the following appears to be spurious: Before this change some queries would not use an index if the data types did not exactly match. This improvement makes index usage more intuitive and consistent. match exactly In the following paragraph there appear to be two typos. I think optimizer make should be optimizer makes and that lose-source should be closed-source. It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustments to the logic used to select indexes, join methods, and join order. They are difficult to explain, but the result is that the optimizer make quicker and better choices in how to execute queries, resulting in improved performance. The close relationship between our developers and users reporting problems allows us to make rapid and complex optimizer improvements that would be very difficult for lose-source companies to emulate. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.5 release notes
In the release not I can read: #Allow arbitrary row expressions (Tom) This allows columns to contain arbitrary composite types like rows from other tables. [SNIPPED] Wasn't this alread true on 7.4 ? See: kalman=# select version(); version - PostgreSQL 7.4.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (1 row) kalman=# create table test ( a varchar, b varchar, c varchar ); CREATE TABLE kalman=# create table test1 ( d integer, e test ); CREATE TABLE kalman=# select * from test1; d | e ---+--- (0 rows) kalman=# select e from test1; e --- (0 rows) kalman=# select (e).a from test1; a --- (0 rows) Regards Gaetano Mendola ---(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
[HACKERS] 7.5 backend crash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm playing with complex row type: kalman=# create table test ( a integer, b integer ); CREATE TABLE kalman=# create table test1 ( c integer , d test ); CREATE TABLE kalman=# insert into test1 values ( 1, (2,3) ); INSERT 17277 1 kalman=# select * from test1; ~ c | d - ---+--- ~ 1 | (2,3) (1 row) kalman=# alter table test drop column b; ALTER TABLE --- Here I think the server shall complain about ~ ( 7.4 doesn't complain neither ) the following select on table test1 will crash the back end kalman=# select * from test1; server closed the connection unexpectedly ~This probably means the server terminated abnormally ~before or while processing the request. The connection to the server was lost. Attempting reset: Failed. ! Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBBFQH7UpzwH2SGd4RAvIXAJ0bcfGdP5sfPFRYdfKOJ0YchRYXPgCfZti7 wKfzG4GwdFft0a1LDXK9fmo= =wjvZ -END PGP SIGNATURE- ---(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] Planning for beta (was Re: Sketch of extending error
On Sun, 25 Jul 2004, Bruce Momjian wrote: Also, we need manual testing because people will do goofy things that the test will not try, I am sure. :-) Agreed, but just want to make sure that Simon realizes that this 'level' of documentation is required for release, not for beta ... in fact, be nice if we could use those 'goofy things' as a pseudo example of where PITR is useful ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.5 release notes
On Mon, Jul 26, 2004 at 02:22:21AM +0200, Gaetano Mendola wrote: In the release not I can read: #Allow arbitrary row expressions (Tom) This allows columns to contain arbitrary composite types like rows from other tables. [SNIPPED] Wasn't this alread true on 7.4 ? No, this is a new feature. Did you try inserting anything into the tables? How about using rowtypes as function parameters? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) If you have nothing to say, maybe you need just the right tool to help you not say it. (New York Times, about Microsoft PowerPoint) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Improvements to PostgreSQL
On Sun, 25 Jul 2004, Bruce Momjian wrote: I am forwarding this to hackers on behalf of some people who want to improve PostgreSQL in India. I suggest you read the developers FAQ on the developers page: http://developers.postgresql.org then subscribe to hackers to discuss feature additions. Thanks. As Bruce suggests, subscribe and consider posting the list of feature differences so that others can see what the diffences are. Thanks, Gavin ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Planning for beta (was Re: Sketch of extending error
On Mon, 2004-07-26 at 02:12, Marc G. Fournier wrote: On Sun, 25 Jul 2004, Bruce Momjian wrote: Also, we need manual testing because people will do goofy things that the test will not try, I am sure. :-) Agreed, but just want to make sure that Simon realizes that this 'level' of documentation is required for release, not for beta ... in fact, be nice if we could use those 'goofy things' as a pseudo example of where PITR is useful ... I think you're arguing in favour of me not completing the todo list, which is great cos I wasn't going to be able to. :) ...and we can do more later. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.5 release notes
On Mon, 2004-07-26 at 00:55, Bruce Momjian wrote: Simon Riggs wrote: On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote: I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. Those were just examples of a suggested style change for some items. Basically, my goal with these release notes is to make it as clear as possible why this new feature would be valuable to the reader. Completely Agree. If it makes our previous release look bad, so be it. Oh. For me, clarity and candor gain a lot more credibility than trying to cover over missing functionality in the past. I am not saying we have to be so honest that we bash PostgreSQL, but in cases where we adjust wording to try to prevent ourselves from looking bad, it is best to be honest and clear about our limitations. I think in the long run it gains us lots of credibility (and ultimately volunteers). I see this as merely a half-full/half-empty viewpoint issue. Honesty and clarity are wonderful things and I subscribe to them. Using them only to describe your own viewpoint is not a reasonable point to make in a hopefully rational discussion about writing style... I'll go back to my docs now, but I guess we may relive this again when you see some of the honest, clear and positive changes I am suggesting. :) -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Planning for beta (was Re: Sketch of extending error handling
Marc G. Fournier wrote: On Sun, 25 Jul 2004, Bruce Momjian wrote: Also, we need manual testing because people will do goofy things that the test will not try, I am sure. :-) Agreed, but just want to make sure that Simon realizes that this 'level' of documentation is required for release, not for beta ... in fact, be nice if we could use those 'goofy things' as a pseudo example of where PITR is useful ... Agreed. We don't need eligance at this stage, just instructions for people to follow. Simon, don't kill yourself on the docs. -- 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] 7.5 release notes
Simon Riggs wrote: For me, clarity and candor gain a lot more credibility than trying to cover over missing functionality in the past. I am not saying we have to be so honest that we bash PostgreSQL, but in cases where we adjust wording to try to prevent ourselves from looking bad, it is best to be honest and clear about our limitations. I think in the long run it gains us lots of credibility (and ultimately volunteers). I see this as merely a half-full/half-empty viewpoint issue. Honesty and clarity are wonderful things and I subscribe to them. Using them only to describe your own viewpoint is not a reasonable point to make in a hopefully rational discussion about writing style... I'll go back to my docs now, but I guess we may relive this again when you see some of the honest, clear and positive changes I am suggesting. :) I wasn't suggesting yours were dishonest. I was saying that I was aiming for the clearest style whether is makes PostgreSQL look good or not. I figured saying in the past you had to do X was clearer than saying you don't have to do X anymore. I am, of course, am open to the community's feedback on this. -- 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] Improvements to PostgreSQL
I reckon they could have a crack at implementing SQL2003 recursive queries (eg. WITH syntax). Or, SQL2003 ROLLUP and CUBE queries. But that's just what I want :) Chris Bruce Momjian wrote: I am forwarding this to hackers on behalf of some people who want to improve PostgreSQL in India. I suggest you read the developers FAQ on the developers page: http://developers.postgresql.org then subscribe to hackers to discuss feature additions. Thanks. --- Suresh Tri wrote: Hi all, We are a bunch(about 10)of enthusiastic software engineers from Bangalore who strongly believe in opensource. We are currently looking at the prospect of improving the PostgreSQL to the enterprise level. At first we would like to take PostgreSQL atleast to the level of Oracle 7i or 8i. We already have the difflist of features differences between Oracle 8i and the current PostgreSQL(7.4). But we are finding it hard to prioritize the features. What do you think are the important features that are present in Oracle 8i but absent in the current PostgreSQL ehich the enterprises look at. It would be of the great help if you can tell us about these featues and also the way in which we can contribute to the PostgreSQL development. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Quick coding question with acl fixes
Yeah, but the point was that he was doing an ALTER OWNER and needed to
fix the ACL to match. I thought he claimed to have written the needed
subroutine. I have not yet looked at his patch though.
I think Fabien's owner changing routine will end up being a strict
subset of my routine. I think his just happens to only work on the
newly created public and info_schema in a new db. It's not complex
enough to work on arbitrary acls. Also, his needs to work as a public
SQL function:
+ /* acl acl_switch_grantor(acl, oldgrantor, newgrantor);
+ * switch grantor id in aclitem array.
+ * used internally for fixing owner rights in new databases.
+ * must be STRICT.
+ */
+ Datum acl_switch_grantor(PG_FUNCTION_ARGS)
+ {
+ Acl * acls = PG_GETARG_ACL_P_COPY(0);
+ int i,
+ old_grantor = PG_GETARG_INT32(1),
+ new_grantor = PG_GETARG_INT32(2);
+ AclItem * item;
+
+ for (i=0, item=ACL_DAT(acls); iACL_NUM(acls); i++, item++)
+ if (item-ai_grantor == old_grantor)
+ item-ai_grantor = new_grantor;
+
+ PG_RETURN_ACL_P(acls);
+ }
Chris
---(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] storage engine , mysql syntax CREATE TABLE t (i INT)
Peter Eisentraut [EMAIL PROTECTED] writes: Postgres was, however, one of the systems that in fact pioneered pluggable storage managers. So we could say we're already one generation ahead of everyone else: we had switchable storage managers, realized we didn't need them, and got rid of them. We do actually still have the smgr switch interface, so in theory you could plug in a new storage manager just as well as you could back in the Berkeley days. If anything better --- smgr is now allowed to handle stuff that was kluged in upper layers back then. I think the reason that this feature is moribund is largely that substituting behaviors at that low level stopped being interesting some time ago. In modern systems the equivalent behavior is down inside the kernel device driver, if not in the storage device itself (think SAN, RAID controllers, etc) and it's just not useful to try to manage it inside an unprivileged-application database. The complaint that's commonly leveled against the MySQL table-handler design is that it puts the switch at too *high* a level --- there are very significant semantic issues that are left to the table handler (eg locking), which means that an application is pretty much locked into the handler it was designed for. MySQL isn't so much one database as it is three or four databases with roughly similar APIs. I don't think it's either practical or interesting to try to introduce an equivalent layering into Postgres. There might be some way to design an intermediate switching layer where interesting behavioral changes could be introduced without breaking application API expectations. But we don't have one, and I think it'd be quite a bit of work to introduce one, even if you could get people to buy into the idea in advance of proof of usefulness :-( regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] storage engine , mysql syntax CREATE TABLE t (i INT)
On Mon, 26 Jul 2004, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Postgres was, however, one of the systems that in fact pioneered pluggable storage managers. So we could say we're already one generation ahead of everyone else: we had switchable storage managers, realized we didn't need them, and got rid of them. We do actually still have the smgr switch interface, so in theory you could plug in a new storage manager just as well as you could back in the Berkeley days. If anything better --- smgr is now allowed to handle stuff that was kluged in upper layers back then. I think the reason that this feature is moribund is largely that substituting behaviors at that low level stopped being interesting some time ago. In modern systems the equivalent behavior is down inside the kernel device driver, if not in the storage device itself (think SAN, RAID controllers, etc) and it's just not useful to try to manage it inside an unprivileged-application database. The complaint that's commonly leveled against the MySQL table-handler design is that it puts the switch at too *high* a level --- there are very significant semantic issues that are left to the table handler (eg locking), which means that an application is pretty much locked into the handler it was designed for. MySQL isn't so much one database as it is three or four databases with roughly similar APIs. I don't think it's either practical or interesting to try to introduce an equivalent layering into Postgres. There might be some way to design an intermediate switching layer where interesting behavioral changes could be introduced without breaking application API expectations. But we don't have one, and I think it'd be quite a bit of work to introduce one, even if you could get people to buy into the idea in advance of proof of usefulness :-( I've looked into this. The problem is that many storage management systems also want to take higher level control of indexing. They also often do their own WAL and PITR. Some do their own buffer management, locking and replication/load management too. So, as you say, its hard say where an interface should be abstracted. Its definately a difficult issue. Gavin ---(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] storage engine , mysql syntax CREATE TABLE t (i INT)
On Sun, 2004-07-25 at 22:23, Tom Lane wrote: I don't think it's either practical or interesting to try to introduce an equivalent layering into Postgres. I can possibly see a use for a row locking storage system, i.e. non MVCC for some applications. But I can't see it being worth the amount of work it would require. Or is the locking model too high level to be handled this way? Just wondering. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] CVS web interface error
Simon Riggs [EMAIL PROTECTED] writes: CVS web interface has not been working for a few days. Not important right now, but something to fix soon-ish. It works okay for me (modulo $PostgreSQL$ issue, see other thread). What URL are you visiting to get the stated error? 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] Sketch of extending error handling for subtransactions
Gaetano Mendola [EMAIL PROTECTED] writes: Tom Lane wrote: | I was just looking around the net to see exactly what Oracle's PL/SQL | syntax is. It doesn't seem too unreasonable syntax-wise: | [ snip pl/sql syntax ] Is this sintax SQL standard driven ? No, AFAIK it's just Oracle's syntax. If not I'd prefere this one: [ some other syntax ] Can you point to any SQL standard or existing database that uses your suggestion? Oracle is certainly the de facto standard in this area, and plpgsql in particular is an unabashed effort to follow their PL/SQL implementation... If we decide that we're going to deliberately vary from Oracle's syntax and semantics, then I have no problem with try/catch as the keywords. (That's actually my programming heritage as well, I was using exception handling with those keywords back in the late 70s at HP.) ~CATCH INTEGER THEN ~ ... error handling statements ... ~CATCH VARCHAR THEN er ... I'm not clear why type names would have anything to do with exceptions. What's your vision here exactly? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Weird...but correct?
It's bizarre how you can comment on columns in composite types! CREATE TYPE test (a int4, b int4); COMMENT ON COLUMN test.a IS 'A column'; Seems harmless, but should we allow it? Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
