Re: tsearch V2 (Was: Re: [HACKERS] Two weeks to feature freeze)
The Hermit Hacker kirjutas R, 20.06.2003 kell 08:28: On Fri, 20 Jun 2003, Tom Lane wrote: On Fri, 20 Jun 2003, The Hermit Hacker wrote: Is there a strong reason why tsearch isn't in gborg? I think text search is a pretty important facility that should eventually be part of the core distribution. It's more likely to get there from contrib than from gborg ... Why part of the core distribution, and not just left as a loadable module, like it is now? I remember Tom saying that builtin functions calls are a lot faster than loadable C functions. If that can be fixed, then it *could* stay loadable. Also, having built-in full text indexing is very desirable. And I don't see any even nearly as good competing fulltext indexing modules anywhere. If we had to move something *out* of core in order to get tsearch in, then I personally would not mind if all geometry types go to gborg, but I'm sure there are some users who would mind ;) --- Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] JDBC in PostgreSql for Linux
I am running a Java application on Linux which connects to the Postgresql on Linux using jdbcodbc bridge. But this is the error I am getting : sun.jdbc.odbc.JdbcOdbcDriverjava.lang.ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver at 0x4028115f: java.lang.Throwable.Throwable(java.lang.String) (/usr/lib/libgcj.so.3) at 0x402740d2: java.lang.Exception.Exception(java.lang.String) (/usr/lib/libgcj.so.3) at 0x402737a8: java.lang.ClassNotFoundException.ClassNotFoundException(java.lang.String) (/usr/lib/libgcj.so.3) at 0x4030b2be: java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.3) at 0x402606d7: gnu.gcj.runtime.VMClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.3) at 0x40272cc7: java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.3) at 0x40260e09: _Jv_FindClass(_Jv_Utf8Const, java.lang.ClassLoader) (/usr/lib/libgcj.so.3) at 0x4025d1fd: java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.3) at 0x4025d2bf: java.lang.Class.forName(java.lang.String) (/usr/lib/libgcj.so.3) at 0x4039d347: ffi_call_SYSV (/usr/lib/libgcj.so.3) at 0x4039d307: ffi_raw_call (/usr/lib/libgcj.so.3) at 0x40248528: _Jv_InterpMethod.continue1(_Jv_InterpMethodInvocation) (/usr/lib/libgcj.so.3) at 0x40248e34: _Jv_InterpMethod.run(ffi_cif, void, ffi_raw, _Jv_InterpMethodInvocation) (/usr/lib/libgcj.so.3) at 0x40246424: _Jv_InterpMethod.run_normal(ffi_cif, void, ffi_raw, void) (/usr/lib/libgcj.so.3) at 0x4039d1bc: ?? (??:0) at 0x4025b308: gnu.gcj.runtime.FirstThread.call_main() (/usr/lib/libgcj.so.3) at 0x402c60b1: gnu.gcj.runtime.FirstThread.run() (/usr/lib/libgcj.so.3) at 0x40267fdc: _Jv_ThreadRun(java.lang.Thread) (/usr/lib/libgcj.so.3) at 0x4023478c: _Jv_RunMain(java.lang.Class, byte const, int, byte const, boolean) (/usr/lib/libgcj.so.3) at 0x08048900: ?? (??:0) at 0x420158d4: ?? (??:0) at 0x080486c1: ?? (??:0) I have also tried running a Java application using the Native JDBC Driver. I get the following error : Driver not found for URL: jdbc:[EMAIL PROTECTED]:5432:notesjava.sql.SQLException: Driver not found for URL: jdbc:[EMAIL PROTECTED]:5432:notes at 0x4028115f: java.lang.Throwable.Throwable(java.lang.String) (/usr/lib/libgcj.so.3) at 0x402740d2: java.lang.Exception.Exception(java.lang.String) (/usr/lib/libgcj.so.3) at 0x40316294: java.sql.SQLException.SQLException(java.lang.String, java.lang.String, int) (/usr/lib/libgcj.so.3) at 0x40316244: java.sql.SQLException.SQLException(java.lang.String) (/usr/lib/libgcj.so.3) at 0x40316102: java.sql.DriverManager.getConnection(java.lang.String, java.util.Properties) (/usr/lib/libgcj.so.3) at 0x4031603a: java.sql.DriverManager.getConnection(java.lang.String, java.lang.String, java.lang.String) (/usr/lib/libgcj.so.3) at 0x4039d347: ffi_call_SYSV (/usr/lib/libgcj.so.3) at 0x4039d307: ffi_raw_call (/usr/lib/libgcj.so.3) at 0x40248528: _Jv_InterpMethod.continue1(_Jv_InterpMethodInvocation) (/usr/lib/libgcj.so.3) at 0x40248e34: _Jv_InterpMethod.run(ffi_cif, void, ffi_raw, _Jv_InterpMethodInvocation) (/usr/lib/libgcj.so.3) at 0x40246424: _Jv_InterpMethod.run_normal(ffi_cif, void, ffi_raw, void) (/usr/lib/libgcj.so.3) at 0x4039d1bc: ?? (??:0) at 0x4025b308: gnu.gcj.runtime.FirstThread.call_main() (/usr/lib/libgcj.so.3) at 0x402c60b1: gnu.gcj.runtime.FirstThread.run() (/usr/lib/libgcj.so.3) at 0x40267fdc: _Jv_ThreadRun(java.lang.Thread) (/usr/lib/libgcj.so.3) at 0x4023478c: _Jv_RunMain(java.lang.Class, byte const, int, byte const, boolean) (/usr/lib/libgcj.so.3) at 0x08048900: ?? (??:0) at 0x420158d4: ?? (??:0) at 0x080486c1: ?? (??:0) Can you help me?Do you have any contact number? Do you have any url links that might be helpful to me? Or any other contact number in India or abroad for PostgreSql? Please do reply me asap. Thanks and Regards, Kallol Nandi,Systems Analyst,Indus Software - A Division of R Systems International Ltd.,Tidel Park, Taramani, Chennai-600113, India.Phone: +91-44-22540014/6 Extn: 209Fax: +91-44-22540017Email: [EMAIL PROTECTED]Visit us @ http://www.indussoft.com/ "The information in this email is confidential, and intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are the addressee, the contents of this email are intended for your use only and it must not be forwarded to any third party, without first obtaining written authorization from the originator, or Indus Software. It may contain information, which is confidential and legally privileged, and the same shall not be used, or dealt with, by any third party, in any manner whatsoever, without the specific consent of Indus Software. The opinions expressed are those of the sender, and do not necessarily reflect those of the Indus Software."
Re: [HACKERS] Access to transaction status
- Original Message - From: Jeroen T. Vermeulen [EMAIL PROTECTED] I ran into the same need (Bruce, we discussed this at FOSDEM in Brussels this February) for libpqxx. My code tries to compensate for the possibility that the backend connection is lost while waiting for a reply to a COMMIT. The way I worked around it was to create a special record at the beginning of the transaction, in a dedicated table that's effectively a custom transaction log. If the record is still there when I reconnect, the transaction committed. If not, it didn't. Obviously this leaves some garbage collection issues, so I'd be really happy with a way to go back to the server after my connection is lost and find out whether my transaction committed or not. I see a race condition in this approach: if you reconnect too fast, and the backend which actually should commit is still in progress (assume it takes a while to commit for whatever reasons) you get the impression that it did not commit - and a short time later the backend will commit... (before noticing that the client connection was lost). A safe method would be to shut down all backends (or is there another method to safely abort all transactions?), then start the backends again, and then read the table with the special records. In this way you would be sure that your transaction is not in progress while you're inspecting the table. Ofcourse, this approach is not very fast and may abort alot of transactions - but if consistency is more important for you than anything else... - Christian ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Access to transaction status
- Original Message - From: Tom Lane [EMAIL PROTECTED] How much later? clog is not kept forever. Due to my setup, I could assure, that for the XID I ask for always (ShmemVariableCache-nextXid - XID) C (and C is in my case something around 150). holds. A possible solution could be to (dynamically) announce this constant C to the clog code, so that the information is kept for a while. Ofcourse one should not do a VACUUM FULL while not being sure about the status of a transaction in the past :) Until now, I did not investigate what happens when ShmemVariableCache-nextXid wraps around. - Christian ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Access to transaction status
On Fri, Jun 20, 2003 at 09:35:08AM +0200, Christian Plattner wrote: I see a race condition in this approach: if you reconnect too fast, and the backend which actually should commit is still in progress (assume it takes a while to commit for whatever reasons) you get the impression that it did not commit - and a short time later the backend will commit... (before noticing that the client connection was lost). Good point. So far I assumed that a broken connection would take a while to repair. OTOH by the time TCP gives up due to a bad network connection, wouldn't the server reach the same conclusion? Jeroen ---(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] Access to transaction status
- Original Message - From: Jeroen T. Vermeulen [EMAIL PROTECTED] I see a race condition in this approach: if you reconnect too fast, and the backend which actually should commit is still in progress (assume it takes a while to commit for whatever reasons) you get the impression that it did not commit - and a short time later the backend will commit... (before noticing that the client connection was lost). Good point. So far I assumed that a broken connection would take a while to repair. OTOH by the time TCP gives up due to a bad network connection, wouldn't the server reach the same conclusion? Well, I wouldn't rely solely on TCP when assuring consistency. Also, I don't think that the backend will ever inspect its TCP socket while committing. btw: There could be also other reasons for the client to loose the connection (i.e. client process crashes). - Christian ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
On Thu, 19 Jun 2003, The Hermit Hacker wrote: On Thu, 19 Jun 2003, Andrew Dunstan wrote: Maybe a better strategy would be to get a release out soon but not wait 6 months for another release which would contain the Win32 port and the PITR stuff (assuming those aren't done in time for this release). Just a thought. And definitely in agreement here ... I'd rather see a shortened dev cycle prompted by a big feature being added, then delaying a release because oh oh, I need another few weeks that draws out when something unexpected happens :( ... I'm not sure why another delay is being considered. There's been a delay of a week because of the server problems hasn't there and wasn't the original delay only acceptable on the basis that that was that and there wasn't going to be another extension? -- Nigel Andrews ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: tsearch V2 (Was: Re: [HACKERS] Two weeks to feature freeze)
On Fri, 20 Jun 2003, Christopher Kings-Lynne wrote: Why part of the core distribution, and not just left as a loadable module, like it is now? The day I can go 'CREATE FULLTEXT INDEX ...' just like MySQL can I will be a very happy chappy... with new tserach v2 we're pretty close to that day. we need more testing, more suggestions and more documentation. There are several issues remains, mostly with core GiST not tsearch. The most important is concurrency support ! We've several times planned to work on it, but real life is rather complex thing :( Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Lotus Domino and PostgreSql in Linux
I am running an agent in the domino server that
connects to a database in Postgresql through odbc dsn.I am getting an error
"Error Creating product object" at the line Set con = New
ODBCConnectionHere is the code :Option PublicUselsx
"*LSXODBC"Sub Initialize Dim con As
ODBCConnection Dim qry As ODBCQuery Dim result
As ODBCResultSet Dim id As Integer Dim nam As
String,job As StringAm getting Error here Set con = New
ODBCConnection Set qry = New ODBCQuery Set
result = New ODBCResultSet Set qry.Connection = con
Set result.Query = qry status =
con.ConnectTo("debug") qry.SQL = "select * from
testtable" result.Execute Do
result.NextRow id =
result.GetValue("a", id) nam =
result.GetValue("b", nam) Loop Until
result.IsEndOfData result.Close(DB_CLOSE)
con.DisconnectEnd SubI guess it is an error related to
Domino.But not sure. may be related to the ODBC driver also.Is there any
way to solve it.
Kallol
Nandi,Systems
Analyst,Indus
Software - A Division of R Systems International Ltd.,Tidel
Park, Taramani, Chennai-600113, India.Phone: +91-44-22540014/6
Extn: 209Fax:
+91-44-22540017Email: [EMAIL PROTECTED]Visit us
@ http://www.indussoft.com/
"The
information in this email is confidential, and intended solely for the
addressee. Access to this email by anyone else is unauthorized. If you are the
addressee, the contents of this email are intended for your use only and it must
not be forwarded to any third party, without first obtaining written
authorization from the originator, or Indus Software. It may contain
information, which is confidential and legally privileged, and the same shall
not be used, or dealt with, by any third party, in any manner whatsoever,
without the specific consent of Indus Software.
The
opinions expressed are those of the sender, and do not necessarily reflect those
of the Indus Software."
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker wrote: On Thu, 19 Jun 2003, Andrew Dunstan wrote: Maybe a better strategy would be to get a release out soon but not wait 6 months for another release which would contain the Win32 port and the PITR stuff (assuming those aren't done in time for this release). Just a thought. And definitely in agreement here ... I'd rather see a shortened dev cycle prompted by a big feature being added, then delaying a release because oh oh, I need another few weeks that draws out when something unexpected happens :( Yep, this makes sense. Looks like it'll be PostgreSQL 7.4 being all the present improvements, but without PITR and Win32. Then, in a few months (hopefully less than 3) we'll have PostgreSQL 8.0, with both of those major features in it (and whatever other enhancements have been added). The only thing that makes me wince is that we have a protocol change at PostgreSQL 7.4 release instead of 8.0. It kind of doesn't sound right, having a protocol change in the 7 series, when we have an 8 series coming up soon after. Oh well, so it's not perfect... ;-) Regards and best wishes, Justin Clift snip ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Ownership change doesn't change privileges
When you change the owner of a table and relacl is null, then the new owner obtains all privileges, because the default privileges apply to the current owner. But when relacl is not null, the old owner retains all privileges and the new owner has none. Perhaps the privileges of the owner should be represented with a different flag in the aclitem, alongside world, group, public? Currently, changing the table ownership requires superuser privileges, so this situation can be fixed manually. But when groups can own tables and users can move table ownerships between their groups (in a way to be defined), this can be trickier. Ideas? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Access to transaction status
On Fri, Jun 20, 2003 at 10:20:14AM +0200, Christian Plattner wrote: Well, I wouldn't rely solely on TCP when assuring consistency. Also, I don't think that the backend will ever inspect its TCP socket while committing. No, but its underlying IP stack would. btw: There could be also other reasons for the client to loose the connection (i.e. client process crashes). In that case the client would lose all its state as well, so not really a problem that can be handled client-side. Jeroen ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Access to transaction status
- Original Message - From: Tom Lane [EMAIL PROTECTED] How much later? clog is not kept forever. I took a deeper look into the source. Forget my last posting. As far as I understand your code there is only one chance that information in clog gets lost: If XIDs are reused then ExtendCLOG will overwrite existing entries. Also, it seems to me that VACCUM has not effect on the clog. Now let's assume that there is a GET_XID_STATUS(xid) function. If at the time GET_XID_STATUS(xid) gets executed 'xid' has not been reused (which only should occur after about 4 billion transactions following xid), then the mechanism should work. If one uses TransactionIdPrecedes to check if xid is in the past (as in my sample code), then the window is restricted to 2 billion transactions, which seems enough for me. I implemented this check so that the clog lookup code does not try to fetch pages that do not yet exist (which crashes the backend) if one supplies a wrong xid. What do you think? Thanks, Christian ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Access to transaction status
- Original Message - From: Jeroen T. Vermeulen [EMAIL PROTECTED] btw: There could be also other reasons for the client to loose the connection (i.e. client process crashes). In that case the client would lose all its state as well, so not really a problem that can be handled client-side. Well, my client (actually it is a middleware layer which routes transactions to a set of replicas) keeps its own log, because it must be able to handle arbitary failures. So it never looses its state. - Christian ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Access to transaction status
On Fri, Jun 20, 2003 at 02:41:29PM +0200, Christian Plattner wrote: Well, my client (actually it is a middleware layer which routes transactions to a set of replicas) keeps its own log, because it must be able to handle arbitary failures. So it never looses its state. In that case perhaps we should see if there's anything we can do for each other. At the current rate, libpqxx is growing towards a sort of middleware product, but obviously it's not the right place to tackle many of the typical middleware problems. Jeroen ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] add column .. default
On Thu, 2003-06-19 at 21:22, Christopher Kings-Lynne wrote: There is no alternative, unless you want the command to be non-roll-back-able. Well, you can do a cluster-type table duplication... Thats still double the disk space, although that has the nice side effect of not requiring a vacuum. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Access to transaction status
Christian Plattner [EMAIL PROTECTED] writes: From: Tom Lane [EMAIL PROTECTED] How much later? clog is not kept forever. ... Ofcourse one should not do a VACUUM FULL while not being sure about the status of a transaction in the past :) As long as you haven't done a cluster-wide VACUUM, clog status will not get recycled. For the application you're describing I think this will work fine. You might want to set up the API of the inquiry function to include specified return codes for UNKNOWN (older than beginning of clog) and FUTURE (greater than NextXid) as well as COMMITTED, ABORTED, and INPROGRESS. The current implementation can't easily give you UNKNOWN (it'll error out instead) but any general-usage function of this kind would have to offer that. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Ownership change doesn't change privileges
Peter Eisentraut [EMAIL PROTECTED] writes: Perhaps the privileges of the owner should be represented with a different flag in the aclitem, alongside world, group, public? Seems reasonable to me. It always struck me as kind of odd that the owner's name would become explicit in the ACL as soon as you did anything. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Access to transaction status
Christian Plattner [EMAIL PROTECTED] writes: From: Tom Lane [EMAIL PROTECTED] How much later? clog is not kept forever. As far as I understand your code there is only one chance that information in clog gets lost: If XIDs are reused then ExtendCLOG will overwrite existing entries. Also, it seems to me that VACCUM has not effect on the clog. You're quite mistaken. clog is truncated during vacuum, once we are confident that there are no unvacuumed rows in the database with XIDs older than a certain point. This is to keep clog space requirements within reason. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
On Fri, 2003-06-20 at 04:41, Nigel J. Andrews wrote:
On Thu, 19 Jun 2003, The Hermit Hacker wrote:
On Thu, 19 Jun 2003, Andrew Dunstan wrote:
Maybe a better strategy would be to get a release out soon but not wait
6 months for another release which would contain the Win32 port and the
PITR stuff (assuming those aren't done in time for this release).
Just a thought.
And definitely in agreement here ... I'd rather see a shortened dev cycle
prompted by a big feature being added, then delaying a release because oh
oh, I need another few weeks that draws out when something unexpected
happens :(
...
I'm not sure why another delay is being considered. There's been a delay of
a week because of the server problems hasn't there and wasn't the original
delay only acceptable on the basis that that was that and there wasn't going to
be another extension?
There really isn't for this release. Any talk of delay is just a thought
on general policy for future releases.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
On Fri, 2003-06-20 at 06:59, Justin Clift wrote:
The Hermit Hacker wrote:
On Thu, 19 Jun 2003, Andrew Dunstan wrote:
Yep, this makes sense. Looks like it'll be PostgreSQL 7.4 being all the
present improvements, but without PITR and Win32. Then, in a few months
(hopefully less than 3) we'll have PostgreSQL 8.0, with both of those
major features in it (and whatever other enhancements have been added).
The only thing that makes me wince is that we have a protocol change at
PostgreSQL 7.4 release instead of 8.0. It kind of doesn't sound right,
having a protocol change in the 7 series, when we have an 8 series
coming up soon after.
Oh well, so it's not perfect...
...which is why I'd advocate making this release an 8.0 regardless of
win32 or pitr. I know it's old school to actually base versioning on
technical criteria instead of buzzwords, but there's no reason we have
to follow the corporate mold. Still, I'd rather not get into that debate
yet since I don't want to let the win32 guys off the hook yet!
win32 for the next release! go guys go!
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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] Two weeks to feature freeze
Robert Treat [EMAIL PROTECTED] writes: On Fri, 2003-06-20 at 06:59, Justin Clift wrote: The only thing that makes me wince is that we have a protocol change at PostgreSQL 7.4 release instead of 8.0. ...which is why I'd advocate making this release an 8.0 regardless of win32 or pitr. shrug ... The backend will still talk to old clients, and libpq will still talk to old backends, so I don't think the protocol change is really going to cause a flag day for anyone. On a technical level it's probably not an adequate reason to call this release 8.0. On the other hand, I dislike the notion that we would call a release 8.0 simply because it now has a native Windows port. (And if there is a short release cycle after this one, that might be about the only big new thing there.) Considering that we aren't going to be recommending the Windows port for production work, we should not let the release numbering give the impression we think it's the greatest Postgres feature ever to come down the pike. I'm happy to keep calling 'em 7.* for the foreseeable future, myself. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: tsearch V2 (Was: Re: [HACKERS] Two weeks to feature freeze)
And, actually, for some reason I hadn't thought of the tsearch as being another 'INDEX' type ... I crawl back over and be quiet now :) Oleg, as far as commits are concerned, I have no problems with extending the privileges to one of your guys for this, just email me seperately who, and I'll get it setup ... On Fri, 20 Jun 2003, Oleg Bartunov wrote: On Fri, 20 Jun 2003, Christopher Kings-Lynne wrote: Why part of the core distribution, and not just left as a loadable module, like it is now? The day I can go 'CREATE FULLTEXT INDEX ...' just like MySQL can I will be a very happy chappy... with new tserach v2 we're pretty close to that day. we need more testing, more suggestions and more documentation. There are several issues remains, mostly with core GiST not tsearch. The most important is concurrency support ! We've several times planned to work on it, but real life is rather complex thing :( Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
On Fri, 2003-06-20 at 10:42, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Fri, 2003-06-20 at 06:59, Justin Clift wrote:
The only thing that makes me wince is that we have a protocol change at
PostgreSQL 7.4 release instead of 8.0.
...which is why I'd advocate making this release an 8.0 regardless of
win32 or pitr.
shrug ... The backend will still talk to old clients, and libpq will
still talk to old backends, so I don't think the protocol change is
really going to cause a flag day for anyone. On a technical level it's
probably not an adequate reason to call this release 8.0.
Can you give me an example of a technical change that would warrant a
major version bump?
On the other hand, I dislike the notion that we would call a release 8.0
simply because it now has a native Windows port. (And if there is a
short release cycle after this one, that might be about the only big new
thing there.) Considering that we aren't going to be recommending the
Windows port for production work, we should not let the release
numbering give the impression we think it's the greatest Postgres
feature ever to come down the pike.
yep.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
Robert Treat [EMAIL PROTECTED] writes: On Fri, 2003-06-20 at 10:42, Tom Lane wrote: shrug ... The backend will still talk to old clients, and libpq will still talk to old backends, so I don't think the protocol change is really going to cause a flag day for anyone. On a technical level it's probably not an adequate reason to call this release 8.0. Can you give me an example of a technical change that would warrant a major version bump? Well, if we hadn't gotten the work done to make libpq still able to talk to older backends, then we'd have had enough of a compatibility issue that I think calling it 8.0 would have been a reasonable thing to do. If you want a feature-with-a-capital-F reason for going to 8.0, there is only one candidate Feature in my personal view, and that's a built-in replication solution. That doesn't seem to be getting any nearer :-( regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
On Fri, 2003-06-20 at 11:21, Josh Berkus wrote:
Robert,
Well, I suppose that history has shown that waiting on specific features
causes trouble with postgresql development, but I don't see why a
release can't be based around waiting for feature x as long as feature x
is being actively worked on by trusted developers who have an endgame in
sight.
Ultimately, this is one of those technical vs. marketing questions ...
absolutely not. this is a x style of development vs. y style of
development discussion. many many projects, commercial and open source,
use a style of releasing based on features included in a given version.
In fact I'd be willing to say that the majority of open source projects
work this way, since open source projects generally aren't beholden to
release dates, giving developers the time they need to get specific
features done and release them when they are ready. as i prefaced in my
message, history has shown us that waiting on specific features causes
trouble with postgresql development, but that doesn't mean we should
act as if this style of development doesn't exist.
whether to release now with a bunch of back-end features that the current
users want, or to release later and include the features that we said were
going to be in 7.4. And PostgreSQL is a technical project, not a marketing
one.
right, which is why core/hackers will decide both what gets into each
releases and when it's released. since i'm not outpacing tom or bruce
in my patch submissions i don't expect them to bend to my whims, but as
someone who follows and participates in postgresql development
regardless of an marketing aspects, i don't mind pointing out
alternatives.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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] Subtraction carry bug in xlog.c in 7.3 and 7.4
The attached patches against 7.3 and 7.4 fix a subtraction carry bug in
xlog.c.
--
John Nield
[EMAIL PROTECTED]
Index: pgsql-server-7_3/src/backend/access/transam/xlog.c
diff -c pgsql-server-7_3/src/backend/access/transam/xlog.c:1.1.1.1
pgsql-server-7_3/src/backend/access/transam/xlog.c:1.1.1.1.2.2
*** pgsql-server-7_3/src/backend/access/transam/xlog.c:1.1.1.1 Thu Jun 19 14:25:08
2003
--- pgsql-server-7_3/src/backend/access/transam/xlog.c Thu Jun 19 18:21:54 2003
***
*** 354,362
logSeg = (xlrp).xrecoff / XLogSegSize \
)
#define XLByteToPrevSeg(xlrp, logId, logSeg) \
! ( logId = (xlrp).xlogid, \
! logSeg = ((xlrp).xrecoff - 1) / XLogSegSize \
! )
/*
* Is an XLogRecPtr within a particular XLOG segment?
--- 354,366
logSeg = (xlrp).xrecoff / XLogSegSize \
)
#define XLByteToPrevSeg(xlrp, logId, logSeg) \
! do { \
! logId = (xlrp).xlogid; \
! if ( (xlrp).xrecoff == 0 ) \
! { logId--; logSeg = XLogSegsPerFile - 1; } \
! else \
! logSeg = ((xlrp).xrecoff - 1) / XLogSegSize; \
! } while (0)
/*
* Is an XLogRecPtr within a particular XLOG segment?
***
*** 369,376
(xlrp).xrecoff / XLogSegSize == (logSeg))
#define XLByteInPrevSeg(xlrp, logId, logSeg) \
! ((xlrp).xlogid == (logId) \
!((xlrp).xrecoff - 1) / XLogSegSize == (logSeg))
#define XLogFileName(path, log, seg) \
--- 373,384
(xlrp).xrecoff / XLogSegSize == (logSeg))
#define XLByteInPrevSeg(xlrp, logId, logSeg) \
! ( \
! ((xlrp).xrecoff == 0)? \
! ((xlrp).xlogid - 1 == (logId) (XLogSegsPerFile - 1) == logSeg): \
! ((xlrp).xlogid == (logId) \
! ((xlrp).xrecoff - 1) / XLogSegSize ==
(logSeg)) \
! )
#define XLogFileName(path, log, seg) \
*** src/backend/access/transam/xlog.c.orig Fri Jun 20 09:04:20 2003
--- src/backend/access/transam/xlog.c Fri Jun 20 09:10:04 2003
***
*** 354,362
logSeg = (xlrp).xrecoff / XLogSegSize \
)
#define XLByteToPrevSeg(xlrp, logId, logSeg) \
! ( logId = (xlrp).xlogid, \
! logSeg = ((xlrp).xrecoff - 1) / XLogSegSize \
! )
/*
* Is an XLogRecPtr within a particular XLOG segment?
--- 354,366
logSeg = (xlrp).xrecoff / XLogSegSize \
)
#define XLByteToPrevSeg(xlrp, logId, logSeg) \
! do { \
! logId = (xlrp).xlogid; \
! if ( (xlrp).xrecoff == 0 ) \
! { logId--; logSeg = XLogSegsPerFile - 1; } \
! else \
! logSeg = ((xlrp).xrecoff - 1) / XLogSegSize; \
! } while (0)
/*
* Is an XLogRecPtr within a particular XLOG segment?
***
*** 369,376
(xlrp).xrecoff / XLogSegSize == (logSeg))
#define XLByteInPrevSeg(xlrp, logId, logSeg) \
! ((xlrp).xlogid == (logId) \
! ((xlrp).xrecoff - 1) / XLogSegSize == (logSeg))
#define XLogFileName(path, log, seg) \
--- 373,384
(xlrp).xrecoff / XLogSegSize == (logSeg))
#define XLByteInPrevSeg(xlrp, logId, logSeg) \
! ( \
! ((xlrp).xrecoff == 0)? \
! ((xlrp).xlogid - 1 == (logId) (XLogSegsPerFile - 1) == logSeg): \
! ((xlrp).xlogid == (logId) \
! ((xlrp).xrecoff - 1) / XLogSegSize == (logSeg)) \
! )
#define XLogFileName(path, log, seg) \
---(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] Subtraction carry bug in xlog.c in 7.3 and 7.4
J.R. Nield [EMAIL PROTECTED] writes: The attached patches against 7.3 and 7.4 fix a subtraction carry bug in xlog.c. This is simply a waste of cycles, because xrecoff can never be zero (if it were, it'd be pointing at a page header, which is not a valid record location). If you look around in the code, you'll note that xrecoff==0 is actually used as an invalid-value flag in a couple of contexts. Can you point to anyplace where the behavior would change? If so I think there's a deeper bug to fix. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] what is the meaning of schema?
My understanding of schema that I discovered in 7.3 (I don't think they were available before) is that you can have two tables with the same name if they are in different schemas. I have done a google search, as well as archive search but pg_dump and pg_dumpall are broken if a database contains schemas. First of all if there are two tables with the same name in different schemas pg_dump only dumps out one table. There is no way to dump other tables and I have checked pg_dump man page Restoring a pg_dumpall is now a nightmare because I had as superuser # create schema test authorization httpd on a database not owned by database owner. And it works merrily until the time to dump and restore. pg_dumpall answers to above create authorization is \connect - httpd create schema test Hell breaks lose with that! Because httpd cannot create schema on a database that it does not own. Why couldn't pg_dumpall does create schema test authorization httpd as superuser when the schema was created in that fashion? I really don't think anyone is going to pay attention to this rant since these list does not like/answer anonymous posts but I have to post just so some poor soul might find it in the archive and be warned. My current versions are 7.3.2 and 7.3.3 and I have been using posgres since 7.1 and consider myself experienced with postgres Schemas are the best thing since slice breads but the baker decided to poison the bread. Nice! Thanks __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ---(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] Two weeks to feature freeze
Robert, absolutely not. this is a x style of development vs. y style of development discussion. many many projects, commercial and open source, use a style of releasing based on features included in a given version. In fact I'd be willing to say that the majority of open source projects work this way, since open source projects generally aren't beholden to release dates, giving developers the time they need to get specific features done and release them when they are ready. as i prefaced in my message, history has shown us that waiting on specific features causes trouble with postgresql development, but that doesn't mean we should act as if this style of development doesn't exist. Ah. I see what you mean. Sorry for the misunderstanding. The thing is, from the perspective of *current* Postgres users, 7.4 has several killer features, some of which have been ready for 3 months. In fact, I just finished sending an e-mail to a client advising them to try 7.4 as soon as it is tested, becuase of hashaggs. So looked at from that perspective, our mistake was to try to cram too many features into 7.4 ... more than could possibly get done in 6-8 months. What's happening now is that the core group has decided, OK, we don't have 5-6 of the features we wanted to have, but we do have 10 other features, so maybe it's time to release. I'm not sure you're correct in the behaviour of the majoirty of OSS projects. Certainly if the Mozilla or OpenOffice.org projects are attaching specific release numbers to specific features, I haven't seen it. Linux does that, I guess, but that does result in a 2-year span between major releases -- and results in a lot of major features being included in incremental releases. But I think most OSS projects just release when they think they have enough tested features to justify a major release -- regardless of what those features are. Anybody here on other projects want to weigh in? Me, I'd be in favor of releasing more frequently ... I felt that we waited too long for 7.4. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
Josh Berkus [EMAIL PROTECTED] writes: So looked at from that perspective, our mistake was to try to cram too many features into 7.4 ... more than could possibly get done in 6-8 months. It's more that we thought that all these features would get done in about the same timeframe, and (not too surprisingly) some got done and some didn't. Me, I'd be in favor of releasing more frequently ... I felt that we waited too long for 7.4. Yeah, this is why I'm not in favor of slipping more. Time was that we had a major release every 3 or 4 months. As the project matures I think it's appropriate for the cycle to get slower: a lot of low-hanging fruit is gone, so we have larger jobs to tackle, plus users are using PG for larger databases and don't want to face major-version changes too often. But I don't want it to get to be a year on average between releases, at least not yet. 8 or 9 months seems reasonable, and by that standard we're overdue. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker [EMAIL PROTECTED] writes: On Thu, 19 Jun 2003, Robert Treat wrote: Well, I suppose that history has shown that waiting on specific features causes trouble with postgresql development, but I don't see why a release can't be based around waiting for feature x as long as feature x is being actively worked on by trusted developers who have an endgame in sight. Everyone has an 'endgame in sight', at least when they ask for a release to be postponed ... but then their date keeps slipping, etc ... The thing is, if win32 is 'that close to being finished', then as soon as v7.4 is out, that code should be ready to throw in ... and the same for every other features that could 'postpone a release' ... I'd rather see the dev cycle shortened by a month, then extended ... Why couldn't you just release the win32 version of 7.4 when it was finished. If it takes an extra month then that just gives you guys the chance to circulate *two* press releases. The Native Win32 port is likely to make a big enough splash all by itself. Jason ---(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] Commands to change name, schema, owner
We only have sporadic support to rename objects, change the owner of objects, and no support to change the schema of an object. So how about a big bang to add support for these three operations for every object where it is applicable? I hope to do it without a separate parse structure and routine for each kind of object and operation, so it can easily be extended. Are there any tricky problems with any of these operations? For example, what happens when an object you have used, say, in a view gets moved to a schema that you don't have access to. Bad luck? Renaming is possible for: aggregate, constraint, conversion, database, domain, function, group, index, language, operator, opclass, rule, schema, sequence, table, trigger, type, user, view. The command is: ALTER THING oldname RENAME TO newname; Requires being the owner of the object (or superuser for group, user, language) and CREATE privilege on containing schema. Changing the owner is possible for: aggregate, conversion, database, domain, function, operator, opclass, schema, sequence, table, type, view. The command is: ALTER THING name AUTHORIZATION username; (This is consistent with the CREATE SCHEMA syntax. Anyone like OWNER better?) Requires being superuser. Changing the schema is possible for: aggregate, conversion, domain, function, operator, opclass, table, type, view. The command is: ALTER THING name SCHEMA newschema; Requires USAGE on old schema(?), owner of object, CREATE in new schema. -- 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] src/bin/scripts seems a bit of a misnomer now
On Thu, 2003-06-19 at 12:09, Jon Jensen wrote:
On Thu, 19 Jun 2003, Christopher Kings-Lynne wrote:
Does anyone care about contrib/reindexdb anymore?
I would've found it handy, but didn't know about it and wrote my own in
Perl. Inside a transaction it drops the index then rebuilds it using what
it gets from pg_get_indexdef(), and it looks at the index files on disk
before and after to show disk space saved (or grown) per index and total.
I run it weekly in cron.
Is something like that of use to anyone else?
I think something like this was either posted to the list, put on gborg,
or maybe hidden in contrib somewhere. I'd like a copy if you don't mind,
I currently use reindex regularly on my database but your script sounds
a little more informational.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
-Original Message- From: Jason Earl [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 10:45 AM To: The Hermit Hacker Cc: Robert Treat; Tom Lane; Christopher Kings-Lynne; Bruce Momjian; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze The Hermit Hacker [EMAIL PROTECTED] writes: On Thu, 19 Jun 2003, Robert Treat wrote: Well, I suppose that history has shown that waiting on specific features causes trouble with postgresql development, but I don't see why a release can't be based around waiting for feature x as long as feature x is being actively worked on by trusted developers who have an endgame in sight. Everyone has an 'endgame in sight', at least when they ask for a release to be postponed ... but then their date keeps slipping, etc ... The thing is, if win32 is 'that close to being finished', then as soon as v7.4 is out, that code should be ready to throw in ... and the same for every other features that could 'postpone a release' ... I'd rather see the dev cycle shortened by a month, then extended ... Why couldn't you just release the win32 version of 7.4 when it was finished. If it takes an extra month then that just gives you guys the chance to circulate *two* press releases. The Native Win32 port is likely to make a big enough splash all by itself. A formal release needs a big testing effort. Two separate releases will double the work of validation. ---(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] psql
what i was trying to do was maintain an array of Buffer pool clusters. What i did previously was change the pointers around in the freelist so instead of one i have 4. Now each buffer pool is called a BP cluster. Within this BP cluster i have things like cluster id, freelist descriptor etc, and a linked list that holds all the relation id's belonging to that cluster (right now it does this randomly but we will change this to grouping according to access patterns). Every time i call RelationBuildDesc from relcache.c, i randomly assign a cluster id and put the relation id in the cluster. And every time i want to remove the relation from the BP i will have to remove it from the linked list of relation ids. I know that this implementation will not work well for multi database systems, but this is just the first step of this work. So what is happening is that i enter the relation ids into the BP cluster linked list fine and every time i call psql, it automatically deletes. hope i gave u a better explanation On Thu, 19 Jun 2003, Bruno Wolff III wrote: On Thu, Jun 19, 2003 at 17:07:43 -0400, Nailah Ogeer [EMAIL PROTECTED] wrote: Please don't respond to other messages to start a new thread. What i am trying to do is to maintain a linked list of all the relations in a database. When i create a db then i want it to insert into the linked list the relation ids. As it stands now, i can create a db fine and i see the relation id's in the linked list. BUT, as soon as i psql into the db then they all disappear. I maintain an array that stores the linked lists which i initialized in buf_init. I don't understand this. Can someone explain why? Is it wiping out the array i initialized before. You might be better off explaining to us what you are really trying to do. Information about relations is already in the system catalogs. Using a linked list in a relation database doesn't work very well. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] [HACKERS] psql
Nailah Ogeer [EMAIL PROTECTED] writes: So what is happening is that i enter the relation ids into the BP cluster linked list fine and every time i call psql, it automatically deletes. Sounds to me like you are trying to keep stuff in backend-local memory that needs to be in shared memory. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] [HACKERS] psql
Well here's the thing. Before i was trying to use ShmemInitStruct in buf_init.c. The problem with this is that you can't shrink or grow shared memory. That is why i switched over and just used malloc. So i seem to be in a big dilemma, on one hand, if i use malloc, i can't keep this info i need; and on the other if i use shmeminitstruct then i can't shrink or grow the BP clusters. But i will try to test your hypothesis to see if shared memory will take care of this. On Fri, 20 Jun 2003, Tom Lane wrote: Nailah Ogeer [EMAIL PROTECTED] writes: So what is happening is that i enter the relation ids into the BP cluster linked list fine and every time i call psql, it automatically deletes. Sounds to me like you are trying to keep stuff in backend-local memory that needs to be in shared memory. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] psql
Nailah == Nailah Ogeer [EMAIL PROTECTED] writes: Nailah Well here's the thing. Before i was trying to use Nailah ShmemInitStruct in buf_init.c. The problem with this is Nailah that you can't shrink or grow shared memory. That is why i Nailah switched over and just used malloc. So i seem to be in a We've implemented a Shared Memory MemoryContext in TelegraphCQ. We used the opensource libmm from the Apache project. Maybe you can try using it - it's fairly easy to use. The current version in the web is based off of 7.2 code, but I hope to refresh with a beta based on 7.3 code in the next few weeks. http://telegraph.cs.berkeley.edu/telegraphcq -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] O_DIRECT in freebsd
On Wed, Jun 18, 2003 at 10:01:37AM +1000, Gavin Sherry wrote: On Tue, 17 Jun 2003, Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: The reason I mention it is that Postgres already supports O_DIRECT I think on some other platforms (for whatever reason). [ sounds of grepping... ] No. The only occurrence of O_DIRECT in the source tree is in TODO: * Consider use of open/fcntl(O_DIRECT) to minimize OS caching I personally disagree with this TODO item for the same reason Sean cited: Postgres is designed and tuned to rely on OS-level disk caching, and bypassing that cache is far more likely to hurt our performance than help it. DB2 and Oracle, from memory, allow users to pass hints to the planner to use/not use file system caching. This could be useful if you had an application retrieving a large amount of data on an adhoc basis. The large retrieval would empty out the disk cache there by negatively impacting upon other applications operating on data which should be cached. I've recently been bitten by this. On DB2, I could change what bufferpool the large tables were using and set it fairly small, but obviously not an option with PGSQL. But, if pgsql could stop caching from occuring on user-specified queries, large table or index scans, etc., it would be very helpful. -- Jim C. Nasby (aka Decibel!)[EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
Dann Corbit wrote: -Original Message- From: Jason Earl [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 10:45 AM To: The Hermit Hacker Cc: Robert Treat; Tom Lane; Christopher Kings-Lynne; Bruce Momjian; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze [...] Why couldn't you just release the win32 version of 7.4 when it was finished. If it takes an extra month then that just gives you guys the chance to circulate *two* press releases. The Native Win32 port is likely to make a big enough splash all by itself. A formal release needs a big testing effort. Two separate releases will double the work of validation. That's true in the general case. But in this case we're talking about releasing for a completely new platform. That's much different than doing another release for the same platform set. The testing that needs to be done for the Win32 release has to be done separately *anyway*, so there's nothing lost by releasing the Win32 port separately. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
-Original Message- From: Jason Earl [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 3:32 PM To: Dann Corbit Cc: Jason Earl; The Hermit Hacker; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze Dann Corbit [EMAIL PROTECTED] writes: Why couldn't you just release the win32 version of 7.4 when it was finished. If it takes an extra month then that just gives you guys the chance to circulate *two* press releases. The Native Win32 port is likely to make a big enough splash all by itself. A formal release needs a big testing effort. Two separate releases will double the work of validation. There are several problems with that statement. The first is that PostgreSQL's testing effort happens right here on this mailing list. That's not exactly reassuring. There is no regression test that gets formal acceptance?! The various PostgreSQL hackers code stuff up, and we try and break it. There's very little /effort/ involved. People that want the new features go out on a limb and start using them. If they don't work, then they bring it up on the list. If they do work then very little gets said. As it now stands Tom Lane is on the record as stating that the new Win32 version isn't going to be ready for production anyhow. If anything the Win32 version *should* get released separately simply because we don't want people mistaking the Win32 version as being up to the PostgreSQL teams high standards. Those people that want the Win32 version to become production ready are going to have to risk their precious data. Otherwise, the Win32 version will likely remain a second class citizen forever. The fact of the matter is that the Win32 specific bits are the parts that are likely to break in the new port. If anything the Windows version will *benefit* from an earlier *nix release because the *nix users will chase down the bugs in the new PostgreSQL features. Once the *nix version is up to 7.4.2 (or so) then a Windows release of 7.4.2 should allow the PostgreSQL hackers to simply chase down Windows specific problems. Then using the same logic, the new Windows version should wait indefinitely, since the *nix version will always be shaking out bugs. Adding a new platform--especially a platform as diverse from the rest of PostgreSQL's supported platforms as Windows--is what adds the work. Testing the new platform is relatively easy. All you need to do is to start using the Win32 version with real live data. That is not testing. Using the world as your beta team seems to be a business model used by a few software giants that is largely frowned upon. I would think that there is an opportunity to do things differently. [Read 'properly']. We (at CONNX Solutions Inc.) have a formal release procedure that includes many tens of thousands of automated tests using dozens of different platforms. There are literally dozens of machines (I would guess 70 or so total) running around the clock for 7 days before we even know if we have a release candidate. The QA team is distinct from the development team, and if they say FLOP! the release goes nowhere. No formal release until QA passes it. If there is no procedure for PostgreSQL of this nature, then there really needs to be. I am sure that MySQL must have something in place like that. Their Crash-Me test suite shows (at least) that they have put a large effort into testing. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
On Fri, Jun 20, 2003 at 03:39:47PM -0700, Dann Corbit wrote: We (at CONNX Solutions Inc.) have a formal release procedure that includes many tens of thousands of automated tests using dozens of different platforms. [...] If there is no procedure for PostgreSQL of this nature, then there really needs to be. I am sure that MySQL must have something in place like that. Their Crash-Me test suite shows (at least) that they have put a large effort into testing. The regression testing suite in Postgres is one of the things that impresses me about this software. It's very rare that a change is even committed to the main tree if a single regression test doesn't pass. When it does, a proper fix is quickly put in or the change reverted. It's even rare that patches with regression failures get posted in pgsql-patches. Regression tests are a very handy tool for contributors to check that their work is safe. It's considered good practice to submit new tests when there's new functionality in a patch. There probably isn't such a gigantic effort like the one you describe, but there certainly _is_ a testing procedure. There's probably room for improvement, of course, but we don't want the tests to take a full week to complete, IMHO. It would be nice to have a system which could receive a patch and compile and verify that it passes the tests before it goes to Bruce's queue; or compile on multiple platforms to check for portability problems, for example. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Uno puede defenderse de los ataques; contra los elogios se esta indefenso ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
Dann Corbit [EMAIL PROTECTED] writes: -Original Message- From: Jason Earl [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 3:32 PM To: Dann Corbit Cc: Jason Earl; The Hermit Hacker; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze Dann Corbit [EMAIL PROTECTED] writes: Why couldn't you just release the win32 version of 7.4 when it was finished. If it takes an extra month then that just gives you guys the chance to circulate *two* press releases. The Native Win32 port is likely to make a big enough splash all by itself. A formal release needs a big testing effort. Two separate releases will double the work of validation. There are several problems with that statement. The first is that PostgreSQL's testing effort happens right here on this mailing list. That's not exactly reassuring. There is no regression test that gets formal acceptance?! Yes, there are regression tests, and new tests get invented all of the time whenever the real world finds new bugs. Regression tests are excellent for making sure that you don't make the same mistake twice, but they aren't a substitute for handing the code over to actual end users. The various PostgreSQL hackers code stuff up, and we try and break it. There's very little /effort/ involved. People that want the new features go out on a limb and start using them. If they don't work, then they bring it up on the list. If they do work then very little gets said. As it now stands Tom Lane is on the record as stating that the new Win32 version isn't going to be ready for production anyhow. If anything the Win32 version *should* get released separately simply because we don't want people mistaking the Win32 version as being up to the PostgreSQL teams high standards. Those people that want the Win32 version to become production ready are going to have to risk their precious data. Otherwise, the Win32 version will likely remain a second class citizen forever. The fact of the matter is that the Win32 specific bits are the parts that are likely to break in the new port. If anything the Windows version will *benefit* from an earlier *nix release because the *nix users will chase down the bugs in the new PostgreSQL features. Once the *nix version is up to 7.4.2 (or so) then a Windows release of 7.4.2 should allow the PostgreSQL hackers to simply chase down Windows specific problems. Then using the same logic, the new Windows version should wait indefinitely, since the *nix version will always be shaking out bugs. That's not true at all. Despite the excellent work by the PostgreSQL team, and despite the beta testing that will be done by volunteers, if history repeats itself, there will be problems with version 7.4.0, even on platforms that have been well supported by PostgreSQL forever. I am not saying that we should hold off indefinitely on the Win32 port, I am simply saying that it probably wouldn't hurt to shake out the normal .0 release bugs before throwing the unique Win32 bugs into the mix. My guess is that reported Win32 bugs are going blamed on the Win32 specific bits at first no matter what happens. Unless the bug can be demonstrated on a *nix version it will be assumed that the problem is a shortcoming of the Win32 specific code. That's just common sense. Adding a new platform--especially a platform as diverse from the rest of PostgreSQL's supported platforms as Windows--is what adds the work. Testing the new platform is relatively easy. All you need to do is to start using the Win32 version with real live data. That is not testing. Using the world as your beta team seems to be a business model used by a few software giants that is largely frowned upon. I would think that there is an opportunity to do things differently. [Read 'properly']. Hmm... I must have missed the huge corporation paying for in house testing of PostgreSQL. In the Free Software world the beta team is all of those people that need the new features so badly that they are willing to risk their own data and hardware testing it. You might not like the way that this sounds, but in practice it works astoundingly well. Chances are you can't name 25 pieces of commercial software that run on the wide array of hardware platforms and OSes as PostgreSQL, and PostgreSQL has a earned a well deserved reputation for being a solid piece of software. Clearly the PostgreSQL team is doing *something* right. We (at CONNX Solutions Inc.) have a formal release procedure that includes many tens of thousands of automated tests using dozens of different platforms. There are literally dozens of machines (I would guess 70 or so total) running around the clock for 7 days before we even know if we have a release candidate. The QA team is distinct from the development team, and if they say FLOP! the release goes nowhere. No formal release until QA
Re: [HACKERS] ss_family in hba.c
On Thu, Jun 19, 2003 at 23:01:19 +0200, Kurt Roeckx [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2003 at 11:01:27PM -0500, Bruno Wolff III wrote: My system does have its own sockaddr_storage definition. I think it uses __ss_ as the prefix. Also, after looking at the fallback definition in pqcomm.h, I don't see where that defines ss_family and hence don't see how that could work. I am going to see if adding __ works as suggested by someone else who replied. See if this patch helps. Don't forget to run autoconf after applying the patch. I get an error message running autoconf claiming I need to be using version 2.53 or higher. However, normally I build from CVS without using it (directly). I run configure and then make. I am guessing that autoconf is used to make a new configure file from configure.in? I can see about getting a new version of autoconf up and running. In the meantime the compile error happens in a different program than it did previously: gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -c printtup.c -o printtup.o In file included from ../../../../src/include/libpq/libpq-be.h:22, from ../../../../src/include/libpq/libpq.h:21, from printtup.c:20: ../../../../src/include/libpq/pqcomm.h:82: #error struct sockaddr_storage does not provide an ss_family member make[4]: *** [printtup.o] Error 1 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ss_family in hba.c
On Fri, Jun 20, 2003 at 18:56:30 -0500, Bruno Wolff III [EMAIL PROTECTED] wrote: On Thu, Jun 19, 2003 at 23:01:19 +0200, Kurt Roeckx [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2003 at 11:01:27PM -0500, Bruno Wolff III wrote: My system does have its own sockaddr_storage definition. I think it uses __ss_ as the prefix. Also, after looking at the fallback definition in pqcomm.h, I don't see where that defines ss_family and hence don't see how that could work. I am going to see if adding __ works as suggested by someone else who replied. See if this patch helps. Don't forget to run autoconf after applying the patch. I get an error message running autoconf claiming I need to be using version 2.53 or higher. However, normally I build from CVS without After getting 2.57 everything seems to be working OK. So the patch seems good from my end. ---(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] Commands to change name, schema, owner
Peter Eisentraut [EMAIL PROTECTED] writes: Are there any tricky problems with any of these operations? A few. Moving a table across schemas would require moving its indexes and rowtype as well; conversely you should forbid moving the indexes and rowtype by themselves, or altering their owners separately from the table, or renaming the rowtype by itself. I am not real sure that renaming a database is safe if there are active backends in it; doesn't a backend have its dbname stored statically in a few places? Same goes for renaming a user who has active backends. (Even if you can fix the instances within the backend, what about connected clients, for instance libpq's private state? And what if the rename means these clients should not have been allowed to connect, per pg_hba.conf?) Renaming operators would possibly change their precedence, which I don't *think* would break rule dumps, but it's something to consider. Renaming sequences would break nextval() and related calls on them, since we don't have any way to find the references and update the text strings. Changing a function owner might be interesting for SECURITY DEFINER functions; I'm not sure what is likely to happen for active or already-planned calls on the function. The command is: ALTER THING oldname RENAME TO newname; Requires being the owner of the object (or superuser for group, user, language) and CREATE privilege on containing schema. The privilege considerations are doubtless different for the several kinds of objects that don't live within schemas; could we see a more complete spec? The command is: ALTER THING name SCHEMA newschema; Requires USAGE on old schema(?), owner of object, CREATE in new schema. If you got as far as executing the command, you have USAGE on the old schema, else you could never have looked up the object. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
-Original Message- From: Jason Earl [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 4:43 PM To: Dann Corbit Cc: Jason Earl; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze Dann Corbit [EMAIL PROTECTED] writes: -Original Message- From: Jason Earl [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 3:32 PM To: Dann Corbit Cc: Jason Earl; The Hermit Hacker; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze Dann Corbit [EMAIL PROTECTED] writes: Why couldn't you just release the win32 version of 7.4 when it was finished. If it takes an extra month then that just gives you guys the chance to circulate *two* press releases. The Native Win32 port is likely to make a big enough splash all by itself. A formal release needs a big testing effort. Two separate releases will double the work of validation. There are several problems with that statement. The first is that PostgreSQL's testing effort happens right here on this mailing list. That's not exactly reassuring. There is no regression test that gets formal acceptance?! Yes, there are regression tests, and new tests get invented all of the time whenever the real world finds new bugs. Regression tests are excellent for making sure that you don't make the same mistake twice, but they aren't a substitute for handing the code over to actual end users. After testing QA, there is a beta period. You don't hand beta code over to actual end users. In the corporate world it would be a clear case of both negligence and incompetence. The various PostgreSQL hackers code stuff up, and we try and break it. There's very little /effort/ involved. People that want the new features go out on a limb and start using them. If they don't work, then they bring it up on the list. If they do work then very little gets said. As it now stands Tom Lane is on the record as stating that the new Win32 version isn't going to be ready for production anyhow. If anything the Win32 version *should* get released separately simply because we don't want people mistaking the Win32 version as being up to the PostgreSQL teams high standards. Those people that want the Win32 version to become production ready are going to have to risk their precious data. Otherwise, the Win32 version will likely remain a second class citizen forever. The fact of the matter is that the Win32 specific bits are the parts that are likely to break in the new port. If anything the Windows version will *benefit* from an earlier *nix release because the *nix users will chase down the bugs in the new PostgreSQL features. Once the *nix version is up to 7.4.2 (or so) then a Windows release of 7.4.2 should allow the PostgreSQL hackers to simply chase down Windows specific problems. Then using the same logic, the new Windows version should wait indefinitely, since the *nix version will always be shaking out bugs. That's not true at all. Despite the excellent work by the PostgreSQL team, and despite the beta testing that will be done by volunteers, if history repeats itself, there will be problems with version 7.4.0, even on platforms that have been well supported by PostgreSQL forever. I am not saying that we should hold off indefinitely on the Win32 port, I am simply saying that it probably wouldn't hurt to shake out the normal .0 release bugs before throwing the unique Win32 bugs into the mix. My guess is that reported Win32 bugs are going blamed on the Win32 specific bits at first no matter what happens. Unless the bug can be demonstrated on a *nix version it will be assumed that the problem is a shortcoming of the Win32 specific code. That's just common sense. You are right that a new feature will add new bugs. I am saying that the Win32 port is a new feature that will need a shakedown, but the shakedown should occur in the testing and beta phase, like any other feature. Adding a new platform--especially a platform as diverse from the rest of PostgreSQL's supported platforms as Windows--is what adds the work. Testing the new platform is relatively easy. All you need to do is to start using the Win32 version with real live data. That is not testing. Using the world as your beta team seems to be a business model used by a few software giants that is largely frowned upon. I would think that there is an opportunity to do things differently. [Read 'properly']. Hmm... I must have missed the huge corporation paying for in house testing of PostgreSQL. In the Free Software world the beta team is all of those people that need the new features so badly that they are willing to risk their own data and hardware testing it. I don't see how this model can possibly succeed then. You can't just hope that
[HACKERS] compile failure on cvs tip --with-krb5
This change (I'm sure this will wrap poorly -- sorry): http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/libpq/pqcomm.h.diff?r1=1.85r2=1.86 modified SockAddr, but no corresponding change was made here (fe-auth.c:612): case AUTH_REQ_KRB5: #ifdef KRB5 if (pg_krb5_sendauth(PQerrormsg, conn-sock, conn-laddr.in, conn-raddr.in, hostname) != STATUS_OK) It's not obvious to me what the change ought to be though. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
Jason Earl [EMAIL PROTECTED] writes: The fact of the matter is that the Win32 specific bits are the parts that are likely to break in the new port. Actually, what scares me about this is the probability that the Win32 port will break other platforms. The changes look to be invasive enough to create a nontrivial risk of that. For comparison, look at the CVS history of the recent efforts to support IPv6 connections. Those patches have broken both IPv4 and Unix-socket connections at different times, and are still a source of ongoing build problems on some platforms, plus who-knows-what problems yet to be found on platforms that aren't used by the bleeding-edge-CVS folk. I predict that the tweaks needed to support Windows' lack of a fork() primitive will be far worse. BTW, I would not approve of a response along the lines of can't you #ifdef to the point that there are no code changes in the Unix builds? No you can't, unless you want to end up with an unmaintainable mess of #ifdef spaghetti. The thing that makes this hard is the tradeoff between making the code readable and maintainable (which requires sharing as much code as possible across platforms) vs isolating platform-specific considerations. Programming at this level is not a science but an art form, and it's very hard to get it right the first time --- especially when none of us have access to all the platforms that the code must ultimately work on. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Two weeks to feature freeze
Dann Corbit [EMAIL PROTECTED] writes: If there is no procedure for PostgreSQL of this nature, then there really needs to be. Are you volunteering to create it? Step right up. I am sure that MySQL must have something in place like that. Their Crash-Me test suite shows (at least) that they have put a large effort into testing. ...ROTFL... Crash-Me is not a regression test. It is a marketing effort. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
Alvaro Herrera [EMAIL PROTECTED] writes: It would be nice to have a system which could receive a patch and compile and verify that it passes the tests before it goes to Bruce's queue; or compile on multiple platforms to check for portability problems, for example. It happens not infrequently that Bruce commits some patch that fails the regression tests. Whereupon he gets chewed out by whoever notices it first :-). I've been guilty of the same on occasion, even though I try hard to avoid it. If the regression tests took two seconds to run I'm sure we'd both set up scripts to ensure we *never* commit without regression testing first. On the other hand, if they took a week to run you can be damn sure that most commits would go in without any regression testing. I think that our existing tests are a fairly happy medium --- they catch most stuff, and the stuff they don't catch is in my opinion stuff that an automated test is unlikely to catch. (I do add things to the regression tests whenever something shows up that looks like it should have been caught.) Another point is that passing on one platform doesn't ensure passing on another. Here we really rely on the willingness of the pghackers community to update to CVS tip regularly and run the regression tests when they do. Again, tests that take a couple minutes to run are ideal; if they took a week then the uptake would drop to zero, and we'd not be ahead. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
Jason Earl [EMAIL PROTECTED] writes: Hmm... I must have missed the huge corporation paying for in house testing of PostgreSQL. In the Free Software world the beta team is all of those people that need the new features so badly that they are willing to risk their own data and hardware testing it. I don't have a lot of faith in huge automated test efforts. They're great at ensuring you don't make the same mistakes you made once before, but in my experience the nastiest bugs are the ones you haven't seen before and would never in a million years have dreamed to test for. Thus, the best test team is a bunch of people doing unplanned things with the software, on a wide variety of platforms... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Two weeks to feature freeze
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: It would be nice to have a system which could receive a patch and compile and verify that it passes the tests before it goes to Bruce's queue; or compile on multiple platforms to check for portability problems, for example. *snip* Another point is that passing on one platform doesn't ensure passing on another. Here we really rely on the willingness of the pghackers community to update to CVS tip regularly and run the regression tests when they do. Again, tests that take a couple minutes to run are ideal; if they took a week then the uptake would drop to zero, and we'd not be ahead. Have you considered something similar to the Mozilla tinderbox approach where you have a daemon checkout the cvs, compile, run regression tests, and report a status or be able to report a status? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 8:36 PM To: Dann Corbit Cc: Jason Earl; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze Dann Corbit [EMAIL PROTECTED] writes: If there is no procedure for PostgreSQL of this nature, then there really needs to be. Are you volunteering to create it? Step right up. No. And as an outsider, I rather doubt if any procedures I developed would be taken very seriously. If such procedures are to be developed, I suspect that they will have to be developed from within if they are to be successful. This would be a good start: A. Combine: 1. Your regression test 2. Crashme (or some rough equivalent if you don't like it) 3. The NIST validation test suite B. Automate: 1. Installation of the tests 2. Execution of the tests 3. Transfer of the test results to a repository 4. Analysis of the test results C. Assign: 1. Criteria for acceptance of a build for release 2. Authority for acceptance of a build for release 3. Delegation rules for issue resolution 4. Procedures for issue resolution I am sure that MySQL must have something in place like that. Their Crash-Me test suite shows (at least) that they have put a large effort into testing. ...ROTFL... Crash-Me is not a regression test. It is a marketing effort. Let's see... Their marketing effort checks for STANDARDS conformance against over several hundred distinct, important properties. Their marketing effort checks for a number of interesting and valuable extensions. Their marketing effort checks for system safety in a manner that is better than anything I have ever seen from a commercial vendor. And the PostgreSQL regression test is superior in what ways? Look at this: http://www.mysql.com/information/crash-me.php?mysql_4_1=onpostgres=on Their marketing effort makes PostgreSQL look superior to MySQL in most areas. If it is a marketing effort, then we must applaud them for their honesty. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 8:58 PM To: Jason Earl Cc: Dann Corbit; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze Jason Earl [EMAIL PROTECTED] writes: Hmm... I must have missed the huge corporation paying for in house testing of PostgreSQL. In the Free Software world the beta team is all of those people that need the new features so badly that they are willing to risk their own data and hardware testing it. I don't have a lot of faith in huge automated test efforts. They're great at ensuring you don't make the same mistakes you made once before, but in my experience the nastiest bugs are the ones you haven't seen before and would never in a million years have dreamed to test for. This is true if and only if the test design is poor. Thus, the best test team is a bunch of people doing unplanned things with the software, on a wide variety of platforms... That is the worst possible test plan. It totally lacks organization and there is no hint to define when the feature set has been covered. Ad hoc testing is a useful addition, but it cannot replace all the standard tests that have been used by the industry for decades. If you run literally hundreds of tests designed to ensure that your product conforms to ANSI/ISO standards then the bugs that are missed will be few and far between. Unless you are bad at designing tests. Designing tests is busywork. Desiging tests is boring. Nobody wants to design tests, let alone interpret the results and define correct baselines. But testing is very, very important. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
--- Dann Corbit [EMAIL PROTECTED] wrote: Why couldn't you just release the win32 version of 7.4 when it was finished. I agree. Don't delay *nix release because of win32 port is not ready. To many users win32 port is of marginal importance anyway. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
Thomas Swan [EMAIL PROTECTED] writes: Have you considered something similar to the Mozilla tinderbox approach where you have a daemon checkout the cvs, compile, run regression tests, and report a status or be able to report a status? Tinderbox is pretty cool. Who wants to set it up? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
Dann Corbit [EMAIL PROTECTED] writes: ...ROTFL... Crash-Me is not a regression test. It is a marketing effort. Their marketing effort checks for STANDARDS conformance against over several hundred distinct, important properties. If you'd not spelled STANDARDS in caps I'd not have taken the trouble to respond ... but I suggest you stop to count exactly how many of their bullet points are actually grounded in the SQL standard, how many are not, and how many are in fact counter to spec but agree with MySQL's deviations from spec (of course those show as green for MySQL's version of reality, and as failures for spec-compliant databases). I have been through crash-me in some detail, and it left a very bad taste in my mouth. Don't bother holding it up as an example of good practice. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 9:19 PM To: Dann Corbit Cc: Jason Earl; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze Dann Corbit [EMAIL PROTECTED] writes: ...ROTFL... Crash-Me is not a regression test. It is a marketing effort. Their marketing effort checks for STANDARDS conformance against over several hundred distinct, important properties. If you'd not spelled STANDARDS in caps I'd not have taken the trouble to respond Sorry for shouting. ... but I suggest you stop to count exactly how many of their bullet points are actually grounded in the SQL standard, how many are not, and how many are in fact counter to spec but agree with MySQL's deviations from spec (of course those show as green for MySQL's version of reality, and as failures for spec-compliant databases). I have been through crash-me in some detail, and it left a very bad taste in my mouth. Don't bother holding it up as an example of good practice. Every single test in their list is interesting and useful. I see several hundred things which I recognize as part of the ANSI/ISO SQL Standard. I have set up and run the tests. I did not go into great detail (as you have done) to ensure that they were really testing what they claimed to test and that correct interpretation of the results was made in each case. If they have done something underhanded, then they should be called out onto the carpet for it. In any case, the general outline of what they are doing is a very good idea. If it can be improved upon, then that would be an excellent idea. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
On Fri, Jun 20, 2003 at 09:25:08PM -0700, Dann Corbit wrote: Citing Tom Lane: I have been through crash-me in some detail, and it left a very bad taste in my mouth. Don't bother holding it up as an example of good practice. Every single test in their list is interesting and useful. At least on the version I just saw there are several results with Postgres that are weird (table names 500 chars?). Other things tested are clearly wrong (things that are = NULL, dates like '00-00-'); results for Postgres that are wrong probably because they are trying a weird syntax. Etc. Things like that drive the credibility of the whole thing to the floor. Maybe something like this should exist for Postgres, but it's not crash-me. Maybe the NIST compliance test is adequate. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La conclusion que podemos sacar de esos estudios es que no podemos sacar ninguna conclusion de ellos (Tanenbaum) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] add column .. default
Thats still double the disk space, although that has the nice side effect of not requiring a vacuum. Also, a rollback after 99% of the updates have been done will waste no diskspace... Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
-Original Message- From: Alvaro Herrera [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 10:00 PM To: Dann Corbit Cc: Tom Lane; Jason Earl; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze On Fri, Jun 20, 2003 at 09:25:08PM -0700, Dann Corbit wrote: Citing Tom Lane: I have been through crash-me in some detail, and it left a very bad taste in my mouth. Don't bother holding it up as an example of good practice. Every single test in their list is interesting and useful. At least on the version I just saw there are several results with Postgres that are weird (table names 500 chars?). It does get silly at a point, but I have seen systems with 128 characters for table names, column names, etc. Some people seem to like it. Not me. Too much typing. Other things tested are clearly wrong (things that are = NULL, Sounds like testing for the existence of a bug. X = NULL X = NULL X = NULL Etc. must always test false, regardless of the contents of X. Test for equality with NULL is a conformance error if NULL == NULL returns true. dates like '00-00-'); Not sure what that might even mean. results for Postgres that are wrong probably because they are trying a weird syntax. Etc. Things like that drive the credibility of the whole thing to the floor. Maybe something like this should exist for Postgres, but it's not crash-me. Maybe the NIST compliance test is adequate. So far, I have seen three problems pointed out (out of 600+ tests). That's 0.5% defects. Why not just drop the stupid tests, or bend them to test for what they ought to be testing. Besides those three, what other tests are bogus and why? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Commands to change name, schema, owner
The command is: ALTER THING name AUTHORIZATION username; (This is consistent with the CREATE SCHEMA syntax. Anyone like OWNER better?) k WHy not copy the exiting ALTER TABLE / OWNER TO syntax? Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
We (at CONNX Solutions Inc.) have a formal release procedure that includes many tens of thousands of automated tests using dozens of different platforms. There are literally dozens of machines (I would guess 70 or so total) running around the clock for 7 days before we even know if we have a release candidate. The QA team is distinct from the development team, and if they say FLOP! the release goes nowhere. No formal release until QA passes it. PostgreSQL has a comprehensive regression suite that is run by the developers all the time... If there is no procedure for PostgreSQL of this nature, then there really needs to be. I am sure that MySQL must have something in place like that. Their Crash-Me test suite shows (at least) that they have put a large effort into testing. No, it means they've put a crap effort into trying to make other databases look bad... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
I don't have a lot of faith in huge automated test efforts. They're great at ensuring you don't make the same mistakes you made once before, but in my experience the nastiest bugs are the ones you haven't seen before and would never in a million years have dreamed to test for. Thus, the best test team is a bunch of people doing unplanned things with the software, on a wide variety of platforms... Which is why I never use a .0 release of PostgreSQL :) 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] Two weeks to feature freeze
Things like that drive the credibility of the whole thing to the floor. Maybe something like this should exist for Postgres, but it's not crash-me. Maybe the NIST compliance test is adequate. Plus I belive the RedHat people are getting PostgreSQL through the NIST compliance tests at the moment...I'd love to see MySQL pass them... 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] Two weeks to feature freeze
Sounds like testing for the existence of a bug. X = NULL X = NULL X = NULL Etc. must always test false, regardless of the contents of X. Test for equality with NULL is a conformance error if NULL == NULL returns true. They should all return NULL, not false... dates like '00-00-'); Yes, that's MySQL's idea of a NULL date. In fact, it's exactly what you get when you insert a NULL date into a NOT NULL column - hooray the test proves that MySQL accepts NULL values in NOT NULL columns... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Maybe the NIST compliance test is adequate. Plus I belive the RedHat people are getting PostgreSQL through the NIST compliance tests at the moment...I'd love to see MySQL pass them... FWIW, the first pass of those tests is complete, and it turned up exactly one bug that we didn't already know of (the outer-level-aggregate bizarrity that I fixed last week ... which MySQL wouldn't be subject to since they haven't got subselects ...) The work is not done, because there are some tests that couldn't be run because they were blocked by known noncompliances (such as lack of updatable views). But I'm not getting a sense that we will learn a whole lot from the NIST tests. Further details will be published soon... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
If you mean the one that comes with PostgreSQL, then I think the MySQL test is better. The PostgreSQL test seems to focus more on extensions than anything else. What the? It tests no extensions. The extensions have their own regression tests. Most of the criticism leveled at their efforts sound like fearful hand waving to me. True, I have not studied the test as carefully as others have. But the PostgreSQL test is not superior to the MySQL test. I have put considerable effort into the PostgreSQL regression test. We achieved 100% success on the Win32 platform, including dynamic loading of functions. Notice that it tests absulutely no parallel functionality, whereas PostgreSQL tests things in parallel to check for concurrency problems: Note that this benchmark is single threaded, so it measures the minimum time for the operations. We plan to in the future add a lot of multi-threaded tests to the benchmark suite. It's said that for at least 4 years now. Crash-me has nothing to do with testing, it jsut checks to see what features a db supports: crash-me tries to determine what features a database supports and what its capabilities and limitations are by actually running queries. For example, it determines: What column types are supported How many indexes are supported What functions are supported How big a query can be How big a VARCHAR column can be Obviously it has nothing to do with can I index every type in the system, can I use the index to look up a set of test values, etc., etc. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
