Re: [HACKERS] Add more regression tests for ASYNC

ith any test that creates a view test: rules -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] [9.3 CF 1] 2 Weeks In & The problem with Performance Patches

(1) if you are qualified to review any of the above, please get started *now*, and leave the non-performance patches for later; (2) ideas on how we can speed up/parallelize performance testing efforts are extremely welcome. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

f USE_POSIX_FALLOCATE. >> Thanks! > > Thank you. > > Greg, are you still working on those tests? Since Greg seems to be busy, what needs to be done to test this? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] [RFC] Minmax indexes

ave the very basic minmax indexes -- the one where we just flag pages as invalid if they get updated -- go into 9.4. That would still work for large, WORM tables, which are a significant and pervasive use case. If Alvaro gets to it, I think the "updating the range, rescan at VACUUM time" ap

Re: [HACKERS] patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

3) time required to read rows with each of 100 random column positions = some value 4) time required to insert 1000 rows 5) time required to update 1000 rows Geez, I feel tired just thinking about it. Jamie, can your team do any of this? -- Josh Berkus PostgreSQL Experts Inc. http://

Re: [HACKERS] ASYNC Privileges proposal

r one without the other. Also, someone would need to do performance tests to see how much the permissions check affects performance. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Kudos for Reviewers -- straw poll

> If we're going to try harder to ensure that reviewers are credited, > it'd probably be better to take both the commit log and the release > notes out of that loop. I'd pull the reviewers out of the CF app. Even in its current implementation, that's the ea

Re: [HACKERS] patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

All, So, is this patch currently depending on performance testing, or not? Like I said, it'll be a chunk of time to set up what I beleive is a realistic performance test, so I don't want to do it if the patch is likely to be bounced for other reasons. -- Josh Berkus PostgreSQL Experts

Re: [HACKERS] Kudos for Reviewers -- straw poll

for 9.3, in order to encourage more reviewers, and encourage reviewers to do more reviews. But that would only work if we're also giving reviewers credit; as several people have said, they care more about credit than they do about prizes. -- Josh Berkus PostgreSQL Experts Inc. http://pgexpe

Re: [HACKERS] fixing pg_ctl with relative paths

On Wed, Jun 26, 2013 at 12:22 PM, Fujii Masao wrote: > On Wed, Jun 26, 2013 at 2:36 PM, Hari Babu wrote: >> On June 26, 2013 5:02 AM Josh Kupershmidt wrote: >>>Thanks for the feedback. Attached is a rebased version of the patch with >> the two small issues noted

[HACKERS] Testing Cascading Replication

at 0/3E00 on timeline 2 LOG: redo starts at 0/3E84 Now, at this time it has successfully connected to the master and started working again. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Spin Lock sleep resolution

cycle that patches which are still under contentious discussion which blocks commit are "waiting on author" rather than some other status. It was not clear to me (or to Mike) that the dicussion on this patch was concluded favorably. Is it? -- Josh Berkus PostgreSQL Experts Inc. http://pgex

Re: [HACKERS] Add more regression tests for dbcommands

orner cases quite systematically, and I feel that it > would be sad if they were lost. My thinking was that someone should add all of his new tests at once, and then see how much of a time difference they make. If it's 7 seconds, who cares? -- Josh Berkus PostgreSQL Experts Inc. http:/

Re: [HACKERS] Kudos for Reviewers -- straw poll

code revision work, like in your FK patch, get listed after the original patch author with the patch, and reviewers do more lightweight reviews get listed at the bottom of the release notes? Seems fair to me. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers

Re: [HACKERS] Add more regression tests for CREATE OPERATOR

cleanly on trunk code. All tests pass, > the test coverage increses as provided."? Or do you expect some more info? Yes, mainly: a) does it test what it purports to test? b) do the tests pass on your machine? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via p

Re: [HACKERS] Add more regression tests for CREATE OPERATOR

's ready or not if he doesn't have a full report from you. Thanks! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

or for 9.5. So, this isn't stopping the patch; I just want a TODO for "implement WITH ORDINALITY in the target list for SRFs". -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chan

Re: FILTER for aggregates [was Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division]

, what other DBMSes support this feature? Will being non-spec introduce migration pain? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

h there would not be an objection. Please plow ahead. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] fixing pg_ctl with relative paths

e patch is good. It makes the pg_ctl restart functionality works > well. Thanks for the feedback. Attached is a rebased version of the patch with the two small issues noted fixed. Josh pgctl_paths.v02.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pluggable compression support

On 06/25/2013 12:23 PM, Tom Lane wrote: > Josh Berkus writes: >> However, can you tell me what exactly you are concerned about? lz4 is >> under the BSD license, and released by Google. Why are we worried, exactly? > > Patents. The license on the code doesn't matter --

Re: [HACKERS] pluggable compression support

es than other work in postgres... We have access to attorneys, both in the US and Canada. I will proceed to ask for real legal advice. However, can you tell me what exactly you are concerned about? lz4 is under the BSD license, and released by Google. Why are we worried, exactly? -- Josh Berkus P

Re: [HACKERS] Kudos for Reviewers -- straw poll

vial patch. On the other hand, I will point out that we currently have a shortage of reviewers, and we do NOT have a shortage of patch submitters. Seems like we should apply incentives where we need help, no? Mind you, my votes are (B), (A), and (A). -- Josh Berkus PostgreSQL Exper

Re: [HACKERS] Kudos for Reviewers -- straw poll

istration and airfare to pgCon. Seems apropos and without the horrible logistics issues of mailing tshirts to 15 countries. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: ht

[HACKERS] Kudos for Reviewers -- straw poll

a "prize", such as a t-shirt, as a promotion to increase the number of non-submitter reviewers? a) yes b) no c) yes, but submitters and committers should get it too Thanks for your feedback! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers m

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

he general crumminess of using CVS [3]. Josh [1] http://pgfoundry.org/scm/browser.php?group_id=1000541 [2] http://pgfoundry.org/forum/forum.php?thread_id=15554&forum_id=44&group_id=113 [3] Since the pgfoundry cvs server apparently doesn't support the 'ls' command, you mi

Re: [HACKERS] patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

o the other performance issues involved. I started evaluating this patch just because I'm one of the few people with a realistic test case. Anyway, let's decide if acceptance of this patch hinges on performance or not. I'll take me a whole evening to set up a good performance test, s

Re: [HACKERS] patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

efficiently, then it would win us some users, since other RDMBSes don't. However, there are multiple issues with having hundreds of columns, of which storage optimization is only one ... and probably the smallest one at that. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via

Re: [HACKERS] patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

didn't think the previous performance test was comprehensive; I was planning to develop one myself this week. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PLR does not install language templates

not CREATE LANGUAGE to > install PLs, and for that you don't need a pltemplate entry. It's > likely that pg_pltemplate will disappear entirely before long. Ah, ok. Thanks! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-h

[HACKERS] PLR does not install language templates

| plpython2u | f | f | plpython2_call_handler | plpython2_inline_handler | plpython2_validator | $libdir/plpython2 | plpython3u | f | f | plpython3_call_handler | plpython3_inline_handler | plpython3_validator | $libdir/plpython3 | (8 rows) -- Josh

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

t; > I'm not sure if such a strict policy will bring anything good. If newbies > won't be able to review patches, they won't be committing simple patches, > as they won't be able to review others. Commit a simple patch, review a simple patch. If we have 20 submitters of

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

My proposal was to have a compiled list of reviewers at the end of the release notes, in the form of: "Reviewers and Testers for #.# Included: name, name, name, name" That way we can pick up the trivial reviewers as well, and even testers who are not otherwise contributors. -- Josh Berku

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

ople. It's not like it costs us money, you know. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

CF, though the > recent "review it within 5 days or else" policy combined with a ton of > my own work has kept me back so far. Thanks! Your help is much appreciated, on whatever schedule you can do it! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via p

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Mon, Jun 24, 2013 at 12:57 PM, Josh Berkus wrote: > Actually, every submitter on that list -- including Maciej -- was sent a > personal, private email a week ago. A few (3) chose to take the > opportunity to review things, or promised to do so, including a brand > new Chinese con

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

JD said: > Leave your ego at the door. Josh is doing what could be considered one > of the most thankless (public) jobs in this project. How about we > support him in getting these patches taken care of instead of whining > about the fact that he called us out for not doing our job

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

>> I will be more than happy to resign as CFM and turn it over to someone >> else if people have a problem with it. > > Heck, Josh. People have to be allowed to critize *a small part* of your > work without you understanding it as a fundamental request to step back > fr

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

which it's impossible to ship from abroad. I have previously proposed that all of the reviewers of a given PostgreSQL release be honored in the release notes as a positive incentive, and was denied on this from doing so. Not coincidentally, we don't seem to have any reviewers-at-large an

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On 06/24/2013 10:02 AM, Dimitri Fontaine wrote: > Josh Berkus writes: >> patch. The vast majority chose not to respond to my email to them at >> all. When private email fails, the next step is public email. > > The only problem I have here is that I don't remember abo

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

to do patch review. Per both of my emails yesterday, I am trying to make sure that this CF finishes on time. Following the rules passed at the developer meetings for how CFs are to be run, I am doing so. If the result is unsatisfactory, I can always resign as CFM. -- Josh Berkus PostgreSQL Expert

[HACKERS] [9.4 CF 1] The Commitfest Slacker List

t Revagade Alexander Lakhin Mark Kirkwood Liming Hu Maciej Gajewski Josh Kuperschmidt Mark Wong Gurjeet Singh Robins Tharakan Tatsuo Ishii Karl O Pinc Additionally, the following committers are not listed as reviewers on any patch. Note that I have no way to search which ones might be *committers*

[HACKERS] [9.4 CF 1] Commitfest Week One

g WAL, XLogInsert scaling, preserving forensic information when we freeze, remove PD_ALL_VISIBLE. These shoud be addressed early so that we can work out the conflicts between them. So, some progress, but more is needed. --Josh Berkus CommitFest Manager -- Josh Berkus PostgreSQL Experts Inc.

Re: [HACKERS] Naming of ORDINALITY column

vers both columns? What does that look like, syntactically? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fixed Cardinality estimation with equality predicates between column of the same table

On 06/21/2013 02:33 PM, desmodemone wrote: > Hi all, > I see a strange behavior ( for me ) on 9.2 (but seems the same on > 9.1 and 9.3) of the optimizer on query like that : > Matteo, I just posted this on -performance. See Tom's answer. -- Josh Berkus PostgreSQL

Re: [HACKERS] Hardware donation

>> Who can be point of contact from the community to arrange shipping, etc? > > I can be. And I'll handle the tax credit once the servers are received. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgr

Re: [HACKERS] Hardware donation

s if that matters). > > Local drives are nothing fancy (though some might possibly be SSD). I'm sure we could use these for the performance test farm. If we need to replace some of the drives, the community has money for that. -- Josh Berkus PostgreSQL Experts Inc. http://pgex

Re: [HACKERS] Why can't I use windowing functions over ordered aggregates?

nd > UNBOUNDED FOLLOWING) from foo; > > What do you expect "SELECT first(val order by ts desc)" to output ? > Ah, right, I see what you mean. Yeah, I was doing queries without peer rows, so it looked the same to me, and it uses some of the same machinery. But of course it

[HACKERS] Why can't I use windowing functions over ordered aggregates?

x27;s the exact same operation. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)

ah, fix those babies!"), I think we don't have a choice about creating new function names and then waiting three years to deprecate the old ones. We really can't afford to put obstacles in the way of people upgrading, especially over an issue as minor as this one. -- Josh Berkus Postg

[HACKERS] isolationtester and 'specs' subdirectory

Hi all, I have a Debian machine with gcc 4.7.2-5 where make check-world fails in the isolation check, like so: ... make[2]: Leaving directory `/home/josh/src/postgresql/src/test/regress' make -C isolation check [snip] gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On 06/19/2013 10:48 AM, Peter Eisentraut wrote: > On 6/13/13 5:47 PM, Josh Berkus wrote: >>> 2. File name to store settings set by ALTER SYSTEM command is still >>>> persistent.auto.conf >> Why? Shouldn't it just be auto.conf? Or system.auto.conf? >> >

Re: [HACKERS] How do we track backpatches?

> I'd imagine having a "CF" entry per release, so after a set of minor > releases, the "CF" is closed. How would we name these? Also, what about patches for beta? Should we have a "beta" CF? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com

Re: [HACKERS] SET work_mem = '1TB';

On 06/18/2013 10:59 AM, Simon Riggs wrote: > Thanks. Please delete the patch marked "Batch API for After Triggers". > All others are submissions by me. The CF app doesn't permit deletion of patches, so I marked it "returned with feedback". -- Josh Berk

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

quot; as a choice above all of the previous: 1) short 2) significantly different from "postgresql.conf" 3) near the beginning of the alphabet, so it should sort near the top if there are other files in conf/ directory -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com --

Re: [HACKERS] SET work_mem = '1TB';

seems churlish of me to interrupt that commit. Well, I think that someone needs to actually test doing a sort with, say, 100GB of RAM and make sure it doesn't crash. Anyone have a machine they can try that on? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent vi

Re: [HACKERS] ASYNC Privileges proposal

UBLIC; GRANT LISTEN ON 'cacheupdates' TO webuser; GRANT LISTEN ON ALL TO admin; I can certainly see wanting this, but it'd be a great deal more sophisticated than what Chris has proposed. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mail

[HACKERS] How do we track backpatches?

(like the autovacuum fix) which were submitted by general contributors. The same goes for beta fixes. Should we add a "prior version" category to the CF to make sure these don't get dropped? Or do something else? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent

Re: [HACKERS] [9.4 CF 1] Added in missing patches

> Just wondering, how many patches did you add? 8? I saw a total of 98 > patches a couple of days ago, now up to 106. Then it must be 8. That sounds a about right. Mind you, I immediately marked 2 as already committed. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com --

[HACKERS] [9.4 CF 1] What the 5-day Deadline Means

they know they won't have time to review something. It doesn't benefit the CF process to have names down of people who aren't actually doing reviews. Thanks! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

[HACKERS] [9.4 CF 1] Added in missing patches

ven a committer. In some cases, I may have accidentally added a patch whose status is already resolved; if so, that's because I couldn't determine the resolution status. Better to add some unnecessary patch entries than to miss a patch. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On 06/17/2013 01:40 PM, Alvaro Herrera wrote: > Andres Freund wrote: > >> PS: Josh, minor thing, but could you please not trim the CC list, at >> least when I am on it? > > Yes, it's annoying. I also get private comments from people who don't want me to cc them

Re: [HACKERS] [RFC] Minmax indexes

(or maybe not). Well, my first thought was "block-range indexing", which I think is the best description, but that isn't exactly an exciting name for a feature which will likely be worthy of short-listing for 9.4. I'd prefer it over minmax, which users will think only works on

Re: [HACKERS] Support for REINDEX CONCURRENTLY

n is fair. Having it would have made > several previous point releases far less painful (e.g. 9.1.6/9.2.1). FWIW, I have a client who needs this implementation enough that we're backporting it to 9.1 for them. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pg

Re: [HACKERS] refresh materialized view concurrently

remental maintenance, I have no objections. Actually, CONCURRENTLY was cited as the #1 deficiency for the matview feature for 9.3. With it, the use-case for Postgres matviews is broadened considerably. So it's very valuable on its own, even if (for example) INCREMENTAL didn't get done for 9.3

Re: [HACKERS] [RFC] Minmax indexes

ly > needed, but I doubt it will be needed - in just the same way as mat > views aren't greedily updated. Ok, in that case, can we add the patch without messing with the FSM logic? It'll work out-of-the-box for append-only tables, and that's a pretty solid use case. --

Re: [HACKERS] [9.4 CF 1] Commit Fest has started

Amit, > I am interested in assisting you for this CF. > Kindly let me know how can I add value for CommitFest management. Thank you for the offer! However, you're currently signed up to review several patches, and I'd rather have you doing that than sending out reminder emails.

[HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

On Fri, Mar 8, 2013 at 11:58 AM, Pavel Stehule wrote: > I'll see - please, stay tuned to 9.4 first commitfest Hi Pavel, Just a reminder, I didn't see this patch in the current commitfest. I would be happy to spend some more time reviewing if you wish to pursue the patch. Josh

Re: [HACKERS] [RFC] Minmax indexes

e index block range faster, not ways to modify how we append to the heap. If we told users "tables with Minmax indexes will be very expensive to update" then I think they'd live with it; dropping and readding an index to enable fast updates is something which is already familiar.

Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages

Hackers, Amit posted a new version of this patch on January 23rd. But last comment on it by Tom is "not sure everyone wants this". https://commitfest.postgresql.org/action/patch_view?id=905 ... so, what's the status of this patch? -- Josh Berkus PostgreSQL Experts Inc. http:

[HACKERS] [9.4 CF 1] Commit Fest has started

like a committer to take responsibility for the large set of Regression Test additions in this CF. * I'd like a committer to take responsibility for Logical Changeset Generation *now* so that it doesn't wait until the last week of the commitfest. Thanks, all, and Review, Review, Review! -- J

Re: [HACKERS] request a new feature in fuzzystrmatch

Liming, I've added your proposal in to the commitfest so that you can get a review this commitfest. However, you need to generate a context diff and submit it to this mailing list for it to really get reviewed. That's a requirement. -- Josh Berkus PostgreSQL Experts Inc. http://pge

Re: [HACKERS] request a new feature in fuzzystrmatch

Liming, I'm putting this in the commitfest regardless, so that it at least gets a review. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mai

Re: [HACKERS] pluggable compression support

o be sufficient. Then it's not "pluggable", is it? It's "upgradable compression support", if anything. Which is fine, but let's not confuse people. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] pluggable compression support

On 06/14/2013 04:01 PM, Andres Freund wrote: > It still contains a guc as described in the above message to control the > algorithm used for compressing new tuples but I think we should remove > that guc after testing. Did you add the storage attribute? -- Josh Berkus PostgreSQL Ex

Re: [HACKERS] [RFC] Minmax indexes

for a prospective "append-only table" and bundle those, rather than tying it to whether a certain index exists or not. Also, I hate the name ... if this feature goes ahead, I'm going to be lobbying to change it. But that's pretty minor compared to the update issues. -- Josh Berku

Re: [HACKERS] Hard to Use WAS: Hard limit on WAL space

ke we're afraid of being polluted by the unwashed DevOps masses. In the meantime, Mongo kicks our butts a new user adoption. Why? Their features suck, but the features they do have are easy to use. You'd think we would have learned something from MySQL. -- Josh Berkus Pos

Re: [HACKERS] postgres user with automate rsync and private/public key pairs

Daniel, The pgsql-hackers mailing list is for people working on the PostgreSQL database engine itself. Please post your question to one of the following lists instead: pgsql-general pgsql-admin Or you can use our IRC channel: http://www.postgresql.org/community/irc/ Thanks! -- Josh Berkus

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

ue, | 'value'}; > > Modified patch contains: > > 1. Syntax implemented is > ALTER SYSTEM SET configuration_parameter {TO | =} {value, | 'value' | > DEFAULT}; > > If user specifies DEFAULT, it will remove entry from auto conf file. > > 2. File nam

Re: [HACKERS] [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)

I'm going to be disappointed if all we can get out of this is > a cardinality() function, and nothing is done about the empty-array > semantics. Well, we can't change the zero-dim behavior without breaking backwards compatibility. And enough people piled on to say NO to that, that it went

Re: [HACKERS] [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)

ad "arrays" in PostgreSQL ... we have always had matrixes. If you think about things that way, most of the current functionality makes sense. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] transforms

Peter, All: Does anyone feel like fixing the LOAD issue with transforms? I haven't seen any activity on the patch. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)

On 04/08/2013 07:16 PM, Brendan Jurd wrote: > On 9 April 2013 09:24, Josh Berkus wrote: >> As much as I have a keen interest in this feature, it isn't (AFAIK) >> being considered for 9.3. Given that it's generated a fair amount of >> controversy, could we table it

[HACKERS] 9.4 CF1 Starts Saturday: need patches, reviewers, asst. CFM

tant Commitfest Manager" to help with managing patches, authors and reviewers. Thanks! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

C} --quiet --archive --rsync-path=${RSYNC} ${SOURCE} \ ${REPLICA}:${DEST} if [ $? -ne 0 ]; then exit 1 fi -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

ample, not a recommendation. If we offer cp as an example, we *are* recommending it. If we don't recommend it, we shouldn't have it as an example. In fact, if we don't recommend cp, then PostgreSQL should ship with some example shell scripts for archive commands, just as we do for

Re: [HACKERS] Configurable location for extension .control files

it recursed (that is, looked for .so's in subdirectories). My reason for this is that I work on applications which have in-house extensions as well as public ones, and I'd like to keep the two separated by directory. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com --

Re: [HACKERS] ALTER DEFAULT PRIVILEGES FOR ROLE is broken

>> Agreed. > > Seems reasonable. Yaaaay! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

Josh, Daniel, >> Right now, what we're telling users is "You can have continuous backup >> with Postgres, but you'd better hire and expensive consultant to set it >> up for you, or use this external tool of dubious provenance which >> there's no packag

Re: [HACKERS] Vacuum, Freeze and Analyze: the big picture

derstand, and I helped design it. I think there's no question that it could be vastly improved. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Last log line for log_temp_files is disassociated with query

On 06/07/2013 04:52 PM, Josh Berkus wrote: > In many cases, this is what I see (9.2.4): > > session_line_num|message|query > 423|temporary file: path ...procid.0 file size: 525122|SELECT ... > 424|temporary file: path ...procid.1 file size: 622044|SELECT ... > 425|duration: 170

[HACKERS] Last log line for log_temp_files is disassociated with query

re request for pg_stat_statements: record cumulative on-disk sort size. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

l tool of dubious provenance which there's no packages for, or you might accidentally cause your database to shut down in the middle of the night." At which point most sensible users say "no thanks, I'll use something else". -- Josh Berkus PostgreSQL Experts Inc

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

to make it easier for the DBA to troubleshoot this, but I'm not sure what. We could use a hard limit for WAL to prevent WAL from contributing to out-of-space, but that'll only prevent a minority of cases. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql

Re: [HACKERS] Redesigning checkpoint_segments

gt; such a manual option in the attached, but that would be easy. Yeah, I'd really like to get away from adding manual options which need to be used in non-specialty cases. I think we'll need one at some point -- there are DB applications which are VERY bursty -- but let's not star

Re: [HACKERS] Redesigning checkpoint_segments

lica, so I don't think it's worth pursuing this line of thinking a lot further. In any case, I'm just pointing out that we need to think of wal_keep_segments as part of the total WAL size, and not as something seperate, because that's confusing our users. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Redesigning checkpoint_segments

Daniel, So your suggestion is that if archiving is falling behind, we should introduce delays on COMMIT in order to slow down the rate of WAL writing? Just so I'm clear. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-ha

Re: [HACKERS] Redesigning checkpoint_segments

re's a > sudden burst of activity. The number of segments preallocated is > auto-tuned, based on the number of segments used in previous checkpoint > cycles. "based on"; can you give me your algorithmic thinking here? I'm thinking we should have some calculation of la

Re: [HACKERS] Configurable location for extension .control files

suspect most packaging cases as well. This seems like it would work for Oliver's case. And I don't see how making the folder relocatable as an on-start option hurts our security at all; we're simply doing something which the same user could do with symlinks, only much more neatly.

Re: [HACKERS] pg_rewind, a tool for resynchronizing an old master after failover

advantages, in having the copyright rest with the original contributors. Mostly, it prevents relicensing of the whole project. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

<    9   10   11   12   13   14   15   16   17   18   >