Re: [HACKERS] CVS head doesn't compile
Alvaro Herrera writes: Apparently this is a flaw in configure, because it detects getaddrinfo but fails to define HAVE_GETADDRINFO in pg_config.h, and it works if I define the symbol manually. Works here and looks right in the CVS web view as well. Are you sure you have cvs-updated and configured properly? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] CVS head doesn't compile
On Sun, Mar 30, 2003 at 03:40:34PM +0200, Peter Eisentraut wrote: Alvaro Herrera writes: Apparently this is a flaw in configure, because it detects getaddrinfo but fails to define HAVE_GETADDRINFO in pg_config.h, and it works if I define the symbol manually. Works here and looks right in the CVS web view as well. Are you sure you have cvs-updated and configured properly? Yes, I had it updated and distcleaned, etc. However I updated again now, and works well. Maybe anoncvs got out of sync. I remember this has happenned to people before. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La Primavera ha venido. Nadie sabe como ha sido (A. Machado) ---(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] Detecting corrupted pages earlier
Kevin Brown [EMAIL PROTECTED] writes: Tom Lane wrote: Basically, one should only turn this variable on after giving up on the possibility of getting any data out of the broken page itself. It would be folly to run with it turned on as a normal setting. This statement should *definitely* go into the documentation for the option, then... Here's what I put in --- feel free to suggest better wording. ZERO_DAMAGED_PAGES (boolean) Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction. Setting zero_damaged_pages to true causes the system to instead report a warning, zero out the damaged page, and continue processing. This behavior emphasiswill lose data/, namely all the rows on the damaged page. But it allows you to get past the error and retrieve rows from any undamaged pages that may be present in the table. So it is useful for recovering data if corruption has occurred due to hardware or software error. The default setting is off, and it can only be changed by a superuser. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
Given a HTTP formatted query: GET http://localhost:8181/pgmuze?query=select+*+from+zsong+limit+2; The output is entered below. Questions: Is there a way, without spcifying a binary cursor, to get the data types associated with columns? Right now I am just using undefined, as the ODBC version works. Anyone see any basic improvements needed? ?xml version = 1.0? soap:Envelope xmlns:MWSSQL=http://www.mohawksoft.com/MWSSQL/envelope; soap:Header !-- Fields in set -- Columns count=9 muzenbrundefined/muzenbr discundefined/disc trkundefined/trk songundefined/song artistidundefined/artistid acdundefined/acd trackidundefined/trackid datasrcundefined/datasrc extidundefined/extid /Columns /soap:Header soap:Body ROWSET columns=9 rows=2 ROW ROWID=0 muzenbr424965/muzenbr disc1/disc trk5/trk songWrite My Name In The Groove/song artistid100021391/artistid acdA/acd trackid203429573/trackid datasrc1/datasrc extid203429573/extid /ROW ROW ROWID=1 muzenbr177516/muzenbr disc1/disc trk1/trk songPapa Was A Rolling Stone/song artistid10411/artistid acdP/acd trackid2/trackid datasrc1/datasrc extid2/extid /ROW /ROWSET /soap:Body /soap:Envelope Steve Wampler wrote: On Fri, 2003-03-28 at 14:39, mlw wrote: I was thinking of using SOAP over HTTP as the protocol, and a minimalist version at best. If the people want more let them add it. I have an HTTP service class in my open source library. It would br trivial to accept a SQL query formatted as a GET request, and then execute the query and, using libpq, format the result as XML. It should be simple enough to do. It would be easy. I've done something similar (using ODBC to get to PostgreSQL) - but using a language none of the rest of you are likely to be interested in (Unicon). Works just fine, though the implementation (deliberately, by personal preference) avoids accepting arbitrary SQL statements from SOAP clients, instead forcing the clients to use an RPC interface so I can do sanity checking in the Unicon [which I know better than I know PostgreSQL...] SOAP servers. I, too, opted for a 'minimal-SOAP' implementation. A 'real' implementation boggles the mind. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Newbie: problem Connecting to Server
Ferindo Middleton Jr [EMAIL PROTECTED] wrote: I'm running Redhat Linux 8. I have registration to the Redhat Network so I'm probably running the latest version of postgresql available. I also have Redhat Databse v2.1 installed, but whenever I try to start a session, I get the following error message: psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket /tmp/.s.PGSQL.5432? Please help me configure my system so that I can connect and begin to use postgresql. Have you checked to see if it is actually running? I rather expect that it isn't. I think RHAT distributes GUIfied tools to manage services started via init.d, so that even if you are afraid of Unix, you should be able to see what it's doing. And it's quite unlikely that RHAT has packaged the very latest version; the fact that they are numbering things independently is quite irritating as it makes it more difficult to ascertain what version it actually is. -- output = (cbbrowne @acm.org) http://www3.sympatico.ca/cbbrowne/rdbms.html ...while I know many people who emphatically believe in reincarnation, I have never met or read one who could satisfactorily explain population growth. -- Spider Robinson ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] updateable cursors visibility
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Hiroshi Inoue writes: Must a SENSITIVE cursor see other applications' changes made while the cursor is open ? Yes. It is immaterial whether the change came from a different application or the same one. Nevertheless, the cursor sensitivity does not excuse you from observing the transaction isolation level. So even if the cursor is sensitive you should not be able to see other transactions' changes if you are in a serializable transaction. Serializable or not, there is a good case for saying that cursors don't see changes made after they are opened, period. The current implementation locks down the cursor's snapshot at DECLARE time. It's only because PostgreSQL( or other MVCC based DBMS) is easy and natural to implement cursors in such a way. However, It isn't a requirement of the SQL standard, IIRC. As for ODBC, ODBC has the following cursor types about the visibility of other changes. 1) static It never detects other changes. 2) dynamic It can detect any changes made to the membership, order, and values of the result set after the cursor is opened. 3) keyset-driven It always detects changes to the values of rows. 4) mixed A combination of a keyset-driven cursor and a dynamic cursor. It's not clear to me now how we should realize the above type of cursors at server side. regards, Hiroshi Inoue http://www.geocities.jp/inocchichichi/psqlodbc/ ---(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] updateable cursors visibility
Peter Eisentraut [EMAIL PROTECTED] writes: Hiroshi Inoue writes: Must a SENSITIVE cursor see other applications' changes made while the cursor is open ? Yes. It is immaterial whether the change came from a different application or the same one. Nevertheless, the cursor sensitivity does not excuse you from observing the transaction isolation level. So even if the cursor is sensitive you should not be able to see other transactions' changes if you are in a serializable transaction. Serializable or not, there is a good case for saying that cursors don't see changes made after they are opened, period. The current implementation locks down the cursor's snapshot at DECLARE time. If we allow the snapshot to change later, what in the world will the semantics be? Will we go back to re-scan rows that we previously skipped? I do not think we have a prayer of making consistent, predictable behavior that works any other way. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
