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/pgsql-bugs
e is true, all the records whose
time is older than
or equal to the recovery_target_time should be applied. If
recovery_target_inclusive
is false, all the records whose time is only older than the
recovery_target_time should
be applied. 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
make no sense as the client could lie which one it is.
Probably I'm missing something, but the standby server only has to reject the
replication connection if cascade replication is disabled, whether it's from
another standby or pg_basebackup. ISTM there is no need to distinguish
those c
On Tue, Oct 16, 2012 at 9:31 PM, Heikki Linnakangas
wrote:
> On 15.10.2012 19:31, Fujii Masao wrote:
>>
>> On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
>> wrote:
>>>
>>> On 15.10.2012 13:13, Heikki Linnakangas wrote:
>>>>
>&g
On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
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 'replyReque
ttached patch fixes that typo.
ISTM you 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 a
_interval) to six,
and those parameters are confusingly similar to existing
tcp_keepalives parameters,
which might cause another confusion to users. One idea to solve this problem is
to use existing tcp_keepalives paramters values for the replication timeout.
Regards,
--
Fujii Masao
--
Sent via p
gt; combine both 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
sed by buffer pin lock which you encountered.
It eliminates only 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
ro then KeepAlive
> message would be send maximum after that time.
> The modified code of WALSendLoop will be as follows:
> 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
--
Sen
On Tue, Sep 18, 2012 at 3:48 PM, Heikki Linnakangas
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 fro
the issue by not only changes on the slave
> side but by checking if the master has been updated as well.
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 maili
On Sat, Sep 15, 2012 at 4:26 PM, Amit kapila wrote:
> On Saturday, September 15, 2012 11:27 AM Fujii Masao wrote:
> On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila wrote:
>>
>> On Thursday, September 13, 2012 10:57 PM Fujii Masao
>> On Thu, Sep 13, 2012 at 1:22 PM, Am
On Fri, Sep 14, 2012 at 12:21 PM, Amit Kapila wrote:
> On Thursday, September 13, 2012 10:32 PM Fujii Masao wrote:
> On Thu, Sep 13, 2012 at 9:21 PM, Heikki Linnakangas wrote:
>> On 12.09.2012 22:03, Fujii Masao wrote:
>>>
>>> On Wed, Sep 12, 2012 at 8:47 PM, wrot
On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila wrote:
>
> On Thursday, September 13, 2012 10:57 PM Fujii Masao
> On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote:
>> On Wednesday, September 12, 2012 10:15 PM Fujii Masao
>> On Wed, Sep 12, 2012 at 8:54 PM, wrote:
>&g
On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote:
> On Wednesday, September 12, 2012 10:15 PM Fujii Masao
> On Wed, Sep 12, 2012 at 8:54 PM, wrote:
>>> The following bug has been logged on the website:
>>>
>>> Bug reference: 7534
>>> Logged
On Thu, Sep 13, 2012 at 9:21 PM, Heikki Linnakangas wrote:
> On 12.09.2012 22:03, Fujii Masao wrote:
>>
>> On Wed, Sep 12, 2012 at 8:47 PM, wrote:
>>>
>>> The following bug has been logged on the website:
>>>
>>> Bug reference: 7533
&g
ControlFile fields
(like backupStartPoint) required for checking that an end-of-backup is
reached are not set at first. IOW, cascaded standby thinks that the
database is consistent from the beginning. This is safe because
a shutdown checkpoint record means that there is no running database
acti
nt. If you need something like
walreceiver-version
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
cp or something instead of pg_standby if you'd like to
use streaming replication. pg_standby is the tool 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
e it has been received
from the primary server. Thus, if one query has resulted in
significant delay, subsequent conflicting queries will have much less
grace time until the standby server has caught up again.
---
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
On Tue, Oct 11, 2011 at 10:44 AM, Fujii Masao 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 on
> the
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
e transaction gets 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 CORPORA
; For backups 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,
--
Fuji
appens if you
use "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
432 user=postgres
> keepalives_idle=30 keepalives_interval=30 keepalives_count=30'
This setting would lead TCP keepalive to take about 930 seconds
(= 30 + 30 * 30) to detect the network outage. If you want to stop
replication as soon as the outage happens, you need to decrease
the keepalive set
eceiver was not invoked in the
standby.
To start replication, you need 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 CO
est.
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 lis
On Wed, Dec 22, 2010 at 3:24 PM, Fujii Masao wrote:
> On Wed, Dec 22, 2010 at 11:48 AM, Tom Lane wrote:
>> Fujii Masao writes:
>>> The proposed patch looks very simple. I don't think that applying that
>>> patch will cause serious risk.
>>
>> Maybe
On Wed, Dec 22, 2010 at 11:48 AM, Tom Lane wrote:
> Fujii Masao 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
version of 8.3. This would
cause more serious 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
On Tue, Oct 19, 2010 at 5:18 PM, Heikki Linnakangas
wrote:
> On 19.10.2010 08:51, Fujii Masao wrote:
>>
>> On Tue, Oct 19, 2010 at 7:00 AM, Jeff Davis wrote:
>>>>>
>>>>> Do users have any expectation that they can restore a backup without
>&
f that's the expectation, I believe my original fix has less impact.
> It's essentially a sanity check to make sure that the first segment
> needed is available before proceeding.
If that's really useful for some cases, I agree with your fix.
Regards,
--
Fujii Masao
NIPPON T
supplied and backup_label exists? This seems to be
simpler than your proposed patch (i.e., check whether REDO location exists).
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
generated by pg_stop_backup in the
step 5), we can think that the database has reach consistency.
Since new standby doesn't accept connections from the client
until that, we can ensure that the users will not access to
inconsistent database.
Regards,
PS. I'll be unable to read hackers f
mpact on the master, if we write clearly that the
procedure is safe only when full_page_writes is enabled. Comments?
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 change
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
is
> just flying blind as to whether the slave is trustworthy yet. I can't
> prove that that's what burnt the original complainant, but it fits the
> symptoms.
The step 2 of the procedure can ensure that new slave has reached
consistency. No?
Regards,
--
Fujii Masao
NIPPON
rm_redo().
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
a large patch for backpatching, IMHO.
Though I thought 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.o
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 TE
8.2 and should 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
() was called in
WalRcvDie() even though libpqwalreceiver.so 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
c 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 T
as soon
as one "dbname" keyword is found. So if more than one "dbname"
keywords 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
o check for the content of the dbname before 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 cha
On Mon, Feb 1, 2010 at 5:31 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> In HEAD, psql using conninfo fails in connecting to the server as follows.
>>
>> $ bin/psql "host=localhost"
>> psql: FATAL: database "host=localhost" do
The following bug has been logged online:
Bug reference: 5304
Logged by: Fujii Masao
Email address: masao.fu...@gmail.com
PostgreSQL version: HEAD
Operating system: RHEL5.1
Description:psql using conninfo fails in connecting to the server
Details:
In HEAD, psql
mmand was not given. In fact, the
WAL file (e.g., pg_xlog/00023C8200A3) required for recovery
was unable to be restored from the archive because restore_command was
not supplied. Then recovery failed.
If the sysadmin had left the recovery.conf and removed the trigger file,
pg_standby in r
believe that such a file permission problem does nothing but
shut down the standby by a FATAL error, and wouldn't cause data
corruption. So if you remove the trigger file with a wrong
permission after the shutdown, you can restart a recovery well
by just starting the standby postgres.
Regards,
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
===
RCS file: /projects/cvsroot/pg
_FOR_INTERRUPTS();
+ #endif /* WIN32 */
if (signaled)
{
Failover = FastFailover;
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (p
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 TELEPH
execute 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/mailpref/pgsql-bugs
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 TELEGRAPH AND T
nificant 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
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:
The
Hi,
On Fri, May 15, 2009 at 8:56 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> On Fri, May 15, 2009 at 8:20 PM, Heikki Linnakangas
>> wrote:
>>>
>>> The probe in findNewestTimeLine() initialized to recovery target timeline
>>> +
>
which I described, 6 is treated as timeline newer than 7.
At least, 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
rchive, we 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
s 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 list (pgsql-bugs@pos
Hi,
On Thu, Apr 9, 2009 at 11:22 PM, Tom Lane wrote:
> Fujii Masao 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-clean sourc
Hi,
On Thu, Apr 9, 2009 at 1:40 PM, Fujii Masao 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:
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
r with --listen_addresses='' to prevent other users to
> connect (there are no local users on the server machine)
> - pg_switch_xlog()
> - shutdown finally
> - let the warm server continue
What if new xlogs are generated by autovacuum or bgwriter
between pg_switch_xlog and final shutdow
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 in
e functions return the name of the preceding transaction
> log file. This is usually the desired 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 TEL
nal
> implementation file 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)
rn value of pg_switch_xlog(). 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 CO
nding WAL file for backup.
It's a bug of pg_stop_backup(), which has been talked before.
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00108.php
Attached is a patch against HEAD. I think that we should
also backport.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
N
etype.html.
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 (
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
The following bug has been logged online:
Bug reference: 3486
Logged by: Fujii Masao
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: RHEL4
Description:doc bug - Preventing transaction ID wraparound failures
Details:
According to "var
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 e
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
>
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_keep
79 matches
Mail list logo
