t for helping me.
After that, I had to stay away from the community for some reason. Now, I'd be
happy if I can contribute to PostgreSQL again. But please excuse me for my
slow restart, as the blank period needs some rehabilitation.
Let me briefly introduce myself. I'm MauMau, this i
g out. There are discussions about backporting stuff
from XC/XL back to core, though that's a tough work. This thread is a
good summary of what is happening lately in this area:
http://www.postgresql.org/message-id/20160223164335.ga11...@momjian.us
Cool, exciting to know this!
Regards
MauMau
-
e interoperable when migrating from
commercial databases?
What is the effective way to absorb user requests for this? Is it enough to
make a questionnaire like the following? What is the popular questionnaire
site which can catch many users (SurveyMonkey?)
https://postgresql.uservoice.com/forums/21853-general
Regards
MauMau
nvincing to appeal the increasing potential of PostgreSQL as a good
replacement for commercial databases?
Change the name :p
--
Sorry, I couldn't catch the implication. Do you mean changing the name
PostgreSQL to something else, or just a joke?
Regards
MauMau
ily
add to the catalog.
Regards
MauMau
Hello,
pg_recvlogical is not included in the Windows client installation,
which is performed by running "install client". The
attached patch based on HEAD fixes this. I confirmed nothing else is
missing in the client installation.
Regards
MauMau (= Takayuki
From: Robert Haas
On Sat, Sep 17, 2016 at 7:44 PM, Michael Paquier
wrote:
> On Sun, Sep 18, 2016 at 7:01 AM, MauMau wrote:
>> pg_recvlogical is not included in the Windows client installation,
>> which is performed by running "install client". The
>> attached pat
From: Simon Riggs
On 14 August 2017 at 23:58, Peter Eisentraut
wrote:
> On 2/28/17 02:39, Tsunakawa, Takayuki wrote:
>> The code for stored functions is not written yet, but I'd like your
feedback for the specification and design based on the current patch.
I'll add this patch to CommitFest 2017-3
From: Thomas Munro
With your v2 patch "make docs" fails. Here is a small patch to apply
on top of yours to fix that and some small copy/paste errors, if I
understood correctly.
Ouch, thanks. I'd like to merge your fix when I submit the next
revision of my patch.
Regards
MauMau
Hello,
Sorry, I may have had to send this to pgsql-hackers. I just replied
to all, which did not include pgsql-hackers but pgsql-bugs because
this discussion was on pgsql-bugs. CommitFest app doesn't seem to
reflect the mails on pgsql-bugs, so I'm re-submitting this here on
pgsql-hackers.
From:
From: Michael Paquier
Hm.. I have just tested HEAD, my patch and your patch using my patch
test on pg_ctl.c, but I am always getting pgwin32_is_service set to 0
when running pg_ctl start from a terminal, and set it to 1 when
running pg_ctl service to register the service startup. Could you
precise
Hi, Michael
As I guessed in the previous mail, both our patches cause
pgwin32_is_service() to return 1 even when SECURITY_SERVICE_RID is
disabled, if the service is running as a Local System. The existing
logic of checking for Local System should be removed. The attached
patch fixes this problem
From: Heikki Linnakangas
So, I think we still need the check for Local System.
Thanks, fixed and confirmed that the error message is output in the
event log.
Regards
MauMau
win32-security-service-v7.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Hello,
As I proposed before in the thread below, I've implemented a simple command
for reliable WAL archiving. I would appreciate it if you could review and
test the patch.
http://www.postgresql.org/message-id/9C1EB95CA1F34DAB93DF549A51E3E874@maumau
Regards
MauMau
pg_copy.
From: "Joe Conway"
That first hunk refers to dblink -- I'm guessing it does not belong with
this patch.
Ouch, what a careless mistake. The attached one is clean. I'll update the
CommitFest entry when I'm back home from work.
Regards
MauMau
pg_copy_v2.patch
From: "Rajeev rastogi"
Please find the attached patch with only documentation change.
I marked this as ready for committer. The patch is good because it matches
the description in the following page:
http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html
Rega
test these files as well for code cleanup?
./configure
./configure.in
./contrib/pgcrypto/Makefile
./src/interfaces/libpq/Makefile
./src/interfaces/libpq/win32.c
./src/interfaces/libpq/win32.mak
./src/test/thread/README
./src/tools/msvc/Mkvcbuild.pm
Regards
MauMau
--
Sent via pgsql-hackers ma
From: "Fujii Masao"
On Wed, Jun 18, 2014 at 7:47 PM, MauMau wrote:
I marked this as ready for committer. The patch is good because it
matches
the description in the following page:
http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html
ISTM that this patch h
dll may also be
obsolete libraries from their names. Could you look into this and revise
the patch if possible? But I don't mind if you do so.
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
n is a waste of processing. I think the original author
wanted to eliminate this waste by creating the context when dblink() should
return a row. I'd like to respect his thought.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
e this, because sinfo is
zero-cleared.
PG_TRY();
{
+ /* Create short-lived memory context for data conversions */
+ sinfo.tmpcontext = AllocSetContextCreate(CurrentMemoryContext,
+"dblink temporary context",
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgs
would solve memory leak issues if other modules had similar
bugs, in addition to the original dblink problem, wouldn't this? Definitely
+1. The original OP wants to use 9.2. I'll report to him when you've
committed this nce patch. Thanks, Tom san.
Regards
MauMau
--
Sent via p
't it?
+ in a console window. It is used automatically by
+ pg_ctl when called with the
+ start subcommand.
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
s change is unnecessary. See src/bin/pg_dumpall.c for similar switches.
- while ((c = getopt_long(argc, argv,
"aAc:d:eEf:F:h:HlL:no:p:P:qR:sStT:U:v:VwWxXz?01",
or+ while ((c = getopt_long(argc, argv,
"aAc:d:eEf:F:h:HlL:no:p:P:qR:sStT:U:v:VwWxXz?001",
Regards
MauMau
--
Sent
each other, whether they are short
or long.
-x, --no-privileges do not dump privileges (grant/revoke)
--binary-upgrade for use by upgrade utilities only
--column-inserts dump data as INSERT commands with column
names
Regards
MauMau
--
Sent via pgsql-hackers ma
as INSERT commands with column
names
ok
I fixed it
Thank you. I marked this patch as ready for committer.
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
red statements for performance.
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
"start and restart mode" for
clarification.
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
quot;));
(8)
"Printing options" section lack the following ones described in psql manual:
columns
expanded (or x)
footer
numericlocale
tableattr (or T)
(9)
+ printf(_("\nEnvironment options:\n"));
should be ""Environment variables". And this section lacks
parator to
use in unaligned output format\n"));
+ printf(_(" title sets the table title for any subsequently
printed tables\n"));
This is all I noticed in the review.
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
ific to
PostgreSQL. However, I don't mind if you retain or remove the description.
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
Thanks, I marked it as ready for committer. I hope Fujii san or another
committer will commit this, refining English expression if necessary.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
s difficult. I wish for
in-core serious auditing functionality.
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
d users don't anticipate it. pg_upgrade appears to
set synchronous_commit to local when starting the database server.
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
ter/pgstat.c). And, there's only one call
site of the following functions:
readDBName
getSavefileNameBeingRestored
markSavefileBeingRestored
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: "Amit Kapila"
On Fri, Jul 4, 2014 at 7:29 PM, MauMau wrote:
[Hypothesis]
Why does the connection processing emit WAL?
Probably, it did page-at-a-time vacuum during access to pg_database and
pg_authid for client authentication. src/backend/access/heap/README.HOT
describes
tion mode offers slightly less data protection than maximum
availability mode and has minimal impact on primary database performance.
======
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
enance even if
* we are waiting for standbys to connect. This is important to ensure we
* aren't blocked from performing anti-wraparound tasks.
*/
if (synchronous_commit > SYNCHRONOUS_COMMIT_LOCAL_FLUSH)
SetConfigOption("synchronous_commit", "local",
PGC_SUSET,
transaction case?
I'd appreciate any opinion on this, too.
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 == 2)
{
$dir = "lib";
$ext = "dll";
}
What do you think? Am I misunderstanding your suggestion?
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
ree contains as many as 206 Makefiles. I'm worried that it
will waste the install time. Should all these Makefiles be examined, or 16
Makefiles in src/interfaces/?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
nateBackgroundWorker, it will be automatically unregistered by the
postmaster on exit."
(27)
As others said, I also think that Buffer Saver should first write to a temp
file, say *.tmp, then rename it to *.save upon completion. That prevents
the Block Reader from reading possibly corrupted
t if you could correct my poor English when committing, if it
needs improvement.
Regards
MauMau
pg_ctl_eventsrc_v10.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
register mode
only, so I still think it's wrong to place it there. It is now grouped
with all other parameters that we specifically *don't* write to the
commandline of the service.
OK, let me reconsider this tomorrow. It's already after midnight here in
Japan, and I have to go t
is not attached to
kill mode.
Do you suggest that -e should be attached to all modes in Synopsis section,
or -e should be placed in the section "Options" instead of "Options for
Windows"?
Regards
MauMau
pg_ctl_eventsrc_v11.patch
Description: Binary data
--
Sent via p
oticed the continued discussion after I had prepared and submitted the
revised patch. OK, how about the patch in the previous mail, Magnus-san?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
repeated review and help, Amit-san.
Regards
MauMau
pgevent.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
From: "Andres Freund"
On 2014-07-18 23:38:09 +0900, MauMau wrote:
LOG: autovacuum: found orphan temp table "pg_temp_838"."some_table" in
database "some_db"
LOG: autovacuum: found orphan temp table "pg_temp_902"."some_table" in
From: "Andres Freund"
On 2014-07-18 23:38:09 +0900, MauMau wrote:
So, I propose a simple fix to change the LOG level to DEBUG1. I don't
know
which of DEBUG1-DEBUG5 is appropriate, and any level is OK. Could you
include this in 9.2.9?
Surely that's the wrong end to tack
From: "Andres Freund"
On 2014-07-22 10:09:04 +0900, MauMau wrote:
Is there any problem if we don't output the message?
Yes. The user won't know that possibly gigabytes worth of diskspace
aren't freed.
RemovePgTempFiles() frees the disk space by removing temp relati
From: "Andres Freund"
On 2014-07-22 17:05:22 +0900, MauMau wrote:
RemovePgTempFiles() frees the disk space by removing temp relation files
at
server start.
But it's not called during a crash restart.
Yes, the comment of the function says:
* NOTE: we could, but don't
From: "Andres Freund"
On 2014-07-22 19:13:56 +0900, MauMau wrote:
But this is true if restart_after_crash = on in postgresql.conf, because
the
crash restart only occurs in that case. However, in HA cluster, whether
it
is shared-disk or replication, restart_after_crash is set to
2.9 if I could submit the patch tomorrow? (I'm not
confident I can finish it...) I'd really appreciate it if you could create
the fix, if tomorrow will be late.
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
to SIGUSR1. Is this
correct?
if (SmgrIsTemp(reln))
/* Do his on behalf of sinval message handler */
smgrclosenode(reln->smgr_rnode);
else
CacheInvalidateSmgr(reln->smgr_rnode);
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
why sinval messages are really necessary
for session-private objects like temp relations. I thought shared inval is,
as the name indicates, for objects "shared" among sessions. If so, sinval
for session-private objects doesn't seem to match the concept.
Regards
MauMau
--
Sent
ere is a problem with the latch and SIGUSR1 mechanism. How can we
fix this problem?
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
to the SIGUSR1 issued for
sinval catchup event?
How should we tackle these problem?
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
nal()).
I'll try the fix tomorrow if possible. What kind of problems do you hink of
for back-patching?
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"
I must add one thing. After some client processes closed the connection
without any hang, their server processes were stuck with a stack trace
like this (I'll look for and show the exact stack trace tomorrow):
I found two kinds of stack traces:
#0 0x00319
session on terminal session 1, run any SQL statement. It
doesn't reply. The backend is stuck at SyncRepWaitForLSN().
Regards
MauMau
sinval_catchup_hang_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
7ricepq6d8-eg...@mail.gmail.com
LINK : fatal error LNK1104: ファイル
'.\release\postgres\src_timezone_win32ver.obj' を開くことができません。
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
R1 handler
functions which have the same contents.
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 version properties.
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
anual how to diagnose and tne the system with
these event info.
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
ossible to access using SQL queries. This prevents the development of
performance diagnostics functionality in GUI administration tools. Also,
statistics views allow for easy access on PAAS like Amazon RDS and Heroku.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
From: "Pavel Stehule"
2014-08-13 13:59 GMT+02:00 MauMau :
Are you concerned about the impactof collection overhead on the queries
diagnosed? Maybe not light, but I'm optimistic. Oracle has the track
record of long use, and MySQL provides performance schema starting from
5.6.
nsigned
integer.
char*linkloc = psprintf("%s/pg_tblspc/%d", basedir, oid);
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 fixed some minor mistakes.
Regards
MauMau
pg_copy_v3.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
I confirmed that all issues are solved. The patch content looks good,
alghouth I'm not confident in Perl. I marked this patch as ready for
committer. I didn't try the patch on MinGW.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Thank you. The code looks correct. I confirmed that the pg_basebackup
could relocate the tablespace directory on Windows.
I marked this patch as ready for committer.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
des
the same functionality as pg_copy does? If there is, I'd like to avoid
duplicate
work basically.
If there exists such a command available in the standard OS installation, I
want to use it.
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 data
erasure during recovery. We can probably extend pg_statsinfo to save the
new info for long-term trend analysis. TBH, I want a feature like
pg_statsinfo in core.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
yet. If we agree to
support this feature, I will do the remaining work.
Could you consider adding a new section for disaster recovery that describes
concrete parameter settings (e.g. how do we discard old archive WAL files
after taking a base backup from standby, because backup label file
.
--
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
anner, executor, etc?
One possible concern is that various PostgreSQL components might be
too dependent on the data model being relational, and it would be
difficult to separate tight coupling.
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
region, so that
appropriate region's routines can be called.
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
ation slot "mysub": ERROR: could not
access file "pgoutput": No such file or directory
postgres=#
The pgoutput is not built with MSVC. The attached patch fixes this.
I confirmed that a few INSERTs were replicated correctly.
Should I add this matter in the PostgreSQL 10 Op
do, so please commit
this. Also, I added an item in the Open Items page.
Regards
MauMau
msvc_build_pgoutput_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
/.
I'm relieved to hear that's already committed. Oh, how careless I
was, thanks.
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
pg_trigger.tgfoid also have been changed to
regproc?
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
uation. I understood that it would do more harm than good
to change existing plain oid columns to reg* types for various
clients, and it wouldn't very beneficial but also not so harmful to
make new catalogs/columns reg* types.
Regards
MauMau
--
Sent via pgsql-hackers mailing list
ll text search did.
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
ot;could not fork WAL writer process:
%m")));
Personally, I prefer "wal writer", "wal sender" and "wal receiver"
that separate words as other process names. But I don't mind leaving
them as they are now. I'd like to make this as ready for committer
ntered an all-zero
page. How did the all-zero page appear on the standby? Was it transferred
from master by pg_basebackup? FYI, the server log didn't contain any
messages related to disk full, nor any ERROR messages.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hack
ry even
on UNIX/Linux. Please see TablespaceCreateDbspace is().
destroy_tablespace_directories() doesn't have to handle such situation.
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
something similar to
what you were reporting "event source not found".
Am I missing something?
Steps
1. installation of PostgreSQL from source code using Install.bat in
mdvc directory
2. initdb -D
3. regsvr32 /n /i:PostgreSQL \lib\pgevent32.dll
Please specify pgevent.dll, not pgevent
y registered."
Please correct me if there's better expression in English.
Are there any other suggestions to make this patch ready for committer? I'd
like to make all changes in one submission.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
ata in another directory
#max_stack_depth = 2MB # min 100kB
#include_if_exists = 'exists.conf' # include file only if it exists
#include = 'special.conf' # include file
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
pg_ctl use the event_source setting. Anyway, not all
parameters in postgresql.conf cannot be used just by uncommenting them.
That's another issue.
I'll update the CommitFest entry soon.
Regards
MauMau
pg_ctl_eventsrc_v5.patch
Description: Binary data
--
Sent via pgsql-hackers m
t, because syslog_ident also has the default value "postgres",
which doesn't contain the major release.
Any (not complicated) suggestions?
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
added some documentation, as
well as modifying the usage at the end of install.pl.
I'll update the CommitFest entry shortly.
Regards
MauMau
client_only_install_win_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
g
output in my customer's environment.
I'll add this to the CommitFest if necessary.
Regards
MauMau
disable_ASLR.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
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_
Hi, Heiki-san,
From: "MauMau"
From: "Heikki Linnakangas"
After some refactoring and fixing bugs in the existing code, I came up
with the attached patch. I called the option simply "recovery_target",
with the only allowed value of "immediate". IOW,
sockets. Plus, if we want to refer to the actual
connection target for libpq implementation in other places than PQhost(), we
can just use PGconn's members. If we do so, we don't have to change
PQhost().
Could you replace the patch?
Regards
MauMau
--
Sent via pgsql-hackers mai
out of disk space in archive
recovery, I wonder if we should perform restartpoints more aggressively.
We
intentionally don't trigger restatpoings by checkpoint_segments, only
checkpoint_timeout, but I wonder if there should be an option for that.
That's an option.
MauMau, did you t
From: "Fujii Masao"
On Fri, Jan 24, 2014 at 9:00 PM, MauMau wrote:
OTOH, regarding PQhost(), I think we had better take my patch.
connectOptions2() computes and set derived values to PGconn, so that
PGconn's members have values which are actually used for connection. To
f
I'm sorry for the late reply. I was unable to access email.
From: "Craig Ringer"
On 01/24/2014 06:42 PM, MauMau wrote:
The customer is using 64-bit PostgreSQL 9.1.x
Which "x"?
9.1.6.
Does this issue also occur on 9.3.2, or in 9.4 HEAD, when tested on
Win2k12?
ndle the testing
of pg_ctl.
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: "Christian Kruse"
personally I really dislike constructs like you used:
Thanks for reviewing the patch. Fixed. I'll add this revised patch to the
CommitFest entry soon.
Regards
MauMau
config_dir_win_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mail
1 - 100 of 369 matches
Mail list logo
