.
if (old_pid != 0)
{
pg_usleep(100);
pid = get_pgpid();
if (pid == old_pid postmaster_is_alive(pid))
{
write_stderr(_(%s: could not start server\n
Examine the log output.\n),
progname);
exit(1);
}
}
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers
() sets the process handle in the structure passed
to it. We can pass the process handle to WaitForSingleObject8) to know
whether postmaster is alive.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
() sets the process handle in the structure passed
to it. We can pass the process handle to WaitForSingleObject8) to know
whether postmaster is alive.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
effective solution will be accepted.
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
I encountered a bug which always causes PostgreSQL to crash on Windows.
Attached is a patch that fixes it. Please review it and include it in the
upcoming minor releases of supported versions.
The following is a bug report.
Your name :MauMau
Your email address :maumau...@gmail.com
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
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
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-hackers
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
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 via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
From: Fujii Masao masao.fu...@gmail.com
On Thu, Jan 24, 2013 at 7:42 AM, MauMau maumau...@gmail.com 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
From: Fujii Masao masao.fu...@gmail.com
On Thu, Jan 24, 2013 at 11:53 PM, MauMau maumau...@gmail.com 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
From: Fujii Masao masao.fu...@gmail.com
On Sun, Jan 27, 2013 at 12:17 AM, MauMau maumau...@gmail.com 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 restarts after the
primary
vacuums and truncates a table
? 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 t...@sss.pgh.pa.us
MauMau maumau...@gmail.com 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
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 masao.fu...@gmail.com
On Wed, May 9, 2012 at 9:10 PM, MauMau maumau...@gmail.com 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
From: Fujii Masao masao.fu...@gmail.com
On Thu, May 10, 2012 at 8:18 AM, Euler Taveira eu...@timbira.com 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
From: Kevin Grittner kevin.gritt...@wicourts.gov
MauMau maumau...@gmail.com 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
From: Kevin Grittner kevin.gritt...@wicourts.gov
MauMau maumau...@gmail.com 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
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 (pgsql-hackers
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.2?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql
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 (pgsql
From: Tom Lane t...@sss.pgh.pa.us
MauMau maumau...@gmail.com 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
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
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
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
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
() and
set PostgreSQL to it in DllInstall(). DllInstall() is not called when /i
is not specified. So, event_source remains empty.
To solve the problem, we need to use wcstombs_s() instead of strncpy(), and
initialize event_source to PostgreSQL when it is defined.
Regards
MauMau
--
Sent via
open CommitFest 2001-9 shortly. Please
review it again.
Regards
MauMau
multi_event_source_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
on the same machine to
distinguish themselves in the event log Edit Patch - Move To Another
CommitFest - Delete Patch
https://commitfest.postgresql.org/action/patch_view?id=562
What should I do? Where should I refer to handle patch status correctly?
Regards
MauMau
--
Sent via pgsql-hackers mailing
From: Tom Lane t...@sss.pgh.pa.us
MauMau maumau...@gmail.com writes:
I re-submitted a patch and added a comment on the page below. I chose
patch from the comment type drop-down box, but the patch status does
not
change from waiting on author. I expected the patch status would become
needs
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
From: Tom Lane t...@sss.pgh.pa.us
MauMau maumau...@gmail.com 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
From: Peter Eisentraut pete...@gmx.net
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'm sorry
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
., somefunc just copy records), the virtual memory of
postgres does not increase.
Is there anything to reason about his comment?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
/SysCache may be the cause.
2011/9/28 MauMau maumau...@gmail.com:
Q1: When are the RelCache/SysCache entries removed from
CacheMemoryContext?
Are they removed only when the corresponding relations are deleted? If so,
many tables and indexes is not friendly for the current PostgreSQL?
Regards
MauMau
/SysCache. As
far as I read the code, PostgreSQL seems to use memory for RelCache/SysCache
without limit until the relations are dropped.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
the reason. I will
report it to the customer and ask him to consider taking the following
measures:
* reduce shared_buffers
* run somefunc() and VACUUM in different psql sessions
* process 100,000 tables in multiple psql sessions
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql
to rethink your schema. 10 tables is
far beyond what any sane design could require, and is costing you on
many levels (I'm sure the OS and filesystem aren't that happy with it
either).
I agree. I'll suggest that to the customer, too. Thank you very much.
Regards
MauMau
--
Sent via pgsql
From: Magnus Hagander mag...@hagander.net
2011/7/16 MauMau maumau...@gmail.com:
Hello,
The attached file is a revised patch which reflects all review comments by
Magnus in:
http://archives.postgresql.org/pgsql-hackers/2011-07/msg00839.php
I have applied this patch after another round
.
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
--
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 and...@dunslane.net 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 I'm
From: Tom Lane t...@sss.pgh.pa.us
MauMau maumau...@gmail.com 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
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 dp...@pgadmin.org
To: Tom Lane t...@sss.pgh.pa.us
Cc: MauMau maumau...@gmail.com; pgsql-hackers
that some committer will modify and commit the
change directly?
Regards,
MauMau
From: MauMau maumau...@gmail.com
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 mag...@hagander.net writes:
Any
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
4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
HTML
HEAD
TITLE
PostgreSQL 9.1beta1 Documentation/TITLE
META
...
/BODY
/HTML
Docs build complete.
--
Regards,
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers
From: Andrew Dunstan and...@dunslane.net
On Thu, May 19, 2011 10:32 am, Robert Haas wrote:
2011/5/16 MauMau maumau...@gmail.com:
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
.
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.org)
To make changes to your
From: Kevin Grittner kevin.gritt...@wicourts.gov
MauMau maumau...@gmail.com 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
Andrew,
From: Andrew Dunstan and...@dunslane.net
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
hope PostgreSQL will provide a reliable archiving facility that is ready
to use.
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: Joshua D. Drake j...@commandprompt.com
On 06/08/2013 07:36 AM, MauMau wrote:
3. You cannot know the reason of archive_command failure (e.g. archive
area full) if you don't use PostgreSQL's server logging.
This is because archive_command failure is not logged in syslog/eventlog.
Wait
can't happen events has
occurred like PostgreSQL's bug. I didn't expect postgres dumps core simply
because disk is full. I want postgres to shutdown with FATAL message in
that exact case.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
full is encountered at end-of-recovery
checkpoint, force archiving all unarchived WAL files and delete/recycle them
at that time.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
From: Craig Ringer cr...@2ndquadrant.com
On 06/09/2013 08:32 AM, MauMau wrote:
- Failure of a disk containing data directory or tablespace
If checkpoint can't write buffers to disk because of disk failure,
checkpoint cannot complete, thus WAL files accumulate in pg_xlog/.
This means that one
would you approach this?
Thanks Craig, you gave me some interesting insights. All of these topics
are interesting, and I'd like to work on them when I have acquired enough
knowledge and experience in PostgreSQL development.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql
and a reasonable behavior, is it described
anywhere?
Regards
MauMau
myfunc.pgc
Description: Binary data
myfunc.sql
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
function is irrelevant. The
leak occurs even when you do not use PL/pgSQL.
[Wordaround]
Use CREATE TABLE IF NOT EXISTS and TRUNCATE (or ON COMMIT DROP in case of
temporary tables) to avoid repeated creation/deletion of the same table.
Regards
MauMau
--
Sent via pgsql-hackers mailing list
From: Jeff Janes jeff.ja...@gmail.com
On Tue, Jun 18, 2013 at 3:40 PM, MauMau maumau...@gmail.com wrote:
Really? Would the catcache be polluted with entries for nonexistent
tables? I'm surprised at this. I don't think it is necessary to speed up
the query that fails with nonexistent tables
, especially in the documentation and source code
comments, as English is not my mother tongue.
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
really name it SignalAlmostAllChildren(), could we ..
I see. thank you.
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 alvhe...@2ndquadrant.com
MauMau escribió:
One concern is that umount would fail in such a situation because
postgres has some open files on the filesystem, which is on the
shared disk in case of traditional HA cluster.
See my reply to Noah. If postmaster stays around
waiting for backends to terminate after sending SIGQUIT. The state
name is natural.
I don't have strong objection to your idea if it makes the code cleaner and
more understandable. Thank you very much.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
not be able to 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
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
From: Alvaro Herrera alvhe...@2ndquadrant.com
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
From: Robert Haas robertmh...@gmail.com
On Fri, Jun 21, 2013 at 10:02 PM, MauMau maumau...@gmail.com 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
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 remove
quickdie() and other
Hi, Alvaro san,
From: Alvaro Herrera alvhe...@2ndquadrant.com
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
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
/buffile.c,
which 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
:\\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
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
From: Michael Meskes mes...@postgresql.org
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
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
/work/maumau/stats_tmp/pgstat.stat
From: Tom Lane t...@sss.pgh.pa.us
MauMau maumau...@gmail.com 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
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 to your subscription:
http
-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 make changes to your subscription:
http
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 changes to your subscription:
http
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
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
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
Hello, Fujii san, all,
From: Fujii Masao masao.fu...@gmail.com
On Sun, Jul 28, 2013 at 7:59 AM, MauMau maumau...@gmail.com 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
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
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@postgresql.org
, I suggest this tiny modification to avoid misunderstanding. In
addition, I suggest removing references to OpenSolaris because OpenSolaris
is already discontinued.
I'm attaching one patch file. Could you commit this change?
Regards
MauMau
doc_solaris_version.patch
Description: Binary data
and completed regression
test on Solaris 10. In addition, EnterpriseDB supports their product on
Solaris, don't they?
I appreciate it if you could commit this patch.
Regards
MauMau
doc_solaris_version_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
/message-id/214653D8DF574BFEAA6ED53E545E99E4@maumau
Heiki helped to solve this and found that pg_statistic entries are left in
CacheMemoryContext, but we have no idea where and how they are created and
left. This seems difficult to me.
Regards
MauMau
--
Sent via pgsql-hackers mailing list
From: Robert Haas robertmh...@gmail.com
OK, patch committed and back-patched to 9.3.
The patch file turned out to be sorta garbled. I'm not sure if a
broken version of diff was used to generate this or whether MauMau
hand-edited it after the fact, but the number of lines that were
indicated
or directory
When talking with operating system experts, numeric errno values are
sometimes more useful and easy to communicate than their corresponding
strings. This is a closely related but a separate proposal.
I want the first patch to be backported at least to 9.2.
Regards
MauMau
appreciated.
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 maumau...@gmail.com
OK, I'll take this approach. That is:
I did as Tom san suggested. Please review the attached patch. I chose as
common errnos by selecting those which are used in PosttgreSQL source code
out of the error numbers defined in POSIX 2013.
As I said, lack
are:
project.max-shm-ids=(priv,32768,deny)
project.max-sem-ids=(priv,4096,deny)
project.max-msg-ids=(priv,4096,deny)
I'm asking you because I found your proposal of the above article here:
http://www.postgresql.org/message-id/4be9c10a.4040...@agliodbs.com
Regards
MauMau
--
Sent via pgsql-hackers mailing
strerror_codeset.patch)
for 9.4, and take the non-bind_textdomain_codeset approach for older
releases.
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
. This is done at session start.
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: Peter Eisentraut pete...@gmx.net
On 9/9/13 4:42 PM, MauMau wrote:
1. Take the approach that doesn't use bind_textdomain_codeset(libc)
(i.e. the second version of errno_str.patch) for 9.4 and older releases.
2. Use bind_textdomain_codeset(libc) (i.e. take
strerror_codeset.patch) for 9.4
to
see this as a separate issue.
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
1 - 100 of 369 matches
Mail list logo
