Re: [HACKERS] sync()
Tom Lane writes: > Right. "Portably" was the key word in my comment (sorry for not > emphasizing this more clearly). The real problem here is how to know > what is the actual behavior of each platform? I'm certainly not > prepared to trust reading-between-the-lines-of-some-man-pages. And I > can't think of a simple yet reliable direct test. Is the "Single Unix Standard, version 2" (aka UNIX98) any better? It says for fsync(): "The fsync() function forces all currently queued I/O operations associated with the file indicated by file descriptor fildes to the synchronised I/O completion state. All I/O operations are completed as defined for synchronised I/O file integrity completion." This to me clearly says that changes to the file must be written, not just changes made via this file descriptor. I did have to test this behaviour once (for a customer, strange situation) but I couldn't find a portable way to do it, either. What I did was read the appropriate disk block from the raw device to bypass the buffer cache. As this required low level knowledge of the on-disk filesystem layout it was not very portable. For anyone interested Tom Christiansen's "icat" program can be ported to UFS derived filesystems fairly easily: http://www.rosat.mpe-garching.mpg.de/mailing-lists/perl5-porters/1997-04/msg00487.html > AFAIK, all Unix implementations are paranoid about consistency of > filesystem metadata, including directory contents. So fsync'ing > directories from a user process strikes me as a waste of time, ... There is one variant where this is not the case: Linux using ext2fs and possibly other filesystems. There was a flame fest of great entertainment value a few years ago between Linus Torvalds and Dan Bernstein. Of course, neither was able to influence the opinion of the other to any noticible degree, but it made fun reading. I think this might be a starting point: http://www.ornl.gov/cts/archives/mailing-lists/qmail/1998/05/msg00667.html A more recent posting from Linus where he continues to recommend fsync() is this: http://www.cs.helsinki.fi/linux/linux-kernel/2001-29/0659.html I've not heard that any other Unix-like OS has abandoned the traditional and POSIX semantic. > assuming that it were portable, which I doubt. What we need to worry > about is whether fsync'ing a bunch of our own data files is a practical > substitute for a global sync() call. I wish that it were. There are situations (serveral GB buffer caches, for example) where I mistrust the current use of sync() to have all writes completed before the sleep() returns. My concern is theoretical at the moment -- I never get to play with machines that large! Regards, Giles ---(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] default to WITHOUT OIDS?
>>>Neil Conway said: > On Fri, 2003-01-10 at 21:27, Christopher Kings-Lynne wrote: > > So what actually is the point of OIDs then? > > My understanding is that they're used to uniquely identify entries in > system catalogs. If there's a good reason to make use of OIDs on user > tables, I can't see it... What happens if you have an existing database and want to load new tables, that rely on their OIDs (the OIDs of the rows actually) to refer to data in other tables (the 'old' way)? Normally, one would dump the old tables 'with oids' and copy to the new database 'with oids'. Chances are, there will be duplicate OIDs in the database - in the existing and new tables Daniel ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] default to WITHOUT OIDS?
If ever this happens, same should be considered for tables created via the SELECT INTO statement. These are in many cases 'temporary' in nature and do not need OIDs (while making much use of the OIDs counter). Daniel ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] PostgreSQL libraries - PThread Support, but
Ok guys, I propose that the new libpq diff and 2 source files which i'll soon send to pgsql-patches is applied to the source. This diff is a cleaned up version of the previous version with the wrapper functions moved out into their own file and more comments added. Also the use of crypt_r() has been removed (not worth the effort), the cpp defines have been renamed to be consistent with each other and Tom's concerns with loose #defines has been partly addressed. This diff does not include any configure changes. I plan to tackle this separately ASAP, and hopefully produce something more acceptable. I will add checks for appropriate compiler thread flags (for compiling libpq, and alow the removal of #defines in libpq-reentrant.h), and link flags & libs (for a planned threaded libpq test program and renentrant ecpg library). If a thread environment is found then check for the reentrant functions will be done. Looking at various open source projects configure.in files there seems to be little commonality in the thread test macros (telp gratefully accepted!), I currently think that something like the approach used by glib is most suitable (switch on OS). All sound acceptable? Thanks, Lee. Peter Eisentraut writes: > Lee Kindness writes: > > > Patches attached to make libpq thread-safe, now uses strerror_r(), > > gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where > > strtok() was previously used strchr() is now used. > > AC_TRY_RUN tests are prohibited. Also, try to factor out some of these > huge tests into separate macros and put them into config/c-library.m4. > And it would be nice if there was some documentation about what was > checked for. If you just want to check whether gethostbyname_r() has 5 or > 6 arguments you can do that in half the space. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL site, put up or shut up?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message > I have no problem with ads being put there, but they should load at > least as fast as the rest of the site. They do so currently, but not > always, it seems... The ads are coming from another site, ads.area902.com; thus they are at the mercy of the speed of that site. However, from the Area902.com home page: "Welcome to area902.com. Our site is a new way to understand more about Nova Scotia and Prince Edward Island. ... Area902.Com is a Free Service provided by Hub.Org Networking Services" Because hub.org is also displaying the postgresql.org page on the same subnet, so the disparity should in theory be quite controllable. *If* we are going to keep the ads (and my vote is a strong nay), can we not just have them served from the same computer and domain? > FTP is just over 800MB, plan for growth. > WEB is just over 90MB, can't tell you what to plan for there. Sorry to be dense, but what time period is this for? > On www/ftp.us I don't even notice the bandwidth, it's less than the normal > traffic for Pop4 (an ISP) and the streaming audio uses up even more than > that. Sounds like the mirrors could easily absorb more of the traffic from the main page, especially once we get an easier mirroring system in place. -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200301130923 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+IsxavJuQZxSWSsgRAjBdAJ9y6PwrxmbVsKbGOGQ7DjimPVVeXACg54/9 vGxO0/uBlV4FB8GZSsAptW0= =BALS -END PGP SIGNATURE- ---(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] PostgreSQL site, put up or shut up?
On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: > > FTP is just over 800MB, plan for growth. > > WEB is just over 90MB, can't tell you what to plan for there. > > Sorry to be dense, but what time period is this for? Any given day. It's disk space, not traffic. > > On www/ftp.us I don't even notice the bandwidth, it's less than the normal > > traffic for Pop4 (an ISP) and the streaming audio uses up even more than > > that. > > Sounds like the mirrors could easily absorb more of the traffic from the > main page, especially once we get an easier mirroring system in place. The mirrors now consist of the Users Lounge - links, docs and mailing list info. If it shrinks much more there won't be any reason to mirror. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL site, put up or shut up?
On 13 Jan 2003 at 9:45, Vince Vielhaber wrote: > On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: > > > > FTP is just over 800MB, plan for growth. > > > WEB is just over 90MB, can't tell you what to plan for there. > > > > Sorry to be dense, but what time period is this for? > > Any given day. It's disk space, not traffic. I think anyone thinking of putting up a mirror will want to know traffic volumes. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_get_constraintdef
On Mon, Jan 13, 2003 at 11:59:33AM +0800, Christopher Kings-Lynne wrote: >Tom Lane writes: > > > > Feel free to contribute some code. > > I will, but unfortunately the damage has already been done...since I have to > support 7.3 anyway, fixing the above problem will actually make my life > harder, not easier... Yeah, but never let that stop you from doing the right thing. Heck, isn't that almost a diagnostic for 'the right thing', "Hmm, this is easy: I must be doing something wrong." ;-) Ross ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL site, put up or shut up?
On Mon, 13 Jan 2003, Dan Langille wrote: > On 13 Jan 2003 at 9:45, Vince Vielhaber wrote: > > > On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: > > > > > > FTP is just over 800MB, plan for growth. > > > > WEB is just over 90MB, can't tell you what to plan for there. > > > > > > Sorry to be dense, but what time period is this for? > > > > Any given day. It's disk space, not traffic. > > I think anyone thinking of putting up a mirror will want to know > traffic volumes. The only info I could give was what I already did. My above statement was to clarify the above numbers. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL site, put up or shut up?
On Mon, Jan 13, 2003 at 10:01:38AM -0500, Vince Vielhaber wrote: > On Mon, 13 Jan 2003, Dan Langille wrote: > > > On 13 Jan 2003 at 9:45, Vince Vielhaber wrote: > > > > > On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: > > > > > > > > FTP is just over 800MB, plan for growth. > > > > > WEB is just over 90MB, can't tell you what to plan for there. > > > > > > > > Sorry to be dense, but what time period is this for? > > > > > > Any given day. It's disk space, not traffic. > > > > I think anyone thinking of putting up a mirror will want to know > > traffic volumes. > > The only info I could give was what I already did. My above statement > was to clarify the above numbers. And there was a statement upthread from someone (Marc?) indicating that the bandwidth was down in the noise for them (as an ISP). Ross ---(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] default to WITHOUT OIDS?
Daniel Kalchev <[EMAIL PROTECTED]> writes: > If ever this happens, same should be considered for tables created via the > SELECT INTO statement. These are in many cases 'temporary' in nature and do > not need OIDs (while making much use of the OIDs counter). SELECT INTO does create tables without OIDs, as of 7.3. We've already had complaints about that ;-) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL site, put up or shut up?
On Mon, 13 Jan 2003, Ross J. Reedstrom wrote: > On Mon, Jan 13, 2003 at 10:01:38AM -0500, Vince Vielhaber wrote: > > On Mon, 13 Jan 2003, Dan Langille wrote: > > > > > On 13 Jan 2003 at 9:45, Vince Vielhaber wrote: > > > > > > > On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: > > > > > > > > > > FTP is just over 800MB, plan for growth. > > > > > > WEB is just over 90MB, can't tell you what to plan for there. > > > > > > > > > > Sorry to be dense, but what time period is this for? > > > > > > > > Any given day. It's disk space, not traffic. > > > > > > I think anyone thinking of putting up a mirror will want to know > > > traffic volumes. > > > > The only info I could give was what I already did. My above statement > > was to clarify the above numbers. > > And there was a statement upthread from someone (Marc?) indicating that > the bandwidth was down in the noise for them (as an ISP). That was me and what I was referring to with, "The only info I could give was what I already did." Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] \d type queries - why not views in system catalog?!?
Hi! I just came across a posting in this list, and a question arose from that which I'm carrying for some time. PG has *some* views in the system catalog, which make life easier, but some essential(?) things like 'list all tables in DB' has to be done in a multi-table join with special attributes. What is the rationale of that? Wouldn't it be easier (and more portable, see 7.3/7.2 system catalogs vs. psql) to have views for that? Do I miss a point here? I'd be even willing to do some work here, if considered worthwhile... Greetings, Joerg -- Leading SW developer - S.E.A GmbH Mail: [EMAIL PROTECTED] WWW: http://www.sea-gmbh.com ---(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] \d type queries - why not views in system catalog?!?
Joerg Hessdoerfer <[EMAIL PROTECTED]> writes: > PG has *some* views in the system catalog, which make life easier, but > some essential(?) things like 'list all tables in DB' has to be done > in a multi-table join with special attributes. What is the rationale > of that? Wouldn't it be easier (and more portable, see 7.3/7.2 system > catalogs vs. psql) to have views for that? Only to the extent that the views match what a particular front-end actually wants to see. Peter Eisentraut is currently working on adding the SQL-spec-mandated "INFORMATION_SCHEMA" views; so as long as all you want to know is what's in the spec, those should be your answer. But I do not foresee psql or pg_dump ever switching over to INFORMATION_SCHEMA, because they want to know about some things that are Postgres-specific. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] \d type queries - why not views in system catalog?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message > Wouldn't it be easier (and more portable, see 7.3/7.2 system catalogs vs. > psql) to have views for that? Do I miss a point here? Putting the \d commands into views has been on the TODO list for a long time: I think it is actually the only psql-related item left, until we change the backend protocol to indicate transaction state. I don't think a view would have helped with the psql 7.2/7.3 change: a lot more changed than simply the underlying SQL. Some of the the backslash commands are not amenable to putting inside a view, as they actually compromise multiple SQL calls and some logic in the C code, but a few could probably be made into views. Could whomever added that particular TODO item expand on this? -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200301131137 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+IuuovJuQZxSWSsgRAgQXAKCdu0+CelZ1V2bwI/HoJHIz+a3DPACgix7u pOcRXwHb+4NJLMeSpNaqzRM= =0yFo -END PGP SIGNATURE- ---(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] PostgreSQL site, put up or shut up?
> -Original Message- > From: Ross J. Reedstrom [mailto:[EMAIL PROTECTED]] > Sent: 13 January 2003 15:16 > To: Vince Vielhaber > Cc: Dan Langille; [EMAIL PROTECTED] > Subject: Re: [HACKERS] PostgreSQL site, put up or shut up? > > > And there was a statement upthread from someone (Marc?) > indicating that the bandwidth was down in the noise for them > (as an ISP). I think that was Vince talking about 1 mirror. The January stats to date (bear in mind it didn't go live until the 4/5th Jan), for the Portal and idocs *only* (ie, not including gborg, techdocs, developer, user-lounge, archives, fts, pgadmin, odbc, jdbc or ftp) are: Total Hits 1339547 Total Files 1064536 Total Pages 324346 Total Visits 58178 Total KBytes 2712883 In other words, 2.7Gb in 8/9 days. I'm not sure I'd call that noise :-) Regards, Dave. ---(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] \d type queries - why not views in system catalog?!?
On Mon, 2003-01-13 at 11:28, [EMAIL PROTECTED] wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > NotDashEscaped: You need GnuPG to verify this message > > > > Wouldn't it be easier (and more portable, see 7.3/7.2 system catalogs vs. > > psql) to have views for that? Do I miss a point here? > > Putting the \d commands into views has been on the TODO list for a long time: > I think it is actually the only psql-related item left, until we change > the backend protocol to indicate transaction state. I don't think a view > would have helped with the psql 7.2/7.3 change: a lot more changed than > simply the underlying SQL. It would be a wise idea to use the INFORMATION_SCHEMA where possible for these, as that is pretty much guaranteed to be static in format. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] PostgreSQL site, put up or shut up?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message > Go back and reread the end of it. The first part was about the ads, > the second was about mirrors. Sorry for the confusion: Dave is right, I just asked the question wrong. I am not really concerned about the mirrors, but how much traffic the main portal endures, and if that number justifies the putting of advertisements on the site. The answer to the first appears to be about 320 MB per day, or about 9 gigs per month. Not too shabby, but not too bad either. To be totally fair, we should also factor in all the other sites (subdomains) that hub.org is providing. I see the big questions as: What prompted the redesign to put the ads on every page of the site, when before they were only on the opening "flags" page? How much monthly revenue do the ads bring in, and can we (the community) provide an alternative to this income, perhaps via direct contributions? -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200301131149 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+Iu5+vJuQZxSWSsgRAjkSAJ9Yit8t0GIwigsdf5DZtDVA71vZCgCgz29S kgC4JGdxFigBpjaHH9KFnaA= =z1RC -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_get_constraintdef
> On Mon, Jan 13, 2003 at 11:59:33AM +0800, Christopher Kings-Lynne wrote: > > > > I will, but unfortunately the damage has already been done...since I have to > > support 7.3 anyway, fixing the above problem will actually make my life > > harder, not easier... Another issue to consider is that when a dump from 7.2 is loaded into 7.3 no foreign keys are listed in pg_constraint, so some backwards compatibility will be required because even if the 7.3 server supports this functionality it does not mean it is being used. Kris Jurka ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL site, put up or shut up?
On Mon, 13 Jan 2003, Dave Page wrote: > > > > -Original Message- > > From: Ross J. Reedstrom [mailto:[EMAIL PROTECTED]] > > Sent: 13 January 2003 15:16 > > To: Vince Vielhaber > > Cc: Dan Langille; [EMAIL PROTECTED] > > Subject: Re: [HACKERS] PostgreSQL site, put up or shut up? > > > > > > And there was a statement upthread from someone (Marc?) > > indicating that the bandwidth was down in the noise for them > > (as an ISP). > > I think that was Vince talking about 1 mirror. The January stats to date > (bear in mind it didn't go live until the 4/5th Jan), for the Portal and > idocs *only* (ie, not including gborg, techdocs, developer, user-lounge, > archives, fts, pgadmin, odbc, jdbc or ftp) are: > > Total Hits 1339547 > Total Files 1064536 > Total Pages 324346 > Total Visits 58178 > Total KBytes 2712883 > > In other words, 2.7Gb in 8/9 days. > > I'm not sure I'd call that noise :-) It's irrelevant. The portal and idocs aren't being mirrored and the question was about mirrors. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL site, put up or shut up?
> -Original Message- > From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] > Sent: 13 January 2003 15:42 > To: Dave Page > Cc: Ross J. Reedstrom; Dan Langille; [EMAIL PROTECTED] > Subject: Re: [HACKERS] PostgreSQL site, put up or shut up? > > > On Mon, 13 Jan 2003, Dave Page wrote: > > > > Total Hits 1339547 > > Total Files 1064536 > > Total Pages 324346 > > Total Visits 58178 > > Total KBytes 2712883 > > > > In other words, 2.7Gb in 8/9 days. > > > > I'm not sure I'd call that noise :-) > > It's irrelevant. The portal and idocs aren't being mirrored > and the question was about mirrors. It's not irrelevant. The original question was a complaint about the ads and why we have them - this shows the amount of traffic we get for a small portion of the site which can give some idea how busy other bits of the sites might get. Regards, Dave. ---(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] \d type queries - why not views in system catalog?!?
On Mon, 2003-01-13 at 11:28, [EMAIL PROTECTED] wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > NotDashEscaped: You need GnuPG to verify this message > > > > Wouldn't it be easier (and more portable, see 7.3/7.2 system catalogs vs. > > psql) to have views for that? Do I miss a point here? > > Putting the \d commands into views has been on the TODO list for a long time: > I think it is actually the only psql-related item left, until we change > the backend protocol to indicate transaction state. I don't think a view > would have helped with the psql 7.2/7.3 change: a lot more changed than > simply the underlying SQL. > > Some of the the backslash commands are not amenable to putting inside a > view, as they actually compromise multiple SQL calls and some logic in > the C code, but a few could probably be made into views. Could whomever > added that particular TODO item expand on this? > One idea I've always thought would be nice would be to make full fledged C functions out of the \ commands and ship them with the database. This way the \ commands could just be alias to "select myfunc()". This would help out all of us who write GUI interfaces since we would have standard functions we could call upon, and would also help with backward compatibility since \dv could always call select list_views(), which would already be included with each server. One of the reasons that this was not feasible in the past was that we needed functions that could return multiple rows and columns easily. Now that we have that in 7.3, it might be worth revisiting. Robert Treat ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] \d type queries - why not views in system catalog?!?
Oh! That's an excellent idea. Seemingly addresses the issue and has value-add. I'm not aware of any gotchas here. Is there something that is being overlooked? Greg On Mon, 2003-01-13 at 14:50, Robert Treat wrote: > On Mon, 2003-01-13 at 11:28, [EMAIL PROTECTED] wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > NotDashEscaped: You need GnuPG to verify this message > > > > > > > Wouldn't it be easier (and more portable, see 7.3/7.2 system catalogs vs. > > > psql) to have views for that? Do I miss a point here? > > > > Putting the \d commands into views has been on the TODO list for a long time: > > I think it is actually the only psql-related item left, until we change > > the backend protocol to indicate transaction state. I don't think a view > > would have helped with the psql 7.2/7.3 change: a lot more changed than > > simply the underlying SQL. > > > > Some of the the backslash commands are not amenable to putting inside a > > view, as they actually compromise multiple SQL calls and some logic in > > the C code, but a few could probably be made into views. Could whomever > > added that particular TODO item expand on this? > > > > One idea I've always thought would be nice would be to make full fledged > C functions out of the \ commands and ship them with the database. This > way the \ commands could just be alias to "select myfunc()". This would > help out all of us who write GUI interfaces since we would have standard > functions we could call upon, and would also help with backward > compatibility since \dv could always call select list_views(), which > would already be included with each server. One of the reasons that this > was not feasible in the past was that we needed functions that could > return multiple rows and columns easily. Now that we have that in 7.3, > it might be worth revisiting. > > Robert Treat > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---(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] PostgreSQL site, put up or shut up?
On Mon, 2003-01-13 at 10:47, Dave Page wrote: > > > > -Original Message- > > From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] > > Sent: 13 January 2003 15:42 > > To: Dave Page > > Cc: Ross J. Reedstrom; Dan Langille; [EMAIL PROTECTED] > > Subject: Re: [HACKERS] PostgreSQL site, put up or shut up? > > > > > > On Mon, 13 Jan 2003, Dave Page wrote: > > > > > > Total Hits 1339547 > > > Total Files 1064536 > > > Total Pages 324346 > > > Total Visits 58178 > > > Total KBytes 2712883 > > > > > > In other words, 2.7Gb in 8/9 days. > > > > > > I'm not sure I'd call that noise :-) > > > > It's irrelevant. The portal and idocs aren't being mirrored > > and the question was about mirrors. > > It's not irrelevant. The original question was a complaint about the ads > and why we have them - this shows the amount of traffic we get for a > small portion of the site which can give some idea how busy other bits > of the sites might get. > Perhaps this means we need to put more focus in finding ways to get other parts of the site mirrored. Robert Treat ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL site, put up or shut up?
On Mon, 13 Jan 2003, Dave Page wrote: > > On Mon, 13 Jan 2003, Dave Page wrote: > > > > > > Total Hits 1339547 > > > Total Files 1064536 > > > Total Pages 324346 > > > Total Visits 58178 > > > Total KBytes 2712883 > > > > > > In other words, 2.7Gb in 8/9 days. > > > > > > I'm not sure I'd call that noise :-) > > > > It's irrelevant. The portal and idocs aren't being mirrored > > and the question was about mirrors. > > It's not irrelevant. The original question was a complaint about the ads > and why we have them - this shows the amount of traffic we get for a > small portion of the site which can give some idea how busy other bits > of the sites might get. Go back and reread the end of it. The first part was about the ads, the second was about mirrors. As far as your numbers go, wait a few months and look again. Any time there's a major change it'll get busy and then settle out. Combine that with everyone talking about it and you'll have even more traffic as folks get curious and go look. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] \d type queries - why not views in system catalog?!?
> -Original Message- > From: Greg Copeland [mailto:[EMAIL PROTECTED]] > Sent: 13 January 2003 20:56 > To: Robert Treat > Cc: [EMAIL PROTECTED]; PostgresSQL Hackers Mailing List > Subject: Re: [HACKERS] \d type queries - why not views in > system catalog?!? > > > Oh! > > That's an excellent idea. Seemingly addresses the issue and > has value-add. I'm not aware of any gotchas here. Is there > something that is being overlooked? Why use functions instead of views? Most UIs will want to format the output as they see fit so a recordset would be the appropriate output. Yes, a function could do this, but surely views would be simpler to implement and maintain. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] \d type queries - why not views in system catalog?!?
Views or C-functions, I think the idea is excellent. It's the concept that I really like. Greg On Mon, 2003-01-13 at 15:00, Dave Page wrote: > > -Original Message- > > From: Greg Copeland [mailto:[EMAIL PROTECTED]] > > Sent: 13 January 2003 20:56 > > To: Robert Treat > > Cc: [EMAIL PROTECTED]; PostgresSQL Hackers Mailing List > > Subject: Re: [HACKERS] \d type queries - why not views in > > system catalog?!? > > > > > > Oh! > > > > That's an excellent idea. Seemingly addresses the issue and > > has value-add. I'm not aware of any gotchas here. Is there > > something that is being overlooked? > > Why use functions instead of views? Most UIs will want to format the > output as they see fit so a recordset would be the appropriate output. > Yes, a function could do this, but surely views would be simpler to > implement and maintain. > > Regards, Dave. > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] \d type queries - why not views in system catalog?!?
You have to do it in functions because some of the \ commands use multiple queries and logic inside the C code. Robert Treat On Mon, 2003-01-13 at 16:42, Greg Copeland wrote: > Views or C-functions, I think the idea is excellent. It's the concept > that I really like. > > Greg > > > On Mon, 2003-01-13 at 15:00, Dave Page wrote: > > > -Original Message- > > > From: Greg Copeland [mailto:[EMAIL PROTECTED]] > > > Sent: 13 January 2003 20:56 > > > To: Robert Treat > > > Cc: [EMAIL PROTECTED]; PostgresSQL Hackers Mailing List > > > Subject: Re: [HACKERS] \d type queries - why not views in > > > system catalog?!? > > > > > > > > > Oh! > > > > > > That's an excellent idea. Seemingly addresses the issue and > > > has value-add. I'm not aware of any gotchas here. Is there > > > something that is being overlooked? > > > > Why use functions instead of views? Most UIs will want to format the > > output as they see fit so a recordset would be the appropriate output. > > Yes, a function could do this, but surely views would be simpler to > > implement and maintain. > > > > Regards, Dave. > > > > ---(end of broadcast)--- > > TIP 4: Don't 'kill -9' the postmaster > -- > Greg Copeland <[EMAIL PROTECTED]> > Copeland Computer Consulting > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org ---(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] \d type queries - why not views in system catalog?!?
Robert Treat kirjutas T, 14.01.2003 kell 01:50: > One of the reasons that this > was not feasible in the past was that we needed functions that could > return multiple rows and columns easily. Now that we have that in 7.3, > it might be worth revisiting. Also, we have schemas now, so it would be easier to avoid name clashes. -- Hannu Krosing <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] copying perms to another user
Often I need to remove a user and cede their permissions to someone else. How about something like this: DROP USER blah PERMISSIONS TO chriskl; or maybe GRANT ALL USER blah TO chriskl; ??? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] copying perms to another user
On Mon, 2003-01-13 at 21:40, Christopher Kings-Lynne wrote: > Often I need to remove a user and cede their permissions to someone else. > How about something like this: > > DROP USER blah PERMISSIONS TO chriskl; If you check that it's a superuser doing the drop, this would be good. However, what (and how many) databases will this command work on? Only the current one? All of them? -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] copying perms to another user
> On Mon, 2003-01-13 at 21:40, Christopher Kings-Lynne wrote: > > Often I need to remove a user and cede their permissions to > someone else. > > How about something like this: > > > > DROP USER blah PERMISSIONS TO chriskl; > > If you check that it's a superuser doing the drop, this would be good. > > However, what (and how many) databases will this command work on? Only > the current one? All of them? Yeah good point...it wouldn't bother me if it were just current database, except that then it wouldn't be useful to use the DROP USER command. ALTER USER or GRANT would be better. BTW Rod, I now get all your emails just fine (not as attachements) - did you change something? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] copying perms to another user
> Yeah good point...it wouldn't bother me if it were just current database, > except that then it wouldn't be useful to use the DROP USER command. ALTER > USER or GRANT would be better. How do you ALTER USER ... after they've been dropped? > BTW Rod, I now get all your emails just fine (not as attachements) - did you > change something? Not that I know of. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] copying perms to another user
> > Yeah good point...it wouldn't bother me if it were just current > database, > > except that then it wouldn't be useful to use the DROP USER > command. ALTER > > USER or GRANT would be better. > > How do you ALTER USER ... after they've been dropped? No, I mean that we don't drop the user. You go: ALTER USER chriskl COPY PERMISSIONS FROM blah; Sort of thing... Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] \d type queries - why not views in system catalog?!?
Robert Treat writes: > One idea I've always thought would be nice would be to make full fledged > C functions out of the \ commands and ship them with the database. The psql meta-commands are not a nicely designed set of queries that one would encapsulate into a public library interface. They are created for interactive use, representing precomposed views of the database that are thought to be useful. If the ideas of usefulness change, then the commands might change. If you want to create a set of views or functions for noninteractive use by client applications, then you need to step back and create maximally decomposed views of the database that can be combined in all possible ways. The SQL information schema is such a set, but the information is perhaps too limited for some applications. (But I urge you too look first.) But any other set would have to be designed on similar principles. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] copying perms to another user
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > No, I mean that we don't drop the user. You go: > ALTER USER chriskl COPY PERMISSIONS FROM blah; That seems cleaner to me than the DROP thingy. You could only easily implement this in the current database --- but since it's not a DROP, one could repeat it in each database as needed. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] copying perms to another user
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > > No, I mean that we don't drop the user. You go: > > ALTER USER chriskl COPY PERMISSIONS FROM blah; > > That seems cleaner to me than the DROP thingy. > > You could only easily implement this in the current database --- but > since it's not a DROP, one could repeat it in each database as needed. Could someone perhaps add it to TODO then (so I don't forget about it)? I can't promise that I can implement it... Chris ---(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] PostgreSQL site, put up or shut up?
[EMAIL PROTECTED] wrote: > Area902.Com is a Free Service provided by Hub.Org Networking Services" > > Because hub.org is also displaying the postgresql.org page on the same subnet, > so the disparity should in theory be quite controllable. *If* we are going > to keep the ads (and my vote is a strong nay), can we not just have them > served from the same computer and domain? Don't do that! Then I can't do "Block all ads from this server" in Mozilla. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] \d type queries - why not views in system catalog?!?
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Robert Treat writes: >> One idea I've always thought would be nice would be to make full fledged >> C functions out of the \ commands and ship them with the database. > The psql meta-commands are not a nicely designed set of queries that one > would encapsulate into a public library interface. They are created for > interactive use, representing precomposed views of the database that are > thought to be useful. If the ideas of usefulness change, then the > commands might change. I think that the proposal is to take describe.c more or less lock-stock-and-barrel out of psql and put it in the backend instead. It doesn't matter whether the views are orthogonal or useful for non-interactive purposes; they're defined to do whatever we think psql should show. The question is whether this gives us a useful amount of decoupling of psql from the backend version. Certainly the describe.c code is the stuff most subject to breakage across versions, but there are a lot of other aspects of psql that could still break. One fairly obvious example of backend-dependent psql code that won't be helped this way is the tab completion code. While I don't have any strong objection to moving the guts of these queries to the backend, I can't get real excited about it either; I suspect that psql will still be pretty version-dependent. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] \d type queries - why not views in system catalog?!?
What should we do with the TODO item? Add question mark? Remove? --- Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Robert Treat writes: > >> One idea I've always thought would be nice would be to make full fledged > >> C functions out of the \ commands and ship them with the database. > > > The psql meta-commands are not a nicely designed set of queries that one > > would encapsulate into a public library interface. They are created for > > interactive use, representing precomposed views of the database that are > > thought to be useful. If the ideas of usefulness change, then the > > commands might change. > > I think that the proposal is to take describe.c more or less > lock-stock-and-barrel out of psql and put it in the backend instead. > It doesn't matter whether the views are orthogonal or useful for > non-interactive purposes; they're defined to do whatever we think > psql should show. > > The question is whether this gives us a useful amount of decoupling of > psql from the backend version. Certainly the describe.c code is the > stuff most subject to breakage across versions, but there are a lot of > other aspects of psql that could still break. One fairly obvious > example of backend-dependent psql code that won't be helped this way is > the tab completion code. > > While I don't have any strong objection to moving the guts of these > queries to the backend, I can't get real excited about it either; > I suspect that psql will still be pretty version-dependent. > > regards, tom lane > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] \d type queries - why not views in system catalog?!?
What about querying the information_schema? Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Treat > Sent: Tuesday, 14 January 2003 6:01 AM > To: Greg Copeland > Cc: Dave Page; [EMAIL PROTECTED]; PostgresSQL Hackers Mailing List > Subject: Re: [HACKERS] \d type queries - why not views in system > catalog?!? > > > You have to do it in functions because some of the \ commands use > multiple queries and logic inside the C code. > > Robert Treat > > On Mon, 2003-01-13 at 16:42, Greg Copeland wrote: > > Views or C-functions, I think the idea is excellent. It's the concept > > that I really like. > > > > Greg > > > > > > On Mon, 2003-01-13 at 15:00, Dave Page wrote: > > > > -Original Message- > > > > From: Greg Copeland [mailto:[EMAIL PROTECTED]] > > > > Sent: 13 January 2003 20:56 > > > > To: Robert Treat > > > > Cc: [EMAIL PROTECTED]; PostgresSQL Hackers Mailing List > > > > Subject: Re: [HACKERS] \d type queries - why not views in > > > > system catalog?!? > > > > > > > > > > > > Oh! > > > > > > > > That's an excellent idea. Seemingly addresses the issue and > > > > has value-add. I'm not aware of any gotchas here. Is there > > > > something that is being overlooked? > > > > > > Why use functions instead of views? Most UIs will want to format the > > > output as they see fit so a recordset would be the appropriate output. > > > Yes, a function could do this, but surely views would be simpler to > > > implement and maintain. > > > > > > Regards, Dave. > > > > > > ---(end of > broadcast)--- > > > TIP 4: Don't 'kill -9' the postmaster > > -- > > Greg Copeland <[EMAIL PROTECTED]> > > Copeland Computer Consulting > > > > > > ---(end of broadcast)--- > > TIP 6: Have you searched our list archives? > > > > http://archives.postgresql.org > > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [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])
[HACKERS] Bug: Re: [JDBC] Warning on transaction commit
Jeremy,
This appears to be a bug in the database. I have been able to
reproduce. It appears that the new 'autocommit' functionality in 7.3
has a problem.
The jdbc driver is essentially issuing the following sql in your example:
set autocommit = off; -- result of the setAutoCommit(false) call
delete ...
insert ...
commit;
select 1; commit; set autocommit = on; -- result of setAC(true) call
Note that the last one is one call to the server issuing three sql
statements together. (The reason for the select 1 and the commit is
intended to ensure a transaction is in progress before committing it and
then turning on autocommit)
If you do the exact same calls in psql it works. But the interesting
thing is that psql will take that last one and break it into three calls
to the server. So if you issue them as one call there is different
behavior than if you issue them in three calls.
So the bug is if a statement that starts a transaction is in the same
set of statements as a commit or rollback the commit or rollback will
not work correctly. In the example of the problem in the jdbc driver
the warning can be ignored, however consider the following example which
would be more of a problem:
set autocommit = off;
insert ...; commit;
rollback;
in this case even though the client application issued a commit the
commit would be ignored and the insert would never be committed.
thanks,
--Barry
Jeremy Buchmann wrote:
Hi all,
I'm getting a warning message in my logs that looks like this:
WARNING: COMMIT: no transaction in progress
when I run this code:
dbh.setAutoCommit(false);
Statement doEvents = dbh.createStatement();
doEvents.executeUpdate("DELETE FROM ...");
doEvents.executeUpdate("INSERT INTO ...");
dbh.commit();
dbh.setAutoCommit(true);
The statements do what they're supposed to do, but I don't understand
why I'm getting that warning message. Anyone know why?
I'm running PostgreSQL 7.3.1 and using the PostgreSQL 7.3 JDBC 2 driver
that I just downloaded a couple days ago from jdbc.postgresql.org.
Thanks,
--Jeremy
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
---(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
