Re: [HACKERS] knngist patch support

2010-02-10 Thread Ragi Y. Burhum
I have to say that as a 3rd party observer it is quite obvious to understand why the PostgreSQL software is so good - people are very passionate about the work they are doing. However, in this instance, as a by-stander, it seems that there is a lot of energy being spent on pointing fingers. At the

Re: [HACKERS] knngist patch support

2010-02-10 Thread Robert Haas
2010/2/11 Oleg Bartunov : > This is very disgraceful from my point of view and reflects real problem > in scheduling of CF. The patch was submitted Nov 23 2009, discussed and > reworked Nov 25. Long holidays in December-January, probably are reason why > there were no any movement on reviewing the

Re: [HACKERS] knngist patch support

2010-02-10 Thread Tom Lane
Oleg Bartunov writes: > This is very disgraceful from my point of view and reflects real problem > in scheduling of CF. The patch was submitted Nov 23 2009, discussed and > reworked Nov 25. Long holidays in December-January, probably are reason why > there were no any movement on reviewing the pa

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-10 Thread Дмитрий Фефелов
> The only case that I think still has any merit is where you get a > significantly better plan with known parameter values than without. > The projected-cost threshold might be a reasonable approach for > attacking that, ie, if estimated cost of generic plan exceeds X > then take the time to build

Re: [HACKERS] knngist patch support

2010-02-10 Thread Oleg Bartunov
This is very disgraceful from my point of view and reflects real problem in scheduling of CF. The patch was submitted Nov 23 2009, discussed and reworked Nov 25. Long holidays in December-January, probably are reason why there were no any movement on reviewing the patch. People with inspiration

Re: [HACKERS] Confusion over Python drivers

2010-02-10 Thread Andrew McNamara
>> I'd like to see a requirement for the use of PQexecParams() over PQexec() - >> even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy. > >Such a rule seems pretty entirely pointless, unless you have a way to >enforce that the query string passed to the function hasn't been >asse

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-10 Thread Greg Smith
Tom Lane wrote: If you feel that a BSD/MIT license is a must-have for your purposes, you're certainly free to push development of one of the other driver projects instead, and to try to organize some other people to help. I don't believe anyone is trying to funnel all development effort into psyc

Re: [HACKERS] Confusion over Python drivers

2010-02-10 Thread Tom Lane
Andrew McNamara writes: >> That's just a matter of prioritizing the issues. Put the big ones at >> the top, the trivia at the bottom, [...] > I'd like to see a requirement for the use of PQexecParams() over PQexec() - > even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy. S

Re: [HACKERS] knngist patch support

2010-02-10 Thread tomas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 10, 2010 at 04:49:59PM -0800, Ragi Y. Burhum wrote: > Hello, > > I noticed this morning that the k nearest neighbor gist patch > https://commitfest.postgresql.org/action/patch_view?id=230 was still being > considered for inclusion in 9. Sa

Re: [HACKERS] Confusion over Python drivers

2010-02-10 Thread Andrew McNamara
>That's just a matter of prioritizing the issues. Put the big ones at >the top, the trivia at the bottom, [...] I'd like to see a requirement for the use of PQexecParams() over PQexec() - even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy. -- Andrew McNamara, Senior Develo

Re: [HACKERS] Postgres Triggers issue

2010-02-10 Thread Euler Taveira de Oliveira
u235sentinel escreveu: > I'm curious what context you were expecting and which group this should > go to. I've posted similar questions in the other groups and they > seem... lost at times. > What group? AFAICS this question belongs to -general. What about starting to show us the definition of m_

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-10 Thread Greg Smith
Kevin Ar18 wrote: Based on that, I guess my question is what would it have taken to have picked one of BSD/MIT projects and working with those people instead? In other words, what key things affected the decision for psycopg? What areas is it so far ahead in or that would have just been too

Re: [HACKERS] Postgres Triggers issue

2010-02-10 Thread u235sentinel
Tom Lane wrote: u235sentinel writes: I have a strange problem we noticed the other day with triggers. We're running 8.3.3 on Solaris 10 (intel) and have a feed that comes in regularly to populate a table we're working on. The feed works just fine inserting rows however the following trig

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-10 Thread Tom Lane
Bruce Momjian writes: > Can someone explain to me why we only do "delayed binding" for unnamed > prepared queries? It was a way of shoehorning in some driver control over the behavior without the protocol bump that would be involved in adding an actual option to Parse messages.

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-10 Thread Kevin Ar18
> Well, all else being equal we'd certainly prefer a library that was > licensed more like the core Postgres database. However, we don't have > infinite resources, and an LGPL license is not a showstopper (at least > not to the people who seem to be willing to work on this problem). > The attract

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Euler Taveira de Oliveira
Tom Lane escreveu: > I'm still quite dubious about the usefulness, but I could live with this > if someone explains to me how the printout is going to stay within 24x80 > given the inevitable growth in number of configure options ... > AFAICS, we have > 40 configure options. If we want this to fit

Re: [HACKERS] log_error_verbosity function display

2010-02-10 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > Right now, log_error_verbosity displays the source code error location > > in this format: > > > LOCATION: parserOpenTable, parse_relation.c:858 > > > I think it would be clearer to add '()' next to the function name. We > > use '() to display fu

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-10 Thread Tom Lane
Kevin Ar18 writes: > When I first heard about the endeavor, I thought the goal was to take > one or several of the non-copyleft projects, which were rather > unfocused, and work with those teams to produce a really good > implementation for Python. However, as I understand it (based on what > Gre

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-10 Thread Bruce Momjian
Tom Lane wrote: > Robert Haas writes: > > On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen wrote: > >> Periodically re-plan prepared statements on EXECUTE. ?This is also a chance > >> for queries that were being re-planned every time to go back to a generic > >> plan. > > > The most common probl

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-10 Thread Bruce Momjian
Kris Jurka wrote: > > The JDBC driver has two methods of disabling permanently planned prepared > statements: > > 1) Use the version two frontend/backend protocol via adding > protocolVersion=2 to your URL. This interpolates all parameters into > the query on the client side. > > 2) Execute

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 9:17 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera >> wrote: >>> If this doesn't fit in 24x80 maybe we need to find a more compact way to >>> display things. > >> +1.  I wouldn't mind a one-line summary, but a two page summar

Re: [HACKERS] Odd cruft in .psql_history in HEAD

2010-02-10 Thread Tom Lane
Jim Nasby writes: > On Jan 13, 2010, at 9:32 PM, Tom Lane wrote: >> Jim Nasby writes: >>> I noticed odd stuff showing up when I fired up an 8.3 psql after using psql >>> in HEAD. It shows up in .psql_history as well: >> >> Platform? readline version? > This is on snow leopard. FWIW it's still

Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)

2010-02-10 Thread Andres Freund
On Monday 08 February 2010 05:53:23 Robert Haas wrote: > On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera > > wrote: > > Andres Freund escribió: > >> I personally think the fsync on the directory should be added to the > >> stable branches - other opinions? > >> If wanted I can prepare patches for

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Tom Lane
Robert Haas writes: > On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera > wrote: >> If this doesn't fit in 24x80 maybe we need to find a more compact way to >> display things. > +1. I wouldn't mind a one-line summary, but a two page summary seems > like a lot. So it seems there's some consensus

Re: [HACKERS] Postgres Triggers issue

2010-02-10 Thread Tom Lane
u235sentinel writes: > I have a strange problem we noticed the other day with triggers. We're > running 8.3.3 on Solaris 10 (intel) and have a feed that comes in > regularly to populate a table we're working on. The feed works just > fine inserting rows however the following trigger stops the

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-10 Thread Marko Tiikkaja
On 2010-02-11 02:13 +0200, I wrote: > On 2010-02-11 01:58 +0200, Robert Haas wrote: >> I have to admit I've been starting to have a feeling over the last >> couple of days that this patch isn't going to make it for 9.0... but >> obviously I'm in no position to guarantee anything one way or the >>

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-10 Thread Kevin Ar18
I hope people don't mind my asking about this on the list... as I hinted at before, I don't really follow the development of PostgreSQL, I was just interested in the Python driver project that I heard about. Anyways, as I understand it, the current goal is to use psycopg and get it changed to

[HACKERS] knngist patch support

2010-02-10 Thread Ragi Y. Burhum
Hello, I noticed this morning that the k nearest neighbor gist patch https://commitfest.postgresql.org/action/patch_view?id=230 was still being considered for inclusion in 9. Sadly, this feature appears to have been dropped from 9. It seems to me that the functionality this brings is one of the m

Re: [HACKERS] log_error_verbosity function display

2010-02-10 Thread Tom Lane
Bruce Momjian writes: > Right now, log_error_verbosity displays the source code error location > in this format: > LOCATION: parserOpenTable, parse_relation.c:858 > I think it would be clearer to add '()' next to the function name. We > use '() to display function names in our docs and I

Re: [HACKERS] psql tab completion for DO blocks

2010-02-10 Thread Bruce Momjian
Takahiro Itagaki wrote: > > Bruce Momjian wrote: > > > Where are we on this patch? We should at least implement the completion > > for 'LANGUAGE' in 'DO', and use the existing pg_language query for > > completion. I am attaching a patch that does exactly this. > > I don't think we need the pa

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-10 Thread Marko Tiikkaja
On 2010-02-11 01:58 +0200, Robert Haas wrote: > On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja > wrote: >> On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote: >> Ok, what about the following: >> - after planning the original query, standard_planner() goes through >>the list of top-level CTEs an

Re: [HACKERS] Odd cruft in .psql_history in HEAD

2010-02-10 Thread Jim Nasby
On Jan 13, 2010, at 9:32 PM, Tom Lane wrote: > Jim Nasby writes: >> I noticed odd stuff showing up when I fired up an 8.3 psql after using psql >> in HEAD. It shows up in .psql_history as well: > > Platform? readline version? This is on snow leopard. FWIW it's still doing it with today's HEAD.

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja wrote: > On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote: >> On 2010-02-10 23:57 +0200, Tom Lane wrote: >>> Robert Haas writes: If the executor has buried in it the assumption that the snapshot can't change after startup, then does that me

[HACKERS] log_error_verbosity function display

2010-02-10 Thread Bruce Momjian
Right now, log_error_verbosity displays the source code error location in this format: LOCATION: parserOpenTable, parse_relation.c:858 I think it would be clearer to add '()' next to the function name. We use '() to display function names in our docs and I think using '()' would clarify

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-10 Thread Marko Tiikkaja
On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote: > On 2010-02-10 23:57 +0200, Tom Lane wrote: >> Robert Haas writes: >>> If the executor has buried in it the assumption that the snapshot >>> can't change after startup, then does that mean that we need to start >>> up and shut down the executor for

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

2010-02-10 Thread Kurt Harriman
On 2/10/2010 7:12 AM, Tom Lane wrote: Kurt, you seem to be more or less impervious to advice :-(. Thank you for reviewing my patch. It is a rare honor to have my personal qualities reviewed here as well. Since this forum is archived for posterity, I suppose I must point out that I have in fac

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-10 Thread Marko Tiikkaja
On 2010-02-10 23:57 +0200, Tom Lane wrote: > Robert Haas writes: >> If the executor has buried in it the assumption that the snapshot >> can't change after startup, then does that mean that we need to start >> up and shut down the executor for each subquery? > > Yes, I think so. That's the way i

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-10 Thread Tom Lane
Robert Haas writes: > If the executor has buried in it the assumption that the snapshot > can't change after startup, then does that mean that we need to start > up and shut down the executor for each subquery? Yes, I think so. That's the way it's always worked in the past; see for example Porta

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera wrote: > Euler Taveira de Oliveira escribió: >> Alvaro Herrera escreveu: >> > The general idea seems sensible to me.  I can't comment on the >> > specifics. >> > >> +1. A lot of other programs have this summary at the end of configure >> execution. T

Re: [HACKERS] TCP keepalive support for libpq

2010-02-10 Thread daveg
On Tue, Feb 09, 2010 at 09:34:10AM -0500, Andrew Chernow wrote: > Tollef Fog Heen wrote: > >(please Cc me on replies, I am not subscribed) > > > >Hi, > > > >libpq currently does not use TCP keepalives. This is a problem in our > >case where we have some clients waiting for notifies and then the >

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Alvaro Herrera
Euler Taveira de Oliveira escribió: > Alvaro Herrera escreveu: > > The general idea seems sensible to me. I can't comment on the > > specifics. > > > +1. A lot of other programs have this summary at the end of configure > execution. The problem is that PostgreSQL has too many options. Do we want

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Euler Taveira de Oliveira
Alvaro Herrera escreveu: > The general idea seems sensible to me. I can't comment on the > specifics. > +1. A lot of other programs have this summary at the end of configure execution. The problem is that PostgreSQL has too many options. Do we want to list all of them? -- Euler Taveira de Ol

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-10 Thread Marko Tiikkaja
On 2010-02-10 21:59 +0200, Robert Haas wrote: > On Wed, Feb 10, 2010 at 5:05 AM, Marko Tiikkaja > wrote: >> On 2010-02-10 03:20 +0200, Tom Lane wrote: >>> Marko Tiikkaja writes: On 2010-02-10 02:19 +0200, Tom Lane wrote: > You still haven't explained why it's a good idea to change the sn

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 5:05 AM, Marko Tiikkaja wrote: > On 2010-02-10 03:20 +0200, Tom Lane wrote: >> Marko Tiikkaja writes: >>> On 2010-02-10 02:19 +0200, Tom Lane wrote: You still haven't explained why it's a good idea to change the snapshot after the executor has started.  Right at

[HACKERS] Postgres Triggers issue

2010-02-10 Thread u235sentinel
I have a strange problem we noticed the other day with triggers. We're running 8.3.3 on Solaris 10 (intel) and have a feed that comes in regularly to populate a table we're working on. The feed works just fine inserting rows however the following trigger stops the feed until we remove the tri

Re: [HACKERS] [CFReview] Red-Black Tree

2010-02-10 Thread Teodor Sigaev
Hey, but rb_freefunc is still there ... It will be reintroduced when ts_stat will be rewrited to use rbtree One very minor quibble: please make the $PostgreSQL$ lines be just that (i.e. remove everything between the : to the terminating $, keeping the latter) ok -- Teodor Sigaev

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 2:16 PM, Alvaro Herrera wrote: > Maybe you didn't type it, but it came from elsewhere?  Maybe you're > inheriting settings from some environment variable, or a file?  Maybe > you're eval'ing pg_config --configure? Yeah, could be. > The general idea seems sensible to me.  

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Alvaro Herrera
Robert Haas escribió: > On Wed, Feb 10, 2010 at 12:01 PM, Priit Laes wrote: > >> Also, it's quite unclear which items deserve a place in the list. > >> If it's just to repeat what was in the configure command-line, what > >> is the value of that? > > > > It might avoid the 'UU, I forgot to

[HACKERS] I still didn't get how tsquery is internally

2010-02-10 Thread Ivan Sergio Borgonovo
I've been working on this http://pgsql.privatepaste.com/2a81432f4f for 8.3 (there should be some comments to port it to 8.4). tsvector_tsquery_size works as expected. But whatever I pass to the function I get an empty tsquery. Yet no memory allocation problem or hang etc... just an empty vector,

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 12:01 PM, Priit Laes wrote: >> Also, it's quite unclear which items deserve a place in the list. >> If it's just to repeat what was in the configure command-line, what >> is the value of that? > > It might avoid the 'UU, I forgot to enable python support.', > after

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 12:08 PM, Alvaro Herrera wrote: > Robert Haas escribió: >> On Wed, Feb 10, 2010 at 11:58 AM, Alvaro Herrera >> wrote: > >> > Is Redhat's Visual Explain still alive?  And what about Tom Raney's stuff? >> >> The core of Tom Raney's work was not so much the EXPLAIN format per

Re: [HACKERS] [CFReview] Red-Black Tree

2010-02-10 Thread Robert Haas
2010/2/10 Teodor Sigaev : >> So suppose at this point that step is the largest integer that can be >> represented... >>> >>> !       step ++; >> >> Boom. >>> >>> !       step>>= 1; > > step>>= 1; > step ++' > > Unboom? Yeah, that'll work. >>> ! >>> !       while(step>  0) { >>> !               in

Re: [HACKERS] [CFReview] Red-Black Tree

2010-02-10 Thread Alvaro Herrera
Teodor Sigaev escribió: > Also, rb_free is removed per Tom's comment. Can I commit the patch? Hey, but rb_freefunc is still there ... One very minor quibble: please make the $PostgreSQL$ lines be just that (i.e. remove everything between the : to the terminating $, keeping the latter) -- Alva

Re: [HACKERS] [CFReview] Red-Black Tree

2010-02-10 Thread Teodor Sigaev
So suppose at this point that step is the largest integer that can be represented... ! step ++; Boom. ! step>>= 1; step>>= 1; step ++' Unboom? ! ! while(step> 0) { ! int i; ! for (i = step-1; i< nentry; i += 2 * step) And similarly here...

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

2010-02-10 Thread Leonardo F
>Perhaps you could supply a .sql file containing a testcase > illustrating the performance benefits you tested with your patch Sure. Attached the updated patch (should solve a bug) and a script. The sql scripts generates a 2M rows table ("orig"); then the table is copied and the copy clustered

Re: [HACKERS] synchronized snapshots

2010-02-10 Thread Heikki Linnakangas
Markus Wanner wrote: > On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland > wrote: >> http://www.postgresql.org/docs/8.4/static/backup-dump.html already >> states about pg_dump: "In particular, it must have read access to all >> tables that you want to back up, so in practice you almost always ha

Re: [HACKERS] Parameter name standby_mode

2010-02-10 Thread Joachim Wieland
On Wed, Feb 10, 2010 at 12:16 PM, Heikki Linnakangas wrote: > If they want to implement the warm standby using the (new) built-in > logic to keep retrying restore_command, they would set > standby_mode='on'. standby_mode='on' doesn't imply streaming replication. > > If you want to use pg_standby o

Re: [HACKERS] synchronized snapshots

2010-02-10 Thread Markus Wanner
Hi Joachim, On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland wrote: http://www.postgresql.org/docs/8.4/static/backup-dump.html already states about pg_dump: "In particular, it must have read access to all tables that you want to back up, so in practice you almost always have to run it as a d

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane escribió: >> ... It would be >> really nice if we could get some feedback on the non-text formats >> *before* they're set in stone. > Is Redhat's Visual Explain still alive? And what about Tom Raney's stuff? Visual Explain is dead as far as Red Hat is concerne

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Ross J. Reedstrom
On Wed, Feb 10, 2010 at 07:01:19PM +0200, Priit Laes wrote: > > It might avoid the 'UU, I forgot to enable python support.', > after you have waited a while for the build to finish... > +1 from me, for that very reason! Ross -- Ross Reedstrom, Ph.D. reed

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Priit Laes
Ühel kenal päeval, K, 2010-02-10 kell 10:39, kirjutas Tom Lane: > Priit Laes writes: > > This patch enables showing configure status at the end of ./configure > > run and thus makes ./configure process a bit easier to follow (in the > > sense of what features are actually enabled). > > I don't th

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Alvaro Herrera
Robert Haas escribió: > On Wed, Feb 10, 2010 at 11:58 AM, Alvaro Herrera > wrote: > > Is Redhat's Visual Explain still alive?  And what about Tom Raney's stuff? > > The core of Tom Raney's work was not so much the EXPLAIN format per se > (which is really mooted by the changes already made in CVS

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 11:58 AM, Alvaro Herrera wrote: > Tom Lane escribió: >> Dave Page writes: >> > On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas wrote: >> >> On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote: >> >>> We can still hope that some feedback comes in during beta. >> >> >> I'm not op

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Alvaro Herrera
Tom Lane escribió: > Dave Page writes: > > On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas wrote: > >> On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote: > >>> We can still hope that some feedback comes in during beta. > > >> I'm not opposed to that in principal, but in practice the PGadmin > >> fol

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Dave Page
On Wed, Feb 10, 2010 at 4:50 PM, Tom Lane wrote: > Dave Page writes: >> On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas wrote: >>> On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote: We can still hope that some feedback comes in during beta. > >>> I'm not opposed to that in principal, but in pra

Re: [HACKERS] pg_restore --single-transaction and --clean

2010-02-10 Thread Alvaro Herrera
Tom Lane escribió: > Alvaro Herrera writes: > > Kevin Grittner escribi�: > >> Robert Haas wrote: > > Tom Lane wrote: > We try to avoid using nonstandard SQL in dumps. > > >>> How often do we succeed? It seems unlikely that our dumps would > >>> be restorable into any other database. > >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

2010-02-10 Thread Heikki Linnakangas
Aidan Van Dyk wrote: > * Heikki Linnakangas [100210 02:33]: > >> Hmm, so after running restore_command, check the file size and if it's >> too short, treat it the same as if restore_command returned non-zero? >> And it will be retried on the next iteration. Works for me, though OTOH >> it will t

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Tom Lane
Dave Page writes: > On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas wrote: >> On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote: >>> We can still hope that some feedback comes in during beta. >> I'm not opposed to that in principal, but in practice the PGadmin >> folks may not like us very much if w

Re: [HACKERS] pg_restore --single-transaction and --clean

2010-02-10 Thread Tom Lane
Alvaro Herrera writes: > Kevin Grittner escribió: >> Robert Haas wrote: > Tom Lane wrote: We try to avoid using nonstandard SQL in dumps. >>> How often do we succeed? It seems unlikely that our dumps would >>> be restorable into any other database. >> When we were running in a mixed envi

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Alvaro Herrera
Robert Haas escribió: > On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote: > > Robert Haas writes: > >> I sort of assumed we might get some feedback from pgadmin or other > >> tool writers between the time this was committed six months ago and > >> now, but I haven't seen a single message from anyo

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Dave Page
On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas wrote: > On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote: >> Robert Haas writes: >>> I sort of assumed we might get some feedback from pgadmin or other >>> tool writers between the time this was committed six months ago and >>> now, but I haven't seen

Re: [HACKERS] pg_restore --single-transaction and --clean

2010-02-10 Thread Alvaro Herrera
Kevin Grittner escribió: > Robert Haas wrote: > > Tom Lane wrote: > > >> We try to avoid using nonstandard SQL in dumps. > > > > How often do we succeed? It seems unlikely that our dumps would > > be restorable into any other database. > > When we were running in a mixed environment we had

Re: [HACKERS] pg_restore --single-transaction and --clean

2010-02-10 Thread Kevin Grittner
Robert Haas wrote: > Tom Lane wrote: >> We try to avoid using nonstandard SQL in dumps. > > How often do we succeed? It seems unlikely that our dumps would > be restorable into any other database. When we were running in a mixed environment we had several occasions where it was useful to fe

Re: [HACKERS] pg_restore --single-transaction and --clean

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 10:16 AM, Tom Lane wrote: > Takahiro Itagaki writes: >> Is it a TODO item to replace "DROP" into "DROP IF EXISTS" >> for cleanup commands in pg_restore? > > No.  We try to avoid using nonstandard SQL in dumps. How often do we succeed? It seems unlikely that our dumps wou

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote: > Robert Haas writes: >> I sort of assumed we might get some feedback from pgadmin or other >> tool writers between the time this was committed six months ago and >> now, but I haven't seen a single message from anyone who has actually >> tried to

Re: [HACKERS] patch to implement ECPG side tracing / tracking ...

2010-02-10 Thread Alvaro Herrera
Hans-Jürgen Schönig wrote: > hi, > > this patch implements SQL side tracing / tracking of statements and > statement execution times. > it is primarily intended to allow programmers to gather information > about the runtime behavior of a program and to figure out easily > where the bottlenecks are

Re: [HACKERS] buildfarm breakage

2010-02-10 Thread Tom Lane
Magnus Hagander writes: > If someone didn't notice, I have applied that fix and it appears to > have solved it. ... and there was much rejoicing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Tom Lane
Priit Laes writes: > This patch enables showing configure status at the end of ./configure > run and thus makes ./configure process a bit easier to follow (in the > sense of what features are actually enabled). I don't think anybody actually reads configure's output anyway, so I'm not sure about

Re: [HACKERS] buildfarm breakage

2010-02-10 Thread Magnus Hagander
2010/2/9 Magnus Hagander : > On Tue, Feb 9, 2010 at 17:11, Tom Lane wrote: >> Magnus Hagander writes: >>> Here's a patch that "fixes" this. I put it locally for the radius >>> authentication for now, since we don't use this anywhere else. Should >>> we put this in /port/ somewhere, or is this goo

Re: [HACKERS] pg_restore --single-transaction and --clean

2010-02-10 Thread Tom Lane
Takahiro Itagaki writes: > Is it a TODO item to replace "DROP" into "DROP IF EXISTS" > for cleanup commands in pg_restore? No. We try to avoid using nonstandard SQL in dumps. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

2010-02-10 Thread Tom Lane
Kurt Harriman writes: > On 1/19/2010 8:01 AM, Peter Eisentraut wrote: >> One principle that I suppose should have been made more explicit is that >> -- in my mind -- we should avoid littering our code with nonstandard >> constructs in place of standard constructs. > Everyone seems to hate the nam

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Tom Lane
Robert Haas writes: > I sort of assumed we might get some feedback from pgadmin or other > tool writers between the time this was committed six months ago and > now, but I haven't seen a single message from anyone who has actually > tried to write a tool. As you imply, I think it will be very har

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 9:09 AM, Greg Stark wrote: > Perhaps this is just a terminology difference but it seems > ridiculously *narrow* to me: Try "select * from pg_class". >> Or as I said at the time... nobody liked anything about the patch >> except that they didn't have to write it. > > I kno

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Greg Stark
On Wed, Feb 10, 2010 at 1:26 PM, Robert Haas wrote: > For example, EXPLAIN (VERBOSE, FORMAT JSON) is often ridiculously > wide because each output list is printed on a single line. Perhaps this is just a terminology difference but it seems ridiculously *narrow* to me: QUERY PLAN -

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

2010-02-10 Thread Leonardo F
I think I've found the problem: tuple->t_data wasn't at HEAPTUPLESIZE distance from tuple. I guess the code makes that assumption somewhere, so I had to do: tuple->t_data = (HeapTupleHeader) ((char *) tuple + HEAPTUPLESIZE); Now that

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

2010-02-10 Thread Aidan Van Dyk
* Heikki Linnakangas [100210 02:33]: > Hmm, so after running restore_command, check the file size and if it's > too short, treat it the same as if restore_command returned non-zero? > And it will be retried on the next iteration. Works for me, though OTOH > it will then fail to complain about a

[HACKERS] [PATCH] Output configuration status after ./configure run.

2010-02-10 Thread Priit Laes
Hi! This patch enables showing configure status at the end of ./configure run and thus makes ./configure process a bit easier to follow (in the sense of what features are actually enabled). Päikest, Priit From c6ab747e581c7ebeb954b2ccb4dbd932e1a61de7 Mon Sep 17 00:00:00 2001 From: Priit Laes Dat

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Robert Haas
On Wed, Feb 10, 2010 at 5:39 AM, Greg Stark wrote: > On Wed, Feb 10, 2010 at 3:59 AM, Robert Haas wrote: >> Yes.  We could add every bell and whistle imaginable to the text >> format and it still would not begin to approach the verbosity of the >> machine-readable formats.  Have you looked at the

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

2010-02-10 Thread Leonardo F
> I think you're confusing HeapTuple and HeapTupleHeader. SortTuple->tuple > field should point to a HeapTupleHeader, not a HeapTuple. Mmh, I don't get it: that would mean I might be using more info than required, but I still don't understand why it's not working... at the end, CLUSTER is going

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

2010-02-10 Thread Heikki Linnakangas
Leonardo F wrote: > static void > writetup_rawheap(Tuplesortstate *state, int tapenum, SortTuple *stup) > { > HeapTupletuple = (HeapTuple) stup->tuple; I think you're confusing HeapTuple and HeapTupleHeader. SortTuple->tuple field should point to a HeapTupleHeader, not a HeapTuple. The right

Re: [HACKERS] About psycopg2 (by its author)

2010-02-10 Thread Federico Di Gregorio
On 09/02/2010 23:37, Greg Smith wrote: [snip] >> So the logical choice is plain LGPL3. I am open to motivated >> suggestions about other >> licenses but I'll ignore such crap as "BSD is more open than LGPL". >> > > I agree with your general logic and while I can't speak for everyone, I > would

Re: [HACKERS] Parameter name standby_mode

2010-02-10 Thread Heikki Linnakangas
Joachim Wieland wrote: > We want to teach people that Hot Standby and Streaming Replication are > two different features. I'm not sure about that, actually. Now that they're both in the tree, they work nicely together and many users will think of them as one. > However, Streaming Replication call

[HACKERS] Parameter name standby_mode

2010-02-10 Thread Joachim Wieland
We want to teach people that Hot Standby and Streaming Replication are two different features. However, Streaming Replication calls its main parameter "standby_mode" which reminds more of Hot Standby than of Streaming Replication. People could also run a warm standby without streaming replication,

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-10 Thread Greg Stark
On Wed, Feb 10, 2010 at 3:59 AM, Robert Haas wrote: > Yes.  We could add every bell and whistle imaginable to the text > format and it still would not begin to approach the verbosity of the > machine-readable formats.  Have you looked at them on a complex plan? > They are really, really long, and

Re: [HACKERS] synchronized snapshots

2010-02-10 Thread Joachim Wieland
Hi Markus, On Fri, Feb 5, 2010 at 6:29 PM, Markus Wanner wrote: > > So, let's first concentrate on the intended use case: allowing parallel > pg_dump. To me it seems like a pragmatic and quick solution, however, I'm > not sure if requiring superuser privileges is acceptable. http://www.postgresq

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

2010-02-10 Thread Kurt Harriman
On 12/16/2009 8:21 AM, Tom Lane wrote: I would only suggest that the cleanest coding would be #ifdef USE_INLINE static inline foo(...) ... #else ... non-inline definition of foo #endif ie, go ahead and rely on autoconf's definition (if any) of "inline

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-10 Thread Marko Tiikkaja
On 2010-02-10 03:20 +0200, Tom Lane wrote: > Marko Tiikkaja writes: >> On 2010-02-10 02:19 +0200, Tom Lane wrote: >>> You still haven't explained why it's a good idea to change the snapshot >>> after the executor has started. Right at the moment I'm prepared to >>> reject the patch on that ground

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

2010-02-10 Thread Kurt Harriman
On 12/16/2009 8:40 AM, Tom Lane wrote: Alvaro Herrera writes: IIRC Kurt was also on about getting rid of some ugly macros that could instead be coded as inline functions (fastgetattr for example) I'd just bounce that as useless activity. If they are macros now, and work, the only possible ef

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

2010-02-10 Thread Kurt Harriman
On 1/19/2010 8:01 AM, Peter Eisentraut wrote: On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote: On 1/18/2010 11:48 PM, Peter Eisentraut wrote: We have some existing inline functions in .c files. These can be more complicated, so it might be ok if the compiler decides to leave them out-of-

[HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

2010-02-10 Thread Fujii Masao
On Wed, Feb 10, 2010 at 4:32 PM, Heikki Linnakangas wrote: > Hmm, so after running restore_command, check the file size and if it's > too short, treat it the same as if restore_command returned non-zero? Yes, only in standby mode case. OTOH I think that normal archive recovery should treat it as

  1   2   >