?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
When is the patch submission deadline for CommitFest 2010-07?
July 14? or June 14 (before review fest)? Sorry, I'm not sure
what is actually different between CF and RF.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql
On Fri, May 28, 2010 at 4:08 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28/05/10 09:26, Fujii Masao wrote:
When is the patch submission deadline for CommitFest 2010-07?
July 14? or June 14 (before review fest)? Sorry, I'm not sure
what is actually different between
(i.e.,
new master).
Can that procedure work around the gap of the timeline ID between servers?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Fri, May 28, 2010 at 11:12 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, May 27, 2010 at 11:13 PM, Robert Haas robertmh...@gmail.com wrote:
I guess this happens because the frequency of checkpoint on the standby is
too lower than that on the master. In the master, checkpoint occurs
the bug that walsender exits
before sending all the WAL up to shutdown checkpoint record when
smart shutdown is requested.
The attached patch fixes the bug and a tiny typo.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql
.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 31, 2010 at 7:03 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
On Thu, May 27, 2010 at 7:21 AM, Heikki Linnakangas
hei...@postgresql.org wrote:
Log Message:
---
In walsender, don't sleep if there's outstanding WAL waiting to be sent,
otherwise we effectively rate
forms
of replication to be potentially delayed without need or benefit.
Issue pointed out exactly by Fujii Masao, following bug report
by Robert Haas on a separate though related topic.
Modified Files:
--
pgsql/src/backend/access/transam:
xact.c (r1.290 - r1.291
On Mon, May 31, 2010 at 7:17 PM, Fujii Masao masao.fu...@gmail.com wrote:
4) Change it so that checkpoint_segments takes effect in standby mode,
but not during recovery otherwise
I revised the patch to achieve 4). This will enable checkpoint_segments
to trigger a restartpoint like
,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 02/06/10 06:23, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:17 PM, Fujii Masaomasao.fu...@gmail.com
wrote:
4) Change it so that checkpoint_segments takes effect in standby mode,
but not during
make a
difference.
Yes. The pace of a recovery has nothing to do with that of log shipping.
So to hurry up a recovery when restoring from archive seems to be useless.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers
asynchronous replication is supported.
But when we'll implement synchronous replication in the future, we
might have to revert that change. Since a transaction commit might wait
for such an extra record to be replicated, walsender should aggressively
send all sendable WAL.
Regards,
--
Fujii
On Thu, Jun 3, 2010 at 6:07 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-06-03 at 17:56 +0900, Fujii Masao wrote:
On Thu, Jun 3, 2010 at 4:41 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I don't understand why you want to use a different delay when you're
or not-caught-up. OTOH, applying WAL restored from archive is not always
the sign of either of them. So isn't it nonsense to separate the delay in
order to control the behavior of a recovery for those cases?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
not specify a database name in the
varnameprimary_conninfo/varname string.
/para
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
()
or somewhere? Or we should stop walreceiver and retry to read WAL from
pg_xlog or the archive?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
. On the other hand, walreceiver doesn't check
update_process_title. Though this check might not be required since it's
within set_ps_display(), we should do that for the sake of consistency?
I attached the patch.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source
On Tue, Jun 8, 2010 at 12:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan and...@dunslane.net wrote:
I tried this with a database name of replication in the .pgpass file,
which matches what we need to use
On Tue, Jun 8, 2010 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
But I think that we don't need to specify other than the wildcard
in the database field of .pgpass to use the replication-specific
password if the replication-specific user is supplied
: recovery_end_command, recovery-end-command,
and recoveryEndCommand.
s/recovery_end_command/restartpoint_command?
I prefer restartpoint_command over archive_cleanup_command because
not only restartpoint_command but also recovery_end_command is used
for archive cleanup.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH
On Tue, Jun 8, 2010 at 1:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Hmm.. is it worth going back to my proposal?
I don't recall exactly what proposal you might be referring to, but
http://archives.postgresql.org/pgsql-hackers/2010-01/msg00400.php
I'm
On Wed, Jun 2, 2010 at 10:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 02/06/10 06:23, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:17 PM, Fujii Masaomasao.fu...@gmail.com
wrote:
4) Change
,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
pgpass_v1.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
?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jun 9, 2010 at 5:47 PM, Fujii Masao masao.fu...@gmail.com wrote:
To fix the problem, when the trigger file is found, I think
that we should cancel all the running read only queries
immediately (or forcibly use -1 as the max_standby_delay
since that point) and make the recovery go ahead
--timeout=N in 9.1
instead of the trigger file based management.
Please feel free to try that ;)
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
.
+1
What about the attached patch?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
trigger_restartpoint_doc_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
functions return NULL in that case.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
recovery_funcs_return_null_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi,
Currently the variable TriggerFile is declared as extern, but
it's not used in other source file than xlog.c. How about
declaring it as static? Here is the patch.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
definition_triggerfile_v1
. That is, fetching_ckpt = true case in the following
code.
if (PrimaryConnInfo)
{
RequestXLogStreaming(
fetching_ckpt ? RedoStartLSN : *RecPtr,
PrimaryConnInfo);
continue;
}
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
to start from the
beginning of the segment? This is probably true. But what if we could not read
the checkpoint record? In this case, the WAL file containing the Redo pointer
also might not exist.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
, and minimize the failover time.
OTOH, queries which don't conflict with a recovery survive the failover.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
prevent_lock_conflict_from_slowing_failover_v1.patch
Description: Binary data
--
Sent via pgsql
On Thu, Jun 10, 2010 at 9:58 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Fujii Masao masao.fu...@gmail.com wrote:
1. Reset max_standby_delay = 0 in postgresql.conf
2. pg_ctl reload
3. Create a trigger file
As far as I read the HS code, SIGHUP is not checked while
be performed more frequently than
checkpoints in the master because restartpoints can only be performed at
checkpoint records.
Yes, that's what I meant.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list
with the replay of the VACUUM or HOT record would often happen.
vacuum_defer_cleanup_age would be helpful for that case, but it seems to be
hard to tune that.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql
Hi,
vacuum_defer_cleanup_age is categorized as Statement Behavior
parameter in the document. On the other hand, it's categorized
as Hot Standby one in postgresql.conf. Why do we need to do so?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
seconds (needs to
be reduced?) before retrying to replay the record which is in the same
location where the invalid one was found. Comments?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
calm_down_retries_v1.patch
Description: Binary data
On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 09/06/10 08:24, Fujii Masao wrote:
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstanand...@dunslane.net
wrote:
There is precedent for .pgpass being a bit ambiguous. See the way
localhost is used
. So, it's also
useful for asynchronous replication.
Thought? Comment? Objection?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
read_wal_buffers_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
ones?
+1. This seems sensible.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jun 11, 2010 at 10:22 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jun 11, 2010 at 9:14 AM, Fujii Masao masao.fu...@gmail.com wrote:
Thought? Comment? Objection?
What happens if the WAL is streamed to the standby and then the master
crashes without writing that WAL to disk
On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 09/06/10 08:24, Fujii Masao wrote:
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstanand...@dunslane.net
wrote:
There is precedent for .pgpass being a bit ambiguous. See the way
localhost is used
files in the pg_xlog directory on the standby are recycled
by every restartpoints. So your proposed function seems not to be helpful
even if hot_standby = on.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list
CONTEXT: xlog redo create ts: 16384 /path_to/ts
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
recovery_ts_hint_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
for some cases. We should provide the knob
to specify whether to allow the standby to go ahead of the master or not?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
, POSIX_FADV_DONTNEED is not used for
WAL files at all.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
to say. Thanks!
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in these days :)
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that immediate-panicking is the best,
we can set it to zero. Thought?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Mon, Jun 14, 2010 at 10:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jun 14, 2010 at 8:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Jun 14, 2010 at 8:10 PM, Robert Haas robertmh...@gmail.com wrote:
Maybe. That sounds like a pretty enormous foot-gun to me, considering
On Tue, Jun 15, 2010 at 12:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Fri, Jun 11, 2010 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, we're already not waiting for fsync, which is the slowest part.
No, currently walsender waits for fsync
()?
or
(2) add But if streaming replication is restarted this will back off
to the beginning of current WAL file into there?
I'm for (2) since it's more informative. Thought?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql
On Tue, Jun 15, 2010 at 2:41 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 15/06/10 08:23, Fujii Masao wrote:
On Thu, Jun 10, 2010 at 11:06 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I'm not sure if it's worth the trouble, or even a particularly smart
idea, to force
On Tue, Jun 15, 2010 at 2:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 15/06/10 07:47, Fujii Masao wrote:
On Tue, Jun 15, 2010 at 12:02 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Fujii Masaomasao.fu...@gmail.com writes:
Walsender tries to send WAL up to xlogctl
\, progname, WALFilePath);
---
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
should not restart the master after the crash in
fsync=off case. That would cause the corruption of the master database
itself.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
send_after_fsync_v1.patch
Description: Binary data
--
Sent via
On Wed, Jun 16, 2010 at 12:24 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Fujii Masao masao.fu...@gmail.com wrote:
This is because pg_archivecleanup puts the line break \n in the head of
debug message. Why should we do so?
---
if (debug)
fprintf
Hi,
We should make trace_recovery_messages available only when
the WAL_DEBUG macro was defined? Currently it's always
available, so the standby seems to call elog() too frequently.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via
Hi,
In the following debug message in RemoveOldXlogFiles(), the variables
log and seg don't indicate LSN, so we should use %u instead of %X?
elog(DEBUG2, removing WAL segments older than %X/%X, log, seg);
I attached the patch to do so.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH
, SO_KEEPALIVE). So even if you change the kernel options
for keepalive, it has no effect on walreceiver.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Fri, Jun 18, 2010 at 2:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
We should make trace_recovery_messages available only when
the WAL_DEBUG macro was defined?
No, because it's used in a lot of other contexts besides that.
Currently it's always
send non-fsync'd WAL
safely if the standby makes the recovery wait until the master has fsync'd
WAL. That is, walsender sends not only non-fsync'd WAL but also WAL flush
location to walreceiver, and the standby applies only the WAL which the
master has already fsync'd. Thought?
Regards,
--
Fujii
},
{keepalives_idle, NULL, NULL, NULL,
TCP-Keepalives-Idle, , 10}, /* strlen(INT32_MAX) == 10 */
In this case, you can check the value of keepalives parameter by seeing
conn-keepalives[0] instead of using strtol() in useKeepalives().
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE
-side.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jun 28, 2010 at 9:54 AM, Robert Haas robertmh...@gmail.com wrote:
This seems useful to me so here's a patch to implement it.
+1
This would be very useful for people who want to give a clusterware
control of postgres.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
On Tue, Jun 15, 2010 at 11:35 AM, Fujii Masao masao.fu...@gmail.com wrote:
On the other hand, I like immediate-panicking. And I don't want the standby
to retry reconnecting the master infinitely.
On second thought, the peremptory PANIC is not good for HA system. If the
master unfortunately has
On Tue, Jun 29, 2010 at 7:59 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 29, 2010 at 3:55 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 15, 2010 at 11:35 AM, Fujii Masao masao.fu...@gmail.com wrote:
On the other hand, I like immediate-panicking. And I don't want
(TCP_KEEPIDLE) nor setsockopt(TCP_KEEPALIVE) are supported
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
. If they are performed in a serial manner, the performance
overhead on the master would become high.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
the patch, we need to check
whether my thought is true.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
trigger_restartpoint_doc_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
while receiving result from server, you will
get PGRES_FATAL_ERROR from PQresultStatus(). Also you can get the
error message could not receive data from server: Connection timed out
via PQerrorMessage().
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
will be sad.
True. But, without SR, an unexpected crash-and-reboot in the master
would make you sad ;) So I'm not sure whether we really need to take
action for the case of SR + fsync=off.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via
for the result of the
query. OTOH, if network goes down after sending query, keepalive
would make you detect the disconnection.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
that. Can the ssh connection detect the disconnection
via keepalive, in that case?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
source);
+const char *show_log_file_mode(void);
You forgot to write the show_log_file_mode()? I was not able to find that
in the patch.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers
to reflect Tom's proposal here.
#--
+# ERROR HANDING
+#--
Typo: s/HANDING/HANDLING
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE
On Wed, Jul 14, 2010 at 11:59 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 14, 2010 at 3:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
I read the patch and found some small typos.
Thanks. Corrected version attached.
We should add something like?:
-
Even
On Thu, Jul 15, 2010 at 12:16 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 14, 2010 at 2:50 AM, Fujii Masao masao.fu...@gmail.com wrote:
The patch have no features for performance improvement of synchronous
replication. I admit that currently the performance overhead in the
master
On Mon, May 31, 2010 at 8:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-05-31 at 20:11 +0900, Fujii Masao wrote:
On Thu, May 13, 2010 at 8:39 PM, Simon Riggs sri...@postgresql.org wrote:
Log Message:
---
Ensure that top level aborts call XLogSetAsyncCommit
On Thu, Jul 1, 2010 at 1:09 PM, Fujii Masao masao.fu...@gmail.com wrote:
Thanks for reminding me. I attached the updated patch.
This patch left uncommitted for half a month. No one is interested in
the patch?
The patch adds the document about the relationship between a restartpoint
longer than 30sec - 1min.
REINDEX or something should not send PROCSIG_CATCHUP_INTERRUPT immediately?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
this fault. And I attached the PDF file which
illustrates the proof of the formula.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
num_of_wal_formula_v1.patch
Description: Binary data
20100721_num_of_wal_in_pg_xlog.pdf
Description: Adobe PDF
\conninfo
You are connected to database postgres on host /tmp at port 5432
as user postgres.
I expected that something like
You are connected to database postgres via local socket on
/tmp at port 5432 as user postgres.
is output.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE
On Fri, Jul 16, 2010 at 7:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 16/07/10 10:40, Fujii Masao wrote:
So we should always prevent the standby from applying any WAL in pg_xlog
unless walreceiver is in progress. That is, if there is no WAL available
in the archive
On Sat, Jul 17, 2010 at 3:25 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14/07/10 09:50, Fujii Masao wrote:
TODO
The patch have no features for performance improvement of synchronous
replication. I admit that currently the performance overhead in the
master
On Sun, Jul 18, 2010 at 3:14 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14/07/10 09:50, Fujii Masao wrote:
Quorum commit
-
In previous discussion about synchronous replication, some people
wanted the quorum commit feature. This feature is included
On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote:
OK, committed.
When I specify the path of the directory for the Unix
On Wed, Jul 21, 2010 at 9:52 PM, Aidan Van Dyk ai...@highrise.ca wrote:
* Fujii Masao masao.fu...@gmail.com [100721 03:49]:
The patch provides quorum parameter in postgresql.conf, which
specifies how many standby servers transaction commit will wait for
WAL records to be replicated
on
/tmp at port 5432 as user postgres.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
conninfo_local_socket_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
, if not all ideas on the design that were raised in the comments on
patch (A)
Yeah, I'd like to cover many good functionalities in (A) as much as possible.
If you found something when you compared the patches, please feel free to
comment.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE
);
+static void WalSndLastCycleHandler(SIGNAL_ARGS);
We seems to have forgotten to add the declaration of WalSndLastCycleHandler().
I also attached the context-diff patch.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_mistakes_hs_sr_v1.patch
On Thu, Jul 22, 2010 at 5:37 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Fujii Masao wrote:
How should the synchronous replication behave when the number of connected
standby servers is less than quorum?
1. Ignore quorum. The current patch adopts this. If the ACKs from all
connected
test.
Yeah, transaction commit seems to have to wait for replication in
not only RecordTransactionCommit() but also EndPrepare(),
RecordTransactionCommitPrepared() and RecordTransactionAbortPrepared().
I'll fix that.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open
On Mon, Jul 26, 2010 at 5:27 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Fujii Masao wrote:
Intuitively by looking at the enumeration of replication_mode I'd think
that
the sync standbys are all standby's that operate in a not async mode.
That
would be clearer with a boolean sync
On Thu, Jul 22, 2010 at 5:37 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Fujii Masao wrote:
How should the synchronous replication behave when the number of connected
standby servers is less than quorum?
1. Ignore quorum. The current patch adopts this. If the ACKs from all
connected
On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Fujii Masao wrote:
I still like
replication_mode = {async|recv|fsync|replay}
rather than
synchronous_replication = {on|off}
acknowledge_commit = {no|recv|fsync|replay}
Hello Fujii,
I wasn't entirely
501 - 600 of 2751 matches
Mail list logo
