On Thu, Jun 30, 2016 at 10:24 AM, Alvaro Herrera
wrote:
> Also, actually, I see no reason for the conninfo to be shown differently
> regardless of a connection being already established. If we show the
> conninfo that the server is trying to use, it might be easier to
> diagnose a problem. In sh
On Thu, Jul 7, 2016 at 4:43 AM, Stephen Frost wrote:
> All,
>
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> Michael Paquier wrote:
>> > On Wed, Jul 6, 2016 at 7:34 PM, Fujii Masao wrote:
>> > > I have one question; why do we call the column "conn_info" instead of
>> > > "conninfo" which
All,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Michael Paquier wrote:
> > On Wed, Jul 6, 2016 at 7:34 PM, Fujii Masao wrote:
> > > I have one question; why do we call the column "conn_info" instead of
> > > "conninfo" which is basically used in other places? "conninfo" is better
> > >
Michael Paquier wrote:
> On Wed, Jul 6, 2016 at 7:34 PM, Fujii Masao wrote:
> > I have one question; why do we call the column "conn_info" instead of
> > "conninfo" which is basically used in other places? "conninfo" is better to
> > me.
>
> No real reason for one or the other to be honest. If y
On Wed, Jul 6, 2016 at 7:34 PM, Fujii Masao wrote:
> I have one question; why do we call the column "conn_info" instead of
> "conninfo" which is basically used in other places? "conninfo" is better to
> me.
No real reason for one or the other to be honest. If you want to
change it you could just
On Mon, Jul 4, 2016 at 12:40 PM, Michael Paquier
wrote:
> On Sat, Jul 2, 2016 at 2:56 AM, Alvaro Herrera
> wrote:
>> Michael Paquier wrote:
>>> On Fri, Jul 1, 2016 at 8:50 AM, Michael Paquier
>>> wrote:
>>
>>> >> Okay, that argument I buy.
>>> >>
>>> >> I suppose this function/view should repor
On Sat, Jul 2, 2016 at 2:56 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> On Fri, Jul 1, 2016 at 8:50 AM, Michael Paquier
>> wrote:
>
>> >> Okay, that argument I buy.
>> >>
>> >> I suppose this function/view should report no row at all if there is no
>> >> wal receiver connected, rather t
Michael Paquier wrote:
> On Fri, Jul 1, 2016 at 8:50 AM, Michael Paquier
> wrote:
> >> Okay, that argument I buy.
> >>
> >> I suppose this function/view should report no row at all if there is no
> >> wal receiver connected, rather than a view with nulls.
> >
> > The function returns PG_RETURN_NU
On Fri, Jul 1, 2016 at 8:50 AM, Michael Paquier
wrote:
> On Fri, Jul 1, 2016 at 8:48 AM, Alvaro Herrera
> wrote:
>> Michael Paquier wrote:
>>> Yeah, I know. Now my opinion regarding this view is that we should
>>> show information about a currently-working WAL receiver, and that it
>>> has nothi
On Fri, Jul 1, 2016 at 8:48 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> Yeah, I know. Now my opinion regarding this view is that we should
>> show information about a currently-working WAL receiver, and that it
>> has nothing to do with reporting information of its previous startup state
Michael Paquier wrote:
> On Fri, Jul 1, 2016 at 8:35 AM, Alvaro Herrera
> wrote:
> > Michael Paquier wrote:
> >> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera
> >> wrote:
> >> > Also, actually, I see no reason for the conninfo to be shown differently
> >> > regardless of a connection being al
On Fri, Jul 1, 2016 at 8:35 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera
>> wrote:
>> > Also, actually, I see no reason for the conninfo to be shown differently
>> > regardless of a connection being already established. If we show the
>>
Michael Paquier wrote:
> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera
> wrote:
> > Also, actually, I see no reason for the conninfo to be shown differently
> > regardless of a connection being already established. If we show the
> > conninfo that the server is trying to use, it might be easie
On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera
wrote:
> Also, actually, I see no reason for the conninfo to be shown differently
> regardless of a connection being already established. If we show the
> conninfo that the server is trying to use, it might be easier to
> diagnose a problem. In sh
Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 10:12 PM, Michael Paquier
> wrote:
> > On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera
> > wrote:
> >> Fujii Masao wrote:
> >>> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
> >>> wrote:
> >>> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao
> >>>
On Thu, Jun 30, 2016 at 10:12 PM, Michael Paquier
wrote:
> On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera
> wrote:
>> Fujii Masao wrote:
>>> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
>>> wrote:
>>> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao
>>> > wrote:
>>
>>> >> ISTM that we will
On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
>> wrote:
>> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote:
>
>> >> ISTM that we will never be able to get out of this loop if walreceiver
>> >> fails to connect
Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
> wrote:
> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote:
> >> ISTM that we will never be able to get out of this loop if walreceiver
> >> fails to connect to the master (e.g., password is wrong) after we enter
> >> thi
On Thu, Jun 30, 2016 at 9:35 PM, Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
> wrote:
>> On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote:
>>> (2)
>>> +retry:
>>> +SpinLockAcquire(&walrcv->mutex);
>>> +if (!walrcv->ready_to_display)
>>> +{
>>> +Spi
On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
wrote:
> On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote:
>> (2)
>> +retry:
>> +SpinLockAcquire(&walrcv->mutex);
>> +if (!walrcv->ready_to_display)
>> +{
>> +SpinLockRelease(&walrcv->mutex);
>> +CHECK_FOR_INTERRUPTS()
Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera
> wrote:
> > Alvaro Herrera wrote:
> >
> >> I propose to push this patch, closing the open item, and you can rework
> >> on top -- I suppose you would completely remove the original conninfo
> >> from shared memory and instead on
On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote:
> (2)
> +retry:
> +SpinLockAcquire(&walrcv->mutex);
> +if (!walrcv->ready_to_display)
> +{
> +SpinLockRelease(&walrcv->mutex);
> +CHECK_FOR_INTERRUPTS();
> +pg_usleep(1000);
> +goto retry;
> +}
> +
On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>
>> I propose to push this patch, closing the open item, and you can rework
>> on top -- I suppose you would completely remove the original conninfo
>> from shared memory and instead only copy the obfuscated version th
Michael Paquier writes:
> On Thu, Jun 30, 2016 at 6:47 AM, Tom Lane wrote:
>> It strikes me that keeping a password embedded in the conninfo from being
>> exposed might be quite a bit harder/riskier if it became a GUC. Something
>> to keep in mind if we ever try to make that change ...
> Exposi
On Thu, Jun 30, 2016 at 6:47 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> There was also that (old) thread about making the recovery.conf parameters
>> be general GUCs. I don't actually remember the consensus there, but diong
>> that would certainly change how it's handled as well.
>
> It str
Magnus Hagander writes:
> There was also that (old) thread about making the recovery.conf parameters
> be general GUCs. I don't actually remember the consensus there, but diong
> that would certainly change how it's handled as well.
It strikes me that keeping a password embedded in the conninfo f
On Wed, Jun 29, 2016 at 11:18 PM, Michael Paquier wrote:
> On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera
> wrote:
> > Alvaro Herrera wrote:
> >
> >> I propose to push this patch, closing the open item, and you can rework
> >> on top -- I suppose you would completely remove the original conninf
On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>
>> I propose to push this patch, closing the open item, and you can rework
>> on top -- I suppose you would completely remove the original conninfo
>> from shared memory and instead only copy the obfuscated version th
Alvaro Herrera wrote:
> I propose to push this patch, closing the open item, and you can rework
> on top -- I suppose you would completely remove the original conninfo
> from shared memory and instead only copy the obfuscated version there
> (and probably also remove the ready_to_display flag). I
Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 2:50 AM, Alvaro Herrera
> wrote:
> > Fujii Masao wrote:
> >> On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
> >> wrote:
> >> > Michael Paquier wrote:
> >> >> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
> >> >> wrote:
> >> >
> >> >> > I have alre
On Thu, Jun 30, 2016 at 2:50 AM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>> On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
>> wrote:
>> > Michael Paquier wrote:
>> >> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
>> >> wrote:
>> >
>> >> > I have already edited the patch following some of
Fujii Masao wrote:
> On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
> wrote:
> > Michael Paquier wrote:
> >> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
> >> wrote:
> >
> >> > I have already edited the patch following some of these ideas. Will
> >> > post a new version later.
> >>
> >> Coo
On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
>> wrote:
>
>> > I have already edited the patch following some of these ideas. Will
>> > post a new version later.
>>
>> Cool, thanks.
>
> Here it is. I found it
On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
>> wrote:
>
>> > I have already edited the patch following some of these ideas. Will
>> > post a new version later.
>>
>> Cool, thanks.
>
> Here it is. I found it
Michael Paquier wrote:
> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
> wrote:
> > I have already edited the patch following some of these ideas. Will
> > post a new version later.
>
> Cool, thanks.
Here it is. I found it was annoying to maintain the function return
tupdesc in two places (
On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> I have been thinking more about that, and came up with the following
>> idea... We do not want to link libpq directly to the server, so let's
>> add a new routine to libpqwalreceiver that builds an obfuscated
>> c
Michael Paquier wrote:
> I have been thinking more about that, and came up with the following
> idea... We do not want to link libpq directly to the server, so let's
> add a new routine to libpqwalreceiver that builds an obfuscated
> connection string and let's have walreceiver.c save it in shared
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Michael Paquier writes:
> > > On Tue, Jun 21, 2016 at 11:29 AM, Tom Lane wrote:
> > >> What I would want to know is whether this specific change is actually a
> > >> good idea. In particular, I'm concerned about the possible secur
Noah Misch wrote:
> On Sun, Jun 19, 2016 at 05:56:12PM +0900, Michael Paquier wrote:
> > The new pg_stat_wal_receiver does not include primary_conninfo.
> > Looking at that now, it looks almost stupid not to include it...
> > Adding it now would require a catalog bump, so I am not sure if this
> >
On Sun, Jun 19, 2016 at 05:56:12PM +0900, Michael Paquier wrote:
> The new pg_stat_wal_receiver does not include primary_conninfo.
> Looking at that now, it looks almost stupid not to include it...
> Adding it now would require a catalog bump, so I am not sure if this
> is acceptable at this stage
On Wed, Jun 22, 2016 at 10:51 AM, Michael Paquier
wrote:
> This connection string is stored in shared memory in WalRcvData, and
> that's the case for a couple of releases now, so it has already a high
> footprint, though I agree that making that available at SQL level
> makes it even worse. Lookin
On Wed, Jun 22, 2016 at 12:04 AM, Stephen Frost wrote:
> Ugh. I would certainly rather not have yet another special, hard-coded,
> bit of logic that magically makes things available to a superuser when
> it's not available to regular users.
> What that results in is the need to have a new default
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Tue, Jun 21, 2016 at 11:29 AM, Tom Lane wrote:
> >> What I would want to know is whether this specific change is actually a
> >> good idea. In particular, I'm concerned about the possible security
> >> implications of exposi
On Tue, Jun 21, 2016 at 12:06 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 6/20/16 10:29 PM, Tom Lane wrote:
>>> What I would want to know is whether this specific change is actually a
>>> good idea. In particular, I'm concerned about the possible security
>>> implications of exposing pr
Peter Eisentraut writes:
> On 6/20/16 10:29 PM, Tom Lane wrote:
>> What I would want to know is whether this specific change is actually a
>> good idea. In particular, I'm concerned about the possible security
>> implications of exposing primary_conninfo --- might it not contain a
>> password, fo
On 6/20/16 10:29 PM, Tom Lane wrote:
What I would want to know is whether this specific change is actually a
good idea. In particular, I'm concerned about the possible security
implications of exposing primary_conninfo --- might it not contain a
password, for example?
That would have been my o
Michael Paquier writes:
> On Tue, Jun 21, 2016 at 11:29 AM, Tom Lane wrote:
>> What I would want to know is whether this specific change is actually a
>> good idea. In particular, I'm concerned about the possible security
>> implications of exposing primary_conninfo --- might it not contain a
>>
On Tue, Jun 21, 2016 at 11:29 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Jun 21, 2016 at 9:58 AM, Tatsuo Ishii wrote:
>>> Even there seems to be ongoing discussions on changing version number
>>> while in the beta period (and which definitely requires initdb). Why
>>> not changing
Michael Paquier writes:
> On Tue, Jun 21, 2016 at 9:58 AM, Tatsuo Ishii wrote:
>> Even there seems to be ongoing discussions on changing version number
>> while in the beta period (and which definitely requires initdb). Why
>> not changing system catalog during beta?:-)
> I am not directly again
On Tue, Jun 21, 2016 at 9:58 AM, Tatsuo Ishii wrote:
>>> Thanks, this looks good. Could you please add it to the next commitfest
>>> so that it doesn't get lost and also so I can do an official review of it?
>>
>> Yes, I just did that. That's too late for 9.6 anyway with beta2 close by.
>
> Even
>> Thanks, this looks good. Could you please add it to the next commitfest
>> so that it doesn't get lost and also so I can do an official review of it?
>
> Yes, I just did that. That's too late for 9.6 anyway with beta2 close by.
Even there seems to be ongoing discussions on changing version nu
On Mon, Jun 20, 2016 at 11:26 PM, Vik Fearing wrote:
> On 19/06/16 13:02, Michael Paquier wrote:
>> On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote:
>>> On 19/06/16 12:28, Michael Paquier wrote:
On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
Or in short the attached.
>>>
>>> The co
On 19/06/16 13:02, Michael Paquier wrote:
> On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote:
>> On 19/06/16 12:28, Michael Paquier wrote:
>>> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
>>> Or in short the attached.
>>
>> The code looks good to me but why no documentation?
>
> Because tha
On 19/06/16 13:02, Michael Paquier wrote:
> On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote:
>> On 19/06/16 12:28, Michael Paquier wrote:
>>> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
>>> Or in short the attached.
>>
>> The code looks good to me but why no documentation?
>
> Because tha
On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote:
> On 19/06/16 12:28, Michael Paquier wrote:
>> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
>> Or in short the attached.
>
> The code looks good to me but why no documentation?
Because that's a long day... Thanks! Now you have it.
--
Michae
On 19/06/16 12:28, Michael Paquier wrote:
> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
> wrote:
>> The new pg_stat_wal_receiver does not include primary_conninfo.
>> Looking at that now, it looks almost stupid not to include it...
>> Adding it now would require a catalog bump, so I am not su
On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
wrote:
> The new pg_stat_wal_receiver does not include primary_conninfo.
> Looking at that now, it looks almost stupid not to include it...
> Adding it now would require a catalog bump, so I am not sure if this
> is acceptable at this stage for 9.6.
Hi all,
The new pg_stat_wal_receiver does not include primary_conninfo.
Looking at that now, it looks almost stupid not to include it...
Adding it now would require a catalog bump, so I am not sure if this
is acceptable at this stage for 9.6...
Regards,
--
Michael
--
Sent via pgsql-hackers ma
58 matches
Mail list logo
