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 done
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. I'd love to
Andrew Gierth and...@tao11.riddles.org.uk 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=#
On 2015-05-31 11:55:44 -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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 official
Joel Jacobson j...@trustly.com 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
On Sun, May 31, 2015 at 11:55:44AM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Sun, May 31, 2015 at 7:46 PM, Tom Lane t...@sss.pgh.pa.us 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
I have attached new versions which apply on the current master.
Andreas
From a4a4970d37b710449ccd57a8b4d896a3c004b62a Mon Sep 17 00:00:00 2001
From: Andreas Karlsson andr...@proxel.se
Date: Thu, 12 Feb 2015 23:55:01 +0100
Subject: [PATCH 1/4] Replace obsolete macros AC_TRY_* with AC_*_IFELSE.
Tomas Vondra tomas.von...@2ndquadrant.com 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
On Sun, May 31, 2015 at 11:03 PM, Bruce Momjian br...@momjian.us 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
On 06/01/15 00:08, Tom Lane wrote:
Tomas Vondra tomas.von...@2ndquadrant.com 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).
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) is
Bruce Momjian br...@momjian.us 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
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
On Fri, May 29, 2015 at 10:37:57AM +1200, Thomas Munro wrote:
On Fri, May 29, 2015 at 7:56 AM, Robert Haas robertmh...@gmail.com 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.
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() and
On Sat, May 30, 2015 at 3:46 PM, Peter Geoghegan p...@heroku.com 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
On Fri, May 29, 2015 at 10:49 PM, Peter Eisentraut pete...@gmx.net 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
On Sat, May 30, 2015 at 7:09 PM, Andres Freund and...@anarazel.de 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
On Fri, May 29, 2015 at 6:45 PM, Andrew Gierth
and...@tao11.riddles.org.uk 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
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 that; and
On Sat, May 30, 2015 at 8:55 PM, Andres Freund and...@anarazel.de 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
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 coverage,
24 matches
Mail list logo
