Re: [HACKERS] Do we really need a 7.4.22 release now?
2008/9/20 Joshua D. Drake [EMAIL PROTECTED]: Andrew Dunstan wrote: Joshua D. Drake wrote: 3 years - Maintenance mode only 5 years - End of life Of course we need to define what maintenance mode only means. We effectively put each release into maintenance mode on day 1, ISTM. True enough. Surely it should be x years from the release of the next major version or something Not x years from release. If we say End of Life is x years from release then don't get round to releasing for ages a version may reach end of life with nothing to replace it. (Which will happen if we ever exhaust the To Do list (bit pie in the sky but never mind)) Peter -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Permanent settings
On 21/02/2008, Joshua D. Drake [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Feb 2008 23:02:34 -0500 Aidan Van Dyk [EMAIL PROTECTED] wrote: * Joshua D. Drake [EMAIL PROTECTED] [080220 21:15]: The one thing this does is make the postgresql.conf basically a placeholder. It is not definitive anymore, in the sense that settings will be overwritten on restart. That really isn't that uncommon anyway in other applications. Man, I'ld screem *bloody murder* if the config file we just finished, after spending days (or weeks) of careful analisys and implementation discussion was overwritten by postmaster automatically on server startup... And I of course would respond, read the docs :P But part of that might just be user education... I personally just can't imagine that education could be enough to let *all* users know that as of version S, postgresql.conf is blatantly ignored, no, more exactly *purposely overwritten* with the old settings... We could also make it optional. Silly point postgresql.conf has a bunch of settings that are needed by the server before it can actually read the database, Sure move out settings that are not needed early in startup but your going to get problems with others. I quite like the function based method its flexible. Allowing pg_settings to be update able does not seam to be a bad idea but then you could do that with triggers and rules that called the functions surly? set should be for temporary transaction and session based variables, not for change permanent things thats what the SQL constructs insert, update, alter, create, delete, drop etc are for. Regards Peter
Re: 8.3.0 release schedule (Was:Re: [HACKERS] [BUGS] BUG #3852: Could not create complex aggregate)
On 08/01/2008, Darcy Buskermolen [EMAIL PROTECTED] wrote: On Monday 07 January 2008 16:06:27 Bruce Momjian wrote: Devrim GÜNDÜZ wrote: Hi, On Mon, 2008-01-07 at 17:12 -0500, Tom Lane wrote: if no serious bugs come up this week, core is thinking of wrapping 8.3.0 at the end of the week, Please give the packagers and other people one more week break between two releases. We all had a busy weekend. We have thousands of people waiting for the 8.3 release. It seems odd to hold up 8.3 because the packagers are too busy. Perhaps we need more packagers or release the source and have the binary packages ready later. Also to be fair I've seen no real announcement of RC1, probabbly because it's been bundled in with security releases for the other branched.. can we maybe do an RC1 announcement, let people actually test the RC before we push a gold ? Indeed the website still says we are on Beta 4. I did not even know RC1 was out until I saw this thread this morning. Peter.
Re: [HACKERS] WORM and Read Only Tables (v0.1)
On 11/12/2007, Csaba Nagy [EMAIL PROTECTED] wrote: On Tue, 2007-12-11 at 14:58 +0200, Hannu Krosing wrote: Ühel kenal päeval, T, 2007-12-11 kell 13:44, kirjutas Csaba Nagy: Then put the active chunk on a high performance file system and the archive tablespace on a compressed/slow/cheap file system and you're done. Allow even the archive chunk to be updateable, and put new tuple data in the active chunk. It would work just fine for cases where the old data is rarely updated/deleted... You can't update a table on a read-only (write-once) partition, at least not with current header structure. OK, but that's what I'm challenging, why do you need a write once partition ? You mean by that tapes ? OK, it means I was thinking in completely different usage scenarios then... Cheers, Csaba. I think DVD or CD would make sence, Tapes have an added limitation of being sequential access only. Peter Childs
Re: [HACKERS] WORM and Read Only Tables (v0.1)
On 11/12/2007, Simon Riggs [EMAIL PROTECTED] wrote: Attach -- Writing tables on one system and then moving that data to other systems is fairly common. If we supported read-only tables then you might consider how you would publish new versions to people. For now, we just want to consider how we will upgrade from one release to another without needing to unload and reload potentially many Terabytes of data. We can't delete the old data until the new data is successfully loaded, so we will have a huge temporary storage cost. This could go very slowly if we use cheaper storage, plus reloading the data means we have to re-freeze it again also. So we need a way of attaching the old tables to the new database. We might call this binary upgrade, or we might be slightly less ambitious and talk about just moving the old read-only data. That's all I want to do at this stage. I'm mentioning this here now to see what comes out in debate, and what others are planning to work on in this area. This sounds like allowing new versions to read old versions file structure, Probably I guess on a tablespace by table space basis Another advantage might be to be able to load an old pitr backup in a new version across major versions. But I'm not sure that would work. Maybe we need a command to upgrade a tablespace to a new versions file format? Need to be careful we don't stunt future progress by fixing file format much. Peter Childs
Re: [HACKERS] psql's describe command (for sequences) output improvement
On 04/12/2007, Aftab Hussain [EMAIL PROTECTED] wrote: Hi all, I have a patch which tries to improve the '\d some_sequence_name' command output in psql utility. Before sending the patch to pgsql-patches I just want to know your opinion whether the new output of the command is OK or it needs to be modified before sending it to pgsql-patches. For comparison purpose, here is the output of the '\d some_sequence_name' command: -- Say we have created a sequence named 'test_seq' already as CREATE SEQUENCE test_seq. -- -- Output: before applying the patch. -- testdb=# \d test_seq; Sequence public.test_seq Column | Type ---+- sequence_name | name last_value| bigint increment_by | bigint max_value | bigint min_value | bigint cache_value | bigint log_cnt | bigint is_cycled | boolean is_called | boolean -- -- Output: after applying the patch. -- testdb=# \d test_seq; Sequence public.test_seq last_value | increment_by | max_value | min_value | cache_value | log_cnt | is_cycled | is_called +--+-+---+-+-+---+--- 1 | 1| 9223372036854775807 | 1 | 1 | 1 | f | f Thanks in advance for your feedback(s). -- Aftab. Why? is that not what select * from test_seq; does already. \d command return meta data not data. Peter Childs
Re: [HACKERS] backup_label and server start
On 21/11/2007, Simon Riggs [EMAIL PROTECTED] wrote: On Wed, 2007-11-21 at 09:04 +0100, Albe Laurenz wrote: If somebody stops the postmaster while an online backup is in progress, there is no warning or nothing. Only the server will fail to restart. Well, it seems best not to do this. There is always a need for a careful procedure to manually shutdown a live server, interlocking with other applications. ISTM like a manual procedure will resolve this for you. If we remove the file in the place you suggest then an Archive Recovery will succeed when it should fail, with no possibility of a hint, which seems a worse error. All I want to do is restart a server after a clean shutdown. How about my second suggestion: Remove backup_label when the server shuts down cleanly. In that case an online backup in progress will not be useful anyway, and there is no need to recover on server restart. That will make PITRs fail: 1. pg_start_backup() 2. backup 3. shutdown, removes backup_label 4. pg_stop_backup() step 4 will now fail because of a missing backup_label file. How about this, emit a warning on shutdown and fail to shutdown until the backup has finished. Seams to me that either way your sunk if you shut down a server while a backup is in progress. Your only way out is to work out weather to use the previous pitr backups plus logs or remove the label. Doing it automatically would be very very dangerous. Peter.
Re: [HACKERS] [GENERAL] Cast your vote ...
On Thu, 2 Jan 2003, Marc G. Fournier wrote: Just got this in my mailbox: 2002 LinuxQuestions.org Members Choice Awards: http://www.linuxquestions.org/questions/showthread.php?s=78a8c06fbc1dcecd52597decd6c56ad8threadid=39870 And we are way behind MySQL (like, d'ah!): http://www.linuxquestions.org/questions/poll.php?s=78a8c06fbc1dcecd52597decd6c56ad8action=showresultspollid=168 The problem, of course, is that you have to be a registered member to vote, so its not an 'open poll' ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Open Poll? Its free to register, so really its to try and stop people voting twice. They don't even want that much data just your E-Mail address. (The rest is optional) The problem with Web Polls is that people can always vote more than once making any result totally meaning less what ever you do. Ensuring an election is anoumous, free and fare is VERY difficult. Peter Childs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
