Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

2013-10-23 Thread Abhijit Menon-Sen
At 2013-10-24 11:33:13 +0530, a...@2ndquadrant.com wrote: > > >From /proc/$pid/status, VmPTE was 2880kb with huge_tlb_pages=off, and > 56kb with it turned on. (VmPTE is the size of the process's page tables.) -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To m

[HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

2013-10-23 Thread Abhijit Menon-Sen
Hi. This is a slightly reworked version of the patch submitted by Richard Poole last month, which was based on Christian Kruse's earlier patch. Apart from doing various minor cleanups and documentation fixes, I also tested this patch against HEAD on a machine with 256GB of RAM. Here's an overview

Re: [HACKERS] CLUSTER FREEZE

2013-10-23 Thread Amit Kapila
On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote: > Hi > I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to add > that, for consistency with VACUUM. Is it useful? I wonder why anyone would like to freeze during CLUSTER command when they already have separate way (VACUUM

[HACKERS] How should RLS treat ON DELETE CASCADE, ON UPDATE CASCADE, and ON DELETE SET NULL?

2013-10-23 Thread Craig Ringer
Hi all I'm interested in an opinion: How should RLS treat cascading RI constraints? The current tests check ON DELETE NO ACTION constraints, causing insertion to fail if a PK row exists but is not visible, and deletion to fail if there's still an invisible FK reference to a visible PK. That seem

Re: [HACKERS] high-dimensional knn-GIST tests (was Re: Cube extension kNN support)

2013-10-23 Thread Alvaro Herrera
Gordon Mohr wrote: > Thanks for this! I decided to give the patch a try at the bleeding > edge with some high-dimensional vectors, specifically the 1.4 > million 1000-dimensional Freebase entity vectors from the Google > 'word2vec' project: > > https://code.google.com/p/word2vec/#Pre-trained_enti

Re: [HACKERS] Re: Using indexes for ORDER BY and PARTITION BY clause in windowing functions

2013-10-23 Thread Sameer Kumar
Agree that windowing function will return all the rows compared to max and group by returing only max rows per group. But even while arriving at the aggregate/sorting windowing function seems to spend more effort than group by/order by. I am just trying to see if we could somehow optimize the way

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Alvaro Herrera
Peter Geoghegan escribió: > I am interested in making it store richer statistics, > provided we're very careful about the costs. Every time those counters > are incremented, a spinlock is held. Hmm, now if we had portable atomic addition, so that we could spare the spinlock ... -- Álvaro Herrer

[HACKERS] RLS syntax

2013-10-23 Thread Craig Ringer
[bikeshed] I'm not totally comfortable with the details of ALTER TABLE ... SET ROW SECURITY FOR ALL . If you read: ALTER TABLE document SET ROW SECURITY FOR ALL TO (...query...) is it obvious to you that "FOR ALL" here refers to all _command types_? I'd like to make that more explicit and

Re: [HACKERS] stats for network traffic WIP

2013-10-23 Thread Nigel Heron
On Wed, Oct 23, 2013 at 2:44 PM, Nigel Heron wrote: > Hi, thanks, I'm still actively working on this patch. I've gotten the > traffic counters working when using SSL enabled clients (includes the > ssl overhead now) but I still have the walsender transfers under SSL > to work on. > I'll post an up

[HACKERS] Testing RLS with SECURITY DEFINER functions returning refcursors

2013-10-23 Thread Craig Ringer
Hi all I'm going to be contributing a fair bit of time to RLS for 2ndQuadrant, courtesy of the EU AXLE project (http://axleproject.eu/). I've been catching up on Kohei KaiGai's work and I've been really impressed by what's already done and working. I'm currently reading the patches, mailing list

[HACKERS] Re: Using indexes for ORDER BY and PARTITION BY clause in windowing functions

2013-10-23 Thread David Johnston
Sameer Kumar wrote > edb=# explain analyze select max(score) from student_score group by > course; This query returns 6 records. The window one returns 123,000. Why do you expect these to have anywhere near the same performance or plan? You can enable/disable indexes/scans to see what alternati

[HACKERS] high-dimensional knn-GIST tests (was Re: Cube extension kNN support)

2013-10-23 Thread Gordon Mohr
On 9/22/13 4:38 PM, Stas Kelvich wrote: Hello, hackers. Here is the patch that introduces kNN search for cubes with euclidean, taxicab and chebyshev distances. Thanks for this! I decided to give the patch a try at the bleeding edge with some high-dimensional vectors, specifically the 1.4 mill

Re: [HACKERS] RULE regression test fragility?

2013-10-23 Thread Tom Lane
Mike Blackwell writes: > While reviewing the Network Stats Traffic patch I discovered the current > regression test for rules depends on the system view definitions not > changing: Yes, this is standard. We just update the expected output anytime somebody changes a system view. (Now, if the sub

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
On Wed, Oct 23, 2013 at 5:15 PM, Gavin Flower wrote: > Anyhow, I was suggesting the faclity be off by default - I see no point in > enabling where people don't need it, even if the resource RAM, processor, > whatever, were minimal. As long as any new field in the Counters struct needs to be prote

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Gavin Flower
On 24/10/13 12:58, Peter Geoghegan wrote: On Wed, Oct 23, 2013 at 4:48 PM, Gavin Flower wrote: 32 int64 buckets is only 256 bytes, so a thousand histograms would be less than a quarter of a MB. Any machine that busy, would likely have many GB's of RAM. I have 32 GB on my development machine.

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
On Wed, Oct 23, 2013 at 4:51 PM, Peter Geoghegan wrote: > No, I'm not. I'm suggesting storing the query texts externally, in a > file. They usually use 1024 bytes of shared memory per entry, > regardless of how long the query text is. I should add that I think that that's about the useful limit o

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
On Wed, Oct 23, 2013 at 4:48 PM, Gavin Flower wrote: > 32 int64 buckets is only 256 bytes, so a thousand histograms would be less > than a quarter of a MB. Any machine that busy, would likely have many GB's > of RAM. I have 32 GB on my development machine. Who wants to just run with a thousand

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Gavin Flower
On 24/10/13 12:46, Josh Berkus wrote: On 10/23/2013 01:26 PM, Peter Geoghegan wrote: So fixing that problem would go a long way towards resolving these concerns. It would also probably have the benefit of making it possible for query texts to be arbitrarily long - we'd be storing them in files (

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
On Wed, Oct 23, 2013 at 4:46 PM, Josh Berkus wrote: > So you're suggesting that instead of storing the aggregates as we > currently do, we store a buffer of the last N queries (in normal form) > and their stats? And then aggregate when the user asks for it? No, I'm not. I'm suggesting storing th

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Gavin Flower
On 24/10/13 12:24, Peter Geoghegan wrote: On Wed, Oct 23, 2013 at 4:14 PM, Jeff Janes wrote: The last bucket would be limited to 8ms < x <= 16 ms. If you find something 16ms, then you have to rescale *before* you increment any of the buckets. Once you do, there is now room to hold it. How i

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
On Wed, Oct 23, 2013 at 4:34 PM, Stephen Frost wrote: > Any chance we could accumulate into the histogram in local memory and > only push to the shared memory on an "infrequent" or at least "less > frequent" basis? Apologies, I've not looked into the pg_stat_statements > bits all that closely, bu

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Josh Berkus
On 10/23/2013 01:26 PM, Peter Geoghegan wrote: > So fixing that problem would go a long > way towards resolving these concerns. It would also probably have the > benefit of making it possible for query texts to be arbitrarily long - > we'd be storing them in files (with a shared memory buffer). I g

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Stephen Frost
* Peter Geoghegan (p...@heroku.com) wrote: > On Wed, Oct 23, 2013 at 4:14 PM, Jeff Janes wrote: > > The last bucket would be limited to 8ms < x <= 16 ms. If you find something > >> 16ms, then you have to rescale *before* you increment any of the buckets. > > Once you do, there is now room to hold

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Gavin Flower
On 24/10/13 12:14, Jeff Janes wrote: On Wed, Oct 23, 2013 at 4:00 PM, Gavin Flower mailto:gavinflo...@archidevsys.co.nz>> wrote: On 24/10/13 11:26, Peter Geoghegan wrote: On Wed, Oct 23, 2013 at 2:57 PM, Gavin Flower mailto:gavinflo...@archidevsys.co.nz>> wrote:

[HACKERS] CLUSTER FREEZE

2013-10-23 Thread Thomas Munro
Hi I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to add that, for consistency with VACUUM. Is it useful? Thanks Thomas Munro cluster-freeze.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subsc

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Stephen Frost
* Martijn van Oosterhout (klep...@svana.org) wrote: > If I had to guess a distribution for query runtimes I'd go for Poisson, > which would mean you'd expect the mean to equal the variance. Don't > have enough experience with such measurements to say whether that is > reasonable. I was thinking th

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
On Wed, Oct 23, 2013 at 4:14 PM, Jeff Janes wrote: > The last bucket would be limited to 8ms < x <= 16 ms. If you find something >> 16ms, then you have to rescale *before* you increment any of the buckets. > Once you do, there is now room to hold it. How is that laid out in shared memory? If the

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Jeff Janes
On Wed, Oct 23, 2013 at 4:00 PM, Gavin Flower wrote: > On 24/10/13 11:26, Peter Geoghegan wrote: > >> On Wed, Oct 23, 2013 at 2:57 PM, Gavin Flower >> wrote: >> >>> Looks definitely bimodal in the log version, very clear! >>> >>> Yes, I feel that having a 32 log binary binned histogram (as Alvar

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Gavin Flower
On 24/10/13 12:00, Gavin Flower wrote: On 24/10/13 11:26, Peter Geoghegan wrote: On Wed, Oct 23, 2013 at 2:57 PM, Gavin Flower wrote: Looks definitely bimodal in the log version, very clear! Yes, I feel that having a 32 log binary binned histogram (as Alvaro Herrera suggested) would be very

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Jeff Janes
On Wed, Oct 23, 2013 at 3:26 PM, Peter Geoghegan wrote: > On Wed, Oct 23, 2013 at 2:57 PM, Gavin Flower > wrote: > > Looks definitely bimodal in the log version, very clear! > > > > Yes, I feel that having a 32 log binary binned histogram (as Alvaro > Herrera > > suggested) would be very useful.

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Gavin Flower
On 24/10/13 11:26, Peter Geoghegan wrote: On Wed, Oct 23, 2013 at 2:57 PM, Gavin Flower wrote: Looks definitely bimodal in the log version, very clear! Yes, I feel that having a 32 log binary binned histogram (as Alvaro Herrera suggested) would be very useful. I'm having a hard time imagining

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
On Wed, Oct 23, 2013 at 2:57 PM, Gavin Flower wrote: > Looks definitely bimodal in the log version, very clear! > > Yes, I feel that having a 32 log binary binned histogram (as Alvaro Herrera > suggested) would be very useful. I'm having a hard time imagining how you'd actually implement that. Fo

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Gavin Flower
On 24/10/13 10:34, Marc Mamin wrote: Oscillating plan changes may fit multimodal but I don't feel that's typical. My experience has been it's either an extremely rare plan difference or it's a shift from one plan to another over time. After all, all of avg, min, max and stdev are only numerical

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
On Wed, Oct 23, 2013 at 2:46 PM, Martijn van Oosterhout wrote: > Well, the standard deviation is the square root of the variance, which > is the second moment of the distribution. The first moment being the > mean. No matter what distribution it is, these are useful numbers. I'm inclined to agree

[HACKERS] Autotuning and RAM survey results

2013-10-23 Thread Josh Berkus
Folks, Of course, this survey is completely unscientific. However, it does give us more information than we had before: http://www.postgresql.org/community/survey/89-what-is-the-smallest-amount-of-ram-you-have-on-a-production-postgresql-server/ So going by this, only 20% of our users have any p

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Martijn van Oosterhout
On Tue, Oct 22, 2013 at 11:16:19AM -0700, Jeff Janes wrote: > On Mon, Oct 21, 2013 at 4:29 PM, Tom Lane wrote: > > Hm. It's been a long time since college statistics, but doesn't the > > entire concept of standard deviation depend on the assumption that the > > underlying distribution is more-or-

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
On Wed, Oct 23, 2013 at 1:07 PM, Jeff Janes wrote: > How does max not answer "is this query ever really slow?"? But good point, > if we have a max, then I think a time-stamp for when that max was obtained > would also be very useful. I'm concerned about the cost of all of this. And like Stephen,

Re: [HACKERS] missing locking in at least INSERT INTO view WITH CHECK

2013-10-23 Thread Dean Rasheed
On 23 October 2013 21:08, Andres Freund wrote: > On 2013-10-23 20:51:27 +0100, Dean Rasheed wrote: >> On 23 October 2013 02:18, Andres Freund wrote: >> > Hi, >> > >> > Using the same debugging hack^Wpatch (0001) as in the matview patch >> > (0002) an hour or so ago I noticed that INSERT INTO view

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Stephen Frost
* Jeff Janes (jeff.ja...@gmail.com) wrote: > On Wed, Oct 23, 2013 at 9:20 AM, Stephen Frost wrote: > > * Josh Berkus (j...@agliodbs.com) wrote: > > > On the other hand, it's still true that a high STDDEV indicates a high > > > variance in the response times of a particular query, whereas a low one

Re: [HACKERS] missing locking in at least INSERT INTO view WITH CHECK

2013-10-23 Thread Andres Freund
On 2013-10-23 20:51:27 +0100, Dean Rasheed wrote: > On 23 October 2013 02:18, Andres Freund wrote: > > Hi, > > > > Using the same debugging hack^Wpatch (0001) as in the matview patch > > (0002) an hour or so ago I noticed that INSERT INTO view WITH CHECK > > doesn't lock the underlying relations p

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Jeff Janes
On Wed, Oct 23, 2013 at 9:20 AM, Stephen Frost wrote: > Josh, > > * Josh Berkus (j...@agliodbs.com) wrote: > > On the other hand, it's still true that a high STDDEV indicates a high > > variance in the response times of a particular query, whereas a low one > > indicates that most are close to th

Re: [HACKERS] missing locking in at least INSERT INTO view WITH CHECK

2013-10-23 Thread Dean Rasheed
On 23 October 2013 02:18, Andres Freund wrote: > Hi, > > Using the same debugging hack^Wpatch (0001) as in the matview patch > (0002) an hour or so ago I noticed that INSERT INTO view WITH CHECK > doesn't lock the underlying relations properly. > > I've attached a sort-of-working (0003) hack but I

Re: [HACKERS] stats for network traffic WIP

2013-10-23 Thread Mike Blackwell
​ On Wed, Oct 23, 2013 at 2:10 PM, Atri Sharma wrote: > > Adding myself as the co reviewer specifically for the testing > purposes, if its ok with you. > ​It's perfectly fine with me. Please do!​ __ *Mike Blackw

Re: [HACKERS] stats for network traffic WIP

2013-10-23 Thread Atri Sharma
On Thu, Oct 24, 2013 at 12:30 AM, Mike Blackwell wrote: > > On Wed, Oct 23, 2013 at 1:58 PM, Atri Sharma wrote: > >> >> IMO, the idea is pretty good. Its just that we need to do some wide >> spectrum performance testing. Thats only my thought though. > > > > I'm looking at trying to do some perfo

Re: [HACKERS] stats for network traffic WIP

2013-10-23 Thread Nigel Heron
On Wed, Oct 23, 2013 at 2:58 PM, Atri Sharma wrote: > On Thu, Oct 24, 2013 at 12:23 AM, Mike Blackwell > wrote: >> Sounds good. I personally don't have any interest in log file i/o counters, >> but that's just me. I wonder if stats collector counters might be useful... >> I seem to recall an e

Re: [HACKERS] stats for network traffic WIP

2013-10-23 Thread Mike Blackwell
​ On Wed, Oct 23, 2013 at 1:58 PM, Atri Sharma wrote: > > IMO, the idea is pretty good. Its just that we need to do some wide > spectrum performance testing. Thats only my thought though. I'm looking at trying to do some performance testing on this. Any suggestions on test scenarios, etc? _

Re: [HACKERS] stats for network traffic WIP

2013-10-23 Thread Atri Sharma
On Thu, Oct 24, 2013 at 12:23 AM, Mike Blackwell wrote: > Sounds good. I personally don't have any interest in log file i/o counters, > but that's just me. I wonder if stats collector counters might be useful... > I seem to recall an effort to improve that area. Maybe not enough use to > take t

Re: [HACKERS] stats for network traffic WIP

2013-10-23 Thread Mike Blackwell
Sounds good. I personally don't have any interest in log file i/o counters, but that's just me. I wonder if stats collector counters might be useful... I seem to recall an effort to improve that area. Maybe not enough use to take the performance hit on a regular basis, though. _

Re: [HACKERS] stats for network traffic WIP

2013-10-23 Thread Nigel Heron
Hi, thanks, I'm still actively working on this patch. I've gotten the traffic counters working when using SSL enabled clients (includes the ssl overhead now) but I still have the walsender transfers under SSL to work on. I'll post an updated patch when i have it figured out. Since the patch changes

Re: [HACKERS] psql tab completion for updatable foreign tables

2013-10-23 Thread Robert Haas
On Sat, Oct 19, 2013 at 5:44 AM, Dean Rasheed wrote: > On 18 October 2013 16:41, Robert Haas wrote: >> On Fri, Oct 18, 2013 at 1:34 AM, Dean Rasheed >> wrote: Personally, I think this is too fancy anyway. I'd just complete all views and foreign tables and be done with it. We don't i

Re: [HACKERS] stats for network traffic WIP

2013-10-23 Thread Mike Blackwell
I added this to the current CF, and am starting to review it as I have time. __ *Mike Blackwell | Technical Analyst, Distribution Services/Rollout Management | RR Donnelley* 1750 Wallace Ave | St Charles, IL 60174-3401

Re: [HACKERS] Location for external scripts for Extensions?

2013-10-23 Thread Christopher Browne
On Wed, Oct 23, 2013 at 12:24 PM, Josh Berkus wrote: > Dimitri, > >> Josh Berkus writes: >>> pg_partman has several external (python) scripts which help the >>> extension, located in /extras/ in its source. The problem currently is >>> that if you install pg_partman via pgxn or package, you don'

Re: [HACKERS] Commitfest II CLosed

2013-10-23 Thread Josh Berkus
On 10/23/2013 05:38 AM, Noah Misch wrote: > We say little about > the correct aspects of a patch; it's usually a given that things not mentioned > are satisfactory and have self-evident value. That's not such an effective > discussion pattern when the topic is management strategies. It's not an e

[HACKERS] RULE regression test fragility?

2013-10-23 Thread Mike Blackwell
While reviewing the Network Stats Traffic patch I discovered the current regression test for rules depends on the system view definitions not changing: -- -- Check that ruleutils are working -- SELECT viewname, definition FROM pg_views WHERE schemaname <> 'information_schema' ORDER BY viewname;

Re: [HACKERS] Using indexes for ORDER BY and PARTITION BY clause in windowing functions

2013-10-23 Thread Sameer Kumar
On Wed, Oct 23, 2013 at 10:58 PM, Tom Lane wrote: > Sameer Kumar writes: > > I am not sure why but my PostgreSQL does not seem to be using indexes for > > ORDER BY clause or PARTITION BY CLAUSE which I use with windowing > function. > > When the entire contents of the table have to be read, a se

Re: [HACKERS] Location for external scripts for Extensions?

2013-10-23 Thread Josh Berkus
Dimitri, > Josh Berkus writes: >> pg_partman has several external (python) scripts which help the >> extension, located in /extras/ in its source. The problem currently is >> that if you install pg_partman via pgxn or package, you don't get those >> scripts, because there's no "install" location

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Stephen Frost
Josh, * Josh Berkus (j...@agliodbs.com) wrote: > On the other hand, it's still true that a high STDDEV indicates a high > variance in the response times of a particular query, whereas a low one > indicates that most are close to the average. While precision math > might not work if we don't have

Re: [HACKERS] Sigh, my old HPUX box is totally broken by DSM patch

2013-10-23 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote: > > Would this make sense as a configure-time check, rather than initdb, to > > try blocking SIGSYS and checking for an ENOSYS from shm_open()? Seems > > preferrable to do that in a configure che

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Josh Berkus
All, Bringing this down to Earth: yes, it would be useful to have min and max for pg_stat_statement, and even if we add more stats to pg_stat_statement, it would be useful to have those two. So can we approve this patch on that basis? For my part, I generally use the 9-part percentiles for quer

Re: [HACKERS] Commitfest II CLosed

2013-10-23 Thread Michael Banck
On Mon, Oct 21, 2013 at 11:10:09AM -0400, Tom Lane wrote: > Heikki Linnakangas writes: > > On 21.10.2013 16:15, Peter Eisentraut wrote: > >> What is the alternative? > > > If no-one really cares enough about a patch to review it, mark it as > > "rejected, because no-one but the patch author care

Re: [HACKERS] Commitfest II CLosed

2013-10-23 Thread Robert Haas
On Wed, Oct 23, 2013 at 8:38 AM, Noah Misch wrote: > On Tue, Oct 22, 2013 at 12:27:13PM -0700, Josh Berkus wrote: >> When I came up with the idea of CommitFests they were supposed to be an >> incremental improvement for us to build on. Instead it's remained >> frozen in amber, and steadily becomi

Re: [HACKERS] Sigh, my old HPUX box is totally broken by DSM patch

2013-10-23 Thread Robert Haas
On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I agree with Robert that it's odd and obnoxious that the call doesn't just >> return with errno = ENOSYS. However, looking in the archives turns up >> this interesting historical info: >> http://www

Re: [HACKERS] Sigh, my old HPUX box is totally broken by DSM patch

2013-10-23 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > I agree with Robert that it's odd and obnoxious that the call doesn't just > return with errno = ENOSYS. However, looking in the archives turns up > this interesting historical info: > http://www.postgresql.org/message-id/25564.962066...@sss.pgh.pa.us Wow,

Re: [HACKERS] Sigh, my old HPUX box is totally broken by DSM patch

2013-10-23 Thread Tom Lane
Stephen Frost writes: > I'm going to guess this idea is a non-starter, but any hope there's some > other system call which would tell us we're on a platform where > shm_open() will hit us with SIGSYS? What happens when shm_unlink() is > called on this platform? Or mmap()? For context's sake, th

Re: [HACKERS] Using indexes for ORDER BY and PARTITION BY clause in windowing functions

2013-10-23 Thread Tom Lane
Sameer Kumar writes: > I am not sure why but my PostgreSQL does not seem to be using indexes for > ORDER BY clause or PARTITION BY CLAUSE which I use with windowing function. When the entire contents of the table have to be read, a seqscan-and-sort will frequently be estimated as cheaper than an

Re: [HACKERS] Sigh, my old HPUX box is totally broken by DSM patch

2013-10-23 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: > I don't think a configure-time test is a good idea because there's no > guarantee that the configure-time machine and the run-time machine > have the same behavior. But having initdb fork a child process to run > the test seems like a reasonable way f

Re: [HACKERS] Sigh, my old HPUX box is totally broken by DSM patch

2013-10-23 Thread Tom Lane
Robert Haas writes: > On Tue, Oct 22, 2013 at 10:07 PM, Tom Lane wrote: >> selecting dynamic shared memory implementation ... Bad system call(coredump) > Well, geez. That's obnoxious. I quite agree :-(. If it were just this old HPUX version, maybe we could write it off as something we don't c

Re: [HACKERS] Sigh, my old HPUX box is totally broken by DSM patch

2013-10-23 Thread Robert Haas
On Tue, Oct 22, 2013 at 10:07 PM, Tom Lane wrote: > initdb.c quoth: > > * ... but the fact that a platform has shm_open > * doesn't guarantee that that call will succeed when attempted. > > Indeed: > > $ initdb > The files belonging to this database system will be owned by user "postgres". > Thi

[HACKERS] Using indexes for ORDER BY and PARTITION BY clause in windowing functions

2013-10-23 Thread Sameer Kumar
Hi, I was dealing with windowing function recently. I feel they are pretty useful and quite handy in lot of operations. I am not sure why but my PostgreSQL does not seem to be using indexes for ORDER BY clause or PARTITION BY CLAUSE which I use with windowing function. I have tried ORDER BY and G

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-23 Thread Tom Lane
David Rowley writes: > On Wed, Oct 23, 2013 at 4:00 AM, Tom Lane wrote: >> Yeah. As a separate matter, it might be useful to revise stringinfo.c >> and the asprintf code so that *if* the returned value is larger than the >> given buffer size, we use it as a guide to resizing, avoiding the possib

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-23 Thread Tom Lane
Florian Weimer writes: > Do you care about the snprintf behavior on very large buffers (larger > than INT_MAX)? Then there's further complication, and it's an area > where glibc behavior is likely to change in the future (because it is > claimed that C99 and POSIX conflict, and glibc implement

Re: [HACKERS] Commitfest II CLosed

2013-10-23 Thread Noah Misch
On Tue, Oct 22, 2013 at 12:27:13PM -0700, Josh Berkus wrote: > When I came up with the idea of CommitFests they were supposed to be an > incremental improvement for us to build on. Instead it's remained > frozen in amber, and steadily becoming less and less effective. I've > suggested a number of

Re: [HACKERS] all_visible replay aborting due to uninitialized pages

2013-10-23 Thread Heikki Linnakangas
On 22.10.2013 14:14, Andres Freund wrote: Hi Robert, Heikki, On 2013-09-24 13:25:41 +0200, Andres Freund wrote: I'm afraid this patch was a few bricks shy of a load. The log_newpage_buffer() function asserts that: /* We should be in a critical section. */ Assert(CritSectionCou

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-23 Thread David Rowley
On Wed, Oct 23, 2013 at 4:00 AM, Tom Lane wrote: > Yeah. As a separate matter, it might be useful to revise stringinfo.c > and the asprintf code so that *if* the returned value is larger than the > given buffer size, we use it as a guide to resizing, avoiding the possible > need to loop multiple

Re: [HACKERS] Review of pg_rewind

2013-10-23 Thread Samrat Revagade
On Wed, Oct 23, 2013 at 2:54 PM, Michael Paquier wrote: > Hi, > > Thanks for the feedback. Btw, pg_rewind is not a project included in > Postgres core as a contrib module or anything, so could you send your > feedback and the issues you find directly on github instead? The URL > of the project is

Re: [HACKERS] Review of pg_rewind

2013-10-23 Thread Michael Paquier
Hi, Thanks for the feedback. Btw, pg_rewind is not a project included in Postgres core as a contrib module or anything, so could you send your feedback and the issues you find directly on github instead? The URL of the project is https://github.com/vmware/pg_rewind. Either way, here are some comm

[HACKERS] Review of pg_rewind

2013-10-23 Thread Samrat Revagade
While testing pg_rewind I encountered following problem. I used following process to do the testing, Please correct me if I am doing it in wrong way. Problem-1: pg_rewind gives error (target master must be shut down cleanly.) when master crashed unexpectedly. 1. Setup Streaming Replication (stan

Re: [HACKERS] Reasons not to like asprintf

2013-10-23 Thread Florian Weimer
On 10/22/2013 11:06 PM, Tom Lane wrote: Attached is a draft, which compiles though I've not yet actually tested it. nprinted = vsnprintf(buf, len, fmt, args); Assert(buf[len - 1] == '\0'); The assert may fire if len > INT_MAX and the system returns with errno == EOVERFLOW, a