Joshua D. Drake wrote:
Modern systems *must* scale beyond a single computer, and the PostgreSQL
support shipped in modern Linux distros is completely incapable of this.
Slony-I is quite capable as a production class FOSS replication system
and is in use widely.
Slony-I is not enough because
Stefan Kaltenbrunner wrote:
It is however async replication so you can loose data commited on the
master but not yet replicated to the slaves in case you loose the master
completely.
Yes, here is an insufficient point of Slony-I, i think.
Most systems will not permit the committed data to be
than WAL sending either.
Which idea should we adopt?
Comments welcome.
--
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
your patch.
Do I need to inform Josh of reviewing it in advance?
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
--
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
and writing it to disk on the slave.
I will submit these patches and tool by Nov Commit Fest at the latest.
Any comment welcome!
best regards
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers
is necessary in order to detect a
network failure soon.
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
or becomes master.
Should we enforce that
timeout within the server, or should we leave that to the external heartbeat
system?
Within the server. All users do not use such an external system. It's not simple
for the external system to leave the master stand-alone.
regards
--
Fujii Masao
NIPPON
--
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
not handle it.
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, Sep 10, 2008 at 4:15 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2008-09-10 at 09:35 +0300, Hannu Krosing wrote:
On Wed, 2008-09-10 at 15:15 +0900, Fujii Masao wrote:
On Wed, Sep 10, 2008 at 12:26 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
If a slave falls behind, how
for that notification.
Your 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/mailpref/pgsql-hackers
,
--
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 Thu, Sep 11, 2008 at 3:17 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2008-09-10 at 17:57 +0900, Fujii Masao wrote:
My sequence covers several cases :
* There is no missing WAL file.
* There is a lot of missing WAL file.
This is the likely case for any medium+ sized database.
I'm
as advised by Tom in the above thread.
* I replaced CatchupInterruptHandler() by new signal handler for SIGUSR1,
adjusted the codes around catchup interrupt to this mechanism.
* remaining work is adjusting the comments around catchup interrupt.
Comments welcome.
Regards,
--
Fujii Masao
On Fri, Sep 12, 2008 at 7:41 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-09-11 at 18:17 +0300, Heikki Linnakangas wrote:
Fujii Masao wrote:
I think that this case would often happen. So, we should establish a
certain
solution or procedure to the case where TLI of the master
On Fri, Sep 12, 2008 at 12:17 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
I think that this case would often happen. So, we should establish a
certain
solution or procedure to the case where TLI of the master doesn't match
TLI of the slave. If we only allow the case
;
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
sync_replication_v1.tgz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
,
--
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, thank you for taking time to review the patch.
On Fri, Oct 31, 2008 at 11:12 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
Attached is a patch for a synchronous log-shipping replication which
was discussed just a month ago. I would like you to review this patch
to comment on it.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Index: src/backend/access/transam/twophase.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/twophase.c,v
On Fri, Oct 31, 2008 at 10:15 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
And, there are some problems in this patch;
* This patch is somewhat big, though it should be subdivided for
review.
* Source code comments and documents are insufficient.
Is it against
On Wed, Nov 5, 2008 at 12:51 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
On Fri, Oct 31, 2008 at 11:12 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
AFAICS, there's no security, at all. Anyone that can log in, can become a
WAL sender, and receive all WAL
Hi, Simon,
On Wed, Nov 5, 2008 at 7:07 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Tue, 2008-11-04 at 22:59 +0900, Fujii Masao wrote:
Hi, thank you for taking time to review the patch.
On Fri, Oct 31, 2008 at 11:12 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote
bgwriter at least in order to
replicate a shutdown checkpoint xlog.
Initialization
In the main routine, walsender sets up signal handlers, etc again.
And some bug fixes.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
!!
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 Thu, Nov 6, 2008 at 3:59 PM, Fujii Masao [EMAIL PROTECTED] wrote:
1) Start postgres in the primary
2) Get an online-backup in the primary
3) Locate the online-backup in the standby
4) Start postgres (with walreceiver) in the standby
# Configure restore_command, host of the primary
Hi, Simon
Thank you for the review.
On Fri, Nov 7, 2008 at 5:49 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2008-11-05 at 23:17 +0900, Fujii Masao wrote:
Authentication
---
As pointed out at another thread, for authentication, I defined the database
only
Hi, Pavan,
On Thu, Nov 6, 2008 at 9:35 PM, Pavan Deolasee [EMAIL PROTECTED] wrote:
On Thu, Nov 6, 2008 at 2:12 PM, Fujii Masao [EMAIL PROTECTED] wrote:
If the database whose timeline is the same as the primary's
exists in the standby, 2)3) getting new online-backup is not
necessary
Hi,
On Thu, Nov 6, 2008 at 3:59 PM, Fujii Masao [EMAIL PROTECTED] wrote:
Again, I would expect this to be integrated with server. I would expect
code to live in src/postmaster/walreceiver.c, with main logic in a file
alongside xlog.c, perhaps xreceive.c. We would start WALReceiver when we
On Tue, Nov 11, 2008 at 9:12 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Mon, 2008-11-10 at 18:22 +0900, Fujii Masao wrote:
Yeah, I also add walsender as new auxiliary process at first. But,
during coding,
I made out that this is more complicated for code and user.
First problem : Which
On Sat, Nov 15, 2008 at 6:12 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
Attached is a patch of signal handling changes for Synch Rep.
It seems that we wouldn't need to use the BackendPidGetProc function, nor
the new AuxiliaryPidGetProc function, if we stored a PGPROC
On Sat, Nov 15, 2008 at 2:00 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
Attached is the latest version of Synch Rep patch.
Why do we need a separate XLogsndRqst variable in shared memory? Don't we
always want to send the WAL up to the same point as we flush it?
It's
;
Likewise, should we also change the assertion against the pid of the
background process (BgWriterPID, PgStatPID)?
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
as possible.
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
if there is the XLOG file with the same logid and segid
even if the target file doesn't exist. Once failing to restore, the startup
process can switch the timeline and try to restore the XLOG file with
new timeline.
Is this idea reasonable? Any comments welcome!
Regards,
--
Fujii Masao
NIPPON
Hi, Heikki. Thanks for the comment!
On Thu, Nov 20, 2008 at 11:24 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
In the current Synch Rep patch, the standby cannot catch up with the
primary which has a bigger timeline.
That would only happen if you've performed
On Fri, Nov 21, 2008 at 12:06 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
Hi, Heikki. Thanks for the comment!
On Thu, Nov 20, 2008 at 11:24 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
In the current Synch Rep patch, the standby cannot catch
case,
we can recover the old primary by using the WAL on the old standby
consistently.
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
Hi, Simon. Thanks for the comment!!
On Sat, Nov 22, 2008 at 2:09 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-11-20 at 22:41 +0900, Fujii Masao wrote:
In the current Synch Rep patch, the standby cannot catch up with the
primary which has a bigger timeline. So, whenever making
point.
That is, we cannot make the standby (old primary) catch up without
a base backup.
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 Tue, Nov 25, 2008 at 11:42 AM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Fujii Masao [EMAIL PROTECTED] wrote:
On Fri, Nov 14, 2008 at 7:15 PM, Fujii Masao [EMAIL PROTECTED] wrote:
Attached is the latest version of Synch Rep patch. Sorry for my late
posting.
I fixed some bugs in v1patch
the
trigger file. Subsequent pg_standby uses the existing trigger
file.
This option is also useful for warm-standby.
Any comments welcome!
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Dickson S. Guedes escribió:
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use another
name for it. The name 'walsender' seems to be an internal module name
but it should
On Wed, Nov 26, 2008 at 12:23 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Fujii Masao escribió:
On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Dickson S. Guedes escribió:
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use
to get over the gap of
timeline this time, because the consensus is not reached.
http://archives.postgresql.org/pgsql-hackers/2008-11/msg01612.php
If you notice anything, please feel free to comment!
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
Hello,
On Tue, Nov 25, 2008 at 6:03 PM, Fujii Masao [EMAIL PROTECTED] wrote:
[2] User-configurable replication_timeout is dangerous
Index: backend/utils/misc/guc.c
+ {replication_timeout, PGC_USERSET, WAL_REPLICATION,
You export replication_timeout as a PGC_USERSET variable
Hello, Simon.
On Fri, Nov 28, 2008 at 4:29 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2008-11-26 at 00:03 +0900, Fujii Masao wrote:
In current pg_standby, the presence of the trigger file causes
recovery to end whether or not the next WAL file is available.
Thereby, some transactions
() for executing archive_command.
What is your opinion?
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
Hi,
On Fri, Nov 28, 2008 at 6:56 PM, Fujii Masao [EMAIL PROTECTED] wrote:
Hi,
The immediate shutdown (pg_ctl -m i stop) might not be able to
kill the startup process during archive recovery. It's because
the startup process calls system() which ignores SIGQUIT for
executing
Hello,
On Sat, Nov 29, 2008 at 12:40 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-11-28 at 19:53 +0900, Fujii Masao wrote:
Hi,
On Fri, Nov 28, 2008 at 6:56 PM, Fujii Masao [EMAIL PROTECTED] wrote:
Hi,
The immediate shutdown (pg_ctl -m i stop) might not be able to
kill
Hi, thanks for the comment!
On Sat, Nov 29, 2008 at 1:10 AM, Tom Lane [EMAIL PROTECTED] wrote:
Fujii Masao [EMAIL PROTECTED] writes:
You export replication_timeout as a PGC_USERSET variable, but it is
dangerous. It allows non-superusers to kill servers easily by setting it
too low value
.
Agreed. I will add new lock for proc.signalFlags.
Anyway, feeling very positive about this. Hope we can get this reviewed
and committed in next 3-4 weeks.
I have many clues as to how to structure my own work also. Thanks.
Thanks again!
Regards,
--
Fujii Masao
NIPPON TELEGRAPH
On Wed, Dec 3, 2008 at 5:13 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
On Wed, Oct 8, 2008 at 10:23 PM, Simon Riggs [EMAIL PROTECTED]
wrote:
Minor bug fix for pg_stop_backup() to prevent it waiting longer than
necessary in certain circumstances.
Why don't you use
the patch up into several parts? We have quite
a few junior reviewers who are idle right now.
Yes, I divided the patch into 9 pieces. Do I need to divide it further?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers
%27s_Development_Projects#Patch_set
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
it.
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
as a common function,
which helps to develop the tool (for example, xlogdump) treating WAL in
the future.
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
, the transaction doesn't need to
wait for the timeout. Configuring keepalive options would help walsender to
detect it. Of course, though keepalive on linux might not work as expected.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql
Hi,
On Tue, Dec 2, 2008 at 10:09 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Tue, 2008-12-02 at 21:37 +0900, Fujii Masao wrote:
Thanks for taking many hours to review the code!!
On Mon, Dec 1, 2008 at 8:42 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Can you confirm that all the docs
was TODO of next time.
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,
On Wed, Dec 3, 2008 at 3:38 PM, Fujii Masao [EMAIL PROTECTED] wrote:
Do we need to worry about periodic
renegotiation of keys in be-secure.c?
What is keys you mean?
See the notes in that file for explanation.
Thanks! I would check it.
The key is used only when we use SSL
, such restriction (always recovery
from a backup) might not matter.
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
is your opinion? I'd like to clear up the goal for 8.4.
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
Hello,
On Fri, Dec 5, 2008 at 12:09 PM, Fujii Masao [EMAIL PROTECTED] wrote:
I was expecting you to have walreceiver and startup share an end of WAL
address via shared memory, so that startup never tries to read past end.
That way we would be able to begin reading a WAL file *before
Hi, sorry for my consecutive posting.
On Fri, Dec 5, 2008 at 4:00 PM, Fujii Masao [EMAIL PROTECTED] wrote:
Hello,
On Fri, Dec 5, 2008 at 12:09 PM, Fujii Masao [EMAIL PROTECTED] wrote:
I was expecting you to have walreceiver and startup share an end of WAL
address via shared memory, so
Hi,
On Fri, Dec 5, 2008 at 7:09 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-12-05 at 12:09 +0900, Fujii Masao wrote:
On Thu, Dec 4, 2008 at 6:29 PM, Simon Riggs [EMAIL PROTECTED] wrote:
The only sensible settings are
synchronous_commit = on, synchronous_replication
Greetings!
On Fri, Dec 5, 2008 at 6:59 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-12-05 at 16:00 +0900, Fujii Masao wrote:
On Fri, Dec 5, 2008 at 12:09 PM, Fujii Masao [EMAIL PROTECTED] wrote:
I was expecting you to have walreceiver and startup share an end of WAL
address via
://www.postgresql.org/mailpref/pgsql-hackers
--
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
handles EINTR by recv().
Does anyone have a better idea?
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
for a multiplexed-signal implementation.
Ok, I was afraid so.
I think we'll need to replace the proposed bitmask with an array of
sig_atomic_t flags then, and do without locking.
Thanks! I updated the patch so (based on signal_handling_v2-heikki-1.patch).
Regards,
--
Fujii Masao
NIPPON TELEGRAPH
-archiving mode. Of course, if archiving
is disabled on the primary in any reason when restarting standby, the
primary need to switch back.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers
or SET command is executed.
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
,
--
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
the patch so. Is this patch ready to apply?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
diff -rc base/src/backend/bootstrap/bootstrap.c new/src/backend/bootstrap/bootstrap.c
*** base/src/backend/bootstrap/bootstrap.c 2008-12-10 16:29:10.0
field. Which
make me believe that the patch can't possibly work.
Ooops! My patch has some bugs :(
I will update the patch based on yours, and add the support for auxiliary
processes into it.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Hi,
On Thu, Dec 11, 2008 at 10:55 AM, Fujii Masao [EMAIL PROTECTED] wrote:
Hi,
My version doesn't have support for auxiliary processes. Does the
synchronous replication patch need that?
Yes, the background writer also generates the WAL like a backend,
so it has to be able to communicate
/git/users/fujii/postgres.git
branch: replication
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
.
This problem should be addressed right now? Or, I should wait
until current simple SR patch has been committed?
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 Thu, Nov 26, 2009 at 4:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
In current SR, since a backup history file is not replicated,
the standby always starts an archive recovery without a backup
history file, and a wrong minRecoveryPoint might
that ASAP.
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, Nov 30, 2009 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Why doesn't application_name appear in postgresql.conf.sample?
That is expected to be set from only libpq?
It would seem pretty silly to set it in the conf file. You *can*,
if you
and the slave can simply resume applying its newly
received WALs to base files.
I'm not sure how. But at first multiple online-backup feature
rather than backup-shipping itself might have to be addressed.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
On Mon, Nov 30, 2009 at 11:21 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Nov 30, 2009 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Why doesn't application_name appear in postgresql.conf.sample?
That is expected to be set from only libpq
Hi,
On Thu, Nov 26, 2009 at 5:20 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Nov 26, 2009 at 5:17 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yeah, that needs to be addressed regardless of HS, because you can
otherwise start up (= fail over to) the standby too
enable all child processes to easily obtain the
parameter values in that, like GUC parameters.
But I'm not sure why recovery.conf should be read separately by
postmaster and the startup process. How about making postmaster
read all of that for the simplification?
Regards,
--
Fujii Masao
NIPPON
be started many times.
Reading the full of the file every startup of such process would somewhat
harm the performance. Though, of course, this is overkill for your purpose.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers
several cases (a crash recovery and replication)
would increase complexity.
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
a lot!
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
recovery even if a relation is corrupted, and drop that
relation after the server has been activated. So I'm going to provide new
recovery.conf parameter specifying whether to let archive recovery fail
when some relations might be corrupted.
Thought? Am I missing something?
Regards,
--
Fujii
PqRecvBuffer seems better because XLogRecPtr message
has some types (i.e., we cannot just drop old message without parsing
all messages in the buffer).
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql
On Wed, Dec 9, 2009 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Thought? Am I missing something?
This seems terribly overdesigned. Just emit a warning when you see
the unlogged op record and have done.
Sounds quite simple. OK, I'll do so
relying on the OS buffer to not fill
up, let's just drop it.
The OS buffer is expected to be able to store a large number of
XLogRecPtr messages, because its size is small. So it's also OK
to just drop it.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
On Wed, Dec 9, 2009 at 10:51 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Dec 9, 2009 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Thought? Am I missing something?
This seems terribly overdesigned. Just emit a warning when you see
and
if evidence emerges that it's a real-world problem. For now,
simple is beautiful.
I just dropped the backend libpq changes related to non-blocking I/O.
git://git.postgresql.org/git/users/fujii/postgres.git
branch: replication
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT
/0001 (log file 0, segment 0): No such file
or directory
I also fixed this problem.
git://git.postgresql.org/git/users/fujii/postgres.git
branch: replication
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers
within 48 hours and commit by Wed.
Great!
Also I would need to adjust the SR patch to HS after it's committed.
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
,
--
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
the new
libpq function only for replication. That is, I didn't want to expose
the low layer of network which libpq should handle.
I think that the friendly function would be useful to implement
the standby program (e.g., a stand-alone walreceiver tool) outside
the core.
Regards,
--
Fujii Masao
instead of --color?
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
1 - 100 of 2751 matches
Mail list logo
