Greetings,
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> >For someone that expounds consistency - this patch is the furthest thing
> >from it.
> >In some places names are randomly changed to have an underscore
> >>(authmethodlocal to authmethod_local with the obvious inconsistency as
> >wel
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> I would be actually tempted to do the following: one single SRF
> function, say pg_wal_info which takes a text argument in input with
> the following values: flush, write, insert, receive, replay. Thinking
> more about it that would be r
Greetings,
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> New version the global patch unshadow.
> * names more consistent and readable.
> * without big changes.
> * goal,, unshadow all global variables, only, even the simplest.
This didn't address any of the comments that I raised elsewhere o
Greetings,
Didn't see this previously (it's our typical approach to 'reply-all' to
people), though I don't think it changes my feelings about the latest
proposed patch.
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> De: Stephen Frost
> Enviadas: Terça-feir
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Wed, Dec 11, 2019 at 10:16:29AM -0500, Stephen Frost wrote:
> > I've not followed this discussion very closely but I agree entirely that
> > it's really nice to have the timeline be able to be queried in a mo
Greetings,
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> De: Stephen Frost
> Enviadas: Quarta-feira, 11 de Dezembro de 2019 15:34
>
> >I agree with not breaking things but that doesn't mean the only
> >reasonable approach is to do the absolute minimum- you might no
Greetings,
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> 1.So I would like to ask you if at least what has consensus could be used.
> Or is it better to leave everything as it is?
As I tried to say before- I'm all for working to eliminate the shadow
variables, but it should be on a case-by-ca
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I noticed while investigating [1] that we have one single solitary
> use of setenv(3) in our code base, in secure_open_gssapi().
>
> It's been project policy since 2001 to avoid setenv(), and I notice
> that src/port/win32env.c lacks support for
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> The idea is that if you connect over a Unix-domain socket and the local
> (effective) user is the same as the server's (effective) user, then
> access should be granted immediately without any checking of
> pg_hba.conf. Bec
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-12-17 05:40, Stephen Frost wrote:
> >* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >>The idea is that if you connect over a Unix-domain socket and the local
> >>(effecti
Greetings,
* Utsav Parmar (utsavp0...@gmail.com) wrote:
> I'm Utsav Parmar, pursuing my B. Tech in Computer Engineering. I like to
> work on new technologies and am currently looking for open-source projects
> to contribute to.
Neat!
> As it may turn out, I've got a college project in my curricu
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Dec 17, 2019 at 9:06 AM Ranier Vilela wrote:
> > De: Michael Paquier
> > Enviadas: Terça-feira, 17 de Dezembro de 2019 04:45
> > >And if you actually group things together so as any individual looking
> > >at your patches does not
Greetings,
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> De: Robert Haas
> Enviado: quarta-feira, 18 de dezembro de 2019 15:44
>
> >A lot of your emails, like this one, seem to be replies to other
> >emails, but at least in my mail reader (gmail) something you're doing
> >is causing the thre
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Dec 18, 2019 at 1:06 PM Simon Riggs wrote:
> > Just consider this part of the recovery toolkit.
>
> I agree that it would be useful to have a recovery toolkit for reading
> uncommitted data, but I think a lot more thought needs to
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Dec 1, 2019 at 01:13:31AM +, Andrew Gierth wrote:
> > This came up recently on IRC, not sure if the report there was passed on
> > at all.
> >
> > ProcessStartupPacket assumes that there will be only one negotiation
> > request f
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-12-18 15:09, Robert Haas wrote:
> >I feel like this is taking a policy decision that properly belongs in
> >pg_hba.conf and making it into a GUC. If you're introducing a GUC
> >because it's not possible to configure
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-12-18 16:24, Stephen Frost wrote:
> >Which represents pretty much exactly what you're going for here, doesn't
> >it..?
>
> This is similar but not exactly the same thing: (1) It doe
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Why not have a special user that can be used for Type: local pg_hba.conf
> > lines? So you'd have:
> > local all localowner peer
> > That way you're:
> > a) only keeping the
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > Well, if this is the pg_hba.conf setup and I am considering the
> > authentication method when creating new users, then my only safe option
> > is to not create any new users. Because which OS users exist is not
Greetings,
(I've added Robbie to this thread, so he can correct me if/when I go
wrong in my descriptions regarding the depths of GSSAPI ;)
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> I found this comment in fe-connect.c:
>
> /*
> * If GSSAPI is enabled a
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> But ... if "peer" auth allowed all the cases Peter wants to allow,
> >> we'd not be having this discussion in the first plac
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Still, I take your point that "peer" does risk letting in a set of
> >> connections wider than what the DBA was thinking about. Enlargin
Greetings,
* Kohei KaiGai (kai...@heterodb.com) wrote:
> 2020年1月2日(木) 20:56 Alvaro Herrera :
> > On 2020-Jan-02, Kohei KaiGai wrote:
> > > 2020年1月2日(木) 12:16 Alvaro Herrera :
> > > > I think this would need to preserve the notion of multi-table truncates.
> > > > Otherwise it won't be possible to
Greetings,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> I'm not objecting to adding it, I'm just curious. In fact, I think
> that if we do add this, then we should probably add lcm() at the same
> time, since handling its overflow cases is sufficiently non-trivial to
> justify not requiring
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 29/12/2019 23:10, Vik Fearing wrote:
> > On 29/12/2019 17:31, Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
> >>> wrote:
> I'm all for this (and even suggested it during the IRC
Greetings,
On Thu, Jan 2, 2020 at 15:04 Tom Lane wrote:
> Stephen Frost writes:
> > We already have a reserved namespace when it comes to roles,
> > specifically "pg_".. why invent something new like this '&' prefix when
> > we could just declar
Greetings,
On Thu, Jan 2, 2020 at 15:50 Tom Lane wrote:
> Andrew Gierth writes:
> > "Tom" == Tom Lane writes:
> > Tom> Meh. If the things aren't actually roles, I think this'd just add
> > Tom> confusion. Or were you proposing to implement them as roles? I'm
> > Tom> not sure if that would
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > On Thu, Jan 2, 2020 at 15:50 Tom Lane wrote:
> >> To cover the proposed functionality, you'd still need some way to
> >> select not-superuser. So I don't think this fully answers
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > AFAICS, the only options to make that work with JSON are (1) introduce
> > a new hand-coded JSON parser designed for frontend operation, (2) add
> > a dependency on an external JSON parser that we can use from frontend
>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 3, 2020 at 11:44 AM Stephen Frost wrote:
> > Sure, it'd be work, and for "adding a simple backup manifest", maybe too
> > much to be worth considering ... but that's not what is going on he
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 3, 2020 at 12:01 PM Stephen Frost wrote:
> > You're certainly intending to do *something* with the manifest, and
> > while I appreciate that you feel you've come up with a complete use-case
> >
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Thu, Nov 7, 2019 at 2:13 PM Stephen Frost wrote:
> >> I do not agree that we should just shift to using default roles instead
> >> of adding new options to GRANT because of an entirely i
Greetings,
* Robbie Harwood (rharw...@redhat.com) wrote:
> Alvaro Herrera writes:
>
> > How about this?
> >
> > * If GSSAPI is enabled and we can reach a credential cache,
> > * set up a handle for it; if it's operating, just send a
> > * GSS st
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, Jan 02, 2020 at 09:46:44AM -0500, Stephen Frost wrote:
> > I agree that the FDW callback should support multiple tables in the
> > TRUNCATE, but I think it also should include CASCADE as an option and
> > h
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2020-Jan-06, Stephen Frost wrote:
>
> > > I wonder if part of the confusion might be due to the synonyms we're
> > > using here for "in use". Things seem to be "got runnin
Greetings -hackers,
Google Summer of Code is back for 2020! They have a similar set of
requirements, expectations, and timeline as last year.
Now is the time to be working to get together a set of projects we'd
like to have GSoC students work on over the summer. Similar to last
year, we need to
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Mon, Jan 6, 2020 at 1:27 PM Tom Lane wrote:
> >> After sleeping on it, I'm liking that idea; it's simple, and it
> >> preserves the existing behavior that DB owners can install trusted PLs
> >> without any extra permi
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Perhaps I'm wrong, but I wouldn't think changing this from a
> > default-role based approach over to a GRANT'able right using our
> > existing GRANT system would be a lot of work.
&g
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 6, 2020 at 6:56 PM Stephen Frost wrote:
> > The first is this- ANYONE can create an extension in the system today,
> > if it's marked as superuser=false. If anything, it seems like that's
> >
Greetings!
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 7, 2020 at 1:17 PM Stephen Frost wrote:
> > Why would it be trusted if it's $SCARY_EXTENSION ...? Why are we trying
> > to punt on solving for that question by installing a much more
> > complicated
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 7, 2020 at 4:36 PM Stephen Frost wrote:
> > Here's the thing though.. creating the extension isn't *really* (in our
> > permissions model anyway) what lets you create outbound connections-
> > i
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 3, 2020 at 2:35 PM Stephen Frost wrote:
> > > Well, I don't know how to make you happy here.
> >
> > I suppose I should admit that, first off, I don't feel you're required
> > to ma
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > On 2020-Jan-06, Stephen Frost wrote:
> > > > I wonder if part of the confusion might be due to the synonyms we're
> > > > using here for "in u
Greetings,
(I'm also overall in favor of the direction this is going, so general +1
from me, and I took a quick look through the patch and didn't
particularly see anything I didn't like besides what's commented on
below.)
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 8, 2020 at 3:26
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 7, 2020 at 7:32 PM Stephen Frost wrote:
> > You raised the point regarding postgres_fdw and a DB owner being able to
> > run 'create extension postgres_fdw;' and to then make network
> > conne
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 8, 2020 at 6:09 PM Stephen Frost wrote:
> > > To me, this seems more accidental than the natural fallout of good design.
> >
> > I disagree that the privilege design for FDWs was accidental.
>
&
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> What I'm basically objecting to is the pseudo-reservedness. If we
> don't want to dodge that with special syntax, we should dodge it
> by making sure the keywords are actually reserved names. In other
> words, add a "pg_" prefix, as somebody el
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 9, 2020 at 10:09 AM Stephen Frost wrote:
> > [ wall of text ]
This really isn't helpful.
> I don't see anything in here I really disagree with, but nor do I
> understand why any of it means that givi
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> But, again, we already *have* a way of solving this problem: use
> quotes. As Simon pointed out, your proposed solution isn't really a
> solution at all, because & can appear in role names. It probably
> won't, but there probably also won't
Greetings,
* Julien Rouhaud (rjuju...@gmail.com) wrote:
> On Thu, Jan 9, 2020 at 7:43 AM Fujii Masao wrote:
> > On Wed, Dec 25, 2019 at 11:11 PM Julien Rouhaud wrote:
> > > On Wed, Dec 25, 2019 at 2:01 PM Fujii Masao wrote:
> > > > I'd like to propose to add pg_file_sync() function into
> > >
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 9, 2020 at 1:35 PM Tom Lane wrote:
> > Robert Haas writes:
> > > Again, as I said upthread, Tom had the exact feature about which I am
> > > talking in the first version of the patch. That is a strong argument
> > > in favor o
Greetings,
On Thu, Jan 9, 2020 at 14:48 Tom Lane wrote:
> Robert Haas writes:
> > So, if I understand correctly, the patch you are proposing to commit
> > has a new system role, and if you've got that system role, then you
> > can install extensions.
>
> Install *trusted* extensions, correct.
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > So I'm at a loss for why there is this insistence on a default role and
> > a superuser-explicit-granting based approach that goes beyond "is it
> > installed on the filesystem
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> > ... and that backs up my position that we are setting up this
> > privilege at the wrong level by using a default role which a superuser must
> > grant independently from DB ownership.
>
> Don't see how this follows. It's somewhat accidental
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 10, 2020 at 9:30 AM Tom Lane wrote:
> > If somebody comes up with a patch
> > that causes "pg_dumpall -g" to include ALTER SYSTEM SET commands for
> > whatever is in postgresql.auto.conf (not an unreasonable idea BTW),
> > will
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > I haven't run it further to ground than that, but there's definitely
> > something fishy here. Based on just these results one would be hard
> > pressed to say if it's our bug or FreeBSD's, but your report that you
> > don't see the
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 10, 2020 at 2:40 PM Tom Lane wrote:
> > Well, the other direction we could go here, which I guess is what
> > you are arguing for, is to forget the new default role and just
> > say that marking an extension trusted allows it t
Greetings,
On Fri, Jan 10, 2020 at 15:58 Tom Lane wrote:
> Stephen Frost writes:
> > Ah-hah. Not sure if that was Robbie or myself (probably me, really,
> > since I rewrote a great deal of that code). I agree that the regression
> > tests don't test with very much
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > To be clear, I was advocating for a NEW DB-level privilege ('INSTALL' or
> > 'CREATE EXTENSION' if we could make that work), so that we have it be
> > distinct from CREATE (
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> On Fri, 2020-01-10 at 09:29 -0500, Tom Lane wrote:
> > > ALTER SYSTEM is read only in my mind.
> >
> > I'm still having trouble with this conclusion. I think it can only
> > be justified by a very narrow reading of "reflected in pg_du
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> On Mon, 2020-01-13 at 13:56 -0500, Stephen Frost wrote:
> > > I think that having ALTER SYSTEM commands in pg_dumpall output
> > > would be a problem. It would cause all kinds of problems whenever
> > > p
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> In the meantime, though, this idea as stated doesn't do anything except
> >> let a DB owner grant install privileges to someone else. I&#
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > Speaking of sensible progress, I think we've drifted off on a tangent
> > here about ALTER SYSTEM.
>
> Agreed, that's not terribly relevant for the proposed patch.
I agree that the proposed patch seems alright by itself
Greetings,
* Julien Rouhaud (rjuju...@gmail.com) wrote:
> On Fri, Jan 10, 2020 at 10:50 AM Fujii Masao wrote:
> > On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud wrote:
> > > I think that pg_write_server_files should be allowed to call that
> > > function by default.
> >
> > But pg_write_server_f
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > Here's a draft patch that cleans up all the logic errors I could find.
>
> So last night I was assuming that this problem just requires more careful
> attention to what to return in the error exit paths. In the light of
> morning,
Greetings,
* David Fetter (da...@fetter.org) wrote:
> On Tue, Jan 14, 2020 at 12:53:04PM -0500, Tom Lane wrote:
> > Robert Haas writes:
> > > ... I would also expect that depending on an external package
> > > would provoke significant opposition. If we suck the code into core,
> > > then we have
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> ... We must remember how much data we encrypted
> >> and then discount that much of the caller's supplied data next time.
> >> Ther
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "asaba.takan...@fujitsu.com" writes:
> > I want to add the feature to erase data so that it cannot be restored
> > because it prevents attackers from stealing data from released data area.
>
> I think this is fairly pointless, unfortunately.
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Wed, Jan 15, 2020 at 10:23:22AM -0500, Stephen Frost wrote:
> >I disagree entirely. If the operating system and hardware level provide
> >a way for this to work, which is actually rather common when you
> >
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Tomas Vondra writes:
> > But let's assume it makes sense - is this really the right solution? I
> > think what I'd prefer is encryption + rotation of the keys. Which should
> > work properly even on COW filesystems, the performance impact is kin
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 15, 2020 at 10:25 AM Peter Eisentraut
> wrote:
> > Well, if the transaction was declared read-only, then committing it
> > (directly or 2PC) shouldn't change anything. This appears to be a
> > circular argument.
>
> I don't t
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 14, 2020 at 1:46 PM Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > Robert Haas writes:
> > > > Speaking of sensible progress, I think we've drifted off on a tang
Greetings,
* asaba.takan...@fujitsu.com (asaba.takan...@fujitsu.com) wrote:
> This feature erases data area just before it is returned to the OS (“erase”
> means that overwrite data area to hide its contents here)
> because there is a risk that the data will be restored by attackers if it is
>
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jan 13, 2020 at 01:56:30PM -0500, Stephen Frost wrote:
> > > I think that having ALTER SYSTEM commands in pg_dumpall output
> > > would be a problem. It would cause all kinds of problems whenever
> > > p
Greetings,
* asaba.takan...@fujitsu.com (asaba.takan...@fujitsu.com) wrote:
> From: Stephen Frost
> > * asaba.takan...@fujitsu.com (asaba.takan...@fujitsu.com) wrote:
> > > This feature erases data area just before it is returned to the OS
> > > (“erase”
> >
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> The patch as I'm proposing it has nothing to do with "CREATE" rights.
> >> You're attacking something different from what I ac
Greetings,
On Tue, Jan 28, 2020 at 16:17 Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jan 28, 2020 at 3:52 PM Tom Lane wrote:
> >> I continue to think that allowing DB owners to decide this is, if not
> >> fundamentally the wrong thing, at least not a feature that anybody has
> >> asked f
Greetings,
* Robbie Harwood (rharw...@redhat.com) wrote:
> Stephen Frost writes:
> > * Robbie Harwood (rharw...@redhat.com) wrote:
> >> Stephen Frost writes:
> >>
> >> I wanted to note a couple things about this approach. It now uses
> >> on
Greetings,
* Darafei "Komяpa" Praliaskouski (m...@komzpa.net) wrote:
> > I'll plan to push this tomorrow with the above change (and a few
> > additional comments to explain what all is going on..).
>
> Is everything ok? Can it be pushed?
This has been pushed now.
Thanks!
Stephen
signature.as
Greetings,
On Tue, Apr 2, 2019 at 18:10 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-02-23 17:27, Stephen Frost wrote:
> >> About pg_hba.conf: The "hostgss" keyword seems a bit confusing. It only
> >> applies to encrypted gss-using
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Apr 3, 2019 at 12:22 AM Joe Conway wrote:
> > On 4/2/19 6:18 PM, Stephen Frost wrote:
> > > On Tue, Apr 2, 2019 at 18:10 Peter Eisentraut
> > > > > <mailto:peter.eisentr...@2ndquadrant.com>
Greetings,
* Justin Pryzby (pry...@telsasoft.com) wrote:
> On Fri, Mar 22, 2019 at 02:27:07PM -0400, Robert Haas wrote:
> > On Tue, Mar 19, 2019 at 1:37 PM Alexander Korotkov
> > wrote:
> > > Thank you for pointing, but none of the threads you pointed describe
> > > this exact problem. Now I see
Greetings,
On Wed, Apr 3, 2019 at 16:01 Andres Freund wrote:
> Hi,
>
> On 2019-04-03 10:43:33 -0400, Stephen Frost wrote:
> > I'll push this in a few hours unless there's anything else.
>
> The CF entry for this is still open - is there any work missing?
Greetings Robbie,
On Wed, Apr 3, 2019 at 17:47 Robbie Harwood wrote:
> Stephen Frost writes:
>
> > On Wed, Apr 3, 2019 at 16:01 Andres Freund wrote:
> >> On 2019-04-03 10:43:33 -0400, Stephen Frost wrote:
> >>
> >>> I'll push this in a few hours
Greetings,
On Wed, Apr 3, 2019 at 22:02 Michael Paquier wrote:
> On Wed, Apr 03, 2019 at 05:51:06PM -0400, Stephen Frost wrote:
> > Thanks so much for pushing on it for so long, it’s a great feature to
> have!
>
> Glad to see that the final result is using an API layer in
>
Greetings,
On Thu, Apr 4, 2019 at 05:20 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> Kerberos tests are now failing for me (macOS). I'm seeing
>
> psql: error: could not connect to server: Over-size error packet sent by
> the server.
> not ok 3 - GSS encryption without auth
>
>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > On Thu, Apr 4, 2019 at 05:20 Peter Eisentraut <
> > peter.eisentr...@2ndquadrant.com> wrote:
> >> Kerberos tests are now failing for me (macOS).
>
> > Interesting, they work loca
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I'm not very sure why the integer/pointer confusion in pgstat_bestart
> >> doesn't cause hard crashes when using gss auth --- or does
&
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Well, if the caller thinks what is being passed back is an int,
> >> it will do a 32-to-64-bit widening, which is almost certainly
> >> go
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> Kerberos tests are now failing for me (macOS). I'm seeing
>
> psql: error: could not connect to server: Over-size error packet sent by
> the server.
> not ok 3 - GSS encryption without auth
>
> # Failed test 'GSS encryp
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > Stephen Frost writes:
> >> So I'm a bit surprised that it's taking 4 minutes for you. I wonder if
> >> there might be an issue related to the KDC wanting to get some amount of
> >&
7;ve just pushed a fix for. That said...
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-04-04 17:35, Stephen Frost wrote:
> > Ok, it looks like there's a server-side error happening here, and it
> > would be good to see what that is, so can you send the ser
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-04-05 04:59, Stephen Frost wrote:
> > Alright, that over-size error was a bug in the error-handling code,
> > which I've just pushed a fix for. That said...
>
> Yes, that looks better no
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-04-05 14:48, Stephen Frost wrote:
> > On a failure to set up an encrypted connection, we'll actually fall back
> > to a non-encrypted one using GSSAPI *just* for authentication, which is>
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-04-05 23:37, Stephen Frost wrote:
> > I wonder if somehow the keytab file that the server is using isn't
> > getting destroyed between the two test runs and so you're ending up with
> >
Greetings,
* Robbie Harwood (rharw...@redhat.com) wrote:
> Bruce Momjian writes:
> > On Wed, Apr 3, 2019 at 08:49:25AM +0200, Magnus Hagander wrote:
> >> On Wed, Apr 3, 2019 at 12:22 AM Joe Conway wrote:
> >>
> >> Personally I don't find it as confusing as is either, and I find
> >> hostgss to
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-04-09 09:32, Peter Eisentraut wrote:
> > On 2019-04-09 04:51, Stephen Frost wrote:
> >>> Running just 002_enc.pl by itself passes the tests!
> >> Great! I think what I'll do i
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Tue, Apr 09, 2019 at 02:29:09PM -0400, Robert Haas wrote:
> >On Tue, Apr 9, 2019 at 11:51 AM Alvaro Herrera
> >wrote:
> >>This is not surprising, considering that columnar store is precisely the
> >>reason for starting the work
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> Several companies, including EnterpriseDB, NTT, and Postgres Pro, have
> developed technology that permits a block-level incremental backup to
> be taken from a PostgreSQL server. I believe the idea in all of those
> cases is that non-rela
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Apr 15, 2019 at 09:01:11AM -0400, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > Several companies, including EnterpriseDB, NTT, and Postgres Pro, have
> > > developed technology
701 - 800 of 1955 matches
Mail list logo
