Re: [HACKERS] start of transaction (was: Re: [PERFORM] Help with
On Sun, 17 Nov 2003, Greg Stark wrote: Neil Conway [EMAIL PROTECTED] writes: What does BEGIN actually do now, from a user's perspective? I think you're thinking about this all wrong. BEGIN doesn't do anything. It's not a procedural statement, it's a declaration. It declares that the block of statements form a transaction so reads should be consistent and failures should be handled in a particular way to preserve data integrity. Given that declaration and the guarantees it requires of the database it's then up to the database to figure out what constraints that imposes on what the database can do and still meet the guarantees the BEGIN declaration requires. The more clever the database is about minimizing those restrictions the better as it means the database can run more efficiently. For what it's worth, this is how Oracle handles things too. On the command-line issuing a BEGIN following a COMMIT is just noise; you're _always_ in a transaction. A COMMIT ends the previous the transaction and implicitly starts the next transaction. But the snapshot isn't frozen until you first read from a table. The earlier portion of the described behavior is AFAICS not complient to SQL99 at least. COMMIT (without AND CHAIN) terminates a transaction and does not begin a new one. The new transaction does not begin until a transaction initiating command (for example START TRANSACTION, CREATE TABLE, INSERT, ...) is executed. The set of things you can do that aren't initiating is fairly small admittedly, but it's not a null set. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Background writer process
On Friday 14 November 2003 22:10, Jan Wieck wrote: Shridhar Daithankar wrote: On Friday 14 November 2003 03:05, Jan Wieck wrote: For sure the sync() needs to be replaced by the discussed fsync() of recently written files. And I think the algorithm how much and how often to flush can be significantly improved. But after all, this does not change the real checkpointing at all, and the general framework having a separate process is what we probably want. Having fsync for regular data files and sync for WAL segment a comfortable compramise? Or this is going to use fsync for all of them. IMO, with fsync, we tell kernel that you can write this buffer. It may or may not write it immediately, unless it is hard sync. I think it's more the other way around. On some systems sync() might return before all buffers are flushed to disk, while fsync() does not. Oops.. that's bad. Since postgresql can afford lazy writes for data files, I think this could work. The whole point of a checkpoint is to know for certain that a specific change is in the datafile, so that it is safe to throw away older WAL segments. I just made another posing on patches for a thread crossing win32-devel. Essentially I said 1. Open WAL files with O_SYNC|O_DIRECT or O_SYNC(Not sure if current code does it. The hackery in xlog.c is not exactly trivial.) 2. Open data files normally and fsync them only in background writer process. Now BGWriter process will flush everything at the time of checkpointing. It does not need to flush WAL because of O_SYNC(ideally but an additional fsync won't hurt). So it just flushes all the file decriptors touched since last checkpoint, which should not be much of a load because it is flushing those files intermittently anyways. It could also work nicely if only background writer fsync the data files. Backends can either wait or proceed to other business by the time disk is flushed. Backends needs to wait for certain while committing and it should be rather small delay of syncing to disk in current process as opposed to in background process. In case of commit, BGWriter could get away with files touched in transaction +WAL as opposed to all files touched since last checkpoint+WAL in case of chekpoint. I don't know how difficult that would be. What is different in currrent BGwriter implementation? Use of sync()? Shridhar ---(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] Release now live ...
Hi, in doc/man1/psql.1 there is a line: Welcome to psql 7.4beta5, the PostgreSQL interactive terminal. Tommi Am Montag, 17. November 2003 02:23 schrieb Marc G. Fournier: 'k, I just moved the release into the /pub/source/v7.4 directory from the v7.4beta one ... RC2 is still in place, so that I don't break a bunch of links ... tomorrow night, I'll remove the RC2 ... ---(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 -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] start of transaction (was: Re: [PERFORM] Help with
Tom Lane kirjutas E, 17.11.2003 kell 02:08: Neil Conway [EMAIL PROTECTED] writes: Hmmm... I agree this behavior isn't ideal, although I can see the case for viewing this as a mistake by the application developer: they are assuming that they know exactly when transactions begin, which is not a feature provided by their language interface. Well, actually, it's a bug in the interface IMHO. But as I said in the last thread, it's a fairly widespread bug. I'm not sure that it is a client-side bug. For example Oracle seems to _always_ have a transaction going, i.e. you can't be outside of transaction, and you use just COMMIT to commit old _and_start_new_ transaction. IIRC the same is true for DB2. For these database the BEGIN TRANSACTION command is mainly used for starting nested transactions, which we don't have. We've been taking the position that the interface libraries should get fixed, and that's not happening. It's probably time to look at a server-side fix. Maybe fixing the interface libraries would make them incompatible with *DBC's for all other databases in some subtle ways ? - Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] start of transaction (was: Re: [PERFORM] Help with
Bruce Momjian kirjutas E, 17.11.2003 kell 02:31: Defining now() as the first call seems pretty arbitrary to me. I can't think of any time-based interface that has that API. And what if a trigger called now() in an earlier query and you didn't even know about it. That would be OK. The whole point of that previous discussion was to have now() that returns the same value over the span of the whole transaction. It would be even better to have now() that returns the time current transaction is COMMITted as this is the time other backend become aware of it ;) --- Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Background writer process
1. Open WAL files with O_SYNC|O_DIRECT or O_SYNC(Not sure if Without grouping WAL writes that does not fly. Iff however such grouping is implemented that should deliver optimal performance. I don't think flushing WAL to the OS early (before a tx commits) is necessary, since writing 8k or 256k to disk with one call takes nearly the same time. The WAL write would need to be done as soon as eighter 256k fill or a txn commits. Andreas ---(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
[HACKERS] commenting on polymorphic aggregates possible?
-- value-independent transition function CREATE AGGREGATE newcnt ( sfunc = int4inc, basetype = 'any', stype = int4, initcond = '0' ); COMMENT ON AGGREGATE newcnt (any) IS 'an any agg comment'; ERROR: syntax error at or near any at character 30 COMMENT ON AGGREGATE newcnt (any) IS NULL; ERROR: syntax error at or near any at character 30 Is there any way of commenting that aggregate? 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] [pgsql-hackers-win32] [PATCHES] SRA Win32 sync() code
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Where am I wrong? I don't think any of this is relevant. There are a certain number of blocks we have to get down to disk before we can declare a transaction committed, and there are a certain number that we have to get down to disk before we can declare a checkpoint complete. You are focusing too much on the question of whether a particular process performs an fsync operation, and ignoring the fact that ultimately it's got to wait for I/O to complete --- directly or indirectly. If it blocks waiting for some other process to declare a buffer clean, rather than writing for itself, what's the difference? Sure, fsync serializes the particular process that's doing it, but we can deal with that by spreading the fsyncs across multiple processes, and trying to ensure that they are mostly background processes rather than foreground ones. I don't claim that immediate-fsync-on-write is the only answer, but I cannot follow your reasoning for dimissing it out of hand ... and I certainly cannot buy *any* logic that says that sync() is a good answer to any of these issues. AFAICS sync() means that we abandon responsibility. [ Discussion moved to hackers/win32.] I was thinking about sync() --- one of its problems is that is schedules writes to disk but returns before it is completed. If we do sync(), then open, write, fsync, close a file, aren't we then pretty sure all the scheduled sync writes have completed too? I know SCSI has tagged queueing, but I figured creating a new file and writing/fsync would come after the sync writes. -- 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] 7.4 make failure on OSX
Hi, I suspect this a problem local to my machine, but I cannot compile with the --with-java option... It fails like so driver: [copy] Copying 1 file to /usr/local/install/postgresql-7.4/src/interfaces/jdbc/org/postgresql [echo] Configured build for the JDBC3 edition driver with SSL compile: BUILD FAILED file:/usr/local/install/postgresql-7.4/src/interfaces/jdbc/build.xml:114: Old driver was detected on classpath or in jre/lib/ext, please remove and try again. Total time: 6 seconds make[3]: *** [all] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 I have removed the driver from my old 7.3 installation... But it still fails like this. Any ideas how to fix this? Thanks Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] logical column position
I'd like to add a new column to pg_attribute that specifies the attribute's logical position within its relation. The idea here is to separate the logical order of the columns in a relation from the on-disk storage of the relation's tuples. This allows us to easily quickly change column order, add an additional column before or after an existing column, etc. At present, attnum basically does three things: identifies an column within a relation, indicates which columns are system columns, and defines the order of a relation's columns. I'd like to move this last functionality into a separate pg_attribute column named attpos (or attlogicalpos): - when the table is created, attnum == attpos. System columns have attpos 0, as with attnum. At no point will two columns of the same relation have the same attpos. - when returning output to the client and no column ordering is implied by the query (e.g. SELECT * ...), we sort the columns in ascending attpos order. - when storing a tuple on disk, we don't consider attpos - if we want to change the order of the column's in a relation, we can do so merely by updating pg_attribute; no changes to the on-disk storage of the relation should be necessary A few notes: (a) ISTM this should also apply to COPY TO and COPY FROM if the user didn't supply a column list. Is this reasonable? It would break dumps of the table's contents, but then again, dumps aren't guaranteed to remain valid over arbitrary changes to the table's meta-data. (b) Using the above scheme that attnum == attpos initially, there won't be any gaps in the sequence of attpos values. That means that if, for example, we want to move the column in position 50 to position 1, we'll need to change the position's of all the columns in positions [1..49] (and suffer the resulting MVCC bloat in pg_attribute). Changing the column order is hardly a performance critical operation, so that might be acceptable. If we want to avoid this, one easy (but arguably unclean) way to do so would be to make the initial value of attpos == attnum * 1000, and make attpos an int4 rather than an int2. Then, we can do most column reordering operations with only a single pg_attribute update -- in the worst-case that enough re-orderings are done that we overflow the 999 padding positions, we can just fall-back to doing multiple pg_attribute updates. Is this worth doing, and/or is there a better way to achieve the same effect? (c) Do I need to consider inheritance? Comments are welcome. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] logical column position
I'd like to add a new column to pg_attribute that specifies the attribute's logical position within its relation. The idea here is to separate the logical order of the columns in a relation from the on-disk storage of the relation's tuples. This allows us to easily quickly change column order, add an additional column before or after an existing column, etc. At present, attnum basically does three things: identifies an column within a relation, indicates which columns are system columns, and defines the order of a relation's columns. I'd like to move this last functionality into a separate pg_attribute column named attpos (or attlogicalpos): - when the table is created, attnum == attpos. System columns have attpos 0, as with attnum. At no point will two columns of the same relation have the same attpos. - when returning output to the client and no column ordering is implied by the query (e.g. SELECT * ...), we sort the columns in ascending attpos order. - when storing a tuple on disk, we don't consider attpos - if we want to change the order of the column's in a relation, we can do so merely by updating pg_attribute; no changes to the on-disk storage of the relation should be necessary A few notes: (a) ISTM this should also apply to COPY TO and COPY FROM if the user didn't supply a column list. Is this reasonable? It would break dumps of the table's contents, but then again, dumps aren't guaranteed to remain valid over arbitrary changes to the table's meta-data. (b) Using the above scheme that attnum == attpos initially, there won't be any gaps in the sequence of attpos values. That means that if, for example, we want to move the column in position 50 to position 1, we'll need to change the position's of all the columns in positions [1..49] (and suffer the resulting MVCC bloat in pg_attribute). Changing the column order is hardly a performance critical operation, so that might be acceptable. If we want to avoid this, one easy (but arguably unclean) way to do so would be to make the initial value of attpos == attnum * 1000, and make attpos an int4 rather than an int2. Then, we can do most column reordering operations with only a single pg_attribute update -- in the worst-case that enough re-orderings are done that we overflow the 999 padding positions, we can just fall-back to doing multiple pg_attribute updates. Is this worth doing, and/or is there a better way to achieve the same effect? (c) Do I need to consider inheritance? Comments are welcome. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 7.4 make failure on OSX ... Please ignore
Sorry, I did find the offending driver in the end... And it is running happily now. Sorry for the noise Adam Hi, I suspect this a problem local to my machine, but I cannot compile with the --with-java option... It fails like so driver: [copy] Copying 1 file to /usr/local/install/postgresql-7.4/src/interfaces/jdbc/org/postgresql [echo] Configured build for the JDBC3 edition driver with SSL compile: BUILD FAILED file:/usr/local/install/postgresql-7.4/src/interfaces/jdbc/build.xml:114: Old driver was detected on classpath or in jre/lib/ext, please remove and try again. Total time: 6 seconds make[3]: *** [all] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 I have removed the driver from my old 7.3 installation... But it still fails like this. Any ideas how to fix this? Thanks Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] logical column position
Neil Conway writes: (b) Using the above scheme that attnum == attpos initially, there won't be any gaps in the sequence of attpos values. That means that if, for example, we want to move the column in position 50 to position 1, we'll need to change the position's of all the columns in positions [1..49] (and suffer the resulting MVCC bloat in pg_attribute). Changing the column order is hardly a performance critical operation, so that might be acceptable. I don't think you can speak of bloat for pg_attribute. But you can speak of a problem when you want to do the old col = col + 1 in the presence of a unique index. (c) Do I need to consider inheritance? Inheritance is based on column names, so initially no, but if there is a command to alter the column order, then it should have an ONLY option. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] logical column position
On Mon, 17 Nov 2003, Neil Conway wrote: I'd like to add a new column to pg_attribute that specifies the attribute's logical position within its relation. The idea here is to separate the logical order of the columns in a relation from the on-disk storage of the relation's tuples. This allows us to easily quickly change column order, add an additional column before or after an existing column, etc. That sounds excellent! (a) ISTM this should also apply to COPY TO and COPY FROM if the user didn't supply a column list. Is this reasonable? It would break dumps of the table's contents, but then again, dumps aren't guaranteed to remain valid over arbitrary changes to the table's meta-data. You're just saying it'd break old dumps, right? I'd assume COPY FROM would use attpos ordering when writing out columns, or that every user-visible interaction with the table pretends the columns are in attpos order. So dumps would break no more or less than when adding or dropping a column currently, right? Jon ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] logical column position
Peter Eisentraut [EMAIL PROTECTED] writes: I don't think you can speak of bloat for pg_attribute. But you can speak of a problem when you want to do the old col = col + 1 in the presence of a unique index. I'm sorry, but I'm not sure what either of these comments mean -- can you elaborate? -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] logical column position
Jon Jensen [EMAIL PROTECTED] writes: You're just saying it'd break old dumps, right? I'd assume COPY FROM would use attpos ordering when writing out columns, or that every user-visible interaction with the table pretends the columns are in attpos order. So dumps would break no more or less than when adding or dropping a column currently, right? Right -- AFAICS, the only change in COPY compatibility would be if you COPY TO'd a table and then changed the logical column order in some fashion, you would no longer be able to restore the dump (unless you specified a column list for the COPY FROM -- which, btw, pg_dump does). I don't think it will be a problem, I just thought I'd mention it. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Connexions question
Hi all, I don't think it's a FAQ, Is it possible to limit then number of simultaneous connexions one can make to a particular databse. E.G: I have 128 connexions max of witch I wan't to restrict at most 60 to database x, leaving in the worst case 68 for all others... Am I clear? -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Connexions question
It's a command line option for the server. http://developer.postgresql.org/docs/postgres/app-postmaster.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 11:21 AM To: pgsql-hackers list Subject: [HACKERS] Connexions question Hi all, I don't think it's a FAQ, Is it possible to limit then number of simultaneous connexions one can make to a particular databse. E.G: I have 128 connexions max of witch I wan't to restrict at most 60 to database x, leaving in the worst case 68 for all others... Am I clear? -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Connexions question
Oops. Never mind. I did not read your message carefully. -Original Message- From: Dann Corbit Sent: Monday, November 17, 2003 11:51 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] Connexions question It's a command line option for the server. http://developer.postgresql.org/docs/postgres/app-postmaster.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 11:21 AM To: pgsql-hackers list Subject: [HACKERS] Connexions question Hi all, I don't think it's a FAQ, Is it possible to limit then number of simultaneous connexions one can make to a particular databse. E.G: I have 128 connexions max of witch I wan't to restrict at most 60 to database x, leaving in the worst case 68 for all others... Am I clear? -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Connexions question
Er, that's a per-server limit, not a per-database limit (which is what he asked for), isn't it? cheers andrew Dann Corbit wrote: It's a command line option for the server. http://developer.postgresql.org/docs/postgres/app-postmaster.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 11:21 AM To: pgsql-hackers list Subject: [HACKERS] Connexions question Hi all, I don't think it's a FAQ, Is it possible to limit then number of simultaneous connexions one can make to a particular databse. E.G: I have 128 connexions max of witch I wan't to restrict at most 60 to database x, leaving in the worst case 68 for all others... Am I clear? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Optimizer optimizer may be worth a look-see
http://www.coyotegulch.com/acovea/index.html ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] libpq thread safety
Hi, I've searched through libpq and looked for global or static variables as indicators of non-threadsafe code. I found: - Win32 and BeOS: there is a global ioctlsocket_ret variable, but it seems to be a dummy variable that is always discarded. - pg_krb4_init(): Are the kerberos libraries thread safe? Additionally, setting init_done is racy. - pg_krb4_authname(): uses a static buffer. - kerberos 5: Is the library thread safe? the initialization could run twice, I'm not sure if that's intentional. - pg_krb4_authname(): relies on the global variable pg_krb5_name. - PQoidStatus: uses a static buffer. - libpq_gettext: setting already_bound is racy. - openssl: According to http://www.openssl.org/docs/crypto/threads.html libpq must register locking callbacks within openssl, otherwise there will be random corruptions. Additionally the SSL_context initialization is not properly synchronized, and SSLerrmessage relies on a static buffer. PQoidStatus is already documented as not thread safe, but what about OpenSSL and kerberos? It seems openssl needs support with callbacks, and according to google searches MIT kerberos 5 is not thread safe, and libpq must use mutexes to prevent concurrent calls into the kerberos library. -- Manfred ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] A big thanks to SuSE
Yesterday I was a bit worried... I switched to SuSE just 2 weeks ago... my newly installed databse server was waitinI thought that I would have to wait so much to have RPMs for SuSE and today I see v7.4 compiled for many flavors of SuSE, even for X86-64. Wow :) Thanks :) -- Daniele Orlandi ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5
On Sun, Nov 02, 2003 at 07:25:38AM -0500, Rod Taylor wrote: On Sat, 2003-11-01 at 20:58, Mark Wong wrote: I don't remember making a conscious decision between the number and integer database type. Is that a significant oversight on my part? Numerics do exact math with support for arbitrary numbers. Unlike Oracle, PostgreSQL does not retype NUMBER to a faster type internally (like int). You may find a good sized improvement (possibly as much as 15%) by switching to integer as it will both reduce CPU load and storage requirements. I've changed all the numerics to integers and reals, where it was appropriate to maintain the precision specificed in the TPC-C spec. Here's a comparison of results: http://developer.osdl.org/markw/dbt2-pgsql/214/ - using all numerics - metric 1831.78 http://developer.osdl.org/markw/dbt2-pgsql/217/ - integers and reals where appropriate - metric 1972.94 Looks like I see about an 8% improvement in the metric with this instance. A definite decrease in user time in the processor utilization chart, which I presume is attributed to the 70% decrease in ticks to SearchCatCache in the database as reported by oprofile. Can anyone explain that one? Mark ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Not 7.5, but 8.0 ?
Folks, Of course, while I was editing press releases at 2am, I started thinking about our next version. It seems certain that the next release, in 6-9 months, will have at a minimum the Windows port and ARC, if not Slony-I as well. Given all that, don't people think it's time to jump to 8.0?Seems like even 7.4 is hardly recognizable as the same database as 7.0. I'm posting this to both Advocacy and Hackers because I think that some people will have rather different points of view on the issue. But I wanted to start a discussion early this time. No flamewars, please! We all want PostgreSQL to be the best possible database. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Josh Berkus [EMAIL PROTECTED] writes: It seems certain that the next release, in 6-9 months, will have at a minimum the Windows port and ARC, if not Slony-I as well. Given all that, don't people think it's time to jump to 8.0? It seems a little premature to speculate on what features may or may not be present in 6 to 9 months time. Why make this decision now, when we don't even know what will be in the next release, rather than at the end of the development cycle? -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Josh Berkus writes: Given all that, don't people think it's time to jump to 8.0? As has been said before, many people think that a Windows port is the least interesting feature ever to happen to PostgreSQL, so you're going to have to come up with better reasons. Also note that most major number changes in the past weren't because the features were cool, but because the project has moved to a new phase. I don't see any such move happening. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Release cycle length
The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. We already have a number of significant improvements in 7.5 now, and several good ones coming up in the next few weeks. We cannot let people wait 1 year for that. I suggest that we aim for a 6 month cycle, consisting of approximately 4 months of development and 2 months of cleanup. So the start of the next beta could be the 1st of March. What do you think? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Hello, If Win32 actually makes it into 7.5 then yes I believe 8.0 would be appropriate. Sincerely, Joshua D. Drake On Mon, 17 Nov 2003, Josh Berkus wrote: Folks, Of course, while I was editing press releases at 2am, I started thinking about our next version. It seems certain that the next release, in 6-9 months, will have at a minimum the Windows port and ARC, if not Slony-I as well. Given all that, don't people think it's time to jump to 8.0?Seems like even 7.4 is hardly recognizable as the same database as 7.0. I'm posting this to both Advocacy and Hackers because I think that some people will have rather different points of view on the issue. But I wanted to start a discussion early this time. No flamewars, please! We all want PostgreSQL to be the best possible database. -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead ---(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] [pgsql-advocacy] Not 7.5, but 8.0 ?
As has been said before, many people think that a Windows port is the least interesting feature ever to happen to PostgreSQL, so you're going to Yes but these are people running Unix/Linux/BSD not Windows ;) have to come up with better reasons. Also note that most major number changes in the past weren't because the features were cool, but because the project has moved to a new phase. I don't see any such move happening. -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead ---(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] Background writer process
Shridhar Daithankar wrote: On Friday 14 November 2003 22:10, Jan Wieck wrote: Shridhar Daithankar wrote: On Friday 14 November 2003 03:05, Jan Wieck wrote: For sure the sync() needs to be replaced by the discussed fsync() of recently written files. And I think the algorithm how much and how often to flush can be significantly improved. But after all, this does not change the real checkpointing at all, and the general framework having a separate process is what we probably want. Having fsync for regular data files and sync for WAL segment a comfortable compromise? Or this is going to use fsync for all of them. IMO, with fsync, we tell kernel that you can write this buffer. It may or may not write it immediately, unless it is hard sync. I think it's more the other way around. On some systems sync() might return before all buffers are flushed to disk, while fsync() does not. Oops.. that's bad. Yes, one I idea I had was to do an fsync on a new file _after_ issuing sync, hoping that this will complete after all the sync buffers are done. Since postgresql can afford lazy writes for data files, I think this could work. The whole point of a checkpoint is to know for certain that a specific change is in the datafile, so that it is safe to throw away older WAL segments. I just made another posing on patches for a thread crossing win32-devel. Essentially I said 1. Open WAL files with O_SYNC|O_DIRECT or O_SYNC(Not sure if current code does it. The hackery in xlog.c is not exactly trivial.) We write WAL, then fsync, so if we write multiple blocks, we can write them and fsync once, rather than O_SYNC every write. 2. Open data files normally and fsync them only in background writer process. Now BGWriter process will flush everything at the time of checkpointing. It does not need to flush WAL because of O_SYNC(ideally but an additional fsync won't hurt). So it just flushes all the file descriptors touched since last checkpoint, which should not be much of a load because it is flushing those files intermittently anyways. It could also work nicely if only background writer fsync the data files. Backends can either wait or proceed to other business by the time disk is flushed. Backends needs to wait for certain while committing and it should be rather small delay of syncing to disk in current process as opposed to in background process. In case of commit, BGWriter could get away with files touched in transaction +WAL as opposed to all files touched since last checkpoint+WAL in case of checkpoint. I don't know how difficult that would be. What is different in current BGwriter implementation? Use of sync()? Well, basically we are still discussing how to do this. Right now the backend writer patch uses sync(), but the final version will use fsync or O_SYNC, or maybe nothing. The open items are whether a background process can keep the dirty buffers cleaned fast enough to keep up with the maximum number of backends. We might need to use multiple processes or threads to do this. We certainly will have a background writer in 7.5 --- the big question is whether _all_ write will go through it. It certainly would be nice if it could, and Tom thinks it can, so we are still exploring this. If the background writer uses fsync, it can write and allow the buffer to be reused and fsync later, while if we use O_SYNC, we have to wait for the O_SYNC write to happen before reusing the buffer; that will be slower. Another open issue is _if_ the backend writer can't keep up with the normal backends, do we allow normal backends to write dirty buffers, and do they use fsync(), or can we record the file in a shared area and have the background writer do the fsync. This is the issue of whether one process can fsync all dirty buffers for the file or just the buffers it wrote. I think this is these are the basics of the current discussion. -- 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] Release cycle length
On Tue, 18 Nov 2003, Peter Eisentraut wrote: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. We already have a number of significant improvements in 7.5 now, and several good ones coming up in the next few weeks. We cannot let people wait 1 year for that. I suggest that we aim for a 6 month cycle, consisting of approximately 4 months of development and 2 months of cleanup. So the start of the next beta could be the 1st of March. What do you think? That is the usual goal *nod* Same goal we try for each release, and never quite seem to get there ... we'll try 'yet again' with v7.5 though, as we always do :) ---(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] [pgsql-advocacy] Not 7.5, but 8.0 ?
On Mon, 17 Nov 2003, Josh Berkus wrote: Given all that, don't people think it's time to jump to 8.0? Seems like even 7.4 is hardly recognizable as the same database as 7.0. Discussion like this tends to be more for just before beta, once we have an idea what actually made it in :) You be putting the cart before the horse, eh? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Release cycle length
Marc G. Fournier writes: That is the usual goal *nod* Same goal we try for each release, and never quite seem to get there ... we'll try 'yet again' with 7.5 though, as we always do :) I don't see how we could have tried for a 4-month development period and ended up with an 8-month period. Something went *really* wrong there. Part of that may have been that few people were actually aware of that schedule. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] start of transaction (was: Re: [PERFORM] Help with count(*))
Hannu Krosing wrote: Bruce Momjian kirjutas E, 17.11.2003 kell 02:31: Defining now() as the first call seems pretty arbitrary to me. I can't think of any time-based interface that has that API. And what if a trigger called now() in an earlier query and you didn't even know about it. That would be OK. The whole point of that previous discussion was to have now() that returns the same value over the span of the whole transaction. I think my issue is that there isn't any predictable way for a user to know when the now() time is recorded. By using start of transaction, at least we know for sure the point in time it is showing. It would be even better to have now() that returns the time current transaction is COMMITted as this is the time other backend become aware of it ;) True, but implementing that would be very hard. -- 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] Release cycle length
On Tue, 18 Nov 2003, Peter Eisentraut wrote: Marc G. Fournier writes: That is the usual goal *nod* Same goal we try for each release, and never quite seem to get there ... we'll try 'yet again' with 7.5 though, as we always do :) I don't see how we could have tried for a 4-month development period and ended up with an 8-month period. Something went *really* wrong there. Part of that may have been that few people were actually aware of that schedule. Everyone on -hackers should have been aware of it, as its always discussed at the end of the previous release cycle ... and I don't think we've hit a release cycle yet that has actually stayed in the 4 month period :( Someone is always 'just sitting on something that is almost done' at the end that pushes it further then originally planned ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Release now live ...
Tommi Maekitalo wrote: Hi, in doc/man1/psql.1 there is a line: Welcome to psql 7.4beta5, the PostgreSQL interactive terminal. Yea, sorry. It pulls the version number from the time those man pages were built. Not sure how we could have prevented 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 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Joshua D. Drake wrote: Hello, If Win32 actually makes it into 7.5 then yes I believe 8.0 would be appropriate. It might be interesting to track Oracle's version number viz. its feature list. IOW, a PostgreSQL 8.0 database would be feature equivalent to an Oracle 8.0 database. That would mean: 1) PITR 2) Distributed Tx 3) Replication 4) Nested Tx 5) PL/SQL Exception Handling IMHO, a major version number jump should at least match the delta in features one finds in the commercial segment with their major version number bumps. Otherwise, I suspect it would be viewed as window dressing... Could be wrong, though... Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Release cycle length
Just did a quick search on archives, and the original plan was for a release in mid-2003, which means the beta would have been *at least* a month before that, so beta starting around May: http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php On Mon, 17 Nov 2003, Marc G. Fournier wrote: On Tue, 18 Nov 2003, Peter Eisentraut wrote: Marc G. Fournier writes: That is the usual goal *nod* Same goal we try for each release, and never quite seem to get there ... we'll try 'yet again' with 7.5 though, as we always do :) I don't see how we could have tried for a 4-month development period and ended up with an 8-month period. Something went *really* wrong there. Part of that may have been that few people were actually aware of that schedule. Everyone on -hackers should have been aware of it, as its always discussed at the end of the previous release cycle ... and I don't think we've hit a release cycle yet that has actually stayed in the 4 month period :( Someone is always 'just sitting on something that is almost done' at the end that pushes it further then originally planned ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Release cycle length
Peter Eisentraut [EMAIL PROTECTED] writes: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. Why is that? -Neil ---(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] Release cycle length
Marc G. Fournier writes: Just did a quick search on archives, and the original plan was for a release in mid-2003, which means the beta would have been *at least* a month before that, so beta starting around May: http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php That was a Bruce Momjian estimate mentioned in passing, not an affirmed plan. Also, I think Bruce's estimates are notoriously off by years. ;-) -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] logical column position
Right -- AFAICS, the only change in COPY compatibility would be if you COPY TO'd a table and then changed the logical column order in some fashion, you would no longer be able to restore the dump (unless you specified a column list for the COPY FROM -- which, btw, pg_dump does). I don't think it will be a problem, I just thought I'd mention it. Well it's the same problem as if you'd dropped a column in the middle of the table. BTW, one main consideration is that all the postgres admin apps will now need to support ORDER BY attlognum for 7.5+. Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Release cycle length
Neil Conway writes: Peter Eisentraut [EMAIL PROTECTED] writes: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. Why is that? First, if you develop something today, the first time users would realistically get a hand at it would be January 2005. Do you want that? Don't you want people to use your code? We fix problems, but people must wait a year for the fix? Second, the longer a release cycle, the more problems amass. People just forget what they were doing in the beginning, no one is around to fix the problems introduced earlier, no one remembers anything when it comes time to write release notes. The longer you develop, the more parallel efforts are underway, and it becomes impossible to synchronize them to a release date. People are not encouraged to provide small, well-thought-out, modular improvements. Instead, they break everything open and worry about it later. At the end, it's always a rush to close these holes. Altogether, it's a loss for both developers and users. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] help!
I screwed up, and dropped a column when I shouldn't have. I have *not* vacuumed this DB yet. Is there any catalog mucking I can do to bring it back? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] logical column position
Neil Conway wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I don't think you can speak of bloat for pg_attribute. But you can speak of a problem when you want to do the old col = col + 1 in the presence of a unique index. I'm sorry, but I'm not sure what either of these comments mean -- can you elaborate? Peter is pointing out a problem with our unique indexes that might cause you a problem. Suppose you have a unique index in attlognum: test= create table xx( lognum int); CREATE TABLE test= insert into xx values (1); INSERT 17145 1 test= insert into xx values (2); INSERT 17146 1 test= update xx set lognum = lognum + 1; UPDATE 2 test= create unique index yy on xx (lognum); CREATE INDEX test= update xx set lognum = lognum + 1; ERROR: duplicate key violates unique constraint yy There is discussion to delay unique constraint failures until commit, then recheck them to see if they are still valid, sort of like what we do with deferred triggers. This would fix the problem because on commit, those values are unique, but aren't while the rows are updated invidually. If we don't get that working you might want to use the 1000 gap idea because it doesn't cause this problem, and we don't support 1600 columns, so a 1000 gap shouldn't cause a problem and can be modified later. If they hit 999 updates, just tell them to dump/reload the table. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Release cycle length
The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. We already have a number of significant improvements in 7.5 now, and several good ones coming up in the next few weeks. We cannot let people wait 1 year for that. I suggest that we aim for a 6 month cycle, consisting of approximately 4 months of development and 2 months of cleanup. So the start of the next beta could be the 1st of March. What do you think? So long as pg_dump object ordering is an early fix to make upgrades rather more painless, I'm all for it :) Does anyone have a comparison of how many lines of code were added in this release compared to previous? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Release cycle length
Everyone on -hackers should have been aware of it, as its always discussed at the end of the previous release cycle ... and I don't think we've hit a release cycle yet that has actually stayed in the 4 month period :( Someone is always 'just sitting on something that is almost done' at the end that pushes it further then originally planned ... I think that the core just need to be tough on it, that's all. If we have pre-published target dates, then everyone knows if they can get their code in or not for that date. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] logical column position
Neil Conway wrote: I'd like to add a new column to pg_attribute that specifies the attribute's logical position within its relation. The idea here is to separate the logical order of the columns in a relation from the on-disk storage of the relation's tuples. This allows us to easily quickly change column order, add an additional column before or after an existing column, etc. At present, attnum basically does three things: identifies an column within a relation, indicates which columns are system columns, and defines the order of a relation's columns. I'd like to move this last functionality into a separate pg_attribute column named attpos (or attlogicalpos): - when the table is created, attnum == attpos. System columns have attpos 0, as with attnum. At no point will two columns of the same relation have the same attpos. - when returning output to the client and no column ordering is implied by the query (e.g. SELECT * ...), we sort the columns in ascending attpos order. Seems the only cases where attpos would be used would be SELECT *, INSERT with no column list, and COPY --- seems like a nifty feature. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] help!
Wait for confirmation from at least one other developer perhaps, buy you can try this: 1. Set attisdropped to false for the attribute 2. Set the atttypid back to whatever the oid of the type of that column is/was (Compare to an undropped similar column) 3. Use ALTER TABLE/SET NOT NULL on the column if it was originally NOT NULL 4. Set attstattarget to -1 to re-enable stat gathering 5. Rename the column (attname field) back to whatever it was. 6. Re set the default on the column 7. Done. (I think) By the way, vacuuming doesn't necessarily have much to do with it - updating rows does though. I'm not 100% sure what will happen exactly when you follow the steps above (reversing what's in RemoveAttributeById). Chris Larry Rosenman wrote: I screwed up, and dropped a column when I shouldn't have. I have *not* vacuumed this DB yet. Is there any catalog mucking I can do to bring it back? LER ---(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] help!
--On Monday, November 17, 2003 19:36:08 -0600 Larry Rosenman [EMAIL PROTECTED] wrote: I screwed up, and dropped a column when I shouldn't have. I have *not* vacuumed this DB yet. Is there any catalog mucking I can do to bring it back? Actually, I got lucky. pg_catalog.pg_attribute is what I needed to muck with, and I got the column I needed back, and then translated. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Release cycle length
Hello, Personally I am for long release cycles, at least for major releases. In fact as of 7.4 I think there should possibly be a slow down in releases with more incremental releases (minor releases) throughout the year. People are running their companies and lives off of PostgreSQL, they should be able to rely on a specific feature set, and support from the community for longer. Sincerely, Joshua Drake Peter Eisentraut wrote: Neil Conway writes: Peter Eisentraut [EMAIL PROTECTED] writes: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. Why is that? First, if you develop something today, the first time users would realistically get a hand at it would be January 2005. Do you want that? Don't you want people to use your code? We fix problems, but people must wait a year for the fix? Second, the longer a release cycle, the more problems amass. People just forget what they were doing in the beginning, no one is around to fix the problems introduced earlier, no one remembers anything when it comes time to write release notes. The longer you develop, the more parallel efforts are underway, and it becomes impossible to synchronize them to a release date. People are not encouraged to provide small, well-thought-out, modular improvements. Instead, they break everything open and worry about it later. At the end, it's always a rush to close these holes. Altogether, it's a loss for both developers and users. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] help!
--On Tuesday, November 18, 2003 09:59:32 +0800 Christopher Kings-Lynne [EMAIL PROTECTED] wrote: Wait for confirmation from at least one other developer perhaps, buy you can try this: 1. Set attisdropped to false for the attribute 2. Set the atttypid back to whatever the oid of the type of that column is/was (Compare to an undropped similar column) 3. Use ALTER TABLE/SET NOT NULL on the column if it was originally NOT NULL 4. Set attstattarget to -1 to re-enable stat gathering 5. Rename the column (attname field) back to whatever it was. 6. Re set the default on the column 7. Done. (I think) By the way, vacuuming doesn't necessarily have much to do with it - updating rows does though. I'm not 100% sure what will happen exactly when you follow the steps above (reversing what's in RemoveAttributeById). I did the following, and was able to do what I needed to do: update pg_catalog.pg_attribute set attname='instance1',attisdropped='f',attypid=1048 where attrelid=2356153 and attname='pg.dropped.6'; and then re-do the stuff that my rt needed, and then re-drop the column. (basically the RT docs blew one character in a field name, and I wasn't paying attention :-) ) LER Chris Larry Rosenman wrote: I screwed up, and dropped a column when I shouldn't have. I have *not* vacuumed this DB yet. Is there any catalog mucking I can do to bring it back? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Release cycle length
On Tue, 18 Nov 2003, Christopher Kings-Lynne wrote: Everyone on -hackers should have been aware of it, as its always discussed at the end of the previous release cycle ... and I don't think we've hit a release cycle yet that has actually stayed in the 4 month period :( Someone is always 'just sitting on something that is almost done' at the end that pushes it further then originally planned ... I think that the core just need to be tough on it, that's all. If we have pre-published target dates, then everyone knows if they can get their code in or not for that date. Right now, I believe we are looking at an April 1st beta, and a May 1st related ... those are, as always, *tentative* dates that will become more fine-tuned as those dates become nearer ... April 1st, or 4 mos from last release, tends to be what we aim for with all releases ... as everyone knows, we don't necessarily acheive it, but ... Actually, historically, it looks like we've always been close to 12 months between releases ... 7.0-7.1: ~11mos, 7.1-7.2: ~10mos, 7.2-7.3: ~9 mos, and 7.3-7.4: ~12mos ... so, on average, we're dealing with an ~10mos release cycle for the past 3 years ... svr1# ls -l */postgresql-7.?.tar.gz -rw-rw-r-- 1 pgsql pgsql 9173732 May 9 2000 v7.0/postgresql-7.0.tar.gz -rw-r--r-- 1 pgsql pgsql 8088678 Apr 13 2001 v7.1/postgresql-7.1.tar.gz -rw-r--r-- 1 pgsql pgsql 9180168 Feb 4 2002 v7.2/postgresql-7.2.tar.gz -rw-r--r-- 1 pgsql pgsql 11059455 Nov 27 2002 v7.3/postgresql-7.3.tar.gz -rw-r--r-- 1 pgsql pgsql 12311256 Nov 16 17:57 v7.4/postgresql-7.4.tar.gz ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
Right now, I believe we are looking at an April 1st beta, and a May 1st related ... those are, as always, *tentative* dates that will become more fine-tuned as those dates become nearer ... April 1st, or 4 mos from last release, tends to be what we aim for with all releases ... as everyone knows, we don't necessarily acheive it, but Make it April 2nd, otherwise everyone will think it's a joke :P Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Release cycle length
Joshua D. Drake [EMAIL PROTECTED] writes: Hello, Personally I am for long release cycles, at least for major releases. In fact as of 7.4 I think there should possibly be a slow down in releases with more incremental releases (minor releases) throughout the year. That would pretty much mean changing the minor releases only for serious bugfixes philosphy. Is that what you are advocating? People are running their companies and lives off of PostgreSQL, they should be able to rely on a specific feature set, and support from the community for longer. If 7.3.4 works for you, there's nothing to stop you running it until the end of time... If you can't patch in bugfixes yourself, you should be willing to pay for support. Commercial companies like Red Hat don't support their releases indefinitely for free; why should the PG community be obligated to? Also, we very rarely remove features--AUTOCOMMIT on the server is about the only one I can think of. -Doug ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Release cycle length
Peter Eisentraut [EMAIL PROTECTED] writes: First, if you develop something today, the first time users would realistically get a hand at it would be January 2005. Do you want that? Don't you want people to use your code? Sure :-) But I don't mind a long release cycle if it is better for users. We fix problems, but people must wait a year for the fix? A couple points: (a) Critical problems can of course be fixed via point releases in the current stable release series (b) As PostgreSQL gets more mature, the number of absolutely show stopping features or bug fixes in a new release gets smaller. For example, I'd argue that neither 7.3 or 7.4 include a single feature that is as important as 7.2's lazy VACUUM or 7.1's WAL. There are lots of great features, but the set of absolutely essential new features tends to grow smaller over time. I'd wager that for the vast majority of our user base, PostgreSQL already works well. (c) As PostgreSQL gets more mature, putting out stable, production-worthy releases becomes even more important. In theory, longer release cycles contribute to higher quality releases: we have more time to implement new features properly, polish rough edges and document things, test and find bugs, and ensure that features we've implemented earlier in the release cycle are properly thought out, and so forth. Note that whether or not we are using those 355 days effectively is another story -- it may well be true that there are we could make parts of the development process much more efficient. Furthermore, longer release cycles reduce, to some degree, the pain of upgrades. Unless we make substantial improvements to the upgrade story any time soon, I wouldn't be surprised if many DBAs are relieved at only needing to upgrade once a year. The longer you develop, the more parallel efforts are underway, and it becomes impossible to synchronize them to a release date. I think this is inherent to the way PostgreSQL is developed: Tom has previously compared PostgreSQL release scheduling to herding cats :-) As long as much of the work on the project is done by volunteers in their spare time, ISTM that coordinating everyone toward a single release date is going to be difficult, if not impossible. The length of the release cycle doesn't really effect this, IMHO. People are not encouraged to provide small, well-thought-out, modular improvements. I agree we can always do better when it comes to code quality. I think the NetBSD team puts it well: Some systems seem to have the philosophy of If it works, it's right. In that light NetBSD could be described as It doesn't work /unless/ it's right. That said, I don't see how this is related to the release schedule. In fact, one could argue that a longer release schedule gives new features a longer gestation period during which developers can ensure that they are well-thought out and implemented properly. Altogether, it's a loss for both developers and users. I don't think it's nearly as clear-cut as that. Both types of release scheduling have their benefits and their drawbacks. My main point is really that a short release cycle is not an unqualified good (not to mention that in the past we've been completely unable to actually *execute* a short release cycle, making this whole discussion a little academic). -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
Marc G. Fournier writes: Right now, I believe we are looking at an April 1st beta, and a May 1st related ... those are, as always, *tentative* dates that will become more fine-tuned as those dates become nearer ... OK, here start the problems. Development already started, so April 1st is already 5 months development. Add 1 month because no one is willing to hold people to these dates. So that's 6 months. Then for 6 months of development, you need at least 2 months of beta. So we're already in the middle of July, everyone is on vacation, and we'll easily reach the 9 months -- instead of 6. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] libpq thread safety
Manfred Spraul wrote: Hi, I've searched through libpq and looked for global or static variables as indicators of non-threadsafe code. I found: - Win32 and BeOS: there is a global ioctlsocket_ret variable, but it seems to be a dummy variable that is always discarded. Right, and it is moving into a compatibility function in 7.5 where it will be a local function variable. - pg_krb4_init(): Are the kerberos libraries thread safe? Additionally, setting init_done is racy. No idea. - pg_krb4_authname(): uses a static buffer. - kerberos 5: Is the library thread safe? the initialization could run twice, I'm not sure if that's intentional. - pg_krb4_authname(): relies on the global variable pg_krb5_name. Seems kerberos isn't. - PQoidStatus: uses a static buffer. Yes, known documented problem. - libpq_gettext: setting already_bound is racy. Does that happen in different threads? - openssl: According to http://www.openssl.org/docs/crypto/threads.html libpq must register locking callbacks within openssl, otherwise there will be random corruptions. Additionally the SSL_context initialization is not properly synchronized, and SSLerrmessage relies on a static buffer. Oh. PQoidStatus is already documented as not thread safe, but what about OpenSSL and kerberos? It seems openssl needs support with callbacks, and according to google searches MIT kerberos 5 is not thread safe, and libpq must use mutexes to prevent concurrent calls into the kerberos library. Oh, seems like a TODO here. We already know how to do thread locking in port/thread.c so maybe we just need to add some locks in there. -- 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] [pgsql-advocacy] Not 7.5, but 8.0 ?
Josh Berkus wrote: Also note that most major number changes in the past weren't because the features were cool, but because the project has moved to a new phase. I don't see any such move happening. Now that is interesting. I missed that. Can you explain how that worked with 7.0? We stopped crashing in 7.0, or was it 6.5 --- that was our milestone, I think. :-) -- 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] Release cycle length
Peter Eisentraut wrote: Marc G. Fournier writes: Right now, I believe we are looking at an April 1st beta, and a May 1st related ... those are, as always, *tentative* dates that will become more fine-tuned as those dates become nearer ... OK, here start the problems. Development already started, so April 1st is already 5 months development. Add 1 month because no one is willing to hold people to these dates. So that's 6 months. Then for 6 months of development, you need at least 2 months of beta. So we're already in the middle of July, everyone is on vacation, and we'll easily reach the 9 months -- instead of 6. Do you think that 2 months for beta is realistic? Tom announced feature freeze on July 1. http://archives.postgresql.org/pgsql-hackers/2003-07/msg00040.php So 7.4 took about 4.5 months to get from feature freeze to release. I think feature freeze is the important date that developers of new features need to concern themselves with. I agree with Peter's other comment, that the longer the development cycle, the longer the beta / bug shakeout period, perhaps a shorter dev cycle would yield a shorter beta period, but perhaps it would also result in a less solid release. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] logical column position
On Mon, 2003-11-17 at 20:24, Christopher Kings-Lynne wrote: Right -- AFAICS, the only change in COPY compatibility would be if you COPY TO'd a table and then changed the logical column order in some fashion, you would no longer be able to restore the dump (unless you specified a column list for the COPY FROM -- which, btw, pg_dump does). I don't think it will be a problem, I just thought I'd mention it. Well it's the same problem as if you'd dropped a column in the middle of the table. BTW, one main consideration is that all the postgres admin apps will now need to support ORDER BY attlognum for 7.5+. Yeah... how about maintaining attnum for the logical attribute number and create an attphysnum or something for the physical position instead? This is more intrusive into the source, but you don't need to teach new tricks to external entities. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] logical column position
Christopher Kings-Lynne writes: BTW, one main consideration is that all the postgres admin apps will now need to support ORDER BY attlognum for 7.5+. But that is only really important if they've also used the ALTER TABLE RESHUFFLE COLUMNS feature. So if they make one alteration for 7.5, they need to do another. That seems fair. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Release cycle length
On Tue, 18 Nov 2003, Peter Eisentraut wrote: Marc G. Fournier writes: Right now, I believe we are looking at an April 1st beta, and a May 1st related ... those are, as always, *tentative* dates that will become more fine-tuned as those dates become nearer ... OK, here start the problems. Development already started, so April 1st is already 5 months development. Add 1 month because no one is willing to hold people to these dates. So that's 6 months. Then for 6 months of development, you need at least 2 months of beta. So we're already in the middle of July, everyone is on vacation, and we'll easily reach the 9 months -- instead of 6. 'K, Sept 1st it is then ... sounds reasonable to me :) ---(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] logical column position
BTW, one main consideration is that all the postgres admin apps will now need to support ORDER BY attlognum for 7.5+. But that is only really important if they've also used the ALTER TABLE RESHUFFLE COLUMNS feature. So if they make one alteration for 7.5, they need to do another. That seems fair. Good point. Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Release cycle length
Matthew T. O'Connor [EMAIL PROTECTED] writes: So 7.4 took about 4.5 months to get from feature freeze to release. I think feature freeze is the important date that developers of new features need to concern themselves with. Rather than the length of the release cycle, I think it's the length of the beta cycle that we should focus on improving. IMHO, we should try to make the beta process more efficient: sometimes I get the impression that the beta process just drags on and on, without the extra time resulting in a huge improvement in the reliability of the .0 release (witness the fact that all the .0 releases I can remember have had a *lot* of serious bugs in them -- we can't catch everything of course, but I think there is definitely room for improvement). That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? -Neil ---(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] logical column position
On Tue, 18 Nov 2003, Peter Eisentraut wrote: Christopher Kings-Lynne writes: BTW, one main consideration is that all the postgres admin apps will now need to support ORDER BY attlognum for 7.5+. But that is only really important if they've also used the ALTER TABLE RESHUFFLE COLUMNS feature. So if they make one alteration for 7.5, they need to do another. That seems fair. The ability to reshuffle and to get the correct ordering in a client app are separate unless we're going to assume that all access goes through that particular client. If one user uses psql and shuffles them, a second user using fooclient may not see the new ordering. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Release cycle length
Neil Conway wrote: Peter Eisentraut [EMAIL PROTECTED] writes: First, if you develop something today, the first time users would realistically get a hand at it would be January 2005. Do you want that? Don't you want people to use your code? Sure :-) But I don't mind a long release cycle if it is better for users. Given that users can run whatever they like, it's not clear that a long release cycle is better for users. (c) As PostgreSQL gets more mature, putting out stable, production-worthy releases becomes even more important. In theory, longer release cycles contribute to higher quality releases: we have more time to implement new features properly, polish rough edges and document things, test and find bugs, and ensure that features we've implemented earlier in the release cycle are properly thought out, and so forth. On the other hand, the longer you wait to release a new feature, the longer it will be before you get your REAL testing done. You don't want to release something that hasn't at least been looked over and checked out by the development community first, of course, but waiting beyond that point to release a new version of PG doesn't help you that much, because most people aren't going to run the latest CVS version -- they'll run the latest released version, whatever that may be. So the time between the testing phase for the feature you implement and the version release is essentially dead time for testing of that feature, because most developers have moved on to working on and/or testing something else. That's why the release methodology used by the Linux kernel development team is a reasonable one. Because the development releases are still releases, people who wish to be more on the bleeding edge can do so without having to grab the source from CVS and compile it themselves. And package maintainers are more likely to package up the development version if it's given to them in a nice, prepackaged format, even if it's just a source tarball. Note that whether or not we are using those 355 days effectively is another story -- it may well be true that there are we could make parts of the development process much more efficient. Furthermore, longer release cycles reduce, to some degree, the pain of upgrades. Unless we make substantial improvements to the upgrade story any time soon, I wouldn't be surprised if many DBAs are relieved at only needing to upgrade once a year. But DBAs only need to upgrade as often as they feel like. Any reasonable distribution will give them an option of using either the stable version or the development version anyway, if we're talking about prepackaged versions. The longer you develop, the more parallel efforts are underway, and it becomes impossible to synchronize them to a release date. I think this is inherent to the way PostgreSQL is developed: Tom has previously compared PostgreSQL release scheduling to herding cats :-) As long as much of the work on the project is done by volunteers in their spare time, ISTM that coordinating everyone toward a single release date is going to be difficult, if not impossible. The length of the release cycle doesn't really effect this, IMHO. Linux, too, is done largely by volunteers in their spare time. Yet Linux kernel releases are much more frequent than PostgreSQL releases. One difference is that the Linux community makes a distinction between development releases and stable releases. The amount of time between stable releases is probably about the same as it is for PostgreSQL. The difference is that the *only* releases PostgreSQL makes are stable releases (or release candidates, when a stable release is close). That's something we might want to re-think. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Release cycle length
Matthew T. O'Connor wrote: I agree with Peter's other comment, that the longer the development cycle, the longer the beta / bug shakeout period, perhaps a shorter dev cycle would yield a shorter beta period, but perhaps it would also result in a less solid release. Perhaps. Perhaps not. The fewer the changes, the less complexity you have to manage. But it would certainly result in a smaller set of feature changes per release. Some people might regard that as a good thing. The advantage to doing more frequent releases is that new features end up with more real-world testing within a given block of time, on average, because a lot more people pick up the releases than the CVS snapshots or even release candidates.. -- Kevin Brown [EMAIL PROTECTED] ---(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] Release cycle length
That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? I can think of a few things. 1. Try to encourage list members to actually test stuff. For example, I decided to find stuff that might be broken. So I checked the tutorial scripts (no-one ever looks at them) and found heaps of bugs. I thought about some new features and tried to break them. I also tend to find bugs by coding phpPgAdmin and delving into the nitty gritty of stuff. Maybe we could actually ask for people for the 'beta team'. Then, once we have volunteers, they are each assigned a set of features to test by the 'testing co-ordinator' (a new core position, say?) What you are asked to test depends on your skill, say. eg. Someone who just knows how to use postgres could test my upcoming COMMENT ON patch. (It's best if I myself do not test it) Someone with more skill with a debugger can be asked to test unique hash indexes by playing with concurrency, etc. The test co-ordinator could also manage the testing of new features as they are committed to save time later. The co-ordinator should also maintain a list of what features have been committed, which have been code reviewed (what Tom usually does) and which have been tested. Of course, I'm not talking about exhaustive testing here, just better and more organised that what we currently have. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
Neil Conway writes: That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? Here are a couple of ideas: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or UnixWare are really becoming old jokes. 2. Have a complete account of the changes available at the start of beta, so people know what to test. 3. Use a bug-tracking system so that open items are known early and by everyone. 4. Have a schedule. Not We're looking at a release early in the later part of this year., but dates for steps such as feature freeze then, proposals for open issues fielded then, string freeze then, release candiate then. 5. If need be, have a release management team that manages 0-4. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] Release cycle length
On Mon, 17 Nov 2003, Neil Conway wrote: That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? Agreed ... here's a thought ... take the download page and break it into two pages: page 1: broken down into dev vs stable versions, including the date of release ... page 2: when you click on the version you want to download, it brings you to a subpage that is what the main page currently is (with all the flags and such) but instead of just sending ppl to the ftp site itself, actually have the link go to the directory that contains that version on the mirror site ... that first page of the download could contain descriptoins of the variosu releases, and state of releases? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release cycle length
eg. Someone who just knows how to use postgres could test my upcoming COMMENT ON patch. (It's best if I myself do not test it) Someone with more skill with a debugger can be asked to test unique hash indexes by playing with concurrency, etc. I forgot to mention that people who just have large, complex production databases and test servers at their disposal should be given the task of: 1. Dumping their old version database 2. Loading that into the dev version of postgres 3. Dumping that using dev pg_dump 4. Loading that dump back in 5. Dumping it again 6. Diffing 3 and 5 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] Release cycle length
--On Tuesday, November 18, 2003 04:43:12 +0100 Peter Eisentraut [EMAIL PROTECTED] wrote: Neil Conway writes: That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? Here are a couple of ideas: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or UnixWare are really becoming old jokes. The only reason we had last minute stuff for UnixWare this time was the timing of PG's release and the UP3 release from SCO. I try to test stuff fairly frequently, and this time I didn't know when, exactly, SCO would make the release of the updated compiler. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Release cycle length
On Tue, 18 Nov 2003, Peter Eisentraut wrote: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. and how do you propose we do that? I think this is the hard part ... other then the first beta, I post a note out to -announce and -general that the beta's have been tag'd and bundled for download ... I know Sean does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb maintainers do anything until the final release ... 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or UnixWare are really becoming old jokes. then each beta will have to be re-certified for that beta, up until release ... doable, but I don't think you'll find many that will bother until we are close to release ... 2. Have a complete account of the changes available at the start of beta, so people know what to test. Bruce, when do you do your initial HISTORY file? Something to move to the start of beta, if not? 3. Use a bug-tracking system so that open items are known early and by everyone. Waiting to see anyone decide on which one to use ... willing to spend the time working to get it online ... 4. Have a schedule. Not We're looking at a release early in the later part of this year., but dates for steps such as feature freeze then, proposals for open issues fielded then, string freeze then, release candiate then. We try that every release ... 5. If need be, have a release management team that manages 0-4. Core does that, but we just don't feel that being totally rigid is (or has ever been) a requirement ... but, if you can provide suggestions on points 0 and 3, we're all ears ... ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Release cycle length
On Mon, 17 Nov 2003, Larry Rosenman wrote: I try to test stuff fairly frequently, and this time I didn't know when, exactly, SCO would make the release of the updated compiler. And there was no way you could predict that your contact there would take off on holidays either :( ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] So as not to break it for anyone ...
Since I can't just go in an remove all the v's from the directory names in the ftp site, without breaking any links to the ftp servers, I just created a new directory that contains the 'non-v' names, with symlink's to the v'd directories ... ftp://ftp.postgresql.org/pub/src/[167].* vs ftp://ftp.postgresql.org/pub/source/v[167].* 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] [pgsql-advocacy] Not 7.5, but 8.0 ?
Mike Mascari [EMAIL PROTECTED] writes: 1) PITR 2) Distributed Tx 3) Replication 4) Nested Tx 5) PL/SQL Exception Handling Of these PITR seems *by far* the most important. It makes the difference between an enterprise-class database capable of running 24x7 with disaster recovery plans, and a lesser beast that needs to be shut down for cold backups periodically. Features like Nested Transactions and Exception Handling are would be nice features. Especially for pre-existing code-bases. But for new projects they're not things that make the difference between measuring up and not. Besides, Oracle 8 had Replication the way Mysql has transactions... It a recently bolted-on addition that only worked in limited cases until a few rewrites later. Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on dozens of OSes already. What's so exciting about one more? Even if it is a pathologically hard OS to port to. Just because it was hard doesn't mean it's useful. -- greg ---(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] [pgsql-advocacy] Not 7.5, but 8.0 ?
Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on dozens of OSes already. What's so exciting about one more? Even if it is a pathologically hard OS to port to. Just because it was hard doesn't mean it's useful. I don't call porting Postgres to run well on something like 40% of the world's servers (or whatever it is) just another port. It could conveivably double Postgres's target audience, could attract heaps of new users, new developers, new companies and put us in a better position to compete with MySQL. I think it's actually a necessary port to keep the project alive in the long term. Chris ---(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] [pgsql-advocacy] Not 7.5, but 8.0 ?
Christopher Kings-Lynne wrote: Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on dozens of OSes already. What's so exciting about one more? Even if it is a pathologically hard OS to port to. Just because it was hard doesn't mean it's useful. I don't call porting Postgres to run well on something like 40% of the world's servers (or whatever it is) just another port. It could conveivably double Postgres's target audience, could attract heaps of new users, new developers, new companies and put us in a better position to compete with MySQL. I think it's actually a necessary port to keep the project alive in the long term. Absolutely! In addition, even if you don't consider win32 a platform to run production databases on, the win32 port will help developers who work from windows boxes, which is the certainly the most widely used desktop environment. My former company would have loved the win32 port for exactly this reason, even though most of our servers were FreeBSD / Linux. ---(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] Release cycle length
Marc G. Fournier [EMAIL PROTECTED] writes: On Tue, 18 Nov 2003, Peter Eisentraut wrote: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. and how do you propose we do that? I think this is the hard part (1) Make the beta more obvious on the website, as we've already discussed (2) Make a freshmeat.net release announcement for _each_ beta, RC, and of course the final release (we totally missed this during 7.4). There are probably other software release announcement sites we could inform. (3) Is it worth trying to get some technical press coverage for the start of the beta process? I don't mean on PHB-oriented sites like ComputerWorld or ZdNet where we need to do the work of getting a press release prepared, but OSNews or Slashdot just need a link to the release notes and the source tarballs. Any other suggestions? Perhaps we could add a list of this sort to src/tools/RELEASE_CHANGES? -Neil ---(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] Release cycle length
On Tue, 18 Nov 2003, Neil Conway wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Tue, 18 Nov 2003, Peter Eisentraut wrote: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. and how do you propose we do that? I think this is the hard part (1) Make the beta more obvious on the website, as we've already discussed (2) Make a freshmeat.net release announcement for _each_ beta, RC, and of course the final release (we totally missed this during 7.4). There are probably other software release announcement sites we could inform. Damn, I keep forgetting freshmeat.net altogether ... will get that one during the day tomorrow ... (3) Is it worth trying to get some technical press coverage for the start of the beta process? I don't mean on PHB-oriented sites like ComputerWorld or ZdNet where we need to do the work of getting a press release prepared, but OSNews or Slashdot just need a link to the release notes and the source tarballs. I think so ... just a heads up to tell ppl that we are heading into the final stretch for the next release, and testing would be 'a good thing' ... ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Matthew T. O'Connor writes: Absolutely! In addition, even if you don't consider win32 a platform to run production databases on, the win32 port will help developers who work from windows boxes, which is the certainly the most widely used desktop environment. At the risk of stating the obvious: Cygwin is your friend in exactly this case. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Matthew T. O'Connor [EMAIL PROTECTED] writes: I don't call porting Postgres to run well on something like 40% of the world's servers (or whatever it is) just another port. It could conveivably double Postgres's target audience, could attract heaps of new users, new developers, new companies and put us in a better position to compete with MySQL. That's a misleading extrapolation. If people wanted to run an open source database they could just as easily run a Solaris, Linux, or BSD server to run it on anyways. I assure you 40% of the worlds servers will not switch from MSSQL to Postgres the day the win32 port comes out... The reality is it just doesn't happen that way. Postgres isn't the first major unixy software to get ported to windows. Emacs, Gcc, Mozilla, Gimp, even X all have windows ports. And they're not dead ports either, they have significant user-bases. But they don't make much of a dent compared to the much larger entrenched Unix user-base and they don't change the nature of the development much. Absolutely! In addition, even if you don't consider win32 a platform to run production databases on, the win32 port will help developers who work from windows boxes, which is the certainly the most widely used desktop environment. My former company would have loved the win32 port for exactly this reason, even though most of our servers were FreeBSD / Linux. Oh sure, it'll be useful. But it doesn't make the difference between different classes of software. It'll still the same Postgres with the same set of things it's capable of handling once you get it running. If you need 24x7, scalability to n terabytes or x transactions/s, guaranteed data integrity in the face of various failures, none of the checklist items you'll be looking for will be win32 support. PITR will probably be a factor in meeting any of those requirements. In any case, my post was mostly a troll, there's not really much point in arguing with it. They're all useful features and I hope they're all in the next version of postgres, whatever version number it's given :) -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
-Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 10:04 PM To: Matthew T. O'Connor Cc: Christopher Kings-Lynne; Greg Stark; [EMAIL PROTECTED] Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ? Matthew T. O'Connor writes: Absolutely! In addition, even if you don't consider win32 a platform to run production databases on, the win32 port will help developers who work from windows boxes, which is the certainly the most widely used desktop environment. At the risk of stating the obvious: Cygwin is your friend in exactly this case. Yes, but how friendly is it? Cygwin requires a license for commercial use. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
-Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 10:34 PM To: Dann Corbit Cc: Matthew T. O'Connor; Christopher Kings-Lynne; Greg Stark; PostgreSQL Development Subject: RE: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ? Dann Corbit writes: At the risk of stating the obvious: Cygwin is your friend in exactly this case. Yes, but how friendly is it? What are you asking here? Is it easy to install and use? Yes. You brought it up. Cygwin requires a license for commercial use. No, it does not. Really? What's this then? http://www.cygwin.com/licensing.html http://www.redhat.com/software/cygwin/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
--- Christopher Kings-Lynne [EMAIL PROTECTED] wrote: I don't call porting Postgres to run well on something like 40% of the world's servers (or whatever it is) just another port. Statistics is a tricky thing. IMHO, there are plenty of things that are much more important than win32 port. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ---(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] [pgsql-advocacy] Not 7.5, but 8.0 ?
-Original Message- From: ow [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 10:39 PM To: Christopher Kings-Lynne; Greg Stark Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ? --- Christopher Kings-Lynne [EMAIL PROTECTED] wrote: I don't call porting Postgres to run well on something like 40% of the world's servers (or whatever it is) just another port. Statistics is a tricky thing. IMHO, there are plenty of things that are much more important than win32 port. Which feature is requested more than that? If you consider the possibility of embedded PostgreSQL, which OS covers the most desktops in the world, by several orders of magnitude? Of the following (which includes every significant DBMS in terms of market share), which did not consider a native Windows port to be important: SQL*Sever (all right, we can discount this one...) DB/2 Oracle MySQL Sybase Informix (Answer: none of them) Maybe they were all mistaken. At the company where I work (CONNX Solutions Inc.) we spent a giant pile of money writing a native port of PostgreSQL 7.1.3 because there were no viable alternatives for what we wanted to do. We would have saved many tens of thousands of dollars if one were available. Now, I imagine other companies might also have their interest piqued if a native port should suddenly appear. ---(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
[HACKERS] 4 Clause license?
The PostgreSQL group has recently had a patch submitted with a snippet of code from FreeBSDs src/bin/mkdir/mkdir.c. http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27 Is this intentionally under the 4 clause license or does the copyright from the website (2 clause) applied to everything that is non-contrib? http://www.freebsd.org/copyright/freebsd-license.html Thanks, Rod ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
