Re: [HACKERS] Bug? Small samples in TABLESAMPLE SYSTEM returns zero rows

On 08/06/2015 12:45 PM, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: On 6 August 2015 at 20:14, Josh Berkus j...@agliodbs.com wrote: Speaking from a user perspective, SYSTEM seems broken to me. I can't imagine using it for anything with a that degree of variation in the number

Re: [HACKERS] Bug? Small samples in TABLESAMPLE SYSTEM returns zero rows

On 08/06/2015 01:19 PM, Simon Riggs wrote: On 6 August 2015 at 21:14, Josh Berkus j...@agliodbs.com mailto:j...@agliodbs.com wrote: On 08/06/2015 01:10 PM, Simon Riggs wrote: Given, user-stated probability of accessing a block of P and N total blocks, there are a few ways

[HACKERS] Bug? Small samples in TABLESAMPLE SYSTEM returns zero rows

. Speaking from a user perspective, SYSTEM seems broken to me. I can't imagine using it for anything with a that degree of variation in the number of results returned, especially if it's possible to return zero rows from a populated table. BERNOULLI works as expected. -- Josh Berkus PostgreSQL

[HACKERS] Draft Alpha 2 announcement

Hackers, Please check over the attached for errors. Also, please suggest major fixes/changes since Alpha 1 I might have missed. Thanks! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com PostgreSQL 9.5 Alpha 2 Released === The PostgreSQL Global

Re: [HACKERS] Freeze avoidance of very large table.

and/or on PGXN. Yes, for tools with overhead we might want to require enabling them in pg.conf. But that's very different from requiring the user to install a separate package. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Draft Alpha 2 announcement

On 08/05/2015 10:29 AM, Joe Conway wrote: On 08/05/2015 10:15 AM, Josh Berkus wrote: * Make pg_dump work back up Row Level Security policies There were far more than this single bugfix related to RLS. You might want to say something like: * Numerous Row Level Security related bug fixes I

Re: [HACKERS] Freeze avoidance of very large table.

On 08/05/2015 10:26 AM, Bruce Momjian wrote: On Wed, Aug 5, 2015 at 10:22:48AM -0700, Josh Berkus wrote: On 08/05/2015 10:00 AM, Alvaro Herrera wrote: Anyway, the patch as proposed puts the new functions in core as builtins (which is what Bruce seems to be objecting to). Maybe instead

Re: [HACKERS] Freeze avoidance of very large table.

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] patch: prevent user from setting wal_buffers over 2GB bytes

On 07/31/2015 10:43 AM, Robert Haas wrote: On Thu, Jul 30, 2015 at 9:17 PM, Josh Berkus j...@agliodbs.com wrote: In guc.c, the maximum for wal_buffers is INT_MAX. However, wal_buffers is actually measured in 8KB buffers, not in bytes. This means that users are able to set wal_buffers 2GB

Re: [HACKERS] Solaris testers wanted for strxfrm() behavior

Noah, All: Where are we with this? Do we feel confident that this bug is only on old versions of Solaris we don't care about? Or does it remain to be resolved? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] 64-bit XIDs again

that clog size had some major performance impacts. -- 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] patch: prevent user from setting wal_buffers over 2GB bytes

Thanks to Andrew Gierth for diagnosing this issue. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c new file mode 100644 index 1b7b914..b3dac51 *** a/src/backend/utils/misc/guc.c --- b/src/backend/utils/misc

[HACKERS] call for contributor recommendations

for 9.4/9.5 Please explain in your nomination what things the nominee did. You do not need to tell me about anything which is in the release notes; I'll get that from them. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

[HACKERS] TODO: replica information functions

for previously discussed reasons pg_recovery_config(config_item TEXT) returns the specified configuration item from recovery.conf superuser-only? Does this make sense? Is there other information we need? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

as well, with some syntax. Seems like a perfect candidate for returned with feedback. We'll straighten it out by the next commitfest. Also note that this has actually spiralled out into 2 or 3 separate features. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql

Re: [HACKERS] security labels on databases are bad for dump restore

get rid of pg_dumpall -g. -- 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] Alpha 2 wrapping August 3

... so please get those fixes/overhauls in in the next week. 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] Autonomous Transaction is back

implementation we end up with, A1 might not even be visible to Y(). So that solves your use case without any need to block ATXs in called functions. However, it leads to some interesting cases involving self-deadlocks; see the original post on this thread. -- Josh Berkus PostgreSQL Experts Inc. http

Re: [HACKERS] Autonomous Transaction is back

? -- 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] Autonomous Transaction is back

On 07/27/2015 03:12 PM, Joel Jacobson wrote: On Mon, Jul 27, 2015 at 11:49 PM, Josh Berkus j...@agliodbs.com mailto:j...@agliodbs.com wrote: Ah, you're missing how commits in ATX are expected to work. Let me illustrate: X ( Data write A1 call Y

Re: [HACKERS] Anyone working on the TOAST items on the TODO list?

On 07/25/2015 07:05 AM, Bill Moran wrote: If not, I'm going to make a little personal project of them for myself (targeting 9.6). Nope. In fact, even the one which was 90% complete (replacing zlib with lz4) completely dropped off the radar. -- Josh Berkus PostgreSQL Experts Inc. http

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

. -- 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] Speakers Wanted for pgDay Cuba

are donated community funds held at SPI, Inc. Speakers will be reimbursed after attending the conference by check or wire transfer.) -- 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] Autonomous Transaction is back

probably neither easy nor uncontroversial. That's more-or-less a summary of what I just posted. -- 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] BRIN index and aborted transaction

with BRIN indexes and frequenly-updated tables should be a blocker for 9.5. Not clear on whether we're considering this an open item or not. -- 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] Autonomous Transaction is back

case. What have you concluded regarding this item? -- 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] Autonomous Transaction is back

On 07/23/2015 11:39 AM, Robert Haas wrote: On Thu, Jul 23, 2015 at 2:33 PM, Josh Berkus j...@agliodbs.com wrote: Requesting for everyone's opinion regarding this based on which we can proceed to enhance/tune/re-write our design. So, one of the things which came up during the discussion

Re: [HACKERS] Queries runs slow on GPU with PG-Strom

. And the results was I believe that pgStrom has its own mailing list. KaiGai? -- 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] Alpha2/Beta1

All: Sounds like the overwhemling consensus is Alpha2 then. Will run with 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

Re: [HACKERS] pgbench stats per script other stuff

-- 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] Alpha2/Beta1

All: At the Developer's Meeting, we said we'd be releasing an alpha or beta each month until final 9.5 release. As such, we should be releasing a 9.5 alpha/beta in the first week of August. My question for Hackers is: should this be Alpha2 or Beta 1? -- Josh Berkus PostgreSQL Experts Inc

Re: [HACKERS] pgbench stats per script other stuff

the above would execute a pgbench with 16 clients, 4 threads, script1 three times as often as script2, and report stats at the script (rather than SQL statement) level. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Implementation of global temporary tables?

Pavel, All: Just to be clear, the idea of a global temp table is that the table def is available to all users, but the data is private to each session? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Support for N synchronous standby servers - take 2

synch rep, but if we add names it will make the non-JSON syntax less compact. I'm guessing it'd be really ugly/hard to support at least this GUC being multi-line? Yes. Mind you, multi-line GUCs would be useful otherwise, but we don't want to hinge this feature on making that work. -- Josh

Re: [HACKERS] 9.5 alpha: some small comments on BRIN and btree_gin

into account, heavily. Can we do that? Is correlation even part of the index costing method now? How accurate are our correlation estimates? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On 07/07/2015 11:29 AM, Stephen Frost wrote: * Josh Berkus (j...@agliodbs.com) wrote: On 07/07/2015 09:06 AM, Magnus Hagander wrote: To make it accessible to monitoring systems that don't run as superuser (which should be most monitoring systems, but we have other cases making that hard

Re: [HACKERS] Information of pg_stat_ssl visible to all users

other routes. -- 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] Support for N synchronous standby servers - take 2

(i.e. no nesting) for 9.5. -- 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.5 alpha: some small comments on BRIN and btree_gin

? -- 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] Support for N synchronous standby servers - take 2

On 07/06/2015 06:40 PM, Michael Paquier wrote: On Tue, Jul 7, 2015 at 2:56 AM, Josh Berkus j...@agliodbs.com wrote: pro-JSON: * standard syntax which is recognizable to sysadmins and devops. * can use JSON/JSONB functions with ALTER SYSTEM SET to easily make additions/deletions from

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 07/06/2015 09:56 PM, Michael Paquier wrote: On Tue, Jul 7, 2015 at 12:51 PM, Josh Berkus j...@agliodbs.com wrote: On 07/06/2015 06:40 PM, Michael Paquier wrote: On Tue, Jul 7, 2015 at 2:56 AM, Josh Berkus j...@agliodbs.com wrote: pro-JSON: * standard syntax which is recognizable

Re: [HACKERS] Synch failover WAS: Support for N synchronous standby servers - take 2

it your best effort. -- 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] Support for N synchronous standby servers - take 2

on this thread who *would*, let's speak to their use case and then we can actually get the feature right. Anyone? -- 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] Support for N synchronous standby servers - take 2

On 07/02/2015 11:31 AM, Andres Freund wrote: On 2015-07-02 11:10:27 -0700, Josh Berkus wrote: If we're always going to be polling the replicas for furthest ahead, then why bother implementing quorum synch at all? That's the basic question I'm asking. What does it buy us that we don't already

[HACKERS] Improve testing notes?

and fruitful as possible. -- 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 checksums without --initdb

nobody is using checksums because of the dump/reload requirement. And that OS packagers aren't packaging PostgreSQL with checksums in the initial initdb because of the upgrade barrier. I'm not so sure about your solution, but it seems like we need *something*. -- Josh Berkus PostgreSQL Experts

Re: [HACKERS] Support for N synchronous standby servers - take 2

All: Replying to multiple people below. On 07/01/2015 07:15 AM, Fujii Masao wrote: On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus j...@agliodbs.com wrote: You're confusing two separate things. The primary manageability problem has nothing to do with altering the parameter. The main problem

Re: [HACKERS] Solaris testers wanted for strxfrm() behavior

On 06/29/2015 07:53 PM, Robert Haas wrote: On Mon, Jun 29, 2015 at 6:07 PM, Josh Berkus j...@agliodbs.com wrote: On 06/29/2015 02:08 PM, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: Joyent confirms that the bug is fixed on SmartOS: The more interesting bit of information would

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 06/29/2015 01:01 AM, Michael Paquier wrote: On Mon, Jun 29, 2015 at 4:20 AM, Josh Berkus j...@agliodbs.com wrote: Right. Well, another reason we should be using a system catalog and not a single GUC ... I assume that this takes into account the fact that you will still need a SIGHUP

Re: [HACKERS] Solaris testers wanted for strxfrm() behavior

On 06/29/2015 02:08 PM, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: Joyent confirms that the bug is fixed on SmartOS: The more interesting bit of information would be *when* it was fixed. Answer: not certain, but fixed at least 2 years ago. -- Josh Berkus PostgreSQL Experts Inc

Re: [HACKERS] Solaris testers wanted for strxfrm() behavior

modified byte at 58 (0x0) locale : strxfrm returned 26; last modified byte at 27 (0x0) Cheers, -- 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

Re: [HACKERS] Solaris testers wanted for strxfrm() behavior

and EDB support more OldSolaris customers than anyone, AFAIK, so I'd like to her some opinions from 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] Support for N synchronous standby servers - take 2

On 06/28/2015 04:36 AM, Sawada Masahiko wrote: On Sat, Jun 27, 2015 at 3:53 AM, Josh Berkus j...@agliodbs.com wrote: On 06/26/2015 11:32 AM, Robert Haas wrote: I think your proposal is worth considering, but you would need to fill in a lot more details and explain how it works in detail

Re: [HACKERS] Support for N synchronous standby servers - take 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] Support for N synchronous standby servers - take 2

. Finally, while I'm raining on everyone's parade: the mechanism of identifying synchronous replicas by setting the application_name on the replica is confusing and error-prone; if we're building out synchronous replication into a sophisticated system, we ought to think about replacing it. -- Josh

Re: [HACKERS] Oh, this is embarrassing: init file logic is still broken

On 06/25/2015 11:04 AM, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: On 06/25/2015 08:12 AM, Tom Lane wrote: I can't see doing a release just for this. If we were due for releases anyway, sure, but we've considerably overstressed our poor packagers of late. Previous discussion

Re: [HACKERS] Oh, this is embarrassing: init file logic is still broken

regularly need to spin up 200 new connections in 90 seconds due to usage peaks. On the other hand, do I want to do another update release right away? No. Hard place, meet rock. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Oh, this is embarrassing: init file logic is still broken

On 06/25/2015 10:47 AM, Peter Geoghegan wrote: On Wed, Jun 24, 2015 at 2:52 PM, Josh Berkus j...@agliodbs.com wrote: OK, this is pretty bad in its real performance effects. On a workload which is dominated by new connection creation, we've lost about 17% throughput. Mistakes happen

Re: [HACKERS] Oh, this is embarrassing: init file logic is still broken

invalidation is really costing us 17%. :-( -- 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] Trustly PostgreSQL Data Corruption Bug Bounty Program

to be disqualified from eligibility, of course. Other than that, I'd be interested to see how it works 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

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

. ... apparently nobody disagrees ... -- 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] Making sure this isn't a new recovery bug ...

if it's a bug we want to investigate, I need to do forensics now. -- 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] pgbench - allow backslash-continuations in custom scripts

and toes. Backwards-compatability for pgdump, pg_basebackup, initdb, etc. matters. The worst case with pgbench is that we break two people's test scripts, they read the release notes, and fix them. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

On 06/19/2015 02:51 PM, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: On 05/14/2015 12:10 PM, Fabien COELHO wrote: Add backslash continuations to pgbench custom scripts. I don't personally agree. I believe that it it worth breaking backwards compatibility to support line breaks

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

-of-statement. Backwards-compatability in custom pgbench scripts is not critical; pgbench scripts are neither used in produciton, nor used in automated systems much that I know of. I'm not clear on why we'd need a full SQL lexer. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com

Re: [HACKERS] Moving Pivotal's Greenplum work upstream

On 06/14/2015 11:44 PM, Craig Ringer wrote: Has anything actually happened on the Greenplum release at this point? All I can find are the same old press releases. Nothing has happened. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Why does replication need the old history file?

is a requirement, then maybe they should go in their own directory in the future. -- 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 does replication need the old history file?

we want to change, and simply error that we can't find the history file instead of FATAL? -- 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

Re: [HACKERS] The purpose of the core team

of things like security releases. I agree that general advocacy can certainly be handled outside core, and should be -- and, for that matter, is. -- 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] On columnar storage

/PgCon_2015_Developer_Unconference#Topics -- 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] Draft release notes for 9.4.4 et al

On 06/10/2015 11:35 PM, Noah Misch wrote: On Tue, Jun 09, 2015 at 04:31:43PM -0700, Josh Berkus wrote: First draft of the release announcement. Noah, thank you for corrections! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] The purpose of the core team

. It seems that only this last one is where most people seem to have a problem. I wonder if it makes sense to create a separate group that handles release activites -- the release team. De-facto, this is Packagers. Which is maybe not the best system, but it's what we're doing now. -- Josh Berkus

Re: [HACKERS] 9.5 release notes

versions. So there's no reason for this note. -- 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] Why does replication need the old history file?

or 9.3.8? It was working in our previous setup, on 9.3.5, although that could have just been that the history file hadn't been removed from the backups yet. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

[HACKERS] Why no jsonb_exists_path()?

, is there some challenge to stopping just short of the value I'm not seeing? Or is this just a didn't get to it yet issue? I'm trying to estimate the difficulty of creating this operator in an extension (obviously we're not doing it for 9.5), and maybe for 9.6. -- Josh Berkus PostgreSQL Experts Inc

Re: [HACKERS] Draft release notes for 9.4.4 et al

On 06/09/2015 04:38 PM, Michael Paquier wrote: On Wed, Jun 10, 2015 at 8:31 AM, Josh Berkus j...@agliodbs.com wrote: Tom, all: First draft of the release announcement. Please improve/edit/correct. Thanks! Some comments: s/expecially/especially. Thanks, fixed This bug fix

Re: [HACKERS] Draft release notes for 9.4.4 et al

Tom, all: First draft of the release announcement. Please improve/edit/correct. Thanks! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com 2015-06-12 Update Release = The PostgreSQL Global Development Group has released an update to all supported versions

Re: [CORE] [HACKERS] back-branch multixact fixes 9.5 alpha/beta: schedule

people even update binaries with the server running; if they don't restart immediately, it could be several days before it fails to start. It's pretty scary. I'm confused by this discussion. 9.4.3 is released. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql

Re: [HACKERS] [CORE] Restore-reliability mode

it with production data. Yes ... that seems like a good compromise. Frankly, I'm testing 9.5 already; having alpha packages would make that testing easier for me, and maybe possible for others. We'd need to take into account that our packagers are a bit overworked this month due to update releases ... -- Josh

Re: [HACKERS] [CORE] Restore-reliability mode

, then let's please make it an *intensive* cleanup delay, with specific goals, milestones, and a schedule. Otherwise, don't bother. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [CORE] [HACKERS] postpone next week's release

) deployment. That is, we can get packager fatigue where some updates don't get packaged, and we can get user fatigue where they start ignoring updates. -- 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] pg_xlog - pg_xjournal?

the heck out of it. Also ... if we were to rename it, it should be pg_wal or pg_xact. Please let's not add yet another term for the WAL. -- 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] nested loop semijoin estimates

this on DBT3, if that's possible for him. I'm very worried about an unanticipated regression. -- 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

Re: [HACKERS] nested loop semijoin estimates

On 06/01/2015 03:22 PM, Tomas Vondra wrote: On 06/01/15 23:47, Josh Berkus wrote: On 06/01/2015 02:18 PM, Tom Lane wrote: Anybody else want to speak for or against back-patching the patch as posted? I intentionally didn't push it in before today's releases, but I will push it later

Re: [HACKERS] pg_xlog - pg_xjournal?

On 06/01/2015 04:22 PM, Thomas Munro wrote: On Tue, Jun 2, 2015 at 8:17 AM, Josh Berkus j...@agliodbs.com wrote: Also ... if we were to rename it, it should be pg_wal or pg_xact. Please let's not add yet another term for the WAL. +1 for pg_wal if it has to be renamed. If pg_clog also has

Re: [HACKERS] Need Force flag for pg_drop_replication_slot()

On 05/29/2015 10:45 AM, Stephen Frost wrote: Andres, * Andres Freund (and...@anarazel.de) wrote: On 2015-05-29 10:15:56 -0700, Josh Berkus wrote: pg_drop_replication_slot() can be a time-critical function when the master is running out of disk space because the replica is falling behind

Re: [HACKERS] Need Force flag for pg_drop_replication_slot()

On 05/29/2015 11:07 AM, Andres Freund wrote: On 2015-05-29 10:53:30 -0700, Josh Berkus wrote: On 05/29/2015 10:45 AM, Stephen Frost wrote: So, here's they scenario: 1. you're almost out of disk space due to a replica falling behind, like down to 16mb left. Or maybe you are out of disk space

[HACKERS] Need Force flag for pg_drop_replication_slot()

fail in production. I think the simplest way to resolve this would be to add a boolean flag to pg_drop_replication_slot(), which would terminate the replication connection and delete the slot as a single operation. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql

Re: [HACKERS] Need Force flag for pg_drop_replication_slot()

On 05/29/2015 11:01 AM, Stephen Frost wrote: * Josh Berkus (j...@agliodbs.com) wrote: 1. you're almost out of disk space due to a replica falling behind, like down to 16mb left. Or maybe you are out of disk space. This right here is a real issue. What I'd personally like to see

Re: [HACKERS] RFC: Remove contrib entirely

, that'd be one possible way to fix it ... FWIW, neither of the projects I know of which uses ISBN has had any issues with the range since the 2010 updates. While the ranges can be updated in theory, in practice is happens glacially slowly. -- Josh Berkus PostgreSQL Experts Inc. http

Re: [HACKERS] Need Force flag for pg_drop_replication_slot()

connection relates to which slots, as far as I can tell. In this test, it's easy because there's only one replication connection and one slot. But imagine the case of 14 replication connections with their own slots. How could you possibly figure out which one was the laggy one? -- Josh Berkus

Re: [HACKERS] RFC: Remove contrib entirely

working with them and convincing them that a change to packaging is worthwhile. And then getting the news to our users. Given that, there needs to be significant benefit to our users in the change. So, what's the benefit? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via

Re: [HACKERS] RFC: Remove contrib entirely

On 05/29/2015 02:08 PM, Peter Geoghegan wrote: On Fri, May 29, 2015 at 11:47 AM, Josh Berkus j...@agliodbs.com wrote: A. Extra commands and tools which aren't considered general enough, or reliable enough, to be included by default, e.g. pg_standby, pgbench and vacuumlo. B. Developer tools

Re: [HACKERS] Re: [GENERAL] 9.4.1 - 9.4.2 problem: could not access status of transaction 1

All, Just saw what looks like a report of this issue on 9.2. https://github.com/wal-e/wal-e/issues/177 -- 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] About that re-release ...

for public announcement Thursday. regards, tom lane Tom, thanks for the advise. I will postpone the deployment of new packages for cygwin until 9.4.3 will be available. You're doing the cygwin packages? You should probably be on the packagers list, then, no? -- Josh Berkus

Re: [HACKERS] fsync bug faq for publication?

On 05/25/2015 11:09 PM, Magnus Hagander wrote: On May 26, 2015 07:31, Tom Lane t...@sss.pgh.pa.us mailto:t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com mailto:j...@agliodbs.com writes: We need to get a notice out to our users who might update their servers and get stuck behind

Re: [HACKERS] fsync bug faq for publication?

On 05/26/2015 10:57 AM, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: Where did we get the idea that this issue only affects symlinked files? Nobody said any such thing. My point was that permissions and ownership both have to be looked at. The Debian situation

Re: [HACKERS] ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

. Linux kernel version of the host? -- 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] fsync-pgdata-on-recovery tries to write to more files than previously

perms. -- 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] [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful

All, If it's any consolation, the folks at kernel.org are having a bad week too: http://lwn.net/Articles/645720/ -- 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

<    1   2   3   4   5   6   7   8   9   10   >