On Sun, Jul 20, 2014 at 7:44 AM, Amit Kapila wrote:
> On Fri, Jul 18, 2014 at 7:08 PM, MauMau wrote:
>>
>> From: "Magnus Hagander"
>>
>>> On Fri, Jul 18, 2014 at 5:33 AM, Amit Kapila
>>> wrote:
On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander
wrote:
>
>
> Did anyone
On Fri, Jul 18, 2014 at 7:08 PM, MauMau wrote:
>
> From: "Magnus Hagander"
>
>> On Fri, Jul 18, 2014 at 5:33 AM, Amit Kapila
wrote:
>>>
>>> On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander
>>> wrote:
Did anyone actually test this patch? :)
I admit I did not build it on
From: "Magnus Hagander"
On Fri, Jul 18, 2014 at 5:33 AM, Amit Kapila
wrote:
On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander
wrote:
Did anyone actually test this patch? :)
I admit I did not build it on Windows specifically because I assumed
that was done as part of the development and revi
On Fri, Jul 18, 2014 at 5:33 AM, Amit Kapila wrote:
> On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander
> wrote:
>>
>> Did anyone actually test this patch? :)
>>
>> I admit I did not build it on Windows specifically because I assumed
>> that was done as part of the development and review. And the
On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander
wrote:
>
> Did anyone actually test this patch? :)
>
> I admit I did not build it on Windows specifically because I assumed
> that was done as part of the development and review. And the changes
> to pg_event.c can never have built, since the file d
On Thu, Jul 17, 2014 at 12:45 PM, Magnus Hagander wrote:
> On Wed, Jul 16, 2014 at 2:01 PM, MauMau wrote:
>> From: "Amit Kapila"
>>
>> So as a conclusion, the left over items to be handled for patch are:
>>>
>>> 1. Remove the new usage related to use of same event source name
>>> for registratio
On Wed, Jul 16, 2014 at 2:01 PM, MauMau wrote:
> From: "Amit Kapila"
>
> So as a conclusion, the left over items to be handled for patch are:
>>
>> 1. Remove the new usage related to use of same event source name
>> for registration from pgevent.
>> 2. Document the information to prevent loss of
From: "Amit Kapila"
So as a conclusion, the left over items to be handled for patch are:
1. Remove the new usage related to use of same event source name
for registration from pgevent.
2. Document the information to prevent loss of messages in some
scenarios as explained above.
I noticed the c
From: "Magnus Hagander"
There's also the change to throw an error if the source is already
registered, which is potentially a bigger problem. Since the default
will be the same everywhere, do we really want to throw an error when
you install a second version, now that this is the normal state?
On Wed, Jul 16, 2014 at 4:06 PM, Magnus Hagander
wrote:
>
> On Wed, Jul 16, 2014 at 12:31 PM, Amit Kapila
wrote:
> > On Wed, Jul 16, 2014 at 2:11 PM, Magnus Hagander
> > wrote:
> >> On Wed, Jul 16, 2014 at 6:37 AM, Amit Kapila
> >> wrote:
> >>
> >> There's also the change to throw an error if t
On Wed, Jul 16, 2014 at 12:31 PM, Amit Kapila wrote:
> On Wed, Jul 16, 2014 at 2:11 PM, Magnus Hagander
> wrote:
>> On Wed, Jul 16, 2014 at 6:37 AM, Amit Kapila
>> wrote:
>>
>> There's also the change to throw an error if the source is already
>> registered, which is potentially a bigger problem
On Wed, Jul 16, 2014 at 2:11 PM, Magnus Hagander
wrote:
> On Wed, Jul 16, 2014 at 6:37 AM, Amit Kapila
wrote:
>
> There's also the change to throw an error if the source is already
> registered, which is potentially a bigger problem.
I think generally if the s/w is installed/registered and we tr
On Wed, Jul 16, 2014 at 6:37 AM, Amit Kapila wrote:
> On Tue, Jul 15, 2014 at 8:57 PM, MauMau wrote:
>>
>> From: "Magnus Hagander"
>>
>>> Well, it does in a couple of places. I'm nto sure it's that important
>>> (as nobody has AFAIK ever requested that change from for example EDB),
>>> but it's
On Tue, Jul 15, 2014 at 8:57 PM, MauMau wrote:
>
> From: "Magnus Hagander"
>
>> Well, it does in a couple of places. I'm nto sure it's that important
>> (as nobody has AFAIK ever requested that change from for example EDB),
>> but it's not a bad thing.
I think this is nothing specific to any ven
From: "Magnus Hagander"
Well, it does in a couple of places. I'm nto sure it's that important
(as nobody has AFAIK ever requested that change from for example EDB),
but it's not a bad thing. However, with a hardcoded service name, I
think the changes to pg_event.c are probably both not necessary
On Tue, Jul 15, 2014 at 4:01 PM, MauMau wrote:
> From: "Magnus Hagander"
>
>> Is there a reason for there still being changes in guc.c, pgevent.c
>> etc? Shouldn't it all be confined to pg_ctl now? That's my
>> understanding from the thread that that's the only part we care about.
>
>
> Yes, stri
From: "Magnus Hagander"
Is there a reason for there still being changes in guc.c, pgevent.c
etc? Shouldn't it all be confined to pg_ctl now? That's my
understanding from the thread that that's the only part we care about.
Yes, strictly speaking, those are useful for the original proposal.
How
On Sat, May 10, 2014 at 4:10 PM, MauMau wrote:
> From: "Amit Kapila"
>
>> I think it's bit late for this patch for 9.4, you might want to move it to
>> next CF.
>
>
> Thanks, I've moved it. It's a regret that this very small patch wasn't put
> in 9.4.
i took a look at the latest version of this
From: "Amit Kapila"
I think it's bit late for this patch for 9.4, you might want to move it to
next CF.
Thanks, I've moved it. It's a regret that this very small patch wasn't put
in 9.4.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Thu, May 8, 2014 at 4:47 PM, MauMau wrote:
> I rebased the patch to HEAD and removed the compilation error on Linux. I
> made event_source variable on all platforms like register_servicename,
> although they are not necessary on non-Windows platforms.
I have verified that current patch is fin
From: "Amit Kapila"
Only one minor suggestion:
+Name of the event source for pg_ctl to use for event log. The
+default is PostgreSQL.
From this description, it is not clear when the event log will be used
in pg_ctl. For example, if user uses -e option with register, then he
m
On Fri, Apr 18, 2014 at 5:21 PM, MauMau wrote:
> From: "Amit Kapila"
>
>> Currently -e option is accepted with all the options that can be provided
>> in pg_ctl. Shouldn't we accept it only with options related to service,
>> because that is only when it will be used. Basically write_stderr() w
From: "Amit Kapila"
Currently -e option is accepted with all the options that can be provided
in pg_ctl. Shouldn't we accept it only with options related to service,
because that is only when it will be used. Basically write_stderr() will
write to event log only incase of service.
Thank you
On Sat, Apr 12, 2014 at 1:21 PM, MauMau wrote:
> Hello, Amit san, Tom san,
>
> I'm sorry for my late response. I've just caught up with the discussion.
> I'm almost convinced.
>
> Please find attached the revised patch. I'd like to follow the idea of
> adding a switch to pg_ctl. The newly added
Hello, Amit san, Tom san,
I'm sorry for my late response. I've just caught up with the discussion.
I'm almost convinced.
Please find attached the revised patch. I'd like to follow the idea of
adding a switch to pg_ctl. The newly added ""-e event_source" sets the
event source name for pg_c
On Mon, Apr 7, 2014 at 7:10 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Sat, Apr 5, 2014 at 8:24 PM, Tom Lane wrote:
> AFAICS, pg_ctl already reports to stderr if stderr is a tty. This whole
> issue only comes up when pg_ctl itself is running as a service (which
> I guess primarily means st
On Sat, Apr 5, 2014 at 10:54 AM, Tom Lane wrote:
> So basically, I think having pg_ctl try to do what this patch proposes
> is a bad idea.
I'm not a Windows person either, but I tend to agree. I can't think
that this is going to be very robust ... and if it's not going to be
robust, what's the p
Amit Kapila writes:
> On Sat, Apr 5, 2014 at 8:24 PM, Tom Lane wrote:
>> How's that going to work during pg_ctl stop? There's no -o switch
>> provided.
> As there's no -o switch, so there won't be problem of getting wrong event
> source name from server due to command line options which you men
On Sat, Apr 5, 2014 at 8:24 PM, Tom Lane wrote:
> Amit Kapila writes:
>> Are you concerned about the case when user passes event_source name
>> in command line at the time of start:
>> pg_ctl start -o "-c event_source=PG9.4" -D
>
> Right.
>
>> If my understanding is right about your concern, the
Amit Kapila writes:
> Are you concerned about the case when user passes event_source name
> in command line at the time of start:
> pg_ctl start -o "-c event_source=PG9.4" -D
Right.
> If my understanding is right about your concern, then I think it will consider
> the above case even when passe
On Sat, Apr 5, 2014 at 4:58 AM, Tom Lane wrote:
> "MauMau" writes:
>> [ pg_ctl_eventsrc_v6.patch ]
>
> I looked at this patch a bit. As a non-Windows person I have no intention
> of being the committer, since I can't test the Windows-specific changes.
> However, I do want to object to the busine
"MauMau" writes:
> [ pg_ctl_eventsrc_v6.patch ]
I looked at this patch a bit. As a non-Windows person I have no intention
of being the committer, since I can't test the Windows-specific changes.
However, I do want to object to the business about having pg_ctl use
"postgres -C" to try to determin
From: "Alvaro Herrera"
MauMau escribió:
The "raw" link only gave the mail in text format. I hoped to import
the mail into Windows Mail on Windows Vista, but I couldn't.
You might need to run a conversion process by which you transform the
raw file (in mbox format) into EML format or whateve
MauMau escribió:
> The "raw" link only gave the mail in text format. I hoped to import
> the mail into Windows Mail on Windows Vista, but I couldn't.
You might need to run a conversion process by which you transform the
raw file (in mbox format) into EML format or whatever it is that Windows
Mai
From: "Alvaro Herrera"
MauMau escribió:
Do you know how I can reply to an email which was deleted locally?
I thought I could download an old mail by clicking "raw" link and
import it to the mailer. However, it requires username/password
input, and it seems to be different from the one for edit
MauMau escribió:
> Hi, Amit san,
>
> I'm replying to your previous email. I wanted to reply to your
> latest mail below, but I removed it from my mailer by mistake.
>
> http://www.postgresql.org/message-id/CAA4eK1LAg6ndZdWLb5e=Ep5DzcE8KZU=JbmO+tFwySYHm2ja=q...@mail.gmail.com
>
> Do you know how
On Mon, Mar 10, 2014 at 2:39 PM, MauMau wrote:
> From: "Amit Kapila"
>
>>> If I understand correctly that objection was on changing Default Event
>>> Source name, and the patch now doesn't contain that change, it's
>>> just a bug fix for letting pg_ctl know the non-default event source
>>> set by
From: "Amit Kapila"
If I understand correctly that objection was on changing Default Event
Source name, and the patch now doesn't contain that change, it's
just a bug fix for letting pg_ctl know the non-default event source
set by user.
Please clarify if I misunderstood something, else this sho
On Mon, Feb 17, 2014 at 9:17 AM, Amit Kapila wrote:
> On Sat, Feb 1, 2014 at 12:31 PM, Amit Kapila wrote:
>> I think it's just a very minor coding style thing, so I am marking this
>> patch as
>> Ready For Committer.
>
> I could see that this patch has been marked as Needs Review in CF app.
> su
On Sat, Feb 1, 2014 at 12:31 PM, Amit Kapila wrote:
> I think it's just a very minor coding style thing, so I am marking this patch
> as
> Ready For Committer.
I could see that this patch has been marked as Needs Review in CF app.
suggesting that it should be rejected based on Tom's rejection in
On Fri, Jan 31, 2014 at 8:20 PM, MauMau wrote:
> Hi, Amit san,
>
> I'm replying to your previous email. I wanted to reply to your latest mail
> below, but I removed it from my mailer by mistake.
>
> http://www.postgresql.org/message-id/CAA4eK1LAg6ndZdWLb5e=Ep5DzcE8KZU=JbmO+tFwySYHm2ja=q...@mail.g
Hi, Amit san,
I'm replying to your previous email. I wanted to reply to your latest mail
below, but I removed it from my mailer by mistake.
http://www.postgresql.org/message-id/CAA4eK1LAg6ndZdWLb5e=Ep5DzcE8KZU=JbmO+tFwySYHm2ja=q...@mail.gmail.com
Do you know how I can reply to an email which
On Fri, Jan 24, 2014 at 4:38 PM, MauMau wrote:
>
>> How about below message:
>>
>> event source "" is already registered.
>> OK, I added several lines for this. Please check the attached patch.
It gives the proper message, but even after error, the second message
box it shows "DLLInstall ... s
On Mon, Jan 27, 2014 at 9:01 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Fri, Jan 24, 2014 at 9:10 AM, Amit Kapila wrote:
>
>> To proceed with the review of this patch, I need to know about
>> whether appending version number or any other constant togli
>
>> Default Event Source name is acce
Amit Kapila writes:
> On Fri, Jan 24, 2014 at 9:10 AM, Amit Kapila wrote:
>> On Fri, Jan 24, 2014 at 2:38 AM, Robert Haas wrote:
>>> I mean, if
>>> there's a GUC that controls the event source name, then it can be
>>> changed between restarts, regardless of what you call it.
>> Yes, but not def
On Fri, Jan 24, 2014 at 9:10 AM, Amit Kapila wrote:
> On Fri, Jan 24, 2014 at 2:38 AM, Robert Haas wrote:
>> On Thu, Jan 23, 2014 at 9:23 AM, Amit Kapila wrote:
>>> On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane wrote:
I think what we might want to do is redefine the server's behavior
>>>
From: "MauMau"
OK, I added several lines for this. Please check the attached patch.
I'm sorry, I attached the old patch as v5 in my previous mail. Attached on
this mail is the correct one.
I'll update the CommitFest entry soon.
Regards
MauMau
pg_ctl_eventsrc_v5.patch
Description: Binar
On Fri, Jan 24, 2014 at 4:22 AM, Tom Lane wrote:
> "MauMau" writes:
>> From: "Tom Lane"
>>> I'm still not clear on why we can't just use the port number.
>
>> To use port, we have to tell the location of $PGDATA to regsvr32.exe.
>
> [ scratches head... ] Exactly which of the other proposals *do
On Fri, Jan 24, 2014 at 2:38 AM, Robert Haas wrote:
> On Thu, Jan 23, 2014 at 9:23 AM, Amit Kapila wrote:
>> On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane wrote:
>>> Amit Kapila writes:
On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote:
> So? Anything which can know the value of a GUC par
"MauMau" writes:
> From: "Tom Lane"
>> I'm still not clear on why we can't just use the port number.
> To use port, we have to tell the location of $PGDATA to regsvr32.exe.
[ scratches head... ] Exactly which of the other proposals *doesn't*
require that? Certainly anything that involves par
From: "Tom Lane"
I'm still not clear on why we can't just use the port number.
It will be possible to use port to set the default value of event_source GUC
when starting postmaster. But using port during event source registration
will involve much more.
To use port, we have to tell the loca
Alvaro Herrera writes:
> Tom Lane escribió:
>> That particular ID would be a horrid choice, because we don't try very
>> hard to ensure it's unique. In particular, a standby server on the same
>> machine as the master (not an uncommon case, at least for testing
>> purposes) would be a guaranteed
Tom Lane escribió:
> Peter Eisentraut writes:
> > On 1/23/14, 4:08 PM, Robert Haas wrote:
> >> Why wouldn't that be necessary with your approach, too? I mean, if
> >> there's a GUC that controls the event source name, then it can be
> >> changed between restarts, regardless of what you call it.
>
Peter Eisentraut writes:
> On 1/23/14, 4:08 PM, Robert Haas wrote:
>> Why wouldn't that be necessary with your approach, too? I mean, if
>> there's a GUC that controls the event source name, then it can be
>> changed between restarts, regardless of what you call it.
> I don't know if it's practi
On 1/23/14, 4:08 PM, Robert Haas wrote:
> Why wouldn't that be necessary with your approach, too? I mean, if
> there's a GUC that controls the event source name, then it can be
> changed between restarts, regardless of what you call it.
I don't know if it's practical, but the logical conclusion h
From: "Amit Kapila"
How about below message:
event source "" is already registered.
OK, I added several lines for this. Please check the attached patch.
What I had in mind was to change it during initdb, we are already doing it
for some other parameter (unix_socket_directories), please re
On Thu, Jan 23, 2014 at 9:23 AM, Amit Kapila wrote:
> On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane wrote:
>> Amit Kapila writes:
>>> On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote:
So? Anything which can know the value of a GUC parameter can certainly
know the selected port number.
>>
On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote:
>>> So? Anything which can know the value of a GUC parameter can certainly
>>> know the selected port number.
>
>> 1. In case of registration of event source, either user
Amit Kapila writes:
> On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote:
>> So? Anything which can know the value of a GUC parameter can certainly
>> know the selected port number.
> 1. In case of registration of event source, either user has to pass the name
> or it uses hard coded default v
On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Wed, Jan 22, 2014 at 6:54 PM, Robert Haas wrote:
>>> I wonder if the port number wouldn't be a better choice. And that
>>> could even be done without adding a parameter.
>
>> We need this for register of event source w
Amit Kapila writes:
> On Wed, Jan 22, 2014 at 6:54 PM, Robert Haas wrote:
>> I wonder if the port number wouldn't be a better choice. And that
>> could even be done without adding a parameter.
> We need this for register of event source which might be done before
> start of server.
So? Anythi
On Wed, Jan 22, 2014 at 6:54 PM, Robert Haas wrote:
> On Tue, Jan 21, 2014 at 11:20 PM, Amit Kapila wrote:
>> On Wed, Jan 22, 2014 at 9:19 AM, Tom Lane wrote:
>>> Amit Kapila writes:
On Tue, Jan 21, 2014 at 6:57 PM, MauMau wrote:
> To follow this, we have the line as:
>
> #eve
On Tue, Jan 21, 2014 at 11:20 PM, Amit Kapila wrote:
> On Wed, Jan 22, 2014 at 9:19 AM, Tom Lane wrote:
>> Amit Kapila writes:
>>> On Tue, Jan 21, 2014 at 6:57 PM, MauMau wrote:
To follow this, we have the line as:
#event_source = 'PostgreSQL 9.4'
But this requires us t
On Wed, Jan 22, 2014 at 9:19 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Tue, Jan 21, 2014 at 6:57 PM, MauMau wrote:
>>> To follow this, we have the line as:
>>>
>>> #event_source = 'PostgreSQL 9.4'
>>>
>>> But this requires us to change this line for each major release. That's a
>>> mainte
Amit Kapila writes:
> On Tue, Jan 21, 2014 at 6:57 PM, MauMau wrote:
>> To follow this, we have the line as:
>>
>> #event_source = 'PostgreSQL 9.4'
>>
>> But this requires us to change this line for each major release. That's a
>> maintenance headache.
> What I had in mind was to change it du
On Tue, Jan 21, 2014 at 6:57 PM, MauMau wrote:
> From: "Amit Kapila"
>> Today, I reviewed the patch again and found it okay, except a small
>> inconsistency which is about default event source name in
>> postgresql.conf, all other places it's changed except in .conf file.
>> Do you think it makes
From: "Amit Kapila"
How about below message:
event source "" is already registered.
Thanks. I'll use this, making the initial letter the capital "E" like other
messages in the same source file. I'm going to submit the final patch and
update the CommitFest entry tomorrow at the earliest.
On Mon, Jan 20, 2014 at 5:38 PM, MauMau wrote:
> From: "Amit Kapila"
>>
>> Do you think without this the problem reported by you is resolved
>> completely.
>> User can hit same problem, if he tries to follow similar steps mentioned
>> in
>> your first mail. I had tried below steps based on
From: "Amit Kapila"
Do you think without this the problem reported by you is resolved
completely.
User can hit same problem, if he tries to follow similar steps mentioned
in
your first mail. I had tried below steps based on description in your
first mail:
If user register/unregister d
On Mon, Jan 20, 2014 at 4:05 AM, MauMau wrote:
> From: "Amit Kapila"
>
>> Today, I was trying to reproduce this issue and found that if user tries
>> to register event source second time with same name, we just replace
>> the previous event source's path in registry.
>> Shouldn't we try to stop u
From: "Amit Kapila"
Today, I was trying to reproduce this issue and found that if user tries
to register event source second time with same name, we just replace
the previous event source's path in registry.
Shouldn't we try to stop user at this step only, means if he tries to
register with same
On Thu, Dec 5, 2013 at 7:54 PM, MauMau wrote:
> Hello,
>
> I've removed a limitation regarding event log on Windows with the attached
> patch. I hesitate to admit this is a bug fix and want to regard this an
> improvement, but maybe it's a bug fix from users' perspective. Actually, I
> received
On Fri, Dec 20, 2013 at 5:26 PM, MauMau wrote:
> From: "Amit Kapila"
>>
>> Few other points:
>>
>> -
>> 1.
>> #ifdef WIN32
>> /* Get event source from postgresql.conf for eventlog output */
>> get_config_value("event_source", event_source, sizeof(event_source));
>> #endif
From: "Amit Kapila"
Few other points:
-
1.
#ifdef WIN32
/* Get event source from postgresql.conf for eventlog output */
get_config_value("event_source", event_source, sizeof(event_source));
#endif
event logging is done for both win32 and cygwin env.
under hash define (Wi
On Tue, Dec 17, 2013 at 5:33 PM, MauMau wrote:
> From: "Amit Kapila"
>
>> Few minor things:
>
> event_source here is a global static char array, so it's automatically
> initialized with zeros and safe to access.
Right, I had missed that point.
>
>
>> 2. minor coding style issue
>
>
> Thanks.
From: "Amit Kapila"
Few minor things:
1.
evtHandle = RegisterEventSource(NULL,
*event_source? event_source: DEFAULT_EVENT_SOURCE);
In this code, you are trying to access the value (*event_source) and
incase it is not initialised,
it will not contain the value and could cause problem, why not
di
On Thu, Dec 12, 2013 at 4:43 PM, MauMau wrote:
> Hi, Amit san,
>
> From: "Amit Kapila"
>>>
>>> [elog.c]
>>> Writing the default value in this file was redundant, because
>>> event_source
>>> cannot be NULL. So change
>>>
>> I think this change might not be safe as write_eventlog() gets called
>>
Hi, Amit san,
From: "Amit Kapila"
[elog.c]
Writing the default value in this file was redundant, because
event_source
cannot be NULL. So change
I think this change might not be safe as write_eventlog() gets called
from write_stderr() which might get called
before reading postgresql.conf, s
On Wed, Dec 11, 2013 at 8:31 PM, MauMau wrote:
>>> From: "Amit Kapila"
>
> I re-considered that. As you suggested, I think I'll do as follows. Would
> this be OK?
>
> [pg_ctl.c]
> evtHandle = RegisterEventSource(NULL, *event_source ? event_source :
>"PostgreSQL " PG_MAJORVERSION);
>
>
> [gu
From: "Amit Kapila"
I think it is better to keep it like what I suggested above,
because in that case
it will assign default name even if postgres -C fails due to some
reason.
2. What will happen if user doesn't change the name in "event_source"
or kept the same name,
won't it hit the
On Mon, Dec 9, 2013 at 5:52 PM, MauMau wrote:
> From: "Amit Kapila"
>
>> 1. isn't it better to handle as it is done in write_eventlog() which
>> means if string is empty then
>>use PostgreSQL.
>> "evtHandle = RegisterEventSource(NULL, event_source ? event_source :
>> "PostgreSQL");"
>
>
> Tha
From: "Amit Kapila"
1. isn't it better to handle as it is done in write_eventlog() which
means if string is empty then
use PostgreSQL.
"evtHandle = RegisterEventSource(NULL, event_source ? event_source :
"PostgreSQL");"
Thank you for reviewing. Yes, I did so with the first revision of this
On Mon, Dec 9, 2013 at 2:25 AM, MauMau wrote:
> From: "Magnus Hagander"
>
>> Not having looked at it in detail yet, but this seems to completely remove
>> the default value. What happens if the error that needs to be logged is
>> the
>> one saying that it couldn't exec postgres to find out the va
From: "Magnus Hagander"
Not having looked at it in detail yet, but this seems to completely remove
the default value. What happens if the error that needs to be logged is
the
one saying that it couldn't exec postgres to find out the value in the
config file? AFAICT it's going to try to registe
On Sun, Dec 8, 2013 at 3:41 AM, MauMau wrote:
> From: "MauMau"
>
> I've removed a limitation regarding event log on Windows with the attached
>> patch. I hesitate to admit this is a bug fix and want to regard this an
>> improvement, but maybe it's a bug fix from users' perspective. Actually,
From: "MauMau"
I've removed a limitation regarding event log on Windows with the attached
patch. I hesitate to admit this is a bug fix and want to regard this an
improvement, but maybe it's a bug fix from users' perspective. Actually,
I
received problem reports from some users.
I've done a
Hello,
I've removed a limitation regarding event log on Windows with the attached
patch. I hesitate to admit this is a bug fix and want to regard this an
improvement, but maybe it's a bug fix from users' perspective. Actually, I
received problem reports from some users.
[Problem]
pg_ctl a
87 matches
Mail list logo
