Re: [HACKERS] Should next release by 8.0 (Was: Re: [GENERAL] I am
On July 5, 2002 10:27 am, Marc G. Fournier wrote:
On Fri, 5 Jul 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Actually, the big change is such that will, at least as far as I'm
understanding it, break pretty much every front-end applicaiton ...
Only those that inspect system catalogs --- I'm not sure what percentage
that is, but surely it's not pretty much every one. psql for example
is only affected because of its \d commands.
Okay, anyone have any ideas of other packages that would inspect the
system catalog? The only ones I could think of, off the top of my head,
would be pgAccess, pgAdmin and phpPgAdmin ... but I would guess that any
'administratively oriented' interface would face similar problems, no?
PyGreSQL pokes into the catalogues a bit.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Proposal: CREATE CONVERSION
Tatsuo Ishii [EMAIL PROTECTED] writes: I am worried about that too. But if we stick a C-level API, how can we define the argument data type suitable for C string? I don't see such data types. Maybe you are suggesting that we should not use CREATE FUNCTION? Well, you'd have to use the same cheat that's used for selectivity estimation functions, triggers, I/O functions and everything else that deals in internal datatypes: declare the function as taking and returning OPAQUE. This is moderately annoying but I don't think there's anything really wrong with it in practice. 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] (A) native Windows port
Andrew Sullivan [EMAIL PROTECTED] writes: On Fri, Jul 05, 2002 at 12:39:13PM -0400, Lamar Owen wrote: One other usability note: why can't postmaster perform the steps of an initdb if -D points to an empty directory? Rank newbies shouldn't be protected in this way, partly because if something goes wrong, _they won't know what to do_. Please, please, don't be putting automagic, database destroying functions like that into the postmaster. I agree completely with Andrew, even though an auto-initdb on an empty directory presumably won't destroy any data. What it *does* do is effectively mask a DBA error. We'll be getting panic-stricken support calls/emails saying all my databases are gone! Postgres sucks! when the problem is just that PG was restarted with the wrong -D pointer. The existing behavior points that out loud and clear, in a context where the DBA shouldn't have too much trouble figuring out what he did wrong. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] BETWEEN Node DROP COLUMN
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] "Christopher Kings-Lynne" [EMAIL PROTECTED] writes: OK, I've been looking at Hiroshi's implementation. It's basically semantically equivalent to mine from what I can see so far. The only difference really is in how the dropped columns are marked. True enough, but that's not a trivial difference. The problem with Hiroshi's implementation is that there's no longer a close tie between pg_attribute.attnum and physical positions of datums in tuples. I think that that's going to affect a lot of low-level code, and that he hasn't found all of it. Please don't propagate an unfair valuation without any verification. regards, Hiroshi Inoue ---(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] Proposal: CREATE CONVERSION
Tatsuo Ishii [EMAIL PROTECTED] writes: I am worried about that too. But if we stick a C-level API, how can we define the argument data type suitable for C string? I don't see such data types. Maybe you are suggesting that we should not use CREATE FUNCTION? Well, you'd have to use the same cheat that's used for selectivity estimation functions, triggers, I/O functions and everything else that deals in internal datatypes: declare the function as taking and returning OPAQUE. This is moderately annoying but I don't think there's anything really wrong with it in practice. Oh, I see. -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] (A) native Windows port
On Saturday 06 July 2002 11:15 am, Tom Lane wrote: Andrew Sullivan [EMAIL PROTECTED] writes: On Fri, Jul 05, 2002 at 12:39:13PM -0400, Lamar Owen wrote: One other usability note: why can't postmaster perform the steps of an initdb if -D points to an empty directory? Rank newbies shouldn't be protected in this way, partly because if something goes wrong, _they won't know what to do_. I agree completely with Andrew, even though an auto-initdb on an empty directory presumably won't destroy any data. Good grief, I was just asking a question. :-) What it *does* do is effectively mask a DBA error. This is a satisfactory answer. In the context of the RPM distribution, if the initscript is used the DBA error probability is greatly reduced, thus the initscript can safely initdb. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] (A) native Windows port
On Sat, 6 Jul 2002, Tom Lane wrote: Andrew Sullivan [EMAIL PROTECTED] writes: On Fri, Jul 05, 2002 at 12:39:13PM -0400, Lamar Owen wrote: One other usability note: why can't postmaster perform the steps of an initdb if -D points to an empty directory? Rank newbies shouldn't be protected in this way, partly because if something goes wrong, _they won't know what to do_. Please, please, don't be putting automagic, database destroying functions like that into the postmaster. I agree completely with Andrew, even though an auto-initdb on an empty directory presumably won't destroy any data. What it *does* do is effectively mask a DBA error. We'll be getting panic-stricken support calls/emails saying all my databases are gone! Postgres sucks! when the problem is just that PG was restarted with the wrong -D pointer. The existing behavior points that out loud and clear, in a context where the DBA shouldn't have too much trouble figuring out what he did wrong. Okay, I'm sitting on the fence on this one ... but, as DBA for several PgSQL installs on at least a half dozen machines or more, if someone restarts PG with the wrong -D pointer, they haven't setup their machine to live through a reboot ... first thing any DBA *should* be doing after they have 'initdb'd their system is add the appropriate start-up scripts for after the reboot ... Also, what is the difference between forgetting where you put it in an initdb or on the first postmaster? Why not put in a 'safety'? If you start up postmaster with -D on a directory that doesn't yet exist, it prompts the DBA as to whether they are certain that they wish to do this? Just thoughts ... I'm happy enough with initdb *shrug* ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)
J.R., Nice first draft and a good read. Was going to comment in-line but thought this method would be easier to follow. The comments/suggestions below assume that PIT recovery is being performed at the cluster level with a data backup image created by a tar-like utility. As noted, one of the main problems is knowing where to begin in the log. This can be handled by having backup processing update the control file with the first lsn and log file required. At the time of the backup, this information is or can be made available. The control file can be the last file added to the tar and can contain information spanning the entire backup process. For data consistency, since the backup is being performed on an active cluster, we have to make sure to mark the end of the backup. On restore, to make the cluster consistent, you have to force the user to perform forward recovery passed the point of the backup completion marker in the (archived) log. This can be handled using a backup end log record. The backup end log record would have to contain an identifier unique to this backup. If a user requests to stop PIT recovery before this log record is encountered, consistency is not guaranteed. PIT should either disallow the action or warn of possible / impending doom. The necessary logging for rtee (and others) insertions/deletions can be added to the base code. Not much of a worry but I would expect to encounter other missing log items during testing. The idea of using the last lsn on the page to detect a partial write is used by other dbms systems. You already have that information available so there is no overhead in computing it. Nothing wrong with CRC though. As for the DB_SHUTDOWNED state, this could be handled by having the backup processing update the control file field to DB_PIT_REQUIRED (or some such identifier). After a restore, users would be blocked from connecting to the cluster's databases until a forward recovery passed the backup end log record has completed successfully. At the end of normal crash recovery, the user has to go digging to identify in-flight transactions still in the system and abort them manually. It would be nice if PIT recovery automatically aborted all in-flight transactions at the end. As PostgreSQL heads towards forward recovery functionality, it may be wise to add headers to the log files. As the logs from any cluster are identically named, the header would allow unique identification of the file and contents (cluster name, unique log id, id of the prior log file for chaining purposes, lsn ranges, etc). Most helpful. Just a few notes from the administrative side. PIT recovery should probably offer the user the following actions: . forward recover to end of logs [and stop] Process log files located in the current directory until you read through the last one. Allow the user the option to stop or not, just in case the logs are archived. Send back the timestamp of the last encountered commit log record and the series of log files scanned. . forward recover to PIT [and stop] Similar to that described above but use the commit timestamps to gauge PIT progress. . forward recover query Send back the log series covered and the last commit timestamp encountered. . forward recover stop Stop the current forward recovery session. Undo all in-flight transactions and bring the databases down in a consistent state. No other external user actions should be required. Looking forward to reading draft 2. Cheers, Patrick -- Patrick Macdonald Red Hat Canada J. R. Nield wrote: Hello: I've got the logging system to the point where I can take a shutdown consistent copy of a system, and play forward through multiple checkpoints. It seems to handle CREATE TABLE/DROP TABLE/TRUNCATE properly, and things are moving forward well. Recovery to an arbitrary point-in-time should be just as easy, but will need some administrative interface for it. At this point, some input would be useful on how I should handle things. The most important questions that need answering are in sections 2 5, since they impact the most other parts of the system. They will also require good documentation for sysadmins. Issues Outstanding for Point In Time Recovery (PITR) $Date: 2002/07/04 14:23:37 $ $Revision: 1.4 $ J.R. Nield (Enc: ISO 8859-15 Latin-9) §0 - Introduction This file is where I'm keeping track of all the issues I run into while trying to get PITR to work properly. Hopefully it will evolve into a description of how PITR actually works once it is implemented. I will also try to add feedback as it comes in. The big items so-far are: §1 - Logging Relation file creation, truncation, and removal This is mostly done. Can do infinte play-forward from online logs. §2 - Partial-Write and Bad Block detection
Re: [HACKERS] (A) native Windows port
Lamar Owen [EMAIL PROTECTED] writes: What it *does* do is effectively mask a DBA error. This is a satisfactory answer. In the context of the RPM distribution, if the initscript is used the DBA error probability is greatly reduced, thus the initscript can safely initdb. Fair enough --- if the upper-layer script thinks it has enough safeties in place, let it auto-initdb. I just don't think the postmaster should do that. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
