[HACKERS] DatumGetInetP buggy

2011-11-08 Thread Boszormenyi Zoltan
Hi, I wanted to do some transformation on an inet value from an SPI-using function. The inet Datum passed from SPI_getbinval() to the values array in heap_form_tuple() obviously gives good data to the frontend. When I use DatumGetInetP() on the Datum, the structure passed to me is corrupt:

Re: [HACKERS] DatumGetInetP buggy

2011-11-08 Thread Heikki Linnakangas
On 08.11.2011 11:22, Boszormenyi Zoltan wrote: Hi, I wanted to do some transformation on an inet value from an SPI-using function. The inet Datum passed from SPI_getbinval() to the values array in heap_form_tuple() obviously gives good data to the frontend. When I use DatumGetInetP() on the

Re: [HACKERS] heap vacuum cleanup locks

2011-11-08 Thread Robert Haas
On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs si...@2ndquadrant.com wrote: On Tue, Nov 8, 2011 at 2:54 AM, Robert Haas robertmh...@gmail.com wrote: It would still be nice to fix the case where we need to freeze a tuple that is on a page someone else has pinned, but I don't have any good ideas

[HACKERS] Disable OpenSSL compression

2011-11-08 Thread Albe Laurenz
I ran into a performance problem described in this thread: http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php continued here: http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php OpenSSL compresses data by default, and that causes a performance penalty of 100%

Re: [HACKERS] proposal: psql concise mode

2011-11-08 Thread Alvaro Herrera
Excerpts from Robert Haas's message of mar nov 08 01:25:31 -0300 2011: But I can't help feeling that as we continue to add more features, we've eventually going to end up with our backs to the wall. Not sure what to do about that, but... What I've imagined for a long time is psql being able

Re: [HACKERS] synchronous commit vs. hint bits

2011-11-08 Thread Robert Haas
On Tue, Nov 8, 2011 at 1:59 AM, Simon Riggs si...@2ndquadrant.com wrote: Please continue to expect that, I just haven't finished it yet... OK. So here's the deal: this is an effective, mostly automatic solution to the performance problem noted in the original post. For example, at 32 clients,

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Magnus Hagander
On Tue, Nov 8, 2011 at 14:59, Albe Laurenz laurenz.a...@wien.gv.at wrote: I ran into a performance problem described in this thread: http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php continued here: http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Martin Pihlak
On 11/08/2011 03:59 PM, Albe Laurenz wrote: If there are concerns about that, maybe a GUC variable like ssl_compression (defaulting to off) would be a solution. I'd vote for a libpq connect option instead. Something like sslcompress=yes|no accompanied by PGSSLCOMPRESS environment variable.

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Marko Kreen
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote: It is possible that this could cause a performance regression for people who SELECT lots of compressible data over really slow network connections, but is that a realistic scenario? Yes, it's a realistic scenario.

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Tom Lane
Marko Kreen mark...@gmail.com writes: On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote: It is possible that this could cause a performance regression for people who SELECT lots of compressible data over really slow network connections, but is that a realistic

Re: [HACKERS] ProcArrayLock contention

2011-11-08 Thread Robert Haas
On Tue, Nov 8, 2011 at 2:24 AM, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: latestCompletedXid got backward due to concurrent updates and it fooled TransactionIdIsInProgress? Ah ha! I bet that's it. I think this could be avoided by a more sophisticated locking scheme. Instead of waking up

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Dave Page
On Tue, Nov 8, 2011 at 2:34 PM, Tom Lane t...@sss.pgh.pa.us wrote: The fact of the matter is that in most situations where you want SSL, ie links across insecure WANs, compression is a win.  Testing a local connection, as you seem to have done, is just about 100% irrelevant to performance in

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Andrew Dunstan
On 11/08/2011 09:34 AM, Tom Lane wrote: Marko Kreenmark...@gmail.com writes: On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenzlaurenz.a...@wien.gv.at wrote: It is possible that this could cause a performance regression for people who SELECT lots of compressible data over really slow network

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: On 11/08/2011 09:34 AM, Tom Lane wrote: There might be some argument for providing a client option to disable compression, but it should not be forced, and it shouldn't even be the default. But before adding YA connection option, I'd want to see some

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Robert Haas
On Tue, Nov 8, 2011 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: On 11/08/2011 09:34 AM, Tom Lane wrote: There might be some argument for providing a client option to disable compression, but it should not be forced, and it shouldn't even be the

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Marko Kreen
On Tue, Nov 8, 2011 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote: Marko Kreen mark...@gmail.com writes: On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote: It is possible that this could cause a performance regression for people who SELECT lots of compressible data

Re: [HACKERS] DatumGetInetP buggy

2011-11-08 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Hmm, it seems to be intentional, but I agree it's very much contrary to the usual convention that DatumGetXXXP() returns a detoasted and depacked datum. I think we should change it. I propose the attached patch. It changes

Re: [HACKERS] heap vacuum cleanup locks

2011-11-08 Thread Simon Riggs
On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas robertmh...@gmail.com wrote: But there's an efficiency argument against doing it that way.  First, if we release the pin then we'll have to reacquire the buffer, which means taking and releasing a BufMappingLock, the buffer header spinlock, and the

Re: [HACKERS] proposal: psql concise mode

2011-11-08 Thread Dickson S. Guedes
2011/11/8 Alvaro Herrera alvhe...@commandprompt.com: What I've imagined for a long time is psql being able to display each row in more than one line; for example something like \df                       Listado de funciones  Esquema |      Nombre       | Tipo de dato de salida | Tipo  

Re: [HACKERS] heap vacuum cleanup locks

2011-11-08 Thread Robert Haas
On Tue, Nov 8, 2011 at 10:08 AM, Simon Riggs si...@2ndquadrant.com wrote: On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas robertmh...@gmail.com wrote: But there's an efficiency argument against doing it that way.  First, if we release the pin then we'll have to reacquire the buffer, which means

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Albe Laurenz
Tom Lane wrote: I distinctly recall us getting bashed a few years ago because there wasn't any convenient way to turn SSL compression *on*. Now that SSL finally does the sane thing by default, you want to turn it off? The fact of the matter is that in most situations where you want SSL, ie

Re: [HACKERS] heap vacuum cleanup locks

2011-11-08 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs si...@2ndquadrant.com wrote: I think we need to avoid long pin hold times generally. In the case of a suspended sequential scan, which is the case where this has most recently bitten me on a production

Re: [HACKERS] proposal: psql concise mode

2011-11-08 Thread Alvaro Herrera
Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011: Isn't that what pagers like 'less' and 'more' do already? May be we could provide a pager more specific to psql output as a contrib or extension. Well, now that you mention it, all pagers I know are line-based. If

Re: [HACKERS] heap vacuum cleanup locks

2011-11-08 Thread Robert Haas
On Tue, Nov 8, 2011 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us wrote: It strikes me that the only case where vacuum now has to wait is where it needs to freeze an old XID.  Couldn't it do that without insisting on exclusive access?  We only need exclusive access if we're going to move data

Re: [HACKERS] heap vacuum cleanup locks

2011-11-08 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: Interesting idea. I think in general we insist that you must have a buffer content lock to inspect the tuple visibility info, in which case that would be safe. But I'm not sure we do that absolutely everywhere. For instance, just last night I

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Albe Laurenz
Tom Lane wrote: There might be some argument for providing a client option to disable compression, but it should not be forced, and it shouldn't even be the default. But before adding YA connection option, I'd want to see some evidence that it's useful over non-local connections. Here are

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread k...@rice.edu
On Tue, Nov 08, 2011 at 04:59:02PM +0100, Albe Laurenz wrote: Tom Lane wrote: There might be some argument for providing a client option to disable compression, but it should not be forced, and it shouldn't even be the default. But before adding YA connection option, I'd want to see some

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread k...@rice.edu
On Tue, Nov 08, 2011 at 04:19:02PM +0100, Albe Laurenz wrote: Tom Lane wrote: I distinctly recall us getting bashed a few years ago because there wasn't any convenient way to turn SSL compression *on*. Now that SSL finally does the sane thing by default, you want to turn it off? The

Re: [HACKERS] heap vacuum cleanup locks

2011-11-08 Thread Robert Haas
On Tue, Nov 8, 2011 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Interesting idea.  I think in general we insist that you must have a buffer content lock to inspect the tuple visibility info, in which case that would be safe.  But I'm not sure we do

Re: [HACKERS] lexemes in prefix search going through dictionary modifications

2011-11-08 Thread Sushant Sinha
I think there is a need to provide prefix search to bypass dictionaries.If you folks think that there is some credibility to such a need then I can think about implementing it. How about an operator like :# that does this? The :* will continue to mean the same as currently. -Sushant. On Tue,

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Christopher Browne
On Tue, Nov 8, 2011 at 11:06 AM, k...@rice.edu k...@rice.edu wrote: I think that JDBC and Npgsql should also support disabling compression. That's the *real* problem here... You're quite right that if we allow controlling this on the libpq side, it is surely desirable to allow controlling this

Re: [HACKERS] [v9.2] Object access hooks with arguments support (v1)

2011-11-08 Thread Robert Haas
On Mon, Nov 7, 2011 at 12:20 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote: If sepgsql would apply permission checks db_procedure:{install} on the OAT_POST_CREATE hook based on the funcion-oid within new entry of system catalog, we can relocate OAT_PREP_CREATE hook more conceptually right place,

Re: [HACKERS] plpython extension control files installation

2011-11-08 Thread Robert Haas
On Sat, Nov 5, 2011 at 10:42 AM, Peter Eisentraut pete...@gmx.net wrote: We only build the language plpython2u or plpython3u, not both, in any build, but we always install the extension control files for all variants.  Is there a reason for this, or just an oversight? Sounds like an oversight.

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Jeroen Vermeulen
On 2011-11-08 22:59, Albe Laurenz wrote: In addition to the oprofile data I collected three times: - the duration as shown in the server log - the duration as shown by \timing - the duration of the psql command as measured by time [...] I think this makes a good case for disabling

Re: [HACKERS] proposal: psql concise mode

2011-11-08 Thread Dickson S. Guedes
2011/11/8 Alvaro Herrera alvhe...@commandprompt.com: Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011: Isn't that what pagers like 'less' and 'more' do already? May be we could provide a pager more specific to psql output as a contrib or extension. Well, now that

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Tom Lane
Jeroen Vermeulen j...@xs4all.nl writes: Another reason why I believe compression is often used with encryption is to maximize information content per byte of data: harder to guess, harder to crack. Would that matter? Yes, it would. There's a reason why the OpenSSL default is what it is.

Re: [HACKERS] DatumGetInetP buggy

2011-11-08 Thread Heikki Linnakangas
On 08.11.2011 17:06, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes: Hmm, it seems to be intentional, but I agree it's very much contrary to the usual convention that DatumGetXXXP() returns a detoasted and depacked datum. I think we should change it. I propose the

[HACKERS] ERROR: MergeAppend child's targetlist doesn't match MergeAppend

2011-11-08 Thread Teodor Sigaev
Hi! I ran into a problem with PG 9.1 and bug is observed even in master. After simplifying a query (original was 9Kb long!) it's possible to reproduce it easily: CREATE TABLE wow (t1 text, t2 text); CREATE INDEX idx ON wow (t1,t2); SET enable_seqscan=off; SET enable_bitmapscan=off; EXPLAIN

Re: [HACKERS] Measuring relation free space

2011-11-08 Thread Greg Smith
On 11/06/2011 11:55 PM, Mark Kirkwood wrote: I am guessing (at this point very much guessing) that pg_freespace map may return its data faster, as pageinspect is gonna have to grovel through all the pages for itself (whereas pg_freespacemap relies on using info from the ... free space map

Re: [HACKERS] DatumGetInetP buggy

2011-11-08 Thread Boszormenyi Zoltan
2011-11-08 18:53 keltezéssel, Heikki Linnakangas írta: On 08.11.2011 17:06, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes: Hmm, it seems to be intentional, but I agree it's very much contrary to the usual convention that DatumGetXXXP() returns a detoasted and

Re: [HACKERS] Disable OpenSSL compression

2011-11-08 Thread Stephen Frost
Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: The fact of the matter is that in most situations where you want SSL, ie links across insecure WANs, compression is a win. Testing a local connection, as you seem to have done, is just about 100% irrelevant to performance in the real world. I'm

Re: [HACKERS] ERROR: MergeAppend child's targetlist doesn't match MergeAppend

2011-11-08 Thread Tom Lane
Teodor Sigaev teo...@sigaev.ru writes: SELECT t1, t2 FROM ( SELECT t1, t2 FROM wow UNION ALL SELECT 'a', 'a' FROM wow ) t ORDER BY t1, t2; Hmm, interesting. It's seems to me that check in create_merge_append_plan() is too restrictive: if (memcmp(sortColIdx,

Re: [HACKERS] unite recovery.conf and postgresql.conf

2011-11-08 Thread Josh Berkus
configuration data somewhere else, but we really need to be able to tell the difference between starting PITR, continuing PITR after a mid-recovery crash, and finished PITR, up and running normally. A GUC is not a good way to do that. Does a GUC make sense to you for how to handle

[HACKERS] 9.1.2 ?

2011-11-08 Thread Greg Jaskiewicz
Given the amount of fixes that went into the branch, and importance of them - when can we expect 9.1.2 to be released officially ? 9.1.1 was stamped on 22nd of September. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] DatumGetInetP buggy

2011-11-08 Thread Heikki Linnakangas
On 08.11.2011 20:46, Boszormenyi Zoltan wrote: 2011-11-08 18:53 keltezéssel, Heikki Linnakangas írta: What do people think of backpatching this? I'm inclined to backpatch, on the grounds that the macro that detoasts and depacks should always work (ie. after this patch), even if the depacking

[HACKERS] Releasing an alpha for CF2

2011-11-08 Thread Josh Berkus
Hackers, I'd really like us to release an alpha version based on the finished CF2. There have been a number of major features added to PostgreSQL prior to this CF -- including Haas's performance improvements and range types -- which we really want at least some users to test early. Would it be

Re: [HACKERS] pl/python custom datatype parsers

2011-11-08 Thread Andrew Dunstan
On 03/01/2011 11:50 AM, Peter Eisentraut wrote: On fre, 2011-02-11 at 16:49 +0100, Jan Urbański wrote: I believe it's (b). But as we don't have time for that discussion that late in the release cycle, I think we need to consider it identical to (c). As I previously mentioned, I think that

Re: [HACKERS] Measuring relation free space

2011-11-08 Thread Jaime Casanova
On Sun, Nov 6, 2011 at 5:38 AM, Magnus Hagander mag...@hagander.net wrote: Looks pretty useful. thanks for the review, attached is a new version of it One quick stylistic comment - we don't generally use * 1.0 to turn an int into a double - just use a cast. ok Hooking into a ring

[HACKERS] Materialized views

2011-11-08 Thread Kevin Grittner
This is the time of year when the Wisconsin Courts formalize their annual plan for where people will be spending the bulk of their time in the coming year. Two years ago at this time, managers decided that serializable transactions were a big enough issue to justify assigning about half of my

Re: [HACKERS] Hot Backup with rsync fails at pg_clog if under load

2011-11-08 Thread Greg Smith
I was curious if anyone running into these problems has gotten a chance to test the 3 fixes committed here. It sounded like Linas even had a repeatable test case? For easier reference the commits are:

Re: [HACKERS] Releasing an alpha for CF2

2011-11-08 Thread Alexander Korotkov
On Wed, Nov 9, 2011 at 12:56 AM, Josh Berkus j...@agliodbs.com wrote: I'd really like us to release an alpha version based on the finished CF2. There have been a number of major features added to PostgreSQL prior to this CF -- including Haas's performance improvements and range types --

Re: [HACKERS] Materialized views

2011-11-08 Thread Thom Brown
On 8 November 2011 21:23, Kevin Grittner kevin.gritt...@wicourts.gov wrote: This is the time of year when the Wisconsin Courts formalize their annual plan for where people will be spending the bulk of their time in the coming year.  Two years ago at this time, managers decided that

[HACKERS] Misleading CREATE TABLE error

2011-11-08 Thread Thom Brown
Hi, I found the following error message misleading: test=# create table cows2 (LIKE cows); ERROR: inherited relation cows is not a table STATEMENT: create table cows2 (LIKE cows); I'm not trying to inherit a relation, I'm trying to base a table on it. As it happens, cows is a foreign table,

Re: [HACKERS] Measuring relation free space

2011-11-08 Thread Robert Treat
On Tue, Nov 8, 2011 at 1:07 PM, Greg Smith g...@2ndquadrant.com wrote: On 11/06/2011 11:55 PM, Mark Kirkwood wrote: I am guessing (at this point very much guessing) that pg_freespace map may return its data faster, as pageinspect is gonna have to grovel through all the pages for itself

Re: [HACKERS] Releasing an alpha for CF2

2011-11-08 Thread Josh Berkus
Alexander, People trying range types are likely to try indexes on them. GiST on range types implementation in head have some limitations: ... it's an alpha. There will always be one more patch. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing

Re: [HACKERS] Materialized views

2011-11-08 Thread Josh Berkus
On 11/8/11 1:23 PM, Kevin Grittner wrote: So the question is, would a patch which does the first two without the third be accepted by the community? AFAIC, yes. For that matter, Part 3 is useful without parts 1 and 2, if someone wanted to work on that. I recall some academic work on

Re: [HACKERS] Materialized views

2011-11-08 Thread Greg Jaskiewicz
On 8 Nov 2011, at 21:23, Kevin Grittner wrote: This is the time of year when the Wisconsin Courts formalize their annual plan for where people will be spending the bulk of their time in the coming year. Two years ago at this time, managers decided that serializable transactions were a big

Re: [HACKERS] Materialized views

2011-11-08 Thread Stephen Frost
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote: So the question is, would a patch which does the first two without the third be accepted by the community? I'm about 99% sure the answer to that is 'yes'. Are you thinking of having a background scheduler which handles the updating of

Re: [HACKERS] Materialized views

2011-11-08 Thread Kevin Grittner
Stephen Frost sfr...@snowman.net wrote: Are you thinking of having a background scheduler which handles the updating of schedule-driven (instead of trigger-driven) MVs..? I'm trying not to get to far into discussing design in advance of reviewing previous work and any papers on the topic.

Re: [HACKERS] Materialized views

2011-11-08 Thread David E. Wheeler
On Nov 8, 2011, at 2:54 PM, Stephen Frost wrote: So the question is, would a patch which does the first two without the third be accepted by the community? +1 Definitely. I'm about 99% sure the answer to that is 'yes'. Are you thinking of having a background scheduler which handles the

Re: [HACKERS] Materialized views

2011-11-08 Thread Josh Berkus
I'm about 99% sure the answer to that is 'yes'. Are you thinking of having a background scheduler which handles the updating of schedule-driven (instead of trigger-driven) MVs..? Not to try to feature-creep this on you, but you might consider how a new backend process which handles

Re: [HACKERS] ERROR: MergeAppend child's targetlist doesn't match MergeAppend

2011-11-08 Thread Tom Lane
I wrote: Not immediately sure what to do about this. The quick-and-dirty fix would be to only apply add_child_rel_equivalences to simple inheritance child relations, for which the added items must be Vars and must be different (which is what that code is expecting). Seems like a bit of a

Re: [HACKERS] Materialized views

2011-11-08 Thread David E. Wheeler
On Nov 8, 2011, at 3:25 PM, Josh Berkus wrote: I'm about 99% sure the answer to that is 'yes'. Are you thinking of having a background scheduler which handles the updating of schedule-driven (instead of trigger-driven) MVs..? Not to try to feature-creep this on you, but you might consider

Re: [HACKERS] Measuring relation free space

2011-11-08 Thread Greg Smith
On 11/08/2011 05:07 PM, Robert Treat wrote: It's already easy to get good enough numbers based on user space tools with very little overhead, so I think it's more important that the server side tool be accurate rather than fast. What user space method do you consider good enough here? I

Re: [HACKERS] Materialized views

2011-11-08 Thread David E. Wheeler
On Nov 8, 2011, at 4:23 PM, Josh Berkus wrote: Well, there has to be some way to refresh an MV at regular intervals, no? For periodic update matviews, yes. However, Kevin needs only produce the command/function call for updating a generic periodic matview. He doesn't need to provide a

Re: [HACKERS] Materialized views

2011-11-08 Thread Josh Berkus
No feature-creeping; the two features described will be hard enough. Besides, we have pg_agent for that. Well, there has to be some way to refresh an MV at regular intervals, no? For periodic update matviews, yes. However, Kevin needs only produce the command/function call for updating a

Re: [HACKERS] 9.1.2 ?

2011-11-08 Thread Tom Lane
Greg Jaskiewicz g...@pointblue.com.pl writes: Given the amount of fixes that went into the branch, and importance of them - when can we expect 9.1.2 to be released officially ? 9.1.1 was stamped on 22nd of September. That's barely more than six weeks ago. Usually, in the absence of any

Re: [HACKERS] lexemes in prefix search going through dictionary modifications

2011-11-08 Thread Tom Lane
Sushant Sinha sushant...@gmail.com writes: I think there is a need to provide prefix search to bypass dictionaries.If you folks think that there is some credibility to such a need then I can think about implementing it. How about an operator like :# that does this? The :* will continue to mean

Re: [HACKERS] Materialized views

2011-11-08 Thread Andrew Dunstan
On 11/08/2011 06:25 PM, Josh Berkus wrote: I'm about 99% sure the answer to that is 'yes'. Are you thinking of having a background scheduler which handles the updating of schedule-driven (instead of trigger-driven) MVs..? Not to try to feature-creep this on you, but you might consider how a

Re: [HACKERS] pg_comments (was: Allow \dd to show constraint comments)

2011-11-08 Thread Thom Brown
On 17 October 2011 03:04, Robert Haas robertmh...@gmail.com wrote: On Fri, Oct 14, 2011 at 11:12 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Oct 12, 2011 at 10:20 PM, Josh Kupershmidt schmi...@gmail.com wrote: On the third hand, Josh's previous batch of changes to clean up psql's

Re: [HACKERS] Materialized views

2011-11-08 Thread Stephen Frost
* Josh Berkus (j...@agliodbs.com) wrote: Well, there has to be some way to refresh an MV at regular intervals, no? For periodic update matviews, yes. However, Kevin needs only produce the command/function call for updating a generic periodic matview. He doesn't need to provide a

Re: [HACKERS] 9.1.2 ?

2011-11-08 Thread Greg Smith
On 11/08/2011 07:34 PM, Tom Lane wrote: I don't recall that we've fixed anything since September that seemed to warrant an immediate release. The backup+pg_clog failure issues fixed last week have been a nasty problem hitting people for a while. Backup corruption is obviously serious.

Re: [HACKERS] Materialized views

2011-11-08 Thread Robert Haas
On Tue, Nov 8, 2011 at 8:31 PM, Stephen Frost sfr...@snowman.net wrote: Perhaps that would be an acceptable initial version, but I'd be pretty disappointed and I certainly don't think we should stop there. I agree that a built-in job scheduler would be pretty awesome, but I think it's a

Re: [HACKERS] 9.1.2 ?

2011-11-08 Thread Tom Lane
Greg Smith g...@2ndquadrant.com writes: I was curious how 9.0 fared last year for comparison, here's that data: Version Date Days Weeks 9.0.009/20/10 9.0.110/04/10142.0 9.0.212/16/107310.4 9.0.301/31/11466.6 9.0.404/18/117711.0

Re: [HACKERS] Releasing an alpha for CF2

2011-11-08 Thread Robert Haas
On Tue, Nov 8, 2011 at 3:56 PM, Josh Berkus j...@agliodbs.com wrote: I'd really like us to release an alpha version based on the finished CF2.  There have been a number of major features added to PostgreSQL prior to this CF -- including Haas's performance improvements and range types -- which

Re: [HACKERS] proposal: psql concise mode

2011-11-08 Thread Josh Kupershmidt
On Mon, Nov 7, 2011 at 11:25 PM, Robert Haas robertmh...@gmail.com wrote: But I can't help feeling that as we continue to add more features, we've eventually going to end up with our backs to the wall.  Not sure what to do about that, but... Seriously, parts of psql are starting to become a

Re: [HACKERS] pg_comments (was: Allow \dd to show constraint comments)

2011-11-08 Thread Robert Haas
On Tue, Nov 8, 2011 at 8:12 PM, Thom Brown t...@linux.com wrote: Why is this marked as done on with Wiki's todo list? I assume you're referring to this item: -- \dd is missing comments for several types of objects. Comments are not handled at all for some object types, and are handled by both

Re: [HACKERS] proposal: psql concise mode

2011-11-08 Thread Tom Lane
Josh Kupershmidt schmi...@gmail.com writes: We're essentially pretending that we support all server versions with this code, instead of erroring out on some definite old version and admitting sorry, can't do it. ... I think we should draw a line somewhere about just how far back psql must

Re: [HACKERS] Materialized views

2011-11-08 Thread Greg Smith
On 11/08/2011 04:23 PM, Kevin Grittner wrote: http://wiki.postgresql.org/wiki/Materialized_Views That page describes three components: creating MVs, updating MVs, and having the planner automatically detect when an MV matches some portion of a regular query and using the MV instead of the

Re: [HACKERS] Releasing an alpha for CF2

2011-11-08 Thread Greg Smith
On 11/08/2011 09:31 PM, Robert Haas wrote: I know various people are working on patches to do various things, but the only outstanding thing that sticks out in my mind as an outstanding big feature patch is Alvaro's work on foreign key locks. I'm sure there must be others... but I'm not sure

Re: [HACKERS] type privileges and default privileges

2011-11-08 Thread Peter Eisentraut
On mån, 2011-11-07 at 12:21 -0500, Robert Haas wrote: As I'm plotting to write code for this, I wonder about how to handle default privileges. For compatibility and convenience, we would still want to have types with public privileges by default. Should we continue to hardcode this, as

Re: [HACKERS] 9.1.2 ?

2011-11-08 Thread Magnus Hagander
On Nov 9, 2011 3:25 AM, Tom Lane t...@sss.pgh.pa.us wrote: Greg Smith g...@2ndquadrant.com writes: I was curious how 9.0 fared last year for comparison, here's that data: Version Date Days Weeks 9.0.009/20/10 9.0.110/04/10142.0 9.0.212/16/107310.4

Re: [HACKERS] type privileges and default privileges

2011-11-08 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: Let me put this differently. Should we either continue to hardcode the default privileges in the acldefault() function, or should we instead initialize the system catalogs with an entry in pg_default_acl as though ALTER DEFAULT PRIVILEGES GRANT USAGE

Re: [HACKERS] ERROR: MergeAppend child's targetlist doesn't match MergeAppend

2011-11-08 Thread Teodor Sigaev
After some thought and experimentation, the best fix seems to be to eliminate the ambiguity by wrapping subquery outputs in PlaceHolderVars whenever there is a risk of confusion. The attached crude patch fixes both test cases. It needs work (more comments and a regression test case would be