On August 25, 2015 08:36:52 PM Tom Lane wrote:
> Jan de Visser writes:
> > On August 25, 2015 09:31:35 PM Michael Paquier wrote:
> >> This patch had feedback, but there has been no update in the last
> >> month, so I am now marking it as returned with feedback.
> >
> > It was suggested that this
Jan de Visser writes:
> On August 25, 2015 09:31:35 PM Michael Paquier wrote:
>> This patch had feedback, but there has been no update in the last
>> month, so I am now marking it as returned with feedback.
> It was suggested that this mechanism became superfluous with the inclusion of
> the vie
On August 25, 2015 09:31:35 PM Michael Paquier wrote:
> On Thu, Jul 23, 2015 at 5:06 PM, Heikki Linnakangas wrote:
> > Other comments:
> > [...]
>
> This patch had feedback, but there has been no update in the last
> month, so I am now marking it as returned with feedback.
It was suggested that t
On Thu, Jul 23, 2015 at 5:06 PM, Heikki Linnakangas wrote:
> Other comments:
> [...]
This patch had feedback, but there has been no update in the last
month, so I am now marking it as returned with feedback.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
On 07/04/2015 04:24 AM, Jan de Visser wrote:
On July 3, 2015 06:21:09 PM Tom Lane wrote:
Jan de Visser writes:
Attached a new patch, rebased against the current head. Errors in
pg_hba.conf and pg_ident.conf are now also noticed.
I checked the documentation for pg_ctl reload, and the only plac
* Jan de Visser (j...@de-visser.net) wrote:
> On July 6, 2015 09:23:12 AM Stephen Frost wrote:
> > > I wonder whether we should consider inventing similar views for
> > > pg_hba.conf and pg_ident.conf.
> >
> > Yes. That's definitely something that I'd been hoping someone would
> > work on.
>
> T
On July 6, 2015 09:23:12 AM Stephen Frost wrote:
> > I wonder whether we should consider inventing similar views for
> > pg_hba.conf and pg_ident.conf.
>
> Yes. That's definitely something that I'd been hoping someone would
> work on.
There actually is a patch in the current CF that provides a v
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Jan de Visser writes:
> > Attached a new patch, rebased against the current head. Errors in
> > pg_hba.conf and pg_ident.conf are now also noticed.
>
> > I checked the documentation for pg_ctl reload, and the only place where
> > it's explained seems to be
On July 3, 2015 06:21:09 PM Tom Lane wrote:
> I wonder whether we should consider inventing similar views for
> pg_hba.conf and pg_ident.conf.
(Apologies for the flurry of emails).
Was there not an attempt at a view for pg_hba.conf which ended in a lot of
bikeshedding and no decisions?
--
Sen
On July 3, 2015 09:24:36 PM Jan de Visser wrote:
> On July 3, 2015 06:21:09 PM Tom Lane wrote:
> > BTW, this version of this patch neglects to update the comments in
> > miscadmin.h, and it makes the return convention for
> > ProcessConfigFileInternal completely unintelligible IMO; the inaccuracy
>
On July 3, 2015 06:21:09 PM Tom Lane wrote:
> Jan de Visser writes:
> > Attached a new patch, rebased against the current head. Errors in
> > pg_hba.conf and pg_ident.conf are now also noticed.
> >
> > I checked the documentation for pg_ctl reload, and the only place where
> > it's explained seem
Jan de Visser writes:
> Attached a new patch, rebased against the current head. Errors in
> pg_hba.conf and pg_ident.conf are now also noticed.
> I checked the documentation for pg_ctl reload, and the only place where
> it's explained seems to be runtime.sgml and that description is so
> high-lev
On Fri, Jul 3, 2015 at 4:47 PM, I wrote:
> Attached a new patch, rebased against the current head. Errors in
> pg_hba.conf and pg_ident.conf are now also noticed.
>
> I checked the documentation for pg_ctl reload, and the only place where
> it's explained seems to be runtime.sgml and that descript
Attached a new patch, rebased against the current head. Errors in
pg_hba.conf and pg_ident.conf are now also noticed.
I checked the documentation for pg_ctl reload, and the only place where
it's explained seems to be runtime.sgml and that description is so
high-level that adding this new bit of fu
On April 22, 2015 06:04:42 PM Payal Singh wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: tested, failed
> Spec compliant: not tested
> Documentation:tested, failed
>
> Error
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:tested, failed
Error in postgresql.conf gives the expected result on pg_ctl reload,
Ah sorry, didn't realize I top posted. I'll test this new one.
Payal.
On Apr 21, 2015 10:23 PM, "Jan de Visser" wrote:
> On April 21, 2015 09:34:51 PM Jan de Visser wrote:
> > On April 21, 2015 09:01:14 PM Jan de Visser wrote:
> > > On April 21, 2015 07:32:05 PM Payal Singh wrote:
> ... snip ...
On April 21, 2015 09:34:51 PM Jan de Visser wrote:
> On April 21, 2015 09:01:14 PM Jan de Visser wrote:
> > On April 21, 2015 07:32:05 PM Payal Singh wrote:
... snip ...
>
> Urgh. It appears you are right. Will fix.
>
> jan
Attached a new attempt. This was one from the category 'I have no idea h
On April 21, 2015 09:01:14 PM Jan de Visser wrote:
> On April 21, 2015 07:32:05 PM Payal Singh wrote:
> > I'm trying to review this patch and applied
> > http://www.postgresql.org/message-id/attachment/37123/Let_pg_ctl_check_the
> > _r esult_of_a_postmaster_config_reload.patch to postgres. gmake ch
(Please don't top post)
On April 21, 2015 07:32:05 PM Payal Singh wrote:
> I'm trying to review this patch and applied
> http://www.postgresql.org/message-id/attachment/37123/Let_pg_ctl_check_the_r
> esult_of_a_postmaster_config_reload.patch to postgres. gmake check passed
> but while starting pos
I'm trying to review this patch and applied
http://www.postgresql.org/message-id/attachment/37123/Let_pg_ctl_check_the_result_of_a_postmaster_config_reload.patch
to postgres. gmake check passed but while starting postgres I see:
[postgres@vagrant-centos65 data]$ LOG: incomplete data in
"postmaste
On 3/4/15 7:13 PM, Jan de Visser wrote:
On March 4, 2015 11:08:09 PM Andres Freund wrote:
Let's get the basic feature (notification of failed reloads) done
first. That will be required with or without including the error
message. Then we can get more fancy later, if somebody really wants to
inv
On March 4, 2015 11:08:09 PM Andres Freund wrote:
> Let's get the basic feature (notification of failed reloads) done
> first. That will be required with or without including the error
> message. Then we can get more fancy later, if somebody really wants to
> invest the time.
Except for also fixi
On 2015-03-04 19:04:02 -0300, Alvaro Herrera wrote:
> This becomes pretty complicated for a PID file, mind you.
Yes.
Let's get the basic feature (notification of failed reloads) done
first. That will be required with or without including the error
message. Then we can get more fancy later, if so
Peter Eisentraut wrote:
> On 3/3/15 7:34 PM, Jim Nasby wrote:
> > Definitely no multi-line. If we keep that restriction, couldn't we just
> > dedicate one entire line to the error message? ISTM that would be safe.
>
> But we have multiline error messages. If we put only the first line in
> the pi
On 3/3/15 7:34 PM, Jim Nasby wrote:
> Definitely no multi-line. If we keep that restriction, couldn't we just
> dedicate one entire line to the error message? ISTM that would be safe.
But we have multiline error messages. If we put only the first line in
the pid file, then all the tools that buil
On March 3, 2015 06:34:33 PM Jim Nasby wrote:
> On 3/3/15 5:24 PM, Jan de Visser wrote:> On March 3, 2015 04:57:58 PM
> Jim Nasby wrote:
> >> On 3/3/15 11:48 AM, Andres Freund wrote:
> >>> I'm saying that you'll need a way to notice that a reload was
> processed
> >> > or not. And that can
On 3/3/15 5:13 PM, Tom Lane wrote:
Jim Nasby writes:
On 3/3/15 11:48 AM, Andres Freund wrote:
It'll be confusing to have different interfaces in one/multiple error cases.
If we simply don't want the code complexity then fine, but I just don't
buy this argument. How could it possibly be conf
On March 3, 2015 04:57:58 PM Jim Nasby wrote:
> On 3/3/15 11:48 AM, Andres Freund wrote:
> > I'm saying that you'll need a way to notice that a reload was processed
> > or not. And that can't really be the message itself, there has to be
> > some other field; like the timestamp Tom proposes.
>
Jim Nasby writes:
> On 3/3/15 11:48 AM, Andres Freund wrote:
>> It'll be confusing to have different interfaces in one/multiple error cases.
> If we simply don't want the code complexity then fine, but I just don't
> buy this argument. How could it possibly be confusing?
What I'm concerned abou
On 3/3/15 11:48 AM, Andres Freund wrote:
On 2015-03-03 11:43:46 -0600, Jim Nasby wrote:
>It's certainly better than now, but why put DBAs through an extra step for
>no reason?
Because it makes it more complicated than it already is? It's nontrivial
to capture the output, escape it to somehow fi
On 2015-03-03 11:43:46 -0600, Jim Nasby wrote:
> It's certainly better than now, but why put DBAs through an extra step for
> no reason?
Because it makes it more complicated than it already is? It's nontrivial
to capture the output, escape it to somehow fit into a delimited field,
et al. I'd rath
On 3/3/15 11:33 AM, Andres Freund wrote:
On 2015-03-03 11:09:29 -0600, Jim Nasby wrote:
On 3/3/15 9:26 AM, Andres Freund wrote:
On 2015-03-03 15:21:24 +, Greg Stark wrote:
Fwiw this concerns me slightly. I'm sure a lot of people are doing
things like "kill -HUP `cat .../postmaster.pid`" or
On 2015-03-03 11:09:29 -0600, Jim Nasby wrote:
> On 3/3/15 9:26 AM, Andres Freund wrote:
> >On 2015-03-03 15:21:24 +, Greg Stark wrote:
> >>Fwiw this concerns me slightly. I'm sure a lot of people are doing
> >>things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> >
> >postmaste
On 3/3/15 11:15 AM, Jan de Visser wrote:
On March 3, 2015 11:09:29 AM Jim Nasby wrote:
On 3/3/15 9:26 AM, Andres Freund wrote:
On 2015-03-03 15:21:24 +, Greg Stark wrote:
Fwiw this concerns me slightly. I'm sure a lot of people are doing
things like "kill -HUP `cat .../postmaster.pid`" or
On March 3, 2015 11:09:29 AM Jim Nasby wrote:
> On 3/3/15 9:26 AM, Andres Freund wrote:
> > On 2015-03-03 15:21:24 +, Greg Stark wrote:
> >> Fwiw this concerns me slightly. I'm sure a lot of people are doing
> >> things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> >
> > postm
On March 3, 2015 10:29:43 AM Tom Lane wrote:
> Andres Freund writes:
> > On 2015-03-03 15:21:24 +, Greg Stark wrote:
> >> Fwiw this concerns me slightly. I'm sure a lot of people are doing
> >> things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> >
> > postmaster.pid already
On 3/3/15 9:26 AM, Andres Freund wrote:
On 2015-03-03 15:21:24 +, Greg Stark wrote:
Fwiw this concerns me slightly. I'm sure a lot of people are doing
things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
postmaster.pid already contains considerably more than just the pid. e.
Andres Freund writes:
> On 2015-03-03 15:21:24 +, Greg Stark wrote:
>> Fwiw this concerns me slightly. I'm sure a lot of people are doing
>> things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> postmaster.pid already contains considerably more than just the pid. e.g.
Yeah, t
On 2015-03-03 15:21:24 +, Greg Stark wrote:
> Fwiw this concerns me slightly. I'm sure a lot of people are doing
> things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
postmaster.pid already contains considerably more than just the pid. e.g.
4071
/srv/dev/pgdev-master
1425396089
On Fri, Feb 20, 2015 at 1:26 AM, Tom Lane wrote:
> 1. Extend the definition of the postmaster.pid file to add another
> line, which will contain the time of the last postmaster configuration
> load attempt (might as well be a numeric Unix-style timestamp) and
> a boolean indication of whether that
On March 2, 2015 12:56:23 AM Jan de Visser wrote:
>
> Here's my first crack at this. Notes:
> 1/ I haven't done the '-W' flag Tom mentions yet.
> 2/ Likewise haven't touched pg_reload_conf()
> 3/ Design details: I introduced a new struct in pg_ctl containing the
> parsed- out data from postmaster.
Jan de Visser wrote:
> On March 2, 2015 09:50:49 AM Tom Lane wrote:
>> However, you could and should use pg_malloc0, which takes care
>> of that for you...
>
> I am (using pg_malloc, that is). So, just to be sure: pg_malloc
> memsets the block to 0, right?
I think you may have misread a zero char
On March 2, 2015 12:44:40 PM Tom Lane wrote:
> No, it doesn't, but pg_malloc0 does. Consult the code if you're confused:
> src/common/fe_memutils.c
Doh! I read pg_malloc( ), not pg_malloc0.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
Jan de Visser writes:
> On March 2, 2015 09:50:49 AM Tom Lane wrote:
>> However, you could and should use pg_malloc0, which takes care of that
>> for you...
> I am (using pg_malloc, that is). So, just to be sure: pg_malloc memsets the
> block to 0, right?
No, it doesn't, but pg_malloc0 does.
On March 2, 2015 09:50:49 AM Tom Lane wrote:
> However, you could and should use pg_malloc0, which takes care of that
> for you...
I am (using pg_malloc, that is). So, just to be sure: pg_malloc memsets the
block to 0, right?
My question was more along the lines if memsetting to 0 to ensure tha
Jan de Visser writes:
> 4/ Question: Can I assume pg_malloc allocated memory is set to zero? If not,
> is it OK to do a memset(..., 0, ...)? I don't have much experience on any of
> the esoteric platforms pgsql supports...
No, you need the memset. You might accidentally get already-zeroed memo
On Mon, Mar 2, 2015 at 3:01 PM, Jan de Visser wrote:
> On March 2, 2015 12:56:23 AM Jan de Visser wrote:
> ... stuff ...
>
> I seem to have mis-clicked something in the CF app - I created two entries
> somehow. I think one got created when I entered the msgid of Tom's original
> message with the e
On March 2, 2015 12:56:23 AM Jan de Visser wrote:
... stuff ...
I seem to have mis-clicked something in the CF app - I created two entries
somehow. I think one got created when I entered the msgid of Tom's original
message with the enclosing '<...>'. If that's the case, then that may be a
bug.
On February 19, 2015 08:26:45 PM Tom Lane wrote:
> Bug #12788 reminded me of a problem I think we've discussed before:
> if you use "pg_ctl reload" to trigger reload of the postmaster's
> config files, and there's something wrong with those files, there's
> no warning to you of that. The postmaste
Jan de Visser writes:
> I can have a crack at this. What's the process? Do I add it to a CF once I
> have a patch, or do I do that beforehand?
The CF process is for reviewing things, so until you have either a patch
or a design sketch you want feedback on, there's no need for a CF entry.
On February 19, 2015 08:26:45 PM Tom Lane wrote:
> I don't have the time to pursue this idea myself, but perhaps someone
> looking for a not-too-complicated project could take it on.
I can have a crack at this. What's the process? Do I add it to a CF once I
have a patch, or do I do that beforehan
Bug #12788 reminded me of a problem I think we've discussed before:
if you use "pg_ctl reload" to trigger reload of the postmaster's
config files, and there's something wrong with those files, there's
no warning to you of that. The postmaster just bleats to its log and
keeps running. If you don't
53 matches
Mail list logo
