When we specify a value which exceeds valid range in Customized
Options , its behavior is different from Parameter Interaction via
Configuration File behavior.
In case of Parameter Interaction via Configuration File, it finish
with FATAL error when it get threshold error.
But in
Hi,
When we specify a value which exceeds valid range in Customized Options ,
its behavior is different from Parameter Interaction via Configuration File
behavior.
In case of Parameter Interaction via Configuration File, it finish with FATAL
error when it get threshold error.
But in Customized
Hi,
pg_ctl stop does't work propley, if --slot option is specified when WAL is
flushed only it has switched.
These processes still continue even after the posmaster failed:pg_receivexlog,
walsender and logger.
How to reproduce:
1.Start PostgreSQL
2.Create slot
3.Specify --slot option to
On Fri, Oct 31, 2014 at 5:46 PM, furu...@pm.nttdata.co.jp wrote:
We seem to be going in circles. You suggested having two options,
--feedback, and --fsync, which is almost exactly what Furuya posted
originally. I objected to that, because I think that user interface
is
too
(2014/08/28 18:00), Etsuro Fujita wrote:
(2014/08/22 11:51), Noah Misch wrote:
Today's ANALYZE VERBOSE messaging for former inheritance parents
(tables with relhassubclass = true but no pg_inherits.inhparent
links) is deceptive, and I welcome a fix to omit the spurious
message. As
We seem to be going in circles. You suggested having two options,
--feedback, and --fsync, which is almost exactly what Furuya posted
originally. I objected to that, because I think that user interface
is
too complicated. Instead, I suggested having just a single option
called
Sorry, I'm going around in the circle. But I'd like to say again, I
don't think this is good idea. It prevents asynchronous
pg_receivexlog from fsyncing WAL data and sending feedbacks more
frequently at all. They are useful, for example, when we want to
monitor the write location of
In synchronous mode, pg_receivexlog should have similar logic as
walreceiver does.
OK. I understand that removing --fsync-interval has no problem.
+1 for adding something like --synchronous option. To me,
it sounds walreceiver-compatible mode rather than synchronous.
Better to add
If we remove --fsync-interval, resoponse time to user will not
be
delay.
Although, fsync will be executed multiple times in a short period.
And there is no way to solve the problem without
--fsync-interval, what
should we do about it?
I'm sorry, I didn't understand that.
If we remove --fsync-interval, resoponse time to user will not be
delay.
Although, fsync will be executed multiple times in a short period.
And there is no way to solve the problem without --fsync-interval,
what
should we do about it?
I'm sorry, I didn't understand that.
Here is
On 10/08/2014 07:23 AM, furu...@pm.nttdata.co.jp wrote:
What set of options would you pass if you want to use it as a
synchronous standby? And if you don't? Could we just have a single
--synchronous
flag, instead of -F and --reply-fsync?
If you set synchronous_commit as remote_write,
What set of options would you pass if you want to use it as a
synchronous standby? And if you don't? Could we just have a single
--synchronous
flag, instead of -F and --reply-fsync?
If you set synchronous_commit as remote_write, the options would
be different .
The set of options
On 09/29/2014 01:13 PM, furu...@pm.nttdata.co.jp wrote:
I don't understand what this patch does. When would you want to use
the new --reply-fsync option? Is there any reason *not* to use it?
In other words, do we need an option for this, couldn't you just
always send the feedback message
On 09/05/2014 08:51 AM, furu...@pm.nttdata.co.jp wrote:
Thanks for the review!
I understand the attention message wasn't appropriate.
To report the write location, even If you do not specify a
replication
slot.
So the fix only appended messages.
There was a description of the
Thanks for the review!
I understand the attention message wasn't appropriate.
To report the write location, even If you do not specify a replication
slot.
So the fix only appended messages.
There was a description of the flush location section of '-S' option,
but I intended to
Thank you for updating the patch.
I reviewed the patch.
First of all, I think that we should not append the above message to
section of '-r' option.
(Or these message might not be needed at all) Whether flush location in
feedback message is valid, is not depend on '-r' option.
If we
When replication slot is not specified in pg_receivexlog, the flush
location in the feedback message always indicates invalid. So there seems
to be no need to send the feedback as soon as fsync is issued, in that
case.
How should this option work when replication slot is not specified?
Thanks for the review!
One question is why reply_fsync is defined as volatile variable?
Sorry I could not understand reason of that.
It was affected to time_to_abort -- since it is unnecessary, it deletes.
Currently patch modifies argument of some function (e.g., Handle
CopyStream, Process
Thank you for updating the patch.
I did not get error with applying, and compiling.
It works fine. I think this function code has no problem.
Could you please submit patch to commit fest app?
Thanks for the review!
As you pointed out, submitted patch to commit fest app.
Regards,
--
Actually I came up with the same need as Magnus, but a bit later, so...
Attached is a patch to support physical slot creation and drop in
pg_receivexlog with the addition of new options --create and --drop. It
would be nice to have that in 9.4, but I will not the one deciding that
at the end
I don't think that it's good idea to control that behavior by using
--status-interval. I'm sure that there are some users who both want that
behavior and want set the maximum interval between a feedback is sent
back to the server because these settings are available in walreceiver.
But your
Hi all,
This patch is to add setting to send status packets after fsync to
--status-interval of pg_receivexlog.
If -1 is specified to --status-interval, status packets is sent as soon as
after fsync.
Others are the same as when 0 is specified to --status-interval.
When requested by the
Okay, applied the patch.
I heavily modified your patch based on the master that the refactoring
patch has been applied. Attached is that modified version. Could you
review that?
Thank you for the patch.
I did a review of the patch.
No problem in the patch.
Behavior after the true return
- break; /* ignore
the rest of this XLogData packet */
+ return true;/* ignore the rest of
this XLogData packet */
For break statement at close of wal file, it is a return to true.
It may be a behavior
I have improved the patch by making following changes:
1. Since stream_stop() was redundant, stream_stop() at the time of
WAL file closing was deleted.
2. Change the Flash judging timing for the readability of source code.
I have changed the Flash judging timing , from the
I have improved the patch by making following changes:
1. Since stream_stop() was redundant, stream_stop() at the time of WAL file
closing was deleted.
2. Change the Flash judging timing for the readability of source code.
I have changed the Flash judging timing , from the continuous
This patch was made by the following process.
1. post patch for additional pg_receivexlog synchronous mode.
2. In response to comment for the flush frequency, I revise the patch to do
flush every consecutive message in reference to walreceiver.
3. The synchronization mode was necessary to
Hi,
At 1047 line of receivelog.c:CopyStreamPoll(), we set NULL to
timeoutptr variable.
if the value of timeoutprt is set NULL then the process will wait
until can read socket using by select() function as following.
if (timeout_ms 0)
timeoutptr = NULL;
else
This patch is modified the comment.
Each comment is coping as follows.
Could you update the status of this patch from Waiting on Author to
Needs Review when you post the revised version of the patch?
Thank you for pointing out.
From now on, I will update status when I post the patch.
+
Thanks for reviewing the patch!
I think that this refactoring patch is useful for improving source
code readability and making the future patches simpler, whether we
adopt your patch or not. So, barring any objections, I'm thinking to
commit this refactoring patch.
Committed!
It is
Thanks for the review!
+if (secs = 0)
+secs = 1;/* Always sleep at least 1 sec */
+
+sleeptime = secs * 1000 + usecs / 1000;
The above is the code which caused that problem. 'usecs' should have been
reset to zero when 'secs' are rounded up to
Synchronous(synchronous_commit = on) mode offers the ability to
confirm WAL have been streamed in the same way as synchronous
replication.
If an output is used as a different disk from the directory where
the
transaction log should be stored.
Prevent the loss of data due
The patch looks somewhat complicated and bugs can be easily introduced
because it tries to not only add new feature but also reorganize the main
loop in HandleCopyStream at the same time. To keep the patch simple, I'm
thinking to firstly apply the attached patch which just refactors the
main
I found that this patch breaks --status-interval option of
pg_receivexlog when -m option which the patch introduced is supplied.
When -m is set, pg_receivexlog tries to send the feedback message as soon
as it flushes WAL file even if status interval timeout has not been passed
yet. If you
You introduced the state machine using the flag flush_flg into
pg_receivexlog.
That's complicated and would reduce the readability of the source code.
I think that the logic should be simpler like walreceiver's one.
Maybe I found one problematic path as follows:
1. WAL is written and
No. IIUC walreceiver does flush *less* frequently than what you
implemented on pg_receivexlog. Your version of pg_receivexlog tries to
do flush every time when it receives one WAL chunk. OTOH, walreceiver
does flush only when there is no extra WAL chunk in receive buffer. IOW,
after writing
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Abhijit
Menon-Sen
Sent: Wednesday, June 04, 2014 7:47 PM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] pg_xlogdump --stats
Hi.
Here's a patch to make
-Original Message-
Flush is not performed every time write, it is performed
collectively like walrecever.
I only glanced at this, but afaics you're only flushing at the end
every WAL segment. That will result in absolutely horrible performance,
right?
Walreceiver does flush
Hi,
This patch implements a pg_receivexlog add synchronous mode.
Now, synchronous(synchronous_commit = remote_write) is supported.
But synchronous(synchronous_commit = remote_write), if the server crashes then
WAL file may not to be flushed to disk , causing data loss.
-Original Message-
Hi,
On 2014-06-05 17:09:44 +0900, furu...@pm.nttdata.co.jp wrote:
Synchronous(synchronous_commit = on) mode offers the ability to
confirm WAL have been streamed in the same way as synchronous
replication.
If an output is used as a different disk from the
40 matches
Mail list logo
