. Currently the recovery process works as expected.
Regards,
--
Fujii Masao
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
need to find out
the XID or the time of that first transaction, e.g., by using pg_xlogdump,
and specify it in the recovery target.
Regards,
--
Fujii Masao
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
On Tue, Oct 16, 2012 at 9:31 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 15.10.2012 19:31, Fujii Masao wrote:
On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 15.10.2012 13:13, Heikki Linnakangas wrote:
Oh, I didn't remember that we've
On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 15.10.2012 13:13, Heikki Linnakangas wrote:
On 13.10.2012 19:35, Fujii Masao wrote:
ISTM you need to update the protocol.sgml because you added
the field 'replyRequested' to WalSndrMessage
need to update the protocol.sgml because you added
the field 'replyRequested' to WalSndrMessage and StandbyReplyMessage.
Is it worth adding the same mechanism (send back the reply immediately
if walsender request a reply) into pg_basebackup and pg_receivexlog?
Regards,
--
Fujii Masao
typo.patch
the fixes and prepare a single patch as fix of this defect.
Go for it!
Regards,
--
Fujii Masao
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, Sep 18, 2012 at 3:48 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 18.09.2012 09:46, Craig Ringer wrote:
On 09/18/2012 07:57 AM, Fujii Masao wrote:
If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from
message would be send maximum after that time.
The modified code of WALSendLoop will be as follows:
snip
Which way you think is better or you have any other idea to handle.
I think #2 is better because it's more intuitive to a user.
Regards,
--
Fujii Masao
--
Sent via pgsql-bugs mailing
the query cancels caused by cleanup of rows. So you might
need to set max_standby_streaming_delay to -1, to avoid query cancels.
Regards,
--
Fujii Masao
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.
Regards,
--
Fujii Masao
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Sat, Sep 15, 2012 at 4:26 PM, Amit kapila amit.kap...@huawei.com wrote:
On Saturday, September 15, 2012 11:27 AM Fujii Masao wrote:
On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila amit.kap...@huawei.com wrote:
On Thursday, September 13, 2012 10:57 PM Fujii Masao
On Thu, Sep 13, 2012 at 1:22
On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila amit.kap...@huawei.com wrote:
On Thursday, September 13, 2012 10:57 PM Fujii Masao
On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Wednesday, September 12, 2012 10:15 PM Fujii Masao
On Wed, Sep 12, 2012 at 8:54 PM
On Thu, Sep 13, 2012 at 9:21 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 12.09.2012 22:03, Fujii Masao wrote:
On Wed, Sep 12, 2012 at 8:47 PM,amit.kap...@huawei.com wrote:
The following bug has been logged on the website:
Bug reference: 7533
Logged by: Amit Kapila
On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Wednesday, September 12, 2012 10:15 PM Fujii Masao
On Wed, Sep 12, 2012 at 8:54 PM, amit.kap...@huawei.com wrote:
The following bug has been logged on the website:
Bug reference: 7534
Logged by: Amit
of replication_timeout, such feature has not been implemented yet. Please feel
free to implement that!
Regards,
--
Fujii Masao
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
state.
Comments? Review?
Regards,
--
Fujii Masao
cascaded_standby_and_shutdown_checkpoint_v1.patch
Description: Binary data
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
for file-based log shipping
replication.
Regards,
--
Fujii Masao
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, Oct 11, 2011 at 10:44 AM, Fujii Masao masao.fu...@gmail.com wrote:
When I built Streaming Replication and Hot Standby environment, set
max_standby_streaming_delay to 1s and ran the following shell script which
creates the conflict between read-only query and recovery, SEGV occurred
The following bug has been logged online:
Bug reference: 6249
Logged by: Fujii Masao
Email address: masao.fu...@gmail.com
PostgreSQL version: 9.2dev
Operating system: Linux hermes 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12
21:18:14 UTC 2011 i686 i686 i386 GNU/Linux
The following bug has been logged online:
Bug reference: 6222
Logged by: Fujii Masao
Email address: masao.fu...@gmail.com
PostgreSQL version: 9.2dev
Operating system: Linux hermes 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12
21:18:14 UTC 2011 i686 i686 i386 GNU/Linux
blocked by sync rep *after* it's committed on the
master. So, we cannot rollback such a transaction because it's already
been committed on the master (i.e., WAL has already been flushed to the disk).
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
taken with pg_basebackup in 9.1, we can add a flag to the
backup_label, indicating that the backup was taken with pg_basebackup. For
such backups, the above scenario really should not happen, and we can still
make it a hard error if it does.
Agreed.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH
all keyword instead of specifying the real user name? What happens
if you use 0.0.0.0/0 instead of specifying the slave's ip? You would need
to do trial and error approach.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs
,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
What log messages did you get right after starting the standby?
Did you locate the recovery.conf in PostgreSQL's data directory,
not /etc or elsewhere?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql
to create the standby (taking the
base backup from the master is required) and start it after you
*ensure* that there is no trigger file in the standby.
I hope this helps..
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs
situation. And, since psqlODBC frequently issues
SAVEPONT and RELEASE SAVEPOINT, this memory-leak is not rare case,
I think.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
On Wed, Dec 22, 2010 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
The proposed patch looks very simple. I don't think that applying that
patch will cause serious risk.
Maybe so, maybe not, but *it won't get tested* to any meaningful degree
if it's
On Wed, Dec 22, 2010 at 3:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Dec 22, 2010 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
The proposed patch looks very simple. I don't think that applying that
patch will cause serious risk.
Maybe
backup_label and continue recovery seems to be
dangerous. How about just emitting FATAL error when neither restore_command
nor primary_conninfo is supplied and backup_label exists? This seems to be
simpler than your proposed patch (i.e., check whether REDO location exists).
Regards,
--
Fujii Masao
on the master. This should be documented.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
that the users will not access to
inconsistent database.
Regards,
PS. I'll be unable to read hackers from Aug 13th to 20th because of
a vacation.
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
().
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
about this issue for a while, I end up agreeing that
the back-patching has a risk.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
of 9.0, I and Heikki appended some description to
make the technique more robust; pg_control file should be backed up first
and the backup end point should be checked before running query.
If it's unsafe, I'm happy to modify it. Which part looks unsafe?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH
be fixed in the same way as 8.3
does. Thought?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
couldn't be loaded. The attached
patch would fix the problem.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
walrcv_segv_v1.patch
Description: Binary data
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
purposes all the information was there in
the old message too, just in a cryptic format. And the new messages
would need translating too.
This looks applicable to also archive_command.
Are you going to apply it to archive_command?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE
are unexpectedly specified in PQconnectdbParams(), the
str_options would be free()-ed doubly.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
calling
it in the future application. Which looks very messy for me.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
.
If the sysadmin had left the recovery.conf and removed the trigger file,
pg_standby in restore_command would have restored all WAL files required
for recovery, and recovery would advance well.
Hope this helps.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, the backport is required for 8.3.x.
Thought?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
? drop_signal_support_for_pgstandby_win32.patch
Index: contrib/pg_standby/pg_standby.c
*/
if (signaled)
{
Failover = FastFailover;
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
the only reason it
compiles at all is that we bring in *some* of our signals emulation
code, but certainly not all of it.
SIGINT has been used in pg_standby for a while (e.g., v8.3.7). I wonder
why this problem arises only in v8.4.0.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
it alone? If not, you might have failed the installation of it.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
, and this with
shared_buffer=32MB. With larger shared_buffers, it happens even less
frequently.
Oh, I misunderstood about how UpdateMinRecoveryPoint() is called.
ISTM that recovery is still fast unless shared_buffers is set to unreasonable
value. Sorry for the noise.
Regards,
--
Fujii Masao
NIPPON
The following bug has been logged online:
Bug reference: 4879
Logged by: Fujii Masao
Email address: masao.fu...@gmail.com
PostgreSQL version: 8.4dev
Operating system: RHEL5.1 x86_64
Description:bgwriter fails to fsync the file in recovery mode
Details
performance
degradation of archive recovery. I think that this is an issue to be fixed.
The warm-standby users (including me) care about the performance
of the standby server, because that affects the failover time, for example.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT
that *all* the history files exist.
So, as Simon says, we should clearly say that a history file
must not be deleted from the archive. Or, we should create
a new solution.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing
pick a unique timeline id.
When only the history file for timeline 6 is deleted, timeline 6 would be
assigned as the newest one *again* at the end of archive recovery.
Is this safe?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via
, this is against the current premise that timeline IDs must be in
increasing sequence.
Let's document that timeline files should not be deleted from the
archive iff there exists a base backup made during a lower numbered
timeline.
Agreed.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH
Hi,
On Fri, May 15, 2009 at 8:56 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Fri, May 15, 2009 at 8:20 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The probe in findNewestTimeLine() initialized to recovery target timeline
Hi,
On Thu, Apr 9, 2009 at 1:40 PM, Fujii Masao masao.fu...@gmail.com wrote:
The following bug has been logged online:
Bug reference: 4752
Logged by: Fujii Masao
Email address: masao.fu...@gmail.com
PostgreSQL version: PostgreSQL 8.4d
Operating system: Red Hat
Hi,
On Thu, Apr 9, 2009 at 11:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Attached patch fixes the bug. Is this worth committing?
Applied to HEAD, but it didn't seem worth back-patching. Thanks.
Thanks.
PS: when you generate a diff against a non
The following bug has been logged online:
Bug reference: 4752
Logged by: Fujii Masao
Email address: masao.fu...@gmail.com
PostgreSQL version: PostgreSQL 8.4d
Operating system: Red Hat Enterprise Linux Server release 5.1 (Tikanga)
Description:sourceline in pg_settings
xlogs
can be ignored?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 4657
Logged by: Fujii Masao
Email address: masao.fu...@gmail.com
PostgreSQL version: 8.3.6 on x86_64
Operating system: Red Hat Enterprise Linux Server release 5.1 (Tikanga)
Description:mod() makes a mistake
(). Only a part of backup
history file (the file name including stop wal location) is changed.
Currently, the file name is wrong if stop wal location indicates a boundary
byte. This would confuse the user, I think.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source
are lots more sensible now.
OK. I understood that changing the filename would more confuse users.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
behavior for managing transaction log
archiving behavior, since the preceding file is the last one that currently
needs to be archived.
-
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list
backport.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
? GNUmakefile
? config.log
? config.status
? src/Makefile.global
? src/backend/postgres
? src/backend/catalog/postgres.bki
? src/backend/catalog/postgres.description
? src/backend/catalog
The following bug has been logged online:
Bug reference: 4109
Logged by: Fujii Masao
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: All
Description:Typo in documentation
Details:
I found the typo in
http://www.postgresql.org/docs/8.3
.
This conflict can confuse the user. So, should we unite the
descriptions of the number of bytes for NAMEDATALEN?
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
TEL (03)5860-5115
FAX (03)5463-5490
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Tom Lane wrote:
According to that, Linux keepalive starts working once you have either
sent or received at least one byte over the connection. Therefore it's
not possible to get past the authentication stage without keepalive
being ready to go. And we do have a pretty short timeout on the
Hi.
I found the cause of the error that tcp_keepalive doesn't work.
The cause is a specification of linux kernel.
In the specification of linux kernel, tcp_keepalive doesn't work
if the network outage occurs before receiving ACK for send() system-call.
This behavior of tcp_keepalive is reported
The following bug has been logged online:
Bug reference: 2576
Logged by: Fujii Masao
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Fedora Core 5
Description:tcp_keepalive doesn't work
Details:
Hi.
I found an error that tcp_keepalive
Hi.
You seem to have a misunderstanding of what tcp_keepalive is for. It
does not kill a backend that is in the midst of a query. A backend will
terminate when it is waiting for a client command and it sees that the
connection has been lost --- which is what a TCP timeout will cause to
68 matches
Mail list logo
