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

On Fri, May 29, 2015 at 04:01:00PM -0400, Tom Lane wrote: > Stephen Frost writes: > > * Bruce Momjian (br...@momjian.us) wrote: > >> I am unclear if we are anywhere near ready for beta1 even in June. Are > >> we? > > > I'm all about having that discussion... but can we do it on another > > thre

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

On May 29, 2015 9:08:07 PM PDT, Tom Lane wrote: >I think your position is completely nuts. Yeehaa. > The GROUPING SETS code is >desperately in need of testing. The custom-plan code is desperately >in need of fixing and testing. The multixact code is desperately >in need of testing. And the

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

On May 29, 2015 8:56:40 PM PDT, Robert Haas wrote: >On Fri, May 29, 2015 at 6:33 PM, Andres Freund >wrote: >> On 2015-05-29 18:02:36 -0400, Robert Haas wrote: >>> Well, I think we ought to take at least a few weeks to try to do a >bit >>> of code review and clean up what we can from the open item

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

Robert Haas writes: > On Fri, May 29, 2015 at 6:33 PM, Andres Freund wrote: >> Why? A large portion of the input required to go from beta towards a >> release is from actual users. To see when things break, what confuses >> them and such. > I have two concerns: > 1. I'm concerned that once we r

Re: [HACKERS] [Proposal] More Vacuum Statistics

Andres Freund wrote: > On 2015-05-29 21:30:57 -0500, Jim Nasby wrote: > > It occurs to me that there's no good reason for vacuum-derived stats to be > > in the stats file; it's not like users run vacuum anywhere near as often as > > other commands. It's stats could be kept in pg_class; we're alread

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

Bruce Momjian wrote: > I think we need to step back and look at the brain power required to > unravel the mess we have made regarding multi-xact and fixes. (I bet > few people can even remember which multi-xact fixes went into which > releases --- I can't.) Instead of working on actual features,

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

Andres Freund wrote: > I considered for a second whether the solution for that could be to not > truncate while inconsistent - but I think that doesn't solve anything as > then we can end up with directories where every single offsets/member > file exists. Hang on a minute. We don't need to scan

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

On Fri, May 29, 2015 at 6:33 PM, Andres Freund wrote: > On 2015-05-29 18:02:36 -0400, Robert Haas wrote: >> Well, I think we ought to take at least a few weeks to try to do a bit >> of code review and clean up what we can from the open items list. > > Why? A large portion of the input required to

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

On Sat, May 30, 2015 at 1:46 PM, Andres Freund wrote: > On 2015-05-29 15:08:11 -0400, Robert Haas wrote: >> It seems pretty clear that we can't effectively determine anything >> about member wraparound until the cluster is consistent. > > I wonder if this doesn't actually hints at a bigger problem

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

On Fri, May 29, 2015 at 9:46 PM, Andres Freund wrote: > On 2015-05-29 15:08:11 -0400, Robert Haas wrote: >> It seems pretty clear that we can't effectively determine anything >> about member wraparound until the cluster is consistent. > > I wonder if this doesn't actually hints at a bigger problem

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

On Fri, May 29, 2015 at 3:08 PM, Robert Haas wrote: > It won't fix the fact that pg_upgrade is putting > a wrong value into everybody's datminmxid field, which should really > be addressed too, but I've been working on this for about three days > virtually non-stop and I don't have the energy to t

[HACKERS] session_replication_role origin vs local

Does anyone know what the difference between the session_replication_role settings of 'origin' vs 'local' is supposed to be? AFAICT, the code treats them the same and has done since this feature was initially introduced. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To m

[HACKERS] cannot set view triggers to replica

It appears to be an omission that ALTER TABLE ... ENABLE TRIGGER and similar commands don't allow acting on views, even though we now have triggers on views. Similarly, the ALTER TABLE ... ENABLE RULE commands only allow acting on tables, even though rules can also exist on views and materialized

Re: [HACKERS] [Proposal] More Vacuum Statistics

On 2015-05-29 21:30:57 -0500, Jim Nasby wrote: > It occurs to me that there's no good reason for vacuum-derived stats to be > in the stats file; it's not like users run vacuum anywhere near as often as > other commands. It's stats could be kept in pg_class; we're already keeping > things like relal

Re: [HACKERS] [Proposal] More Vacuum Statistics

On 5/28/15 9:14 AM, Tom Lane wrote: Naoya Anzai writes: In my much experience up until now,I have an idea that we can add 2 new vacuum statistics into pg_stat_xxx_tables. Adding new stats in that way requires adding per-table counters, which bloat the statistics files (especially in database

Re: [HACKERS] nested loop semijoin estimates

On 05/30/15 01:20, Tomas Vondra wrote: Notice the cost - it's way lover than the previous plan (9.2 vs ~111k), yet this plan was not chosen. So either the change broke something (e.g. by violating some optimizer assumption), or maybe there's a bug somewhere else ... After a bit more investig

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

On 2015-05-29 15:08:11 -0400, Robert Haas wrote: > It seems pretty clear that we can't effectively determine anything > about member wraparound until the cluster is consistent. I wonder if this doesn't actually hints at a bigger problem. Currently, to determine where we need to truncate SlruScanD

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

On 2015-05-29 15:49:53 -0400, Bruce Momjian wrote: > I think we need to step back and look at the brain power required to > unravel the mess we have made regarding multi-xact and fixes. (I bet > few people can even remember which multi-xact fixes went into which > releases --- I can't.) Instead o

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

* Andres Freund (and...@anarazel.de) wrote: > On 2015-05-29 18:02:36 -0400, Robert Haas wrote: > > Well, I think we ought to take at least a few weeks to try to do a bit > > of code review and clean up what we can from the open items list. > > Why? A large portion of the input required to go from

[HACKERS] nested loop semijoin estimates

Hi, while looking at this post from pgsql-performance about plan changes http://www.postgresql.org/message-id/flat/20150529095117.gb15...@hjp.at I noticed that initial_cost_nestloop() does this in (9.1, mentioned in the pgsql-performance post uses the same logic): if (jointype == JOIN_S

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

On 2015-05-30 10:55:30 +1200, Thomas Munro wrote: > That's the error message, but then further down: Ooops. > "I have confirmed that directory "pg_multixact/members" does not > existing in the restored data directory. > > I can see this directory and the file if i restore a few days old > backup.

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

On Sat, May 30, 2015 at 10:48 AM, Andres Freund wrote: > On 2015-05-30 10:41:01 +1200, Thomas Munro wrote: >> On Sat, May 30, 2015 at 10:29 AM, Robert Haas wrote: >> > On Fri, May 29, 2015 at 5:14 PM, Josh Berkus wrote: >> >> Just saw what looks like a report of this issue on 9.2. >> >> >> >> ht

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

On 2015-05-30 10:41:01 +1200, Thomas Munro wrote: > On Sat, May 30, 2015 at 10:29 AM, Robert Haas wrote: > > On Fri, May 29, 2015 at 5:14 PM, Josh Berkus wrote: > >> Just saw what looks like a report of this issue on 9.2. > >> > >> https://github.com/wal-e/wal-e/issues/177 > > > > Urk. That look

[HACKERS] Join Filter vs. Index Cond (performance regression 9.1->9.2+/HEAD)

This is distilled down from a performance regression problem that came past on IRC earlier today: create table t1 (a integer, b integer, c integer, primary key (a,b,c)); create table t2 (k2 integer, a integer, primary key (k2,a)); create table t3 (k3 integer, b integer, primary key (k3,b)); create

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

On Sat, May 30, 2015 at 10:29 AM, Robert Haas wrote: > On Fri, May 29, 2015 at 5:14 PM, Josh Berkus wrote: >> Just saw what looks like a report of this issue on 9.2. >> >> https://github.com/wal-e/wal-e/issues/177 > > Urk. That looks awfully similar, but I don't think any of the code > that is a

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

On 2015-05-29 18:02:36 -0400, Robert Haas wrote: > Well, I think we ought to take at least a few weeks to try to do a bit > of code review and clean up what we can from the open items list. Why? A large portion of the input required to go from beta towards a release is from actual users. To see wh

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

On Fri, May 29, 2015 at 5:14 PM, Josh Berkus wrote: > Just saw what looks like a report of this issue on 9.2. > > https://github.com/wal-e/wal-e/issues/177 Urk. That looks awfully similar, but I don't think any of the code that is affected here exists in 9.2, or that any of the fixes involved we

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

On Fri, May 29, 2015 at 05:37:13PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Do we need release notes for an alpha? Once I do the release notes, it > > is possible to miss subtle changes in the code that aren't mentioned in > > commit messages. > > If the commit message isn't clear abou

Re: [HACKERS] RFC: Remove contrib entirely

On 05/29/2015 02:54 PM, Tom Lane wrote: > Peter Geoghegan writes: >> The problem here is that these ranges are controlled by a >> decentralized patchwork of national standards bodies, and the ranges >> are always subject to revision. I think that it's egregious that >> contrib/isn imagines it can

Re: [HACKERS] RFC: Remove contrib entirely

On Fri, May 29, 2015 at 2:54 PM, Tom Lane wrote: > Well, that module has already been rewritten once (which proves that > there's an audience out there for it). Perhaps somebody will rewrite it > again to support a non-hardwired set of ranges. Now that we have the > concept of an extension confi

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

On Fri, May 29, 2015 at 4:37 PM, Tom Lane wrote: > Robert Haas writes: >> I'm personally kind of astonished that we're even thinking about beta >> so soon. I mean, we at least need to go through the stuff listed >> here, I think: >> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items > >

Re: [HACKERS] RFC: Remove contrib entirely

Peter Geoghegan writes: > The problem here is that these ranges are controlled by a > decentralized patchwork of national standards bodies, and the ranges > are always subject to revision. I think that it's egregious that > contrib/isn imagines it can track that with a static array. Well, that mo

Re: [HACKERS] RFC: Remove contrib entirely

On Fri, May 29, 2015 at 2:35 PM, Tom Lane wrote: > It made us realize that extensions that create types > that are physically equivalent to int8 or float8 were broken when we made > those types potentially pass-by-value; we had to add a CREATE TYPE option > to allow that to still work (cf commit 3

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

Bruce Momjian writes: > Do we need release notes for an alpha? Once I do the release notes, it > is possible to miss subtle changes in the code that aren't mentioned in > commit messages. If the commit message isn't clear about something, you'd likely miss the issue anyway, no? Anyway, once the

Re: [HACKERS] RFC: Remove contrib entirely

Josh Berkus writes: > On 05/29/2015 02:08 PM, Peter Geoghegan wrote: >> I always liked the idea of organizing contrib along these lines. >> >> I know that I will never be successful in convincing people to remove, >> say, contrib/isn, which is total garbage, but the next best thing is >> to categ

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

On Fri, May 29, 2015 at 12:08 PM Robert Haas wrote: > OK, here's a patch. > I grabbed branch REL9_4_STABLE from git, and Robert got me a 9.4-specific patch. I rebuilt, installed, and postgres started up successfully! I did a bunch of checks, had our app run several thousand SQL queries against

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

On May 29, 2015 2:12:24 PM PDT, Bruce Momjian wrote: >On Fri, May 29, 2015 at 11:04:59PM +0200, Andres Freund wrote: >> On 2015-05-29 16:37:00 -0400, Tom Lane wrote: >> > Well, maybe we ought to call it an alpha not a beta, but I think we >ought >> > to put out some kind of release that we can enc

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://www.postgresql

Re: [HACKERS] RFC: Remove contrib entirely

On Fri, May 29, 2015 at 11:47 AM, Josh Berkus 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, like spi, start-scripts, and oid2name. > > C. "Core Extension

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

On Fri, May 29, 2015 at 11:04:59PM +0200, Andres Freund wrote: > On 2015-05-29 16:37:00 -0400, Tom Lane wrote: > > Well, maybe we ought to call it an alpha not a beta, but I think we ought > > to put out some kind of release that we can encourage people to test. > > I also do think it's important

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 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, like sp

[HACKERS] initdb -S versus superuser check and Windows restricted mode

I noticed that if you use "initdb -S", the code does its thing and exits without ever calling get_restricted_token(). It doesn't get to get_id() where the no-superuser check is, either. Is this OK, or should we reorder the operations so that fsyncing is done with the usual restricted privileges?

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

On 2015-05-29 16:37:00 -0400, Tom Lane wrote: > Well, maybe we ought to call it an alpha not a beta, but I think we ought > to put out some kind of release that we can encourage people to test. I also do think it's important that we put out a beta (or alpha) relatively soon. Both because we actual

[HACKERS] Re: 9.5 release notes may need ON CONFLICT DO NOTHING compatibility notice for FDW authors

On Mon, May 25, 2015 at 1:28 AM, Simon Riggs wrote: > My earlier summary was that the support for multiple constraints has been > poorly thought through. This is an example of the breakage I have been > complaining about when we are forced to specify the constraint > (conflict-target). > > This is

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

On 29 May 2015 at 18:15, Josh Berkus wrote: > While I'm just doing this during testing That part is good. I'm sure you will find something in need of improvement. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Rem

Re: [HACKERS] Re: 9.5 release notes may need ON CONFLICT DO NOTHING compatibility notice for FDW authors

On Thu, May 28, 2015 at 1:20 AM, Etsuro Fujita wrote: > I think that those are interesting problems. Wouldn't we need some > additional hacks for the core or FDW to perform an operation that is > equivalent to dynamically switching the ExecInsert/ExecForeignInsert > processing to the ExecUpdate/E

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

On 29 May 2015 at 18:15, 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. So I was a little startled by this: > > cio=# select > pg_drop_replication_slot('bdr_24577_61477206451

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 21:59 GMT+02:00 Joshua D. Drake : > > On 05/29/2015 12:30 PM, Pavel Stehule wrote: > > Contrib made sense years ago. It does not any longer. Let's put the >> old horse down and raise a new herd of ponies on a new pasture. >> >> >> Still there is strong sense - it is a referenti

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

Robert Haas writes: > I'm personally kind of astonished that we're even thinking about beta > so soon. I mean, we at least need to go through the stuff listed > here, I think: > https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items Well, maybe we ought to call it an alpha not a beta, but I

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

* Josh Berkus (j...@agliodbs.com) wrote: > On 05/29/2015 11:30 AM, Stephen Frost wrote: > > I know how big my WAL partition is. Let me tell PG how big it is and to > > not do anything that'll end up going over that amount, and we'll never > > see a crash due to out of disk space for WAL again. >

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

On Fri, May 29, 2015 at 4:01 PM, Tom Lane wrote: > It's possible that we ought to give up on a pre-conference beta. > Certainly a whole lot of time that I'd hoped would go into reviewing > 9.5 feature commits has instead gone into back-branch bug chasing this > week. I'm personally kind of astoni

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

On 05/29/2015 11:30 AM, Stephen Frost wrote: > I know how big my WAL partition is. Let me tell PG how big it is and to > not do anything that'll end up going over that amount, and we'll never > see a crash due to out of disk space for WAL again. H. Do we have a clear idea anywhere in server

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

On 05/29/2015 01:03 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: It's possible that we ought to give up on a pre-conference beta. Certainly a whole lot of time that I'd hoped would go into reviewing 9.5 feature commits has instead gone into back-branch bug chasing this week.

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

On Fri, May 29, 2015 at 04:01:00PM -0400, Tom Lane wrote: > Stephen Frost writes: > > * Bruce Momjian (br...@momjian.us) wrote: > >> I am unclear if we are anywhere near ready for beta1 even in June. Are > >> we? > > > I'm all about having that discussion... but can we do it on another > > thre

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > It's possible that we ought to give up on a pre-conference beta. > Certainly a whole lot of time that I'd hoped would go into reviewing > 9.5 feature commits has instead gone into back-branch bug chasing this > week. I guess that's what I'm getting at. We

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

Stephen Frost writes: > * Bruce Momjian (br...@momjian.us) wrote: >> I am unclear if we are anywhere near ready for beta1 even in June. Are >> we? > I'm all about having that discussion... but can we do it on another > thread or at least wait til we've decided about the back-branch > releases?

Re: [HACKERS] RFC: Remove contrib entirely

On 05/29/2015 12:30 PM, Pavel Stehule wrote: Contrib made sense years ago. It does not any longer. Let's put the old horse down and raise a new herd of ponies on a new pasture. Still there is strong sense - it is a referential implementation of our extension API. We need it to find re

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

* Bruce Momjian (br...@momjian.us) wrote: > On Fri, May 29, 2015 at 03:32:57PM -0400, Tom Lane wrote: > > I know Josh doesn't like to do beta1 releases concurrently with back > > branches because it confuses the PR messaging. But we could make an > > exception perhaps; or do all those releases the

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

On Fri, May 29, 2015 at 03:32:57PM -0400, Tom Lane wrote: > I know Josh doesn't like to do beta1 releases concurrently with back > branches because it confuses the PR messaging. But we could make an > exception perhaps; or do all those releases the same week but announce > the beta the day after t

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

* Magnus Hagander (mag...@hagander.net) wrote: > On Fri, May 29, 2015 at 9:46 PM, Stephen Frost wrote: > > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Magnus Hagander writes: > > > > On Fri, May 29, 2015 at 9:32 PM, Tom Lane wrote: > > > >> I think there's no way that we wait more than one a

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

On Thu, May 28, 2015 at 07:24:26PM -0400, Robert Haas wrote: > On Thu, May 28, 2015 at 4:06 PM, Joshua D. Drake > wrote: > > FTR: Robert, you have been a Samurai on this issue. Our many thanks. > > Thanks! I really appreciate the kind words. > > So, in thinking through this situation further,

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

On Fri, May 29, 2015 at 9:46 PM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Magnus Hagander writes: > > > On Fri, May 29, 2015 at 9:32 PM, Tom Lane wrote: > > >> I think there's no way that we wait more than one additional week to > push > > >> the fsync fix. So the prob

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Magnus Hagander writes: > > On Fri, May 29, 2015 at 9:32 PM, Tom Lane wrote: > >> I think there's no way that we wait more than one additional week to push > >> the fsync fix. So the problem is not with scheduling the update releases, > >> it's with wheth

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

Magnus Hagander writes: > On Fri, May 29, 2015 at 9:32 PM, Tom Lane wrote: >> I think there's no way that we wait more than one additional week to push >> the fsync fix. So the problem is not with scheduling the update releases, >> it's with whether we can also fit in a 9.5 beta release before P

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

On 05/29/2015 12:27 PM, Andres Freund wrote: > On 2015-05-29 12:08:24 -0700, Josh Berkus wrote: >> Now, BDR is good because it sets an application_name which lets me >> figure out what's using the replication slot. But that's by no means >> required; other LC plug-ins, I expect, do not do so. So

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > (I can't see doing a beta *during* PGCon week. I for one am going to be > on an airplane at the time I'd normally have to be Doing Release Stuff.) [...] > Or we just let the beta slide till after PGCon, but then I think we're > missing some excitement facto

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

On Fri, May 29, 2015 at 9:32 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Fri, May 29, 2015 at 8:54 PM, Stephen Frost > wrote: > >> I just caution that we appreciate PGCon coming up and that we do our > >> best to avoid running into a case where we have to push it further due > >> to ev

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

Magnus Hagander writes: > On Fri, May 29, 2015 at 8:54 PM, Stephen Frost wrote: >> I just caution that we appreciate PGCon coming up and that we do our >> best to avoid running into a case where we have to push it further due >> to everyone being at the conference. > If we plan it, we certainly

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

On 05/29/2015 12:18 PM, Robert Haas wrote: On Fri, May 29, 2015 at 3:09 PM, Magnus Hagander wrote: Do you have any feeling of how likely people are to actually hit the multixact one? I've followed some of that impressive debugging you guys did, and I know it's a pretty critical bug if you hit

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 21:20 GMT+02:00 Joshua D. Drake : > > On 05/29/2015 11:27 AM, Jeff Janes wrote: > > It would be less confusing for users. Contrib modules seem to be >> first class extensions, leaving doubt on other extensions. >> >> >> Presumably there are still going to be some extensions mai

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

* Magnus Hagander (mag...@hagander.net) wrote: > On Fri, May 29, 2015 at 8:54 PM, Stephen Frost wrote: > > > * Robert Haas (robertmh...@gmail.com) wrote: > > > I think we should postpone next week's release. I have been hard at > > > work on the multixact-related bugs that were reported in 9.4.2

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

On 2015-05-29 12:08:24 -0700, Josh Berkus wrote: > Now, BDR is good because it sets an application_name which lets me > figure out what's using the replication slot. But that's by no means > required; other LC plug-ins, I expect, do not do so. So there's no way > for the user to figure out which

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

On 2015-05-29 14:39:02 -0400, Stephen Frost wrote: > * Andres Freund (and...@anarazel.de) wrote: > > How is this measurably worse than trying to truncate a log table that > > has grown too large? That's often harder to fight actually, because > > there's dozens of other processes that might be usin

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

On 05/29/2015 12:08 PM, Josh Berkus wrote: Now, BDR is good because it sets an application_name which lets me figure out what's using the replication slot. But that's by no means required; other LC plug-ins, I expect, do not do so. So there's no way for the user to figure out which replicatio

Re: [HACKERS] RFC: Remove contrib entirely

On 05/29/2015 11:27 AM, Jeff Janes wrote: It would be less confusing for users. Contrib modules seem to be first class extensions, leaving doubt on other extensions. Presumably there are still going to be some extensions maintained by -hackers, and some not. I don't think we are goin

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

On Fri, May 29, 2015 at 3:09 PM, Magnus Hagander wrote: > Do you have any feeling of how likely people are to actually hit the > multixact one? I've followed some of that impressive debugging you guys did, > and I know it's a pretty critical bug if you hit it, but how wide-spread > will it be? Th

Re: [HACKERS] RFC: Remove contrib entirely

On 05/29/2015 11:02 AM, Jeff Janes wrote: Also, removing a feature is a regression, and someone is always bound to complain... What is the real benefit? ISTM that it is a solution that fixes no important problem. Reaching a consensus about what to move here or there will consum

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

On Fri, May 29, 2015 at 8:54 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: > > I think we should postpone next week's release. I have been hard at > > work on the multixact-related bugs that were reported in 9.4.2 and > > 9.3.7, and the subsequent bugs found by code-rea

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

On Fri, May 29, 2015 at 8:02 PM, Robert Haas wrote: > Hi, > > I think we should postpone next week's release. I have been hard at > work on the multixact-related bugs that were reported in 9.4.2 and > 9.3.7, and the subsequent bugs found by code-reading, but getting them > all fixed by Monday do

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

On Fri, May 29, 2015 at 12:43 PM, Robert Haas wrote: > Working on that now. OK, here's a patch. Actually two patches, differing only in whitespace, for 9.3 and for master (ha!). I now think that the root of the problem here is that DetermineSafeOldestOffset() and SetMultiXactIdLimit() were larg

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

So, here's an example of why it's hard to give our users a workaround. cio=# select * from pg_replication_slots; slot_name| plugin | slot_type | datoid | database | active | xmin | catalog_xmin | restart_lsn -++---

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Re: Tom Lane 2015-05-29 <13871.1432921...@sss.pgh.pa.us> > Why can't the user stop it? We won't be bleating about the case of a > symlink to a non-writable file someplace else, which is the Debian use > case. I don't see a very good excuse to have a non-writable file right > in the data directory

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

On Fri, May 29, 2015 at 02:54:31PM -0400, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: > > I think we should postpone next week's release. I have been hard at > > work on the multixact-related bugs that were reported in 9.4.2 and > > 9.3.7, and the subsequent bugs found by c

Re: [HACKERS] postpone next week's release

* Robert Haas (robertmh...@gmail.com) wrote: > I think we should postpone next week's release. I have been hard at > work on the multixact-related bugs that were reported in 9.4.2 and > 9.3.7, and the subsequent bugs found by code-reading, but getting them > all fixed by Monday doesn't seem realis

Re: [HACKERS] postpone next week's release

On Fri, May 29, 2015 at 02:02:43PM -0400, Robert Haas wrote: > Hi, > > I think we should postpone next week's release. I have been hard at > work on the multixact-related bugs that were reported in 9.4.2 and > 9.3.7, and the subsequent bugs found by code-reading, but getting them > all fixed by M

Re: [HACKERS] RFC: Remove contrib entirely

All, So there are currently three kinds of things in contrib: 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, like spi, start-scripts, and oid2name. C. "Core Extensions"

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

* Andres Freund (and...@anarazel.de) wrote: > How is this measurably worse than trying to truncate a log table that > has grown too large? That's often harder to fight actually, because > there's dozens of other processes that might be using the relation? In > one case you don't have wait ordering

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

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

* Josh Berkus (j...@agliodbs.com) wrote: > 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

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

* Andres Freund (and...@anarazel.de) wrote: > On 2015-05-29 13:49:16 -0400, Tom Lane wrote: > > > That sounds like a potentially nontrivial amount of repetitive log bleat > > > after every crash start? One which the user can't really stop? > > > > Why can't the user stop it? > > Because it makes

Re: [HACKERS] RFC: Remove contrib entirely

On Thu, May 28, 2015 at 11:26 PM, Guillaume Lelarge wrote: > Le 29 mai 2015 8:01 AM, "Fabien COELHO" a écrit : > > > > > >> FWIW, I don't mind which one we put in core and which one we put out of > >> core. But I like Joshua's idea of getting rid of contribs and pushing > them > >> out as any ot

Re: [HACKERS] pgindent vs emacs

On 05/29/2015 01:49 PM, Andres Freund wrote: On 2015-05-29 13:37:40 -0400, Andrew Dunstan wrote: One of the annoying inconsistencies between emacs and pgindent is that emacs refuses to offset a block following a case label, while pgindent does. Is there anything we can do to induce emacs to do

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 2015-05-29 14:15:48 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2015-05-29 13:49:16 -0400, Tom Lane wrote: > >> Why can't the user stop it? > > > Because it makes a good amount of sense to have e.g. certificates not > > owned by postgres and not writeable? You don't necessarily want

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Andres Freund writes: > On 2015-05-29 13:49:16 -0400, Tom Lane wrote: >> Why can't the user stop it? > Because it makes a good amount of sense to have e.g. certificates not > owned by postgres and not writeable? You don't necessarily want to > symlink them somewhere else, because that makes movin

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

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. > > 2. You need to drop the laggy repl

Re: [HACKERS] RFC: Remove contrib entirely

On Thu, May 28, 2015 at 11:01 PM, Fabien COELHO wrote: > > FWIW, I don't mind which one we put in core and which one we put out of >> core. But I like Joshua's idea of getting rid of contribs and pushing them >> out as any other extensions. >> > > Hmmm. > > I like the contrib directory as a livi

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 is a

[HACKERS] postpone next week's release

Hi, I think we should postpone next week's release. I have been hard at work on the multixact-related bugs that were reported in 9.4.2 and 9.3.7, and the subsequent bugs found by code-reading, but getting them all fixed by Monday doesn't seem realistic. Such fixes should have careful review, and

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

* 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 is an option which says "you have X GB of disk space. Onc

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 2015-05-29 13:49:16 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2015-05-29 13:14:18 -0400, Tom Lane wrote: > >> Abhijit Menon-Sen writes: > >> As I mentioned yesterday, I'm not really on board with ignoring EACCES, > >> except for the directories-on-Windows case. Since we're only lo

  1   2   >