respond to the immediate shutdown request.
What DBAs want from "pg_ctl stop -mi" is to shutdown the database server as
immediately as possible. So I think 5 second is reasonable.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
uot;?
Checkpoint is irrelevant here because we are discussing immediate shutdown.
Some problems with "killall -9 postgres" are:
1. It's not available on Windows.
2. It may kill other database server instances running on the same machine.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From: "Alvaro Herrera"
MauMau escribió:
I thought of adding some new state of pmState for some reason (that
might be the same as your idea).
But I refrained from doing that, because pmState has already many
states. I was afraid adding a new pmState value for this bug fix
would comp
From: "Robert Haas"
On Fri, Jun 21, 2013 at 10:02 PM, MauMau wrote:
I'm comfortable with 5 seconds. We are talking about the interval
between
sending SIGQUIT to the children and then sending SIGKILL to them. In
most
situations, the backends should terminate immediately.
.
Noah Misch escribió:
On Sun, Jun 23, 2013 at 01:55:19PM +0900, MauMau wrote:
> the clients at the immediate shutdown. The code gets much simpler. In
> addition, it may be better that we similarly send SIGKILL in backend
> crash (FatalError) case, eliminate the use of SIGQUIT and re
Hi, Alvaro san,
From: "Alvaro Herrera"
MauMau escribió:
Yeah, I see that --- after removing that early exit, there are unwanted
messages. And in fact there are some signals sent that weren't
previously sent. Clearly we need something here: if we're in immediate
shutdown h
ported. Could you commit this?
Regards
MauMau
ecpg_var_doc.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ch in turn uses OpenTemporaryFile in src/backend/storage/file/fd.c.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e input file name like this:
#line 1 "c:\\command\\a.pgc"
This is necessary not only on Windows but also on UNIX/Linux. For your
information, running "gcc -E di\\r/a.c" escapes \ and outputs the line:
# 1 "di\\r/a.c"
Regards
MauMau
ecpg_line.patch
Descrip
From: "Michael Meskes"
So that means MauMau was right and backslashes have to be escaped in
filenames
in #line directives, right? Apparently my examples were badly chosen as I
didn't see an error no matter how many backslashes I had.
Yes, the below examples shows the case:
few seconds like this:
WARNING: could not open statistics file
"/work/maumau/stats_tmp/pgstat.stat": Permission denied
LOG: could not open temporary statistics file
"/work/maumau/stats_tmp/pgstat.tmp": Permission denied
WARNING: could not open statistics file
"/wor
From: "Tom Lane"
"MauMau" writes:
If the directory specified by stats_temp_directory becomes inaccessible
to
postgres, enormous amount of WARNING messages are output.
Well, yeah, because all of that functionality just broke. Not warning
about it doesn't seem
ecord
altogether.
I think we need to take approach 1 even when we also does 2, because 1 is
necessary when the backup and archive WAL are already taken with the current
PostgreSQL anyway.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
t;Jul 24 2013", but I got:
date
07-24-2013
(1 行)
This does not follow the above statement in 8.5.2. This output is created
by EncodeDateOnly() in src/backend/utils/adt/datetime.c.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
place the above files in bin and remove them from lib?
BTW, why is libpq.dll in lib necessary? For the above files? If so, we can
remove libpq.dll from lib. Or, libpqwalreceiver.dll needs it?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
e fixed? If possible,
could you fix it in the next minor release? If you all are busy, I'll try
to fix it, but give me advice how to do that.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
f
libpq is just installed in the bin directory and not in lib.
Yes, it does need it.
Just out of curiosity, what needs libpq.dll in lib?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ry (e.g. to use the same recovery.conf for all cases). What do you
think? Is there any other good condition to judge if cascading replication
is used?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello, Fujii san, all,
From: "Fujii Masao"
On Sun, Jul 28, 2013 at 7:59 AM, MauMau wrote:
Do you think this should be fixed?
I think so.
How should it be fixed?
What about removing the restored archived file as soon as it's replayed
if cascading replication is n
ough.
Please take either this patch or the previous one.
Regards
MauMau
skip_wal_save_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
by, v1 patch is definitely better because the standby server
would not keep restored archive WAL in pg_xlog when cascading replication is
not used. Otherwise, we have to take v2 patch.
Could you choose either and commit it?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
ng, hstore/JSONB
etc) than we have examples of things languishing in need of attention
(partitioning).
I'm hoping PostgreSQL will have an audit trail feature. I'd like to support
your work by reviewing and testing, although I'm not sure I can fully
understand the code soon.
Rega
Hello,
One user reported a hang problem with 9.4 beta2 on Windows. The PostgreSQL
is 64-bit version. I couldn't find the cause, but want to solve the
problem. Could you help with this?
I heard that the user had run 16 concurrent psql sessions which executes
INSERT and UPDATE statements, w
im anyway.
How were the stacks captured - what tool?
According to his mail, Windbg or userdump.exe. I'll ask him about this.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
se records. I'll ask him again.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e(lock, 0)
FYI, the user reported today that the problem didn't occur when he ran the
same test for 24 hours on 9.3.5. Do you see something relevant in 9.4?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
ink = lock->head;
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From: "MauMau"
Thank you very much. I didn't anticipate such a difficult complicated
cause. The user agreed to try the patch tonight. I'll report back the
result as soon as I got it from him.
The test ran successfully without hang for 24 hours. It was run with your
p
TO should be added to read and write respectively.
(8)
The code looks good. However, I'm worried about the maintenance. How can
developers notice that pgaudit.c needs modification when they add a new SQL
statement? What keyword can they use to grep the source code to find
pgaudit.c?
logs in
separate files.
* Does the command text need "" around it in case it contains commas?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
---
I've heard that the next minor release is scheduled during this weekend. I
really wish this problem will be fixed in that release. If you wish, I'll
post the patch tomorrow or the next day. Could you include the fix in the
weekend release?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ease of use of PostgreSQL.
So I believe PG should handle the problem, not the archive_command.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
do
you think about this fix?
I think having PG automatically destroy archive files is bordering on
insane.
I agree. Before that, PG cannot know the archive location, so PG cannot
delete the partially filled archive files.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-h
forever unless the DBA delete
them. That occurs if pg_xlog/ is lost and the incomplete archive files will
not be overwritten.
Could you give me opinions what to do? I'm willing to submit these fixes.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ions did not reach a solution.
I also found a discussion which might relate to this problem. Does this fix
the problem?
[BUG] lag of minRecoveryPont in archive recovery
http://www.postgresql.org/message-id/20121206.130458.170549097.horiguchi.kyot...@lab.ntt.co.jp
Regards
MauMau
--
Sent
From: "Fujii Masao"
On Thu, Jan 24, 2013 at 7:42 AM, MauMau wrote:
I searched through PostgreSQL mailing lists with "WAL contains references
to
invalid pages", and i found 19 messages. Some people encountered similar
problem. There were some discussions regarding tho
From: "Fujii Masao"
On Thu, Jan 24, 2013 at 11:53 PM, MauMau wrote:
I'm wondering if the fix discussed in the above thread solves my problem.
I
found the following differences between Horiguchi-san's case and my case:
(1)
Horiguchi-san says the bug outputs the message:
From: "Fujii Masao"
On Sun, Jan 27, 2013 at 12:17 AM, MauMau wrote:
Although you said the fix will solve my problem, I don't feel it will.
The
discussion is about the crash when the standby "re"starts after the
primary
vacuums and truncates a table. On the ot
the fix? If it's okay
and you want, I'll submit the patch.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From: "Tom Lane"
"MauMau" writes:
I think the solution is the typical one. That is, to just remember the
receipt of SIGQUIT by setting a global variable and call siglongjmp() in
quickdie(), and perform tasks currently done in quickdie() when
sigsetjmp()
returns in Postg
As I promised yesterday, I'll show you the precise call stack:
#0 0x003fa0cf542e in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x003fa0c7bed5 in _L_lock_9323 () from /lib64/libc.so.6
#2 0x003fa0c797c6 in malloc () from /lib64/libc.so.6
#3 0x003fa0c2fd99 in _nl_make_l1
From: "Tom Lane"
"MauMau" writes:
How about the case where some backend crashes due to a bug of PostgreSQL?
In this case, postmaster sends SIGQUIT to all backends, too. The
instance
is expected to disappear cleanly and quickly. Doesn't the hanging
backend
harm th
From: "Peter Eisentraut"
On 1/30/13 9:11 AM, MauMau wrote:
When I ran "pg_ctl stop -mi" against the primary, some applications
connected to the primary did not stop. The cause was that the backends
was deadlocked in quickdie() with some call stack like the following.
I&
to remaining children if all of the child
processes do not terminate within 10 seconds since the start of immediate
shutdown or FatalError condition.
3. On Windows, kill(SIGKILL) calls TerminateProcess().
4. Documentation change to describe the behavior of immediate shutdown.
Regards
MauMau
KEEPONLYALNUM
in contrib/pg_trgm/trgm.h? If no, what kind of problems would happen?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From: "Fujii Masao"
On Wed, May 9, 2012 at 9:10 PM, MauMau wrote:
This question may be appropriate for pgsql-general, but let me ask here
because the only relevant discussion seems to have been done on
pgsql-hackers:
http://archives.postgresql.org/pgsql-hackers/2011-09/msg0016
From: "Fujii Masao"
On Thu, May 10, 2012 at 8:18 AM, Euler Taveira wrote:
On 09-05-2012 19:17, MauMau wrote:
Then, does it make sense to remove "#define KEEPONLYALNUM" in 9.1.4?
Would it
cause any problems? If no, I wish that, because it eliminates the need
to do
the re
From: "Kevin Grittner"
"MauMau" wrote:
For information, what kind of breakage would occur?
I imagined removing KEEPONLYALNUM would just accept
non-alphanumeric characters and cause no harm to those who use
only alphanumeric characters.
This would break our current u
From: "Kevin Grittner"
"MauMau" wrote:
For information, what kind of breakage would occur?
I imagined removing KEEPONLYALNUM would just accept
non-alphanumeric characters and cause no harm to those who use
only alphanumeric characters.
This would break our current u
From: "Tom Lane"
"MauMau" writes:
I've encountered one problem on Windows. I need to support running all of
my
products on one host simultaneously. Plus, I need to log messages in
syslog/event log. On Linux, I can distinguish the messages of one product
and those of
not a problem because
starting/stopping the database/application is infrequent once the system is
in steady operation." -- this may sound abrupt, though.
Regards,
MauMau
- Original Message -
From: "Dave Page"
To: "Tom Lane"
Cc: "MauMau"
r, can I expect that some committer will modify and commit the
change directly?
Regards,
MauMau
From: ""MauMau""
Sent: Saturday, May 07, 2011 9:35 AM
Subject: Re: [BUGS] BUG #6011: Some extra messages are output in the event
log at PostgreSQL startup
Magnus Hagander writes
does not refuse to take -s, so this is not a big problem.
pg_ctl register [-N servicename] [-U username] [-P password] [-D datadir]
[-w] [-t seconds] [-o options]
Regards,
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;make-errcodes-table.pl": No such file or directory
Running first build...
http://www.w3.org/TR/html4/loose.dtd";>
...
Running collateindex...
collateindex.pl: file "HTML.index" does not exist
Running second build...
http://www.w3.org/TR/html4/loose.dtd";>
...
From: "Andrew Dunstan"
On Thu, May 19, 2011 10:32 am, Robert Haas wrote:
2011/5/16 MauMau :
Can't open perl script "make-errcodes-table.pl": No such file or
directory
I think this is the root of the problem. We have no script called
make-errcodes-table.pl. C
ing to the wrong list.
Yes, I was torn between pgsql-hackers and pgsql-general. I didn't want to
unintentionally give misconception about 9.0 quality to general users, so I
kept the mail here in the end.
Regards,
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
From: "Kevin Grittner"
"MauMau" wrote:
Make pg_ctl's -s option suppress informational event logging.
This will ultimately be up to a committer (and I'm not one), but to
me it seems reasonable to back-patch if it is addressed this way.
the PostgreSQL Windows
Andrew,
From: "Andrew Dunstan"
builddoc.bat failed on my system and reading it made my head hurt. So I
did what I've done with other bat files and rewrote it in Perl. The
result is attached. It works for me, and should be a dropin replacement.
Just put it in the src/tools/msvc directory and run
appreciate if someone could test it
on 64-bit Windows who has the 64-bit environment.
I'll add this patch to the first CommitFest of 9.2. Thank you in advance for
reviewing it.
Regards
MauMau
multi_event_source.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list
d easy. One concern is whether postmaster
can inherit pipes through system() call.
Please give me your ideas. Of course, I would be very happy if some
experienced community member could address this problem.
And finally, do you think this should be handled as a bug, or an improvement
in 9.
Hello,
I posted a patch for bug #6011 to pgsql-hackers several days ago. How can I
check the status of bug fixes? I'm worried that the patch might be
forgotten, because bug #5842 was missed for two months until Bruce noticed
it.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (
From: "Tom Lane"
"MauMau" writes:
The bad thing is that pg_ctl continues to wait until the specified
duration
passes, even if postgres fails to start. For example, it is naturally
desirable for pg_ctl to terminate when postgresql.conf contains a syntax
error.
Hmm, I tho
counts such as the number of bugs per major/minor release,
not-fixed bugs, new features in each major release, etc.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o either of CommitFest or Open Items list a few days
later. (But I'm reluctant to pollute those pages with bug fixes which apply
to previous versions. That can't be helped.)
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e of other MLs
such as pgsql-general, pgsql-jdbc etc.
What could be wrong?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
enough for me.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
set_eventlog_parameters()
Does the community prefer separate parameters for each purpose (syslog and
event log) at the expense of a bit duplicate code, or one unified parameter
(program_name) with less code?
I would appreciate your opinions and advice. I'll try making the patch while
I'
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I'm sorry that I've mistakenly sent an empty mail. This is the intended
mail.
"Andrew Dunstan" wrote in message
news:4d889879.3080...@dunslane.net...
On 03/22/2011 08:22 AM, MauMau wrote:
I would appreciate your opinions and advice. I'll try making the patch
while
uld back-port this. Personally, in practice, 9.1 and
later will be sufficient.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Y'
So, my suggestion is to just add the following sentence right after the
above one.
The Postgres style is an exception: the output of the date type is either
MM-DD- (e.g. 12-17-1997) or DD-MM- (e.g. 17-12-1997), which is
different from the date part of the output of the timesta
database server, it fails to start as follows. In my environment
(RHEL6 for Intel64), it takes about 15 seconds before postgres prints the
messages. This is OK.
[maumau@myhost pgdata]$ pg_ctl -w start
waiting for server to startLOG: could not translate
host name &quo
Hello,
The attached patch implements the below proposal, and moves libecpg.dll,
libecpg_compat.dll, and libpgtypes.dll from lib to bin folder on Windows,
where they should be.
http://www.postgresql.org/message-id/10470B394DB8486F93AC60107CC44C8B@maumau
As Andrew-san said, I don't expe
es and "pg_ctl start" starts another one,
"pg_ctl stop" can terminate successfully because the original postgres it
was waiting for actually terminated.
I'll submit the revised patch tomorrow.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-h
From: "MauMau"
In addition, I'll remove libpq.dll from lib folder unless somebody
objects.
Currently, libpq.dll is placed in both bin and lib. I guess libpq.dll was
left in lib because it was considered necessary for ECPG DLLs.
The attached patch also removes libpq.dll from
ninfo receives NULL from PQhost(), it assumes /tmp.
[Fix]
PQhost() should return the actual destination.
Regards
MauMau
conninfo.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a solution based on approach 1, but I doubt there's one.
If okay, I want to take approach 2. Could you give me your thoughts?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From: "Tom Lane"
If you're going to do a postmaster_is_alive check, why bother with
repeated get_pgpid()?
As I said yesterday, I removed get_pgpid() calls. I'll add this patch to
2014-1 commitfest this weekend if it is not committed until then.
Regards
MauMau
p
From: "Amit Kapila"
On Wed, Dec 4, 2013 at 7:57 PM, MauMau wrote:
* Approach 1
When postgres starts, it removes Administrator privileges from its own
process. But is this possible at all? Windows security API is complex
and
provides many functions. It seems difficult to under
[Fix]
Make pg_ctl use event_source setting in postgresql.conf. This eliminates
the need for every instance to use the event source "PostgreSQL" for its
pg_ctl.
Regards
MauMau
pg_ctl_eventsrc.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
handling both client report and
process termination.
log_min_messages = PANIC;
ereport(FATAL,
(errcode(ERRCODE_CANNOT_CONNECT_NOW),
errmsg("the database system is starting up")));
May I hear your opinions?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgs
richer infrastracture in the long
run. I'm also interested in the latter, and want to discuss it after
solving the problem in front of me.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t be allowed to find out how often #4 is
happening is insane.
I thought someone would point out so. You are right, #4 is a strong hint
for the DBA about max_connection setting or connection pool configuration.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
ight now, I have to suss those out by
regex.
What are the issues of using SQLSTATE XXnnn as a filter?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
er. But what do you think of my original suggestion to easily solve
the current issue? I'd like to remove the current annoying problem first
before spending much time for more excited infrastructure.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
modules
If the second argument is given as "client" or omitted, all files are
installed. With 9.4, the whole installation takes up about 80 MB, and the
client-only installation takes up only 24 MB.
Any comments would be appreciated.
Regards
MauMau
client_only_install_win.patch
D
is.
Am I correct?
* #1 through #3 are necessary for the DBA to investigate and explain to the
end user why he cannot connect to the database.
* #4 and #5 are unnecessary for the DBA. I can't find out any reason why
these are useful for the DBA.
Regards
MauMau
--
Sent via pgsql-hackers m
ficulty? May I implement this feature and submit
a patch for the next commitfest if I have time?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
output. What I'm seeing as a problem is that
FATAL messages are output in a normal situation, which worries the DBA, and
those messages don't help the DBA with anything. They merely worry the DBA.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
uot;FATAL" messages merely make him worried.
The extra FATAL messages can be a problem for support staff. What do you
feel if the DBA asks you for help when some emergency trouble occurs during
recovery, with a few important messages buried in lots of unnecessary FATAL
ones?
Regards
MauMau
invocation of postgres -C/--describe-config still cannot be helped.
I think it is important to resolve this problem, so please godhead and
upload this patch to next CF.
Thanks.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
From: "Michael Paquier"
On Sat, Dec 7, 2013 at 9:06 AM, MauMau wrote:
Recovery target 'immediate'
http://www.postgresql.org/message-id/51703751.2020...@vmware.com
May I implement this feature and submit a patch for the next commitfest
if I have time?
Please feel f
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 fro
27;s going to try to register an eventsource with
whatever random garbage happens to be in the variable.
Thank you for commenting, Magnus san.
The variable is global and contains an empty string, so even in the unlikely
situation where postgres -C fails, the event source simply becomes blank.
Regar
not client-oriented.
If we want to keep the messages, I think LOG or DEBUG would be appropriate.
How about altering "ereport(FATAL, ...)" to "ereport(LOG, ...);
proc_exit(1)"?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tomers and colleagues, who are relatively new to PostgreSQL, asked
like "Is this FATAL message a sign of some problem? What does it mean?" I
think it's natural to show concern when finding FATAL messages. I find it
unnatural for a normal administration operation to emit a FATAL
atabase cluster
http://www.postgresql.org/message-id/F93E42280A9A4A5EB74FC7350C801A20@maumau
I'm wondering if I can do this with cleaner and less code. It would be
grateful if you could give me any advice.
Regards
MauMau
recover_to_backup.patch
Description: Binary data
--
Sent via pgsql-ha
the
community installer, the installer can set event_source = 'PostgreSQL 9.3'
and 'PostgreSQL 9.4' for each instance.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e committed.
In any case, that's a separate discussion and separate patch.
I think so, too. That still seems a bit difficult for what I am now. If
someone starts a discussion in a separate thread, I'd like to join it.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-
NULL. So change
evtHandle = RegisterEventSource(NULL, event_source ? event_source :
"PostgreSQL");
to
evtHandle = RegisterEventSource(NULL, event_source);
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
201 - 300 of 369 matches
Mail list logo
