Re: [HACKERS] [bug fix] pg_ctl fails with config-only directory

2013-12-06 Thread Amit Kapila
On Thu, Dec 5, 2013 at 6:30 PM, MauMau wrote: > From: "Amit Kapila" >> >> On Wed, Dec 4, 2013 at 7:57 PM, MauMau wrote: >>> >> >> Approach-2 has been discussed previously to resolve it and it doesn't seem >> to be >> a good way to handle it. Please refer link: >> http://www.postgresql.org/messag

Re: [HACKERS] ANALYZE sampling is too good

2013-12-06 Thread Fabien COELHO
http://en.wikipedia.org/wiki/Cluster_sampling http://en.wikipedia.org/wiki/Multistage_sampling I suspect the hard part will be characterising the nature of the non-uniformity in the sample generated by taking a whole block. Some of it may come from how the rows were loaded (e.g. older rows were

Re: [HACKERS] RFC: programmable file format for postgresql.conf

2013-12-06 Thread Álvaro Hernández Tortosa
On 06/12/2013 22:59, Peter Eisentraut wrote: On 12/6/13, 12:29 PM, Álvaro Hernández Tortosa wrote: What I've been trying to do is summarize what has already been discussed here and propose a solution. You say that "you can already do those thisngs", but that's not what I have read here. Gr

Re: [HACKERS] RFC: programmable file format for postgresql.conf

2013-12-06 Thread Álvaro Hernández Tortosa
On 06/12/2013 19:11, David Johnston wrote: Álvaro Hernández Tortosa wrote Note that you are not required to maintain your configuration data in a postgresql.conf-formatted file. You can keep it anywhere you like, GUI around in it, and convert it back to the required format. Most of the

Re: [HACKERS] Recovery to backup point

2013-12-06 Thread Michael Paquier
On Sat, Dec 7, 2013 at 9:06 AM, MauMau wrote: > It seems that Everyone welcomed the following functionality, and I also want > it to solve some problem. But this doesn't appear to be undertaken. Indeed, nobody has really showed up to implement that. > > Recovery target 'immediate' > http://www.p

Re: [HACKERS] Performance optimization of btree binary search

2013-12-06 Thread Peter Geoghegan
On Thu, Dec 5, 2013 at 2:19 AM, Peter Geoghegan wrote: > I did a relatively short variant 'insert' pgbench-tools benchmark, > with a serial primary index created on the pgbench_history table. > Results: > > http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/insert/ I saw something toda

[HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

2013-12-06 Thread David Johnston
MauMau wrote > From: "Tom Lane" < > tgl@.pa > > >> There is no enthusiasm for a quick-hack solution here, and most people >> don't actually agree with your proposal that these errors should never >> get logged. So no, that is not happening. You can hack your local >> copy that way if you like o

[HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

2013-12-06 Thread David Johnston
David Johnston wrote > > MauMau wrote >> From: "Tom Lane" < >> tgl@.pa >> > >>> There is no enthusiasm for a quick-hack solution here, and most people >>> don't actually agree with your proposal that these errors should never >>> get logged. So no, that is not happening. You can hack your loca

[HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

2013-12-06 Thread David Johnston
MauMau wrote > From: "Tom Lane" < > tgl@.pa > > >> There is no enthusiasm for a quick-hack solution here, and most people >> don't actually agree with your proposal that these errors should never >> get logged. So no, that is not happening. You can hack your local >> copy that way if you like o

[HACKERS] Recovery to backup point

2013-12-06 Thread MauMau
Hello, It seems that Everyone welcomed the following functionality, and I also want it to solve some problem. But this doesn't appear to be undertaken. Recovery target 'immediate' http://www.postgresql.org/message-id/51703751.2020...@vmware.com Is there any technical difficulty? May I imple

Re: [HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

2013-12-06 Thread MauMau
From: "Tom Lane" There is no enthusiasm for a quick-hack solution here, and most people don't actually agree with your proposal that these errors should never get logged. So no, that is not happening. You can hack your local copy that way if you like of course, but it's not getting committed.

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Andrew Gierth
> "Tom" == Tom Lane writes: Tom> Not wanting to consider the sort args when there's more than one Tom> doesn't square with forcing them to be considered when there's Tom> just one. It's the same aggregate after all, This logic is only applied in the patch to aggregates that _aren't_ hypo

Re: [HACKERS] writable FDWs / update targets confusion

2013-12-06 Thread Tom Lane
Tomas Vondra writes: > I think that we should make the documentation more explicit about this > limitation, because the current wording in fdw-callbacks documentation > seems to suggest it's possible to add such hidden columns. At least > that's how I read it before running into this. You can add

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Tom Lane
Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Meh. I don't think you can have that and also have the behavior > Tom> that multiple ORDER BY items aren't constrained to have the same > Tom> collation; at least not without some rule that amounts to a > Tom> special case for percenti

Re: [HACKERS] writable FDWs / update targets confusion

2013-12-06 Thread Tomas Vondra
On 18.11.2013 09:28, Albe Laurenz wrote: > Tom Lane wrote: >>> Tom, could you show us a rope if there is one? >> >> What is it you actually need to fetch? >> >> IIRC, the idea was that most FDWs would do the equivalent of fetching the >> primary-key columns to use in an update. If that's what you

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Andrew Gierth
> "Tom" == Tom Lane writes: Tom> 2. For an ordered set function, n must equal aggnfixedargs. We Tom> treat all n fixed arguments as contributing to the aggregate's Tom> result collation, but ignore the sort arguments. >> That doesn't work for getting a sensible collation out of >> perc

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Tom Lane
Andrew Gierth writes: > The patch as submitted answers those questions as follows: > CREATE AGGREGATE func(integer) WITHIN GROUP (text) ... You've glossed over a significant amount of complexity, as shown by your example that prints WITHIN GROUP (*), a syntax that you've not defined here. In th

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Andrew Gierth
> "Josh" == Josh Berkus writes: >> Since I don't particularly trust my own judgement on aesthetics, I >> used the feedback I got from others when deciding what to >> do. Frankly I think this one needs wider input than just you and >> me arguing over it. Josh> Can someone paste examples

Re: [HACKERS] RFC: programmable file format for postgresql.conf

2013-12-06 Thread Peter Eisentraut
On 12/6/13, 12:29 PM, Álvaro Hernández Tortosa wrote: > What I've been trying to do is summarize what has already been > discussed here and propose a solution. You say that "you can already do > those thisngs", but that's not what I have read here. Greg Smith (cc'ed > as I'm quoting you) was ex

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Tom Lane
Josh Berkus writes: > Can someone paste examples of the two syntax alternatives we're talking > about here? I've lost track. I'll leave it to Andrew to describe/defend exactly what his patch is doing. The alternative I'm thinking about is that in CREATE AGGREGATE as well as \da output, the argu

Re: [HACKERS] Wildcard usage enhancements in .pgpass

2013-12-06 Thread Peter Eisentraut
On 11/17/13, 1:56 PM, Martijn van Oosterhout wrote: > Looks interesting, though I wonder if you could use fnmatch(3) here. Or > woud that match more than you expect? For example, it would allow > 'foo*bar' to match 'foo.bar' which your code doesn't. The question is whether you'd want that. We ha

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Andrew Gierth
> "Tom" == Tom Lane writes: Tom> Another thing to think about here is to wonder why the committee chose Tom> anything as verbose as "agg(...) WITHIN GROUP (ORDER BY ...)" in the Tom> first place. The words ORDER BY certainly seem pretty unnecessary. All of the ordered-set functions that

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Josh Berkus
On 12/06/2013 01:30 PM, Andrew Gierth wrote: > Since I don't particularly trust my own judgement on aesthetics, I used > the feedback I got from others when deciding what to do. Frankly I think > this one needs wider input than just you and me arguing over it. Can someone paste examples of the two

Re: [HACKERS] pg_stat_statements: calls under-estimation propagation

2013-12-06 Thread Peter Geoghegan
On Fri, Dec 6, 2013 at 12:24 PM, Tom Lane wrote: >> There seems to be no problem even if we use bigint as the type of >> unsigned 32-bit integer like queryid. For example, txid_current() >> returns the transaction ID, i.e., unsigned 32-bit integer, as bigint. >> Could you tell me what the problem

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Andrew Gierth
> "Tom" == Tom Lane writes: >> pg_get_function_arguments()'s interface assumes that the caller is >> providing the enclosing parens. Changing it would have meant >> returning a result like 'float8) WITHIN GROUP (float8' which I >> reckoned would have too much chance of breaking existing c

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Tom Lane
Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Actually, now that I think of it, why not use this syntax for > Tom> declaration and display purposes: > Tom> type1, type2 ORDER BY type3, type4 > But unfortunately it looks exactly like the calling sequence for a > normal aggre

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread David Johnston
Andrew Gierth wrote >> "Tom" == Tom Lane < > tgl@.pa > > writes: > > >> Please don't object that that doesn't look exactly like the syntax > >> for calling the function, because it doesn't anyway --- remember > >> you also need ORDER BY in the call. > > Tom> Actually, now that I think o

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Andrew Gierth
> "Tom" == Tom Lane writes: >> Please don't object that that doesn't look exactly like the syntax >> for calling the function, because it doesn't anyway --- remember >> you also need ORDER BY in the call. Tom> Actually, now that I think of it, why not use this syntax for Tom> declaratio

Re: [HACKERS] Reference to parent query from ANY sublink

2013-12-06 Thread Kevin Grittner
Kevin Grittner wrote: > test=# SELECT * > FROM    tab1 a > LEFT JOIN > tab2 b > ON a.i = ANY ( > SELECT  k     > FROM    tab3 c > WHERE    k = a.i); >  i | j > ---+--- >  1 | 4 >  1 | 5 >  1 | 6 >  2 | >  3 | 4 >  3 | 5 >  3 | 6 > (7 rows) > >> SELECT  * >>

Re: [HACKERS] pg_stat_statements: calls under-estimation propagation

2013-12-06 Thread Tom Lane
Fujii Masao writes: > On Sun, Nov 24, 2013 at 10:58 AM, Peter Geoghegan wrote: >> I decided that queryid should be of type oid, not bigint. This is >> arguably a slight abuse of notation, but since ultimately Oids are >> just abstract object identifiers (so say the docs), but also because >> ther

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Tom Lane
I wrote: > One possibility is to forget all the parens and say that the display > looks like > type1, type2 WITHIN GROUP type3, type4 > Please don't object that that doesn't look exactly like the syntax > for calling the function, because it doesn't anyway --- remember you > also need ORDER B

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Tom Lane
Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Regardless of that, though ... what is the reasoning for > Tom> inventing pg_get_aggregate_arguments() rather than just making > Tom> pg_get_function_arguments() do the right thing? > pg_get_function_arguments()'s interface assumes that

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Andrew Gierth
> "Tom" == Tom Lane writes: Tom> Regardless of that, though ... what is the reasoning for Tom> inventing pg_get_aggregate_arguments() rather than just making Tom> pg_get_function_arguments() do the right thing? pg_get_function_arguments()'s interface assumes that the caller is providing t

Re: [HACKERS] pg_stat_statements: calls under-estimation propagation

2013-12-06 Thread Fujii Masao
On Sun, Nov 24, 2013 at 10:58 AM, Peter Geoghegan wrote: > On Mon, Nov 18, 2013 at 1:54 AM, Sameer Thakur wrote: >> Please find v10 of patch attached. This patch addresses following >> review comments > > I've cleaned this up - revision attached - and marked it "ready for > committer". > > I dec

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Tom Lane
I don't especially like the syntax you invented for listing arguments in CREATE AGGREGATE, especially not the WITHIN GROUP (*) special case. If we stick with that we're going to need to touch a lot more places than you have, notably regprocedure. I also fear that this syntax is not appropriate for

Re: [HACKERS] RFC: programmable file format for postgresql.conf

2013-12-06 Thread David Johnston
Álvaro Hernández Tortosa wrote >> Note that you are not required to maintain your configuration data in a >> postgresql.conf-formatted file. You can keep it anywhere you like, GUI >> around in it, and convert it back to the required format. Most of the > > I think it is not a very good i

Re: [HACKERS] RFC: programmable file format for postgresql.conf

2013-12-06 Thread Álvaro Hernández Tortosa
On 06/12/13 04:47, Peter Eisentraut wrote: On Thu, 2013-12-05 at 00:51 +0100, Álvaro Hernández Tortosa wrote: The tradeoff seems quite positive to me. I see no strong reasons why not do it... am I missing something? I don't buy your argument. You say, if we make this change, tho

Re: [HACKERS] Dynamic Shared Memory stuff

2013-12-06 Thread Robert Haas
On Thu, Dec 5, 2013 at 4:06 PM, Heikki Linnakangas wrote: >> That's a very interesting idea. I've been thinking that we needed to >> preserve the property that new workers could attach to the shared >> memory segment at any time, but that might not be necessary in all >> case. We could introduce

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

2013-12-06 Thread Tom Lane
Andres Freund writes: > On 2013-12-06 11:02:48 -0500, Tom Lane wrote: >> I think the special-purpose command line switches you mention can be >> passed through PGOPTIONS, rather than inventing a new parameter -- do you >> have an objection to that? > I am not sure if they currently will get recog

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

2013-12-06 Thread Andres Freund
On 2013-12-06 11:02:48 -0500, Tom Lane wrote: > Andres Freund writes: > My feeling is that we should just treat the executable name and data > directory path as new connection parameters, which'd be ignored in > normal-connection mode, just as some other parameters will be ignored in > single-user

[HACKERS] commit fest 2013-11 week 3 report

2013-12-06 Thread Peter Eisentraut
Last week's status: Fri Nov 29 Status Summary. Needs Review: 29, Waiting on Author: 33, Ready for Committer: 13, Committed: 24, Returned with Feedback: 5, Rejected: 5. Total: 109. Current status: Fri Dec 6 10:55 Status Summary. Needs Review: 24, Waiting on Author: 21, Ready for Committer: 14,

Re: [HACKERS] pg_archivecleanup bug

2013-12-06 Thread Tom Lane
Robert Haas writes: > On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote: >> In general, I think there is no excuse for code in the backend to use >> readdir() directly; it should be using ReadDir(), which takes care of this >> as well as error reporting. > My understanding is that the fd.c infrastr

Re: [HACKERS] ANALYZE sampling is too good

2013-12-06 Thread Greg Stark
It looks like this is a fairly well understood problem because in the real world it's also often cheaper to speak to people in a small geographic area or time interval too. These wikipedia pages sound interesting and have some external references: http://en.wikipedia.org/wiki/Cluster_sampling http

Re: [HACKERS] Time-Delayed Standbys

2013-12-06 Thread Fabrízio de Royes Mello
On Fri, Dec 6, 2013 at 1:36 PM, Robert Haas wrote: > On Thu, Dec 5, 2013 at 11:07 PM, Fabrízio de Royes Mello > wrote: > > On Tue, Dec 3, 2013 at 5:33 PM, Simon Riggs > wrote: > >> > >> > - compute recoveryUntilDelayTime in XLOG_XACT_COMMIT and > >> > XLOG_XACT_COMMIT_COMPACT checks > >> > >> W

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

2013-12-06 Thread Tom Lane
Andres Freund writes: > On 2013-12-05 23:01:28 +0200, Heikki Linnakangas wrote: >> Right. Not all of the parameters will make sense for a stand-alone backend >> though, like the hostname and port number. And I think you need need a new >> parameter to pass the path to the 'postgres' executable, un

Re: [HACKERS] pg_archivecleanup bug

2013-12-06 Thread Robert Haas
On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote: > In general, I think there is no excuse for code in the backend to use > readdir() directly; it should be using ReadDir(), which takes care of this > as well as error reporting. My understanding is that the fd.c infrastructure can't be used in the

Re: [HACKERS] Time-Delayed Standbys

2013-12-06 Thread Robert Haas
On Thu, Dec 5, 2013 at 11:07 PM, Fabrízio de Royes Mello wrote: > On Tue, Dec 3, 2013 at 5:33 PM, Simon Riggs wrote: >> >> > - compute recoveryUntilDelayTime in XLOG_XACT_COMMIT and >> > XLOG_XACT_COMMIT_COMPACT checks >> >> Why just those? Why not aborts and restore points also? >> > > I think m

Re: [HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

2013-12-06 Thread Tom Lane
"MauMau" writes: > That discussion sounds interesting, and I want to take more time to > consider. But what do you think of my original suggestion to easily solve > the current issue? I'd like to remove the current annoying problem first > before spending much time for more excited infrastruc

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

2013-12-06 Thread Andres Freund
On 2013-12-05 23:01:28 +0200, Heikki Linnakangas wrote: > On 12/05/2013 10:37 PM, Robert Haas wrote: > >On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane wrote: > >>It might be unpleasant to use in some cases, though. > > > >Why would there be more than a few cases in the first place? Who is > >going to u

Re: Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

2013-12-06 Thread Antonin Houska
Tested git apply and build again. No warnings. The regression test also looks good to me now. I'm done with this review. (Not sure if I should move it to 'ready for committer' status or the CFM should do). // Antonin Houska (Tony) On 12/06/2013 02:01 PM, Boszormenyi Zoltan wrote: > 2013-12-04

Re: [HACKERS] Add %z support to elog/ereport?

2013-12-06 Thread Peter Eisentraut
On 11/11/13, 12:01 PM, Tom Lane wrote: > I do recall Peter saying that the infrastructure knows how to > verify conversion specs in translated strings, so it would have to be > aware of 'z' flags for this to work. It just checks that the same conversion placeholders appear in the translation. It

Re: [HACKERS] Trust intermediate CA for client certificates

2013-12-06 Thread Bruce Momjian
On Mon, Dec 2, 2013 at 12:44:08PM -0500, Bruce Momjian wrote: > On Sat, Nov 30, 2013 at 12:10:19PM -0500, Bruce Momjian wrote: > > > Drat, you're quite right. I've always included the full certificate > > > chain in client certs but it's in no way required. > > > > > > I guess that pretty much me

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Tom Lane
Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> I believe that the spec requires that the "direct" arguments of > Tom> an inverse or hypothetical-set aggregate must not contain any > Tom> Vars of the current query level. > In any event, going by the docs on the web, Oracle does not f

Re: [HACKERS] Reference to parent query from ANY sublink

2013-12-06 Thread Kevin Grittner
Antonin Houska wrote: > SELECT * > FROM    tab1 a > LEFT JOIN > tab2 b > ON a.i = ANY ( > SELECT  k > FROM    tab3 c > WHERE    k = a.i); This query works with k in any or all tables, but the semantics certainly vary depending on where k happens to be.  It wou

[HACKERS] [patch] Client-only installation on Windows

2013-12-06 Thread MauMau
Hello, According to this page, http://www.postgresql.org/docs/current/static/install-procedure.html client-only installation is possible on UNIX/Linux like this: gmake -C src/bin install gmake -C src/include install gmake -C src/interfaces install gmake -C doc install With the attach

Re: [HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

2013-12-06 Thread MauMau
From: "Alvaro Herrera" There was also the idea that this would be driven off SQLSTATE but this seems pretty unwieldy to me. You are referring to this long discussion, don't you? http://www.postgresql.org/message-id/19791.1335902...@sss.pgh.pa.us I've read it before, and liked the SQLSTATE-ba

Re: [HACKERS] Feature request: Logging SSL connections

2013-12-06 Thread Dr. Andreas Kunert
Anything else missing? Functionally it's fine now, but I see few style problems: - "if (port->ssl > 0)" is wrong, ->ssl is pointer. So use just "if (port->ssl)". - Deeper indentation would look nicer with braces. - There are some duplicated message, could you restructure it so that each

Re: [HACKERS] [RFC] Shouldn't we remove annoying FATAL messages from server log?

2013-12-06 Thread Andres Freund
On 2013-12-06 22:35:21 +0900, MauMau wrote: > From: "Tom Lane" > >No. They are FATAL so far as the individual session is concerned. > >Possibly some documentation effort is needed here, but I don't think > >any change in the code behavior would be an improvement. > > You are suggesting that we s

Re: [HACKERS] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

2013-12-06 Thread MauMau
From: "Josh Berkus" Heck, I'd be happy just to have a class of messages which specifically means "OMG, there's something wrong with the server", that is, a flag for messages which only occur when PostgreSQL encounters a bug, data corrpution, or platform error. Right now, I have to suss those ou

Re: [HACKERS] [RFC] Shouldn't we remove annoying FATAL messages from server log?

2013-12-06 Thread MauMau
From: "Tom Lane" No. They are FATAL so far as the individual session is concerned. Possibly some documentation effort is needed here, but I don't think any change in the code behavior would be an improvement. You are suggesting that we should add a note like "Don't worry about the following

Re: [HACKERS] Feature request: Logging SSL connections

2013-12-06 Thread Marko Kreen
On Fri, Dec 06, 2013 at 11:43:55AM +0100, Dr. Andreas Kunert wrote: > >>That seems useful. Do we need more information, like whether a client > >>certificate was presented, or what ciphers were used? > > > >Yes, please show ciphersuite and TLS version too. Andreas, you can use my > >recent \conni

Re: [HACKERS] [RFC] Shouldn't we remove annoying FATAL messages from server log?

2013-12-06 Thread MauMau
From: "Peter Eisentraut" Yeah, this is part of a more general problem, which you have characterized correctly: What is fatal (or error, or warning, ...) to the client isn't necessarily fatal (or error, or warning, ...) to the server or DBA. Thanks. In addition, #5 and #6 in my previous mail a

Re: [HACKERS] shared memory message queues

2013-12-06 Thread Andres Freund
On 2013-12-05 14:07:39 -0500, Robert Haas wrote: > On Thu, Dec 5, 2013 at 8:29 AM, Andres Freund wrote: > > Hm. The API change of on_shmem_exit() is going to cause a fair bit of > > pain. There are a fair number of extensions out there using it and all > > would need to be littered by version depe

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

2013-12-06 Thread Amit Kapila
On Fri, Dec 6, 2013 at 3:39 PM, Haribabu kommi wrote: > On 06 December 2013 12:29 Amit Kapila wrote: >> >> Note - >> >> a. Performance is data is taken on my laptop, needs to be tested on >> >> some better m/c b. Attached Patch is just a prototype of chunkwise >> >> concept, code needs to be impro

Re: [HACKERS] dblink performance regression

2013-12-06 Thread Fabrízio de Royes Mello
On Fri, Dec 6, 2013 at 2:50 AM, Joe Conway wrote: > > On 12/05/2013 07:16 PM, Fabrízio de Royes Mello wrote: > > Hi Joe, how are you? > > Hi Fabrizio -- great to hear from you! I'm well. > :-) > > Well, when Tom sent this email I was reviewing your patch and the > > main suggestion is about use

Re: [HACKERS] [PATCH] Add transforms feature

2013-12-06 Thread Hannu Krosing
On 12/06/2013 07:25 AM, Peter Eisentraut wrote: > On Tue, 2013-11-26 at 18:10 +0100, Dimitri Fontaine wrote: >> The problem is installing a set of extensions where some of them are >> already using the new transform feature and some of them are not. We >> need a way to cater with that, I think. > H

Re: [HACKERS] Feature request: Logging SSL connections

2013-12-06 Thread Dr. Andreas Kunert
That seems useful. Do we need more information, like whether a client certificate was presented, or what ciphers were used? Yes, please show ciphersuite and TLS version too. Andreas, you can use my recent \conninfo patch as template: https://github.com/markokr/postgres/commit/7d1b27ac7464

Re: [HACKERS] [PATCH] Add transforms feature

2013-12-06 Thread Dimitri Fontaine
Peter Eisentraut writes: > Here is an idea. Add a GUC that basically says something like > use_transforms = on|off. You can then attach that to individual > functions, which is the right granularity, because only the function > knows whether its code expects transforms or not. But you can use t

Re: [HACKERS] spinlocks storm bug

2013-12-06 Thread Pavel Stehule
2013/12/6 Andres Freund > On 2013-12-06 07:22:27 +0100, Pavel Stehule wrote: > > I have a report of critical bug (database is temporary unavailability .. > > restart is necessary). > > > PostgreSQL 9.2.4, > > 24 CPU > > 140G RAM > > SSD disc for all > > > > > > Database is under high load. There

Re: [HACKERS] Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan

2013-12-06 Thread Etsuro Fujita
I wrote: > Amit Khandekar wrote: > > Yes, I agree that rather than looking at the bitmap heap scan to track > > the number of pages, we should look somewhere in the underlying index > > scan. Yes, we should get a constant number of index pages regardless > > of the actual parent table rows. > I ag

Re: [HACKERS] spinlocks storm bug

2013-12-06 Thread Andres Freund
On 2013-12-06 07:22:27 +0100, Pavel Stehule wrote: > I have a report of critical bug (database is temporary unavailability .. > restart is necessary). > PostgreSQL 9.2.4, > 24 CPU > 140G RAM > SSD disc for all > > > Database is under high load. There is a few databases with very high number > of

Re: [HACKERS] Backup throttling

2013-12-06 Thread Boszormenyi Zoltan
Hi, 2013-12-05 15:36 keltezéssel, Antonin Houska írta: On 12/02/2013 02:23 PM, Boszormenyi Zoltan wrote: Hi, I am reviewing your patch. Thanks. New version attached. I have reviewed and tested it and marked it as ready for committer. Best regards, Zoltán Böszörményi -- ---

Re: [HACKERS] ANALYZE sampling is too good

2013-12-06 Thread Andres Freund
On 2013-12-05 17:52:34 -0800, Peter Geoghegan wrote: > Has anyone ever thought about opportunistic ANALYZE piggy-backing on > other full-table scans? That doesn't really help Greg, because his > complaint is mostly that a fresh ANALYZE is too expensive, but it > could be an interesting, albeit risk

Re: [HACKERS] ANALYZE sampling is too good

2013-12-06 Thread Amit Kapila
On Fri, Dec 6, 2013 at 7:22 AM, Peter Geoghegan wrote: > On Thu, Dec 5, 2013 at 3:50 PM, Josh Berkus wrote: >> There are fairly well researched algorithms for block-based sampling >> which estimate for the skew introduced by looking at consecutive rows in >> a block. In general, a minimum sample

Re: [HACKERS] WITHIN GROUP patch

2013-12-06 Thread Andrew Gierth
> "Tom" == Tom Lane writes: Tom> Further questions about WITHIN GROUP: Tom> I believe that the spec requires that the "direct" arguments of Tom> an inverse or hypothetical-set aggregate must not contain any Tom> Vars of the current query level. False. The spec requires that the direct