Re: [HACKERS] ANALYZE sampling is too good

at a reasonable size, and even then I'll bet we have to offer a GUC. -- 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] Errors on missing pg_subtrans/ files with 9.3

Andres, all: We've just run across a case of this exact issue on 9.2.4. I thought it was supposed to be 9.3-only? -- 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

Re: [HACKERS] Errors on missing pg_subtrans/ files with 9.3

On 12/10/2013 10:39 AM, Andres Freund wrote: Hi, On 2013-12-10 10:38:32 -0800, Josh Berkus wrote: We've just run across a case of this exact issue on 9.2.4. I thought it was supposed to be 9.3-only? Could you please describe this exact issue? Fatal errors due to missing pg_subtrans

Re: [HACKERS] coredump of 9.3.2

... -- 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] Errors on missing pg_subtrans/ files with 9.3

On 12/10/2013 10:48 AM, Andres Freund wrote: On 2013-12-10 10:44:30 -0800, Josh Berkus wrote: On 12/10/2013 10:39 AM, Andres Freund wrote: Hi, On 2013-12-10 10:38:32 -0800, Josh Berkus wrote: We've just run across a case of this exact issue on 9.2.4. I thought it was supposed to be 9.3

Re: [HACKERS] ANALYZE sampling is too good

. As discussed, we need math though. Does anyone have an ACM subscription and time to do a search? Someone must. We can buy one with community funds, but no reason to do so if we don't have to. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list

Re: [HACKERS] plpgsql_check_function - rebase for 9.3

of one, offhand. And +1 for NOT adding a new knob. -- 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] ANALYZE sampling is too good

sampled are representative of the population. -- 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] ANALYZE sampling is too good

. You do seem kind of hostile to the idea of full-page-sampling, going pretty far beyond the I'd need to see the math. Why? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] ANALYZE sampling is too good

. Nobody has done an analysis of whether it's worse, on average, to estimate low vs. high for ndistinct. -- 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

Re: [HACKERS] ANALYZE sampling is too good

. -- 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] ANALYZE sampling is too good

recoginze common distribution patterns, then not only could we have better query estimates, those would require keeping *fewer* stats, since all you need for a normal distribution are the end points and the variance. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql

Re: [HACKERS] dblink performance regression

All, I tested out Joe's original patch, and it does eliminate the 8% performance regression. Will try the new one. -- 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

Re: [HACKERS] WITHIN GROUP patch

syntax alternatives we're talking about here? I've lost track. -- 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] Why we are going to have to go DirectIO

manage that have already said that MMAP is a bad interface for persistent RAM. They haven't defined a good one, though. -- 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

Re: [HACKERS] Why we are going to have to go DirectIO

On 12/05/2013 05:48 AM, Stephen Frost wrote: * Peter Geoghegan (p...@heroku.com) wrote: On Wed, Dec 4, 2013 at 11:07 AM, Josh Berkus j...@agliodbs.com wrote: But you know what? 2.6, overall, still performs better than any kernel in the 3.X series, at least for Postgres. What about the fseek

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

feature added. -- 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] Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

when PostgreSQL encounters a bug, data corrpution, or platform error. Right now, I have to suss those out by regex. -- 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

Re: [HACKERS] Why we are going to have to go DirectIO

On 12/05/2013 12:41 PM, Robert Haas wrote: On Thu, Dec 5, 2013 at 12:54 PM, Josh Berkus j...@agliodbs.com wrote: Actually, I've been able to do 35K TPS on commodity hardware on Ubuntu 10.04. I have yet to go about 15K on any Ubuntu running a 3.X Kernel. The CPU scheduling on 2.6 just seems

Re: [HACKERS] ANALYZE sampling is too good

, but of course, I don't know which specific algo they use. -- 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] Why we are going to have to go DirectIO

On 12/04/2013 07:33 AM, Jonathan Corbet wrote: Wow, Josh, I'm surprised to hear this from you. Well, I figured it was too angry to propose for an LWN article. ;-) The active/inactive list mechanism works great for the vast majority of users. The second-use algorithm prevents a lot

Re: [HACKERS] Why we are going to have to go DirectIO

, for 3.13) and running a few benchmarks on it. If you report a performance regression at that stage, it will get attention. Yeah, back to the we need resources for good benchmarks discussion fork ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing

[HACKERS] Why we are going to have to go DirectIO

with the potential to destroy PostgreSQL performance without warning, leaving us scrambling for workarounds. Too bad the alternatives are so unpopular. I don't know where we'll get the resources to implement our own storage, but it's looking like we don't have a choice. -- Josh Berkus PostgreSQL

Re: [HACKERS] Why we are going to have to go DirectIO

it. -- 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] Why we are going to have to go DirectIO

., Mark or me for 6 solid months to develop them, since worthwhile open source performance test platforms currently don't exist. That money has never been available; maybe I should do a kickstarter. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing

Re: [HACKERS] Why we are going to have to go DirectIO

money and having an open bid process for the person to do the work. I think we cold raise more money that way, and are likely to get a better end result. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Draft release notes for 9.3.2

, what? -- 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] Visual Studio 2013 build

problems foreseeable. I will add it to the CommitFest 2014-01 so that there is time for testing and tweaking. Wow, thanks for doing this! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

to support the syntax of this feature in commonly used ORMs. That is, can I write a fairly small Django or Rails extension which does upsert using this patch? Fortunately, I think I can ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] pre-commit triggers

On 11/24/2013 06:42 AM, Simon Riggs wrote: I think we should be thinking harder about how to implement ASSERTIONs, possibly calling them ASSERTION TRIGGERs not pre-commit write event triggers. I don't know that anyone is working on this, though, or even plans to. -- Josh Berkus PostgreSQL

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

has all those squiggly brackets. PostgreSQL is very accepting of new procedural languages; you could always create your own, with whatever syntax you want. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] pre-commit triggers

On 11/26/2013 09:45 AM, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: On 11/24/2013 06:42 AM, Simon Riggs wrote: I think we should be thinking harder about how to implement ASSERTIONs, possibly calling them ASSERTION TRIGGERs not pre-commit write event triggers. I don't know

Re: [HACKERS] Can we trust fsync?

. I guess we could reimplement this in C if someone wants to do the legwork. Yeah, too bad Brad didn't post a license for it. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] additional json functionality

, and a situation similar to this: http://xkcd.com/927/ Apparently you missed that JSONB is just Hstore2 with different in/out functions? Postgres' greatest and most under-advertised feature is it's extensibility. I agree that we don't do enough to promote our extensions. -- Josh Berkus PostgreSQL Experts

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

on the master, you can't trigger the bug? -- 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] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

it already has corruption. -- 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] -d option for pg_isready is broken

through the shell (as I currently do with pg_isready). -- 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] additional json functionality

of trouble to extend our home-grown format if we've got a standard format to plug into? See hstore2 patch from Teodor. That's what we're talking about, not hstore1, which as you point out is non-heirarchical. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers

Re: [HACKERS] Storage formats for JSON WAS: additional json functionality

for heirarchical data storage, but practically it's not. Of course, an investigation into this by someone with much more knowledge of low-level storage than me (most of this list) is welcome. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

Andrews, Kevin: Presumably a replica created while all traffic was halted on the master would be clean, correct? This bug can only be triggered if there's heavy write load on the master, right? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

On 11/20/2013 10:30 AM, Josh Berkus wrote: Andrews, Kevin: Andres, that is. Presumably a replica created while all traffic was halted on the master would be clean, correct? This bug can only be triggered if there's heavy write load on the master, right? Also, just to verify

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

questsions? Yeah, thanks. If you have any ideas for how we'd write code to scan for this kind of corruption, please post them. -- 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

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

, the combination of those is guilty. Man, this is (to a good part my) bad. But that'd mean nobody noticed it during 9.3's beta... Ah, so this affected 9.3.0 as well? Maybe it's worth it now to devise some automated replication testing? -- Josh Berkus PostgreSQL Experts Inc. http

Re: [HACKERS] additional json functionality

not significant * reordering of keys * duplicate keys prohibited If people want other manglings of JSON, they can use TEXT fields and custom parsers written in PL/v8, the same way I do. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers

Re: [HACKERS] More legacy code: pg_ctl

On 11/19/2013 08:29 AM, Robert Haas wrote: On Mon, Nov 18, 2013 at 8:20 PM, Josh Berkus j...@agliodbs.com wrote: Oh, and one more: c) that stop defaults to smart mode, instead of fast mode. And that smart mode is called smart instead of footgun. Right, exactly. Personally, I can't think

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

On 11/19/2013 09:58 AM, Andres Freund wrote: On 2013-11-19 09:51:28 -0800, Josh Berkus wrote: Maybe it's worth it now to devise some automated replication testing? It'd be a good idea, but I am not sure where to get resources for it from. Well, servers isn't hard ... various cloud companies

Re: [HACKERS] -d option for pg_isready is broken

does pg_isready have its own code for this? -- 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] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

certainly do know that we won't catch these kinds of bugs *without* testing. Heck, even MySQL AB had automated testing for replication. They largely ignored the results, but they had it. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

. I can't see how you expect to complete streaming logical replication without a replication testing framework. -- 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

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

, just that you should be worried about it, and maybe shouting for help. -- 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] pre-commit triggers

tables were modified and how. This is the sort of thing the SQL committee covered in ASSERTIONS, but of course they never specified any method for implementation. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

on our side. -- 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] additional json functionality

On 11/18/2013 06:13 AM, Peter Eisentraut wrote: On 11/15/13, 6:15 PM, Josh Berkus wrote: Thing is, I'm not particularly concerned about *Merlin's* specific use case, which there are ways around. What I am concerned about is that we may have users who have years of data stored in JSON text

Re: [HACKERS] additional json functionality

. Note that this raises the issue of first alternate data type ambiguity again for overloading builtin functions. We really need that method of prefering a specific version of the function ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] CLUSTER FREEZE

, which is going to be an almost zero population. +1 None of our users would willingly choose worse performance over the 0.1% possibility of needing to analyze a transaction failure. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

for the same client (9.0.14 and 9.3.1), one for a different client (9.2.5). To emphasize a salient point: we have not previously seen data corruption with these exact symptoms prior to the recent patch release. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers

[HACKERS] More legacy code: pg_ctl

script. I don't know if the answer is to rename the utility like we're discussing with pg_dump/pg_backup, or something else. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] More legacy code: pg_ctl

On 11/18/2013 05:09 PM, Josh Berkus wrote: Folks, Speaking of legacy code with bad default behaviors: pg_ctl. The current utility is designed to fathfully reproduce the rather hackish shell script we originally had for postgres startup. This results in a couple of unintuitive defaults

Re: [HACKERS] additional json functionality

by these people: http://www.jstor.org/ ;-) -- 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] additional json functionality

, and it gives people the idea that this is the successor type to JSON. So +1 from me as well on JSONB. -- 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

Re: [HACKERS] additional json functionality

-dependant type That's not at all workable. Users would be completely unable to predict or understand the JSON type and how it acts. That's not just violating POLS; that's bashing POLS' head in with a shovel. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers

Re: [HACKERS] Turning recovery.conf into GUCs

-function] those are functions that are no longer used but Josh considered they could become useful before release. i can put them inside #ifdef _NOT_USED_ decorations or just remove them now and if/when we find some use for them re add them Wait, which Josh? Not me ... -- Josh Berkus

Re: [HACKERS] additional json functionality

the possibility that a future binary type might need to be a separate type due to compatibility issues. The only sad thing is the naming; it would be better for the new type to carry the JSON name in the future, but there's no way to make that work that I can think of. -- Josh Berkus PostgreSQL

Re: [HACKERS] additional json functionality

roadblock to upgrading. -- 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] additional json functionality

with their standard. That's a reason why we won't use the name BSON, either, since it's a trademark of 10gen. -- 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

Re: [HACKERS] additional json functionality

() ) Yes, you could do this with a two-array version as well; it's just not more intuitive, and in cases where you have dozens of columns, puts you in column-counting hell. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] additional json functionality

having text JSON even after we have binary JSON. There's a strong simplicity argument against that, though ... -- 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

[HACKERS] -d option for pg_isready is broken

the utility. I'll note that the -U option doesn't appear to do anything relevant either, but at least it doesn't error unnecessarily: handyrep@john:~/handyrep$ pg_isready -h john -p 5432 -U no_such_user john:5432 - accepting connections -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com

Re: [HACKERS] pg_dump and pg_dumpall in real life

it.. +1 -- 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] pg_dump and pg_dumpall in real life

On 11/11/2013 03:06 PM, David Johnston wrote: Josh Berkus wrote Well, then we just need pg_restore to handle the role already exists error message gracefully. That's all. Or a CREATE ROLE IF NOT EXISTS statement, and use that for roles. My only qualm here is if the exists check is based

Re: [HACKERS] Changing pg_dump default file format

to pgsql-security. Even though the 8.1 driver had been officially deprecated for 2 years before the security issue was discovered. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Changing pg_dump default file format

to make filename a required parameter. If we wanted to change the defaults, I think it would be easier to create a separate bin name (e.g. pg_backup) than to change the existing parameters for pg_dump. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing

Re: [HACKERS] Changing pg_dump default file format

All, I'm amused at how this has become a let's pile on everything which has ever been missing in pg_dump into one thread. Agree with Tom that if we're going to create a new program name, we should fix the pg_dumpall issue as well. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com

Re: [HACKERS] [v9.4] row level security

All, Just a comment: I'm really glad to see the serious work on this. If RLS doesn't make it into 9.4, it'll be because the problems of RLS are fundamentally unsolvable, not because we didn't give it our best. Great work, all! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com

Re: [HACKERS] List of binary-compatible data types

to validate it, sure, but we don't need to rewrite it. -- 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] List of binary-compatible data types

binary JSON in 9.4 (Oleg?), then a binary conversion will be required, so maybe it's a moot point. -- 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

Re: [HACKERS] List of binary-compatible data types

could be useful for a lot of type conversions. I'd also love some way of doing a no-rewrite conversion between timestamp and timestamptz, based on the assumption that the original values are UTC time. That's one I encounter a lot. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com

[HACKERS] List of binary-compatible data types

or an unconstrained domain over the new type, a table rewrite is not needed ... Which is nice, but nowhere do we present users with a set of binary-compatible data types, even among the built-in types. I'd happily write this up, if I knew what the binary-compatible data types *were*. -- Josh

Re: [HACKERS] List of binary-compatible data types

Thom, SELECT castsource::regtype::text, array_agg(casttarget::regtype order by casttarget::regtype::text) casttargets FROM pg_cast WHERE castmethod = 'b' GROUP BY 1 ORDER BY 1; Are we actually covering 100% of these for ALTER COLUMN now? -- Josh Berkus PostgreSQL Experts Inc

Re: [HACKERS] List of binary-compatible data types

On 11/04/2013 05:21 PM, Josh Berkus wrote: Thom, SELECT castsource::regtype::text, array_agg(casttarget::regtype order by casttarget::regtype::text) casttargets FROM pg_cast WHERE castmethod = 'b' GROUP BY 1 ORDER BY 1; Are we actually covering 100% of these for ALTER COLUMN

Re: [HACKERS] CLUSTER FREEZE

. -- 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] CLUSTER FREEZE

anyway, let's freeze it. Otherwise, you have to write the same pages twice, if both CLUSTER and FREEZE are required. -- 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

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

could spare the spinlock ... Oh, sure, just take the *easy* way out. ;-) -- 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 for fail-back without fresh backup

? I'm opposed to the idea of having a GUC to enable failback. When would anyone using replication ever want to disable that? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Patch for fail-back without fresh backup

On 10/24/2013 11:12 AM, Heikki Linnakangas wrote: On 24.10.2013 20:39, Josh Berkus wrote: On 10/24/2013 04:15 AM, Pavan Deolasee wrote: If we do what you are suggesting, it seems like a single line patch to me. In XLogSaveBufferForHint(), we probably need to look at this additional GUC

Re: [HACKERS] Patch for fail-back without fresh backup

having a GUC for this, I'm for it. And if we do have a GUC, failback should be enabled by default. -- 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

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

On 10/24/2013 02:36 PM, Peter Eisentraut wrote: On 10/22/13, 2:27 PM, Josh Berkus wrote: 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

Re: [HACKERS] CLUSTER FREEZE

On 10/24/2013 04:55 PM, Robert Haas wrote: On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus j...@agliodbs.com wrote: On 10/23/2013 09:58 PM, Amit Kapila wrote: I wonder why anyone would like to freeze during CLUSTER command when they already have separate way (VACUUM FREEZE) to achieve it, do you

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

in many cases of: Does this query have a high average because of outliers, or because it's consisently slow? by looking at the STDDEV. And FWIW, for sites where we monitor pg_stat_statements, we reset daily or weekly. Otherwise, the stats have no meaning. -- Josh Berkus PostgreSQL Experts Inc

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

Dimitri, Josh Berkus josh(at)agliodbs(dot)com 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

Re: [HACKERS] Commitfest II CLosed

not an effective discussion pattern when dealing with new code contributors either, or even some old ones. -- 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

[HACKERS] Autotuning and RAM survey results

an example doc of recalibrating for small RAM, but I don't think that's that hard. -- 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] Add min and max execute statement time in pg_stat_statement

of these stats concerns. Any approach we take using histograms etc. is going to leave out some stat someone needs. -- 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

[HACKERS] Location for external scripts for Extensions?

? PGSHARE/pg_partman/? Or somewhere else? I'm looking to set a canonical location for extensions with external scripts. -- 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

Re: [HACKERS] Commitfest II CLosed

On 10/21/2013 11:59 AM, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: Either you're proposing a solution, supporting someone else's solution, or you're saying the problem isn't important. There is no fourth alternative. Nonsense. Pointing out that a proposed solution isn't

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

On Mon, Oct 14, 2013 at 5:38 PM, Josh Kupershmidt schmi...@gmail.com wrote: Also, Pavel, this patch is still listed as 'Needs Review' in the CF app, but I haven't seen a response to the concerns in my last message. It looks like this patch has been imported into the 2013-11 CF [1] and marked

Re: [HACKERS] Turning recovery.conf into GUCs

both models is going to be annoying. But necessary. And, as I said before, we need to do the GUC merger in the same release we introduce configuration directory (or after it). -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Commitfest II CLosed

problem with reviews and reviewers, and that it's worth a project-wide effort to do something about it. Apparently that day hasn't come yet; most people are still in denial. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Commitfest II CLosed

free to nag me :-). Josh tried that with the infamous Slacker List, but that backfired. Rather than posting a public list of shame, I think it would work better to send short off-list nag emails, or chat via IM. Something like Hey, you've signed up to review this. Any progress?. Or Hey, could you

Re: [HACKERS] Commitfest II CLosed

, shows that they don't actually care. Where's your solution? -- 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

<    5   6   7   8   9   10   11   12   13   14   >