Re: [HACKERS] New DTrace probes proposal
On Sat, 17 May 2008, Robert Lor wrote: I'd like to propose adding the following probes (some of which came from Simon) to 8.4. There's also a big DTrace probe set patch available from OmniTI: https://labs.omniti.com/project-dtrace/trunk/postgresql/ http://labs.omniti.com/trac/project-dtrace/wiki/Applications#PostgreSQL I don't know if you've looked at that before. There's some overlap but many unique and handy probes to each set. I think it would be nice to consider a superset union of the two. I would guess OmniTI would be glad to have their set assimilated into core as well so they don't have to maintain their patch past 8.3; hopefully Theo or Robert will chime in on that. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] odd output in restore mode
Dave Page wrote: On Tue, May 13, 2008 at 5:11 PM, Alvaro Herrera [EMAIL PROTECTED] wrote: Andrew Dunstan wrote: I would be very surprised if xcopy did not exhibit the same preallocating behaviour as copy. I, on the other hand, would not say anything until someone tried it, and then wouldn't be surprised if it behaved either way :-) It pre-allocates the space as copy does. And yes, I did test :-p Dave, I don't know how you tested, but could you please repeat the test with GnuWin32's cp.exe? If it doesn't preallocate the space then I think our way forward is reasonably clear: . we recommend its use for Windows archive_command settings . we provide the delay kluge as switchable behaviour on Windows instead of having it always on. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Can't t compile current HEAD
On Thu, 15 May 2008, Nikhils wrote: On Thu, May 15, 2008 at 11:59 AM, Pavel Stehule [EMAIL PROTECTED] wrote: I always use a ~/.cvsrc containing My .cvsrc also includes: Good hints, and there's now a little section including them all at http://wiki.postgresql.org/wiki/Working_with_CVS#Initial_setup -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ignore $PostgreSQL lines in regression tests?
Recently while adding $PostgreSQL markers to a bunch of .c and .h files I ran into trouble with the ecpg regression tests and had to revert the change for a handful of files. However, it occurred to me that we could have pg_regress tell diff to ignore such lines, by passing it the arguments -I '\$PostgreSQL:' , which would tell it to ignore additions or deletions of lines matching that regex. That would probably also allow us to add such markers as comments in results files, which mightn't be a bad thing either. I'm a bit unsure how portable this is, though. Linux, Windows and OSX should be ok, but they are the only OSs I run so I don't know about others. Would this be a good thing to do? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ignore $PostgreSQL lines in regression tests?
Andrew Dunstan [EMAIL PROTECTED] writes: Recently while adding $PostgreSQL markers to a bunch of .c and .h files I ran into trouble with the ecpg regression tests and had to revert the change for a handful of files. However, it occurred to me that we could have pg_regress tell diff to ignore such lines, by passing it the arguments -I '\$PostgreSQL:' , which would tell it to ignore additions or deletions of lines matching that regex. Would this be a good thing to do? I'm inclined to think not. It's easy to think of scenarios where such a switch would mask errors. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ignore $PostgreSQL lines in regression tests?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Recently while adding $PostgreSQL markers to a bunch of .c and .h files I ran into trouble with the ecpg regression tests and had to revert the change for a handful of files. However, it occurred to me that we could have pg_regress tell diff to ignore such lines, by passing it the arguments -I '\$PostgreSQL:' , which would tell it to ignore additions or deletions of lines matching that regex. Would this be a good thing to do? I'm inclined to think not. It's easy to think of scenarios where such a switch would mask errors. OK. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote: WITH RECURSIVE patch V0.1 Here are patches to implement WITH RECURSIVE clause. There are some limitiations and TODO items(see the Current limitations section below). Comments are welcome. 1. Credit These patches were developed by Yoshiyuki Asaba ([EMAIL PROTECTED]) with some discussions with Tatsuo Ishii ([EMAIL PROTECTED]). This is really great! Kudos to all who made this happen :) I tried a bunch of different queries, and so far, only these two haven't worked. Any ideas what I'm doing wrong here? WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT n+1 FROM t WHERE n 100 ) SELECT * FROM t; ERROR: cannot extract attribute from empty tuple slot WITH RECURSIVE t(n) AS ( VALUES (1) UNION ALL SELECT n+1 FROM t WHERE n 100 ) SELECT * FROM t; ERROR: cannot extract attribute from empty tuple slot Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] notification information functions
I am working on moving the notification buffer into shared memory as previously discussed. Since pg_listener will no longer exist, I think we need to provide a couple of information functions. I suggest: pg_listened_events(out event name) returns setof record pg_pending_events(out event name, out message text) returns setof record The first would show events being listened on by the current backend, while the second would show all pending events for the current db. Given that there will no longer be any central place where events will be registered to be listened on, it will not be possible to show all such events for the current db. Comments? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] notification information functions
Andrew Dunstan [EMAIL PROTECTED] writes: I suggest: pg_listened_events(out event name) returns setof record pg_pending_events(out event name, out message text) returns setof record The first would show events being listened on by the current backend, while the second would show all pending events for the current db. pg_listened_events seems reasonable, but what's a pending event? If you mean stuff that hasn't yet been removed from the shared circular buffer, it seems like that would be too transient (not to mention implementation-dependent) to be interesting. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] notification information functions
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I suggest: pg_listened_events(out event name) returns setof record pg_pending_events(out event name, out message text) returns setof record The first would show events being listened on by the current backend, while the second would show all pending events for the current db. pg_listened_events seems reasonable, but what's a pending event? If you mean stuff that hasn't yet been removed from the shared circular buffer, it seems like that would be too transient (not to mention implementation-dependent) to be interesting. Fair enough. I'm all for less work ;-) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New DTrace probes proposal
Greg Smith wrote: There's also a big DTrace probe set patch available from OmniTI: https://labs.omniti.com/project-dtrace/trunk/postgresql/ http://labs.omniti.com/trac/project-dtrace/wiki/Applications#PostgreSQL I don't know if you've looked at that before. There's some overlap but many unique and handy probes to each set. I think it would be nice to consider a superset union of the two. I heard about Theo's probes recently, but I haven't had a chance to look at them closely. I'm more than happy to adapt his probes for 8.4 and remove any duplicates if there are no objections from Theo. I would guess OmniTI would be glad to have their set assimilated into core as well so they don't have to maintain their patch past 8.3; I'd think so too! -Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] odd output in restore mode
On Sun, May 18, 2008 at 1:38 PM, Andrew Dunstan [EMAIL PROTECTED] wrote: I don't know how you tested, Copy a large file across a relatively slow network, and check the size on the destination drive before it finishes. but could you please repeat the test with GnuWin32's cp.exe? If it doesn't preallocate the space then I think our way forward is reasonably clear: It does not pre-allocate. . we recommend its use for Windows archive_command settings . we provide the delay kluge as switchable behaviour on Windows instead of having it always on. Sounds reasonable to me. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Link requirements creep
Tom Lane wrote: I've been testing a new patch and do not see the problem on Fedora 8, so at least that platform's readline seems to be fixed. I find the hack Martijn proposes in the above message to be pretty ugly, so what I'm inclined to do is leave that out for now and see what failures we get. The availability of the buildfarm makes experimenting with this kind of thing a lot safer ... It broke my FC6 box :-( The box is due to be upgraded when I return from pgcon, but we have a few oldish boxes on the buildfarm. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
On Sun, May 18, 2008 at 5:22 PM, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Can we get the rows in tree order, please? I.e. something like this: Is ordering by tree order defined in the standard when no explicit order is given? If not, it probably returns them in the order they are pulled up, which might be the fastest way. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
Merlin Moncure wrote: On Sun, May 18, 2008 at 5:22 PM, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Can we get the rows in tree order, please? I.e. something like this: Is ordering by tree order defined in the standard when no explicit order is given? If not, it probably returns them in the order they are pulled up, which might be the fastest way +1 for the fastest way, which I expect to often be find all level 1 matches, find all level 2 matches, ... If ORDER BY is important, it should be specified (although it may be difficult or impossible to properly represent ORDER BY for a tree? not sure?) I think most uses of recursive require extra client side code to deal with anyways, so only relative order is important (order within a particular branch). There are things I'd like to use this for right now. Currently I use plpgsql procedures to implement my own recursion. :-) Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: [HACKERS] Link requirements creep
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I've been testing a new patch and do not see the problem on Fedora 8, so at least that platform's readline seems to be fixed. It broke my FC6 box :-( Yeah, I saw. I'm inclined to wait a day to get a handle on the scope of the problem before trying to choose an appropriate fix. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WITH RECURSIVE patch V0.1
On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote: Zoltan Boszormenyi [EMAIL PROTECTED] writes: Also, it seems there are no infinite recursion detection: # with recursive x(level, parent, child) as ( select 1::integer, * from test_connect_by where parent is null union all select x.level + 1, base.* from test_connect_by as base, x where base.child = x.child ) select * from x; ... it waits and waits and waits ... Well, psql might wait and wait but it's actually receiving rows. A cleverer client should be able to deal with infinite streams of records. That would be a very good thing for libpq (and its descendants) to have :) I think DB2 does produce a warning if there is no clause it can determine will bound the results. But that's not actually reliable. I'd think not, as it's (in some sense) a Halting Problem. It's quite possible to have clauses which will limit the output but not in a way the database can determine. Consider for example a tree-traversal for a binary tree stored in a recursive table reference. The DBA might know that the data contains no loops but the database doesn't. I seem to recall Oracle's implementation can do this traversal on write operations, but maybe that's just their marketing. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New DTrace probes proposal
On Sunday 18 May 2008 03:18:13 Greg Smith wrote: On Sat, 17 May 2008, Robert Lor wrote: I'd like to propose adding the following probes (some of which came from Simon) to 8.4. There's also a big DTrace probe set patch available from OmniTI: https://labs.omniti.com/project-dtrace/trunk/postgresql/ http://labs.omniti.com/trac/project-dtrace/wiki/Applications#PostgreSQL I don't know if you've looked at that before. There's some overlap but many unique and handy probes to each set. I think it would be nice to consider a superset union of the two. I would guess OmniTI would be glad to have their set assimilated into core as well so they don't have to maintain their patch past 8.3; hopefully Theo or Robert will chime in on that. chimeWe've had it in the back of our minds to submit the patch set for 8.4, just hadn't gotten around to it. As we've started to see some 3rd party uptake of the set, it might be better to get something in sooner rather than later, so yes, we'd be happy to see the patch set adopted upstream./chime -- Robert Treat Database Architect http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WITH RECURSIVE patch V0.1
David Fetter [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote: Zoltan Boszormenyi [EMAIL PROTECTED] writes: Also, it seems there are no infinite recursion detection: # with recursive x(level, parent, child) as ( select 1::integer, * from test_connect_by where parent is null union all select x.level + 1, base.* from test_connect_by as base, x where base.child = x.child ) select * from x; ... it waits and waits and waits ... Well, psql might wait and wait but it's actually receiving rows. A cleverer client should be able to deal with infinite streams of records. That would be a very good thing for libpq (and its descendants) to have :) I think you can do it in libpq. In psql you can use \set FETCH_COUNT or somrthing like this (I can't look it up just now) to use a cursor to do this too. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WITH RECURSIVE patch V0.1
This is indeed really cool. I'm sorry I haven't gotten to doing what I promised in this area but I'm glad it's happening anyways. Zoltan Boszormenyi [EMAIL PROTECTED] writes: Can we get the rows in tree order, please? ... After all, I didn't specify any ORDER BY clauses in the base, recursive or the final queries. The standard has a clause to specify depth-first order. However doing a depth-first traversal would necessitate quite a different looking plan and it's far less obvious (to me anyways) how to do it. Also, it seems there are no infinite recursion detection: # with recursive x(level, parent, child) as ( select 1::integer, * from test_connect_by where parent is null union all select x.level + 1, base.* from test_connect_by as base, x where base.child = x.child ) select * from x; ... it waits and waits and waits ... Well, psql might wait and wait but it's actually receiving rows. A cleverer client should be able to deal with infinite streams of records. I think DB2 does produce a warning if there is no clause it can determine will bound the results. But that's not actually reliable. It's quite possible to have clauses which will limit the output but not in a way the database can determine. Consider for example a tree-traversal for a binary tree stored in a recursive table reference. The DBA might know that the data contains no loops but the database doesn't. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
