On Fri, May 29, 2015 at 10:37:57AM +1200, Thomas Munro wrote:
> On Fri, May 29, 2015 at 7:56 AM, Robert Haas wrote:
> > - There's a third possible problem related to boundary cases in
> > SlruScanDirCbRemoveMembers, but I don't understand that one well
> > enough to explain it. Maybe Thomas can j
Incomplete review, done in a relative rush:
On Fri, May 29, 2015 at 03:08:11PM -0400, Robert Haas wrote:
> 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() a
At 2015-05-31 13:46:33 -0400, t...@sss.pgh.pa.us wrote:
>
> just always create pg_xlog as a symlink to pg_xjournal during initdb.
At first glance, the Subject: of this thread made me think that *was*
Joel's proposal. :-) But I think it's a great idea, and worth doing.
I think "pg_journal" (no "x"
On Sun, May 31, 2015 at 11:03 PM, Bruce Momjian wrote:
> On Sun, May 31, 2015 at 09:50:25AM -0400, Bruce Momjian wrote:
>> > +1. Complexity has increased, and we are actually never at 100% sure
>> > that a given bug fix does not have side effects on other things, hence
>> > I think that a portion
On 06/01/15 00:08, Tom Lane wrote:
Tomas Vondra writes:
On 05/30/15 23:16, Tom Lane wrote:
Attached is a draft patch for that. It fixes the problem for me:
Seems to be working OK, but I still do get a Bitmap Heap Scan there (but
more about that later).
Attached is an incremental patch (o
Tomas Vondra writes:
> On 05/30/15 23:16, Tom Lane wrote:
>> Attached is a draft patch for that. It fixes the problem for me:
> Seems to be working OK, but I still do get a Bitmap Heap Scan there (but
> more about that later).
Attached is an incremental patch (on top of the previous one) to al
I have attached new versions which apply on the current master.
Andreas
>From a4a4970d37b710449ccd57a8b4d896a3c004b62a Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Thu, 12 Feb 2015 23:55:01 +0100
Subject: [PATCH 1/4] Replace obsolete macros AC_TRY_* with AC_*_IFELSE.
The AC_TRY_* macro
On Sun, May 31, 2015 at 7:46 PM, Tom Lane wrote:
> Hm. I think the impact on third-party backup tools would be rather bad,
> but there's a simple modification of the idea that might fix that:
> just always create pg_xlog as a symlink to pg_xjournal during initdb.
> Anybody who blindly removes pg_
On 2015-05-31 11:55:44 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> >> FYI, I realize that one additional thing that has discouraged code
> >> reorganization is the additional backpatch overhead. I think we now
> >> need to accept that our reorganization-adverse approach might have cost
> >>
Joel Jacobson writes:
> If we could turn back time, would we have picked "pg_xlog" as the most
> optimal name for this important directory, or would we have come up with a
> more user-friendly name?
Yeah...
> My suggestion is to use "pg_xjournal" instead of "pg_xlog" when new users
> create a ne
While anyone who is familiar with postgres would never do something as
stupid as to delete pg_xlog,
according to Google, there appears to be a fair amount of end-users out
there having made the irrevocable mistake of deleting the precious
directory,
a decision made on the assumption that since "it
Andrew Gierth writes:
> Obviously it makes little sense to use an (a,b,c) index to look up just
> (a,b) and then filter on c; the question is, what is the planner doing
> that leads it to get this so wrong?
It's not so astonishing as all that; compare
regression=# explain select * from t1 where
On Sun, May 31, 2015 at 11:55:44AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> >> FYI, I realize that one additional thing that has discouraged code
> >> reorganization is the additional backpatch overhead. I think we now
> >> need to accept that our reorganization-adverse approach might hav
On 5/31/15 11:49 AM, Noah Misch wrote:
> On Sat, May 30, 2015 at 09:51:04PM -0400, David Steele wrote:
>> On 5/30/15 8:38 PM, Joshua D. Drake wrote:
>>> On 05/30/2015 03:48 PM, David Steele wrote:
I would argue Heikki's WAL stuff is a perfect case for releasing a
public alpha/beta soon.
Bruce Momjian writes:
>> FYI, I realize that one additional thing that has discouraged code
>> reorganization is the additional backpatch overhead. I think we now
>> need to accept that our reorganization-adverse approach might have cost
>> us some reliability, and that reorganization is going to
On Sat, May 30, 2015 at 09:51:04PM -0400, David Steele wrote:
> On 5/30/15 8:38 PM, Joshua D. Drake wrote:
> > On 05/30/2015 03:48 PM, David Steele wrote:
> >> I would argue Heikki's WAL stuff is a perfect case for releasing a
> >> public alpha/beta soon. I'd love to test PgBackRest with an "offic
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> Have we some possibility to take info about external user when any login
> via mapping is used?
Certainly sounds like a very useful things to me.
I'll note that, for client-side certificates, we actually do include
that info, but it's don
On Sun, May 31, 2015 at 09:50:25AM -0400, Bruce Momjian wrote:
> > +1. Complexity has increased, and we are actually never at 100% sure
> > that a given bug fix does not have side effects on other things, hence
> > I think that a portion of this technical debt is the lack of
> > regression test cov
On Sun, May 31, 2015 at 08:15:38PM +0900, Michael Paquier wrote:
> On Sun, May 31, 2015 at 11:48 AM, Bruce Momjian wrote:
> > On Sat, May 30, 2015 at 10:47:27PM +0200, Andres Freund wrote:
> >> So, I think we have built up a lot of technical debt. And very little
> >> effort has been made to fix th
On Sat, May 30, 2015 at 7:09 PM, Andres Freund wrote:
> On 2015-05-27 21:23:34 -0400, Robert Haas wrote:
>> > Oh wow, that's bad, and could explain a couple of the problems we're
>> > seing. One possible way to fix is to replace the sequence with if
>> > (!TAS(spin)) S_UNLOCK();. But that'd mean T
On Fri, May 29, 2015 at 6:45 PM, Andrew Gierth
wrote:
> Obviously it makes little sense to use an (a,b,c) index to look up just
> (a,b) and then filter on c; the question is, what is the planner doing
> that leads it to get this so wrong? Finding a workaround for it was not
> easy, either - the on
On Fri, May 29, 2015 at 10:49 PM, Peter Eisentraut wrote:
> 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.
I assume
On Sat, May 30, 2015 at 8:55 PM, Andres Freund wrote:
> Is oldestMulti, nextMulti - 1 really suitable for this? Are both
> actually guaranteed to exist in the offsets slru and be valid? Hm. I
> guess you intend to simply truncate everything else, but just in
> offsets?
oldestMulti in theory is t
On Sat, May 30, 2015 at 3:46 PM, Peter Geoghegan wrote:
>> What, in this release, could break things badly? RLS? Grouping sets?
>> Heikki's WAL format changes? That last one sounds really scary to me;
>> it's painful if not impossible to fix the WAL format in a minor
>> release.
>
> I think we a
On Sun, May 31, 2015 at 11:48 AM, Bruce Momjian wrote:
> On Sat, May 30, 2015 at 10:47:27PM +0200, Andres Freund wrote:
>> So, I think we have built up a lot of technical debt. And very little
>> effort has been made to fix that; and in the cases where people have the
>> reception has often been co
On 30 May 2015 at 03:47, Peter Eisentraut wrote:
> 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.
>
It was deliberately omitted from the original INSTEAD OF triggers
patch because it
26 matches
Mail list logo
