the standby tries to start the replication from the
starting point of WAL record, i.e., that's the location of the former WAL file.
So the already-read WAL file is requested via replication.
To address this problem, maybe we can just use the location where the remaining
half of WAL record starts from as the replication starting location. We would
need to look at carefully the side effect of that change, though.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> (etc)
>
> Does anyone have any ideas what the problem may be? I suspect I may be
> missing a library somewhere - I can't believe that streaming replication
> just doesn't work on Solaris 10.
I guess that the version of the libpq library you use is not 9.
Regards,
--
Fujii
ndby, you have to create the trigger file on
the location
specified in -t option of pg_standby.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your sub
Forever until the archive will have been available again.
BTW, since the primary cannot remove the unarchived WAL file from
pg_xlog directory, unless you fix the archive soon, the primary might
run out of the disk space and cause a PANIC error.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPH
this function
> completely.
I couldn't reproduce this. Could you provide a self-contained test case?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to y
eckpoint rather than NULL in that
case?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
point? In this case, it seems bad to
return the timestamp of the checkpoint whenever there is no replay transaction,
since the result timestamp would go back once at least one transaction has been
replayed before reaching the checkpoint record.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHO
before getting PANIC, but that isn't in your
log messages.
LOG: entering standby mode
So I guess you forgot placing recovery.conf in HS server.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (
sql.org/wiki/Binary_Replication_Tutorial
http://wiki.postgresql.org/wiki/Streaming_Replication#How_to_Use
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscr
grade
your database since 7.4 is already end-of-life.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
rocess).
>
> The steps I am following are as follows,
> - search for trigger file.
> - Complete the recovery- rename recovery.conf file.
> any step is missing I am not sure.
The backtrace of that orphan process would be helpful for the analysis.
Regards,
--
Fujii Masao
NIPPON TE
org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
y.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
master and integrity of the data?
When the standby fails to read the WAL file from the archive, it tries to read
that from the master via replication connection. So the standby would not skip
that file.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
you might point the author at
> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=40f908bdcdc726fc11912cd95dfd2f89603d1f37#patch10
> which shows how it needs to be done in 9.0 and later.
I reported this problem to the author in offlist. Thanks for the bug report!
Regards,
--
Fu
ry. Then the startup process reads the WAL records
from the pg_xlog directory, and replays them.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
hing about it. I also have a hot standby on another
> machine connecting to the same master, but there is nothing strange in
> its logs either.
>
> Any thoughts what it was?
Is the value of replication_timeout sufficiently-larger than the status-interval
of pg_receivexlog?
Regards,
--
s
the database cluster on DRBD, it's better to check the status of
DRBD filesystem.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
an switch manually / automatically to TC2.
>
> Is there more appropriate solution? Would you use something else?
Nope. I've heard the similar configuration, though it uses shared disk
failover solution instead of DRBD.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2008/4/25 Aleksander Kmetec - INTERA <[EMAIL PROTECTED]>:
> Is there a way to get the time of the last insert, update or delete
> statement for a specific table?
You can check the time stamp of the file corresponding the table
after checkpoint. The relationship between the table name and
the file
ustering was happening will be out of
> order, but that should only be a few.
In your proposal, a large amount of dead tuple can be generated in both
table and index. This is a serious problem that spoils the effect of clustering.
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATIO
m wrong, is there still danger to the slave
> in this kind of setup?
No, I think.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
to understand
> better what's going on.)
Did you run query on the standby? If yes, I guess that query conflict prevented
the reply location from advancing.
http://www.postgresql.org/docs/9.0/static/hot-standby.html#HOT-STANDBY-CONFLICT
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPH
s flushed to the standby.
So that WAL record was replayed and the replay location advanced. I guess
you observed the above situation.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.or
On Fri, Jul 1, 2011 at 6:18 PM, AI Rumman wrote:
> Could anyone please tell me whether I can use pg_rman in my Windows
> environment?
http://code.google.com/p/pg-rman/wiki/Platforms
According to the above page, you cannot use it on Windows.
Regards,
--
Fujii Masao
NIPPON TELEGRA
uded in next minor
update (i.e., 9.0.5).
http://archives.postgresql.org/pgsql-committers/2011-06/msg00101.php
Of course, you can avoid the problem by building PostgreSQL with
gcc != 4.6.0, I think.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent
r.
In this case, you can re-point S2 as a standby just by changing
primary_conninfo in
S2's recovery.conf and restarting S2. When S2 restarts, S2 reads the
timeline history
file which was created by S1 at failover and adjust its timeline ID to
S1's. So timeline
conflict doesn't happe
e time to run
> without a restore_command ?
Specifically, what problem are you concerned about?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
aster,
create recovery.conf and start the server as the standby from the backup.
I have no idea about other replication method.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql
t advance recovery at all. OTOH,
if you set restore_command on the standby and have the shared
archive area, the standby can read new WAL file from it by using
restore_command and advance recovery.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source S
us_standby_names to '*',
"create database" hanged, i.e., was waiting for its WAL to be
replicated to the standby.
Only standby whose application_name matches synchronous_standby_names
can run as synchronous standby. '*' matches any application_name, so
'*' m
east one synchronous
standby has appeared and its WAL has been replicated to it.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscripti
off".
To enable;
Set synchronous_standby_names or set synchronous_commit to "on".
And then reload the configuration file.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To mak
seems applicable.
Increasing max_standby_archive_delay and max_standby_streaming_delay
would be helpful to make the query complete. Please see the following manual
for details.
http://www.postgresql.org/docs/9.0/interactive/hot-standby.html#HOT-STANDBY-CONFLICT
Regards,
--
Fujii Masao
NIP
modified file time of the xlog, but I'm hoping there is a better
> alternative that I haven't found yet
Your complaint makes sense. I'll implement something like
pg_last_xact_timestamp() for 9.2. But unfortunately there is
no way to know such a timestamp on the master, i
On Thu, Sep 8, 2011 at 3:19 PM, Simon Riggs wrote:
> On Thu, Sep 8, 2011 at 6:43 AM, Fujii Masao wrote:
>> Your complaint makes sense. I'll implement something like
>> pg_last_xact_timestamp() for 9.2. But unfortunately there is
>> no way to know such a timestamp on th
ult settings, it takes about two hours.
Setting keepalives parameters in primary_conninfo would help to fix
such a problem.
http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sen
On Mon, Oct 3, 2011 at 11:39 PM, senthilnathan
wrote:
> Is there any way to avoid time line increase /change on recovery
No, there is no way to prevent the timeline ID from being incremented
at the end of archive recovery.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
_backend(pid) from pg_stat_replication".
Then replication connection will be terminated. The standby tries reconnecting
to the master, but which will continue failing until you'll change pg_hba.conf
again.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-general@post
upgrades, etc].
>
>
> Are per-chance looking for pg_xlog_replay_pause() and
> pg_xlog_replay_resume() ?
Those can pause and resume WAL replay in the standby, but not streaming
replication. Even while WAL replay is being paused, WAL can be streamed
from the master to the standby.
Regar
On Wed, May 30, 2012 at 2:38 AM, Michael Nolan wrote:
>
>
> -- Forwarded message --
> From: Michael Nolan
> Date: Tue, May 29, 2012 at 1:37 PM
> Subject: Re: [GENERAL] Disable Streaming Replication without restarting
> either master or slave
> To: Fujii
end SIGTERM signal to currently-running walsender process, e.g., by
>> "select pg_terminate_backend(pid) from pg_stat_replication".
>
>
> Will it be helpful here sending SIGINT instead of killing ?
No, walsender ignores SIGINT signal.
Regards,
--
Fujii Masao
--
Sen
> Because we're using wal archiving, can we simplify and
> leave out step 3?
Yes.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mon, Aug 6, 2012 at 3:29 AM, Ben Chobot wrote:
>
> On Aug 5, 2012, at 11:12 AM, Fujii Masao wrote:
>
>> On Sat, Jul 28, 2012 at 2:00 AM, Ben Chobot wrote:
>>> We make heavy use of streaming replication on PG 9.1 and it's been great for
>>> us. We do have
but the number of archived WAL segments just increased to 1018.
wal_keep_segments affects the WAL files in pg_xlog directory,
not archive directory. When and how to remove archived files is
basically responsibility of a user.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list
IGHUP once
> per outer loop, so the change would only take effect once you catch up,
> which is not going to help much in this case. Possibly we should change
> it to check for SIGHUP after each archive_command execution.
+1
Here is the simple patch to do so.
Regards,
--
Fujii Masao
ed the following
> command, but it did not work:
>
> archive_command = 'if not exist C:\\pgsql\\backup_in_progress || copy
> %p C:\\pgsqlarchive\\%f'
You want to take "standalone hot backup" instead of normal one? If not,
you don't need to check the file &
FY_SYSTEM"
systemid | timeline
-+--
5488763631978937207 |1
(1 row)
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, Jul 1, 2010 at 1:02 PM, Tom Lane wrote:
> Fujii Masao writes:
>> Hmm... you'd like to get the system identifier from the postgres
>> server via SQL rather than starting replication? If so, you can do
>> that by adding replication entry into pg_hba.conf and p
very process once more, and provide
> a couple of minutes
> earlier time as recovery_target_time.
How about setting recovery_target_timeline to the old timeline ID (= 1)?
http://www.postgresql.org/docs/8.4/static/continuous-archiving.html#RECOVERY-TARGET-TIMELINE
Regards,
--
Fujii Masao
N
> timeline etc? May be doing the recovery in debug/logging mode or something
> like that?
xlogviewer reads WAL files and displays the contents of them. But
it's been inactive for several years, so I'm not sure if it's available now.
http://pgfoundry.org/projects/xlogviewer/
R
2010/8/6 Devrim GÜNDÜZ :
> Why can't I see psql there? Is it just because that logging is performed
> just before detecting application name?
Yes. The backend checks whether target database exists, before
processing application name.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AN
nk. Since any of them prevents the master from running
queries from the client, we should cause a failover.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to
be called instead of
pg_last_xlog_receive_location.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
master.
You can specify how many WAL files you'd keep in the master by using
wal_keep_segments parameter.
http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html#RUNTIME-CONFIG-REPLICATION
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Sourc
000EA" from archive
> LOG: redo starts at 25/EA87BA18
> FATAL: too many KnownAssignedXids
> CONTEXT: xlog redo insert: rel 1663/16399/303892827; tid 1503/119
> LOG: startup process (PID 20693) exited with exit code 1
> LOG: terminating any other active server processes
WAL files, and I'm
now proposing that.
http://archives.postgresql.org/pgsql-hackers/2010-09/msg02040.php
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
So you don't need to change wal_level and
hot_standby parameters.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi,
In order to check the plan of PreparedStatement,
I'm going to analyze the output of debug_print_plan.
But, since its output is very complicated, it's difficult
to analyze it.
Please let me know the method and tool which analyze it
easily.
--
Fujii Masao
NIPPON TELEGRAPH AND
re 10 .ready files in pg_xlog/archive_status, you might have
to wait for the reloading until the archiver finish archiving 10 WAL files.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgres
On Fri, Dec 5, 2008 at 11:25 PM, Glyn Astill <[EMAIL PROTECTED]> wrote:
>
> select pg_cancel_backend();
No, pg_cancel_backend() cancels only *query*, and doesn't kill idle
in transaction. I think that killing the backend (idle in transaction) with
SIGTERM is better way.
Regards,
pt which adds the timestamp into the head of
the output by using awk, perl, etc.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://w
hose
.ready file exists in archive_status directory.
And, note that you must get out of the archiving problem *before* making
a new base backup because pg_stop_backup() waits until the last WAL file
filled during backup has been archived. Otherwise, pg_stop_backup() would
get stuck.
Regards,
--
F
e termination of connection from the standby server.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
t a full sync may be
> required).
The standby periodically tries reconnecting to the master after it detects
the termination of replication connection. So even after prolonged disconnect,
replication can automatically resume.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT
if you granted
the "postgres" user the superuser privilege by using ALTER ROLE, the
replication privilege would not be granted.
You can check whether the "postgres" user has the replication privilege
by executing "\du" command.
Regards,
--
Fujii Masao
NIPPON TE
ated by pg_dumpall
in 9.0 instead of 9.1? If yes, that dump file would contain the "ALTER ROLE
postgres" command and revoke the replication privilege, I guess.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general m
eed to have the shared archive directory.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
veness ? tcp connection timeouts, replication timeouts all
>>> detect the failures, but i want to run some corrective action on these
>>> failure detection.
PostgreSQL doesn't have such a capability, but pgpool-II might have.
Can you ask that in pgpool-II mailing-list?
Rega
Postgres-XC.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
t as a replication
itself. You can health-check, do failover if necessary and manage the
PostgreSQL replication by using pgpool-II. AFAIK pgpool-II has such an
operation mode. But you are still not comfortable in using pgpool-II in
that way?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TEL
stat_replication or not. But I have no good idea about
the way to automatically run some action like reload of the configuration file
on the failure detection. Maybe you need to implement that on your own...
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source S
etting synchronous_commit to local can prevent new
transactions (which are executed after setting synchronous_commit to local)
from being blocked, but cannot resume the already-blocking transactions.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
bled there,
you should get the following log message at the start of recovery:
LOG: entering standby mode
But you didn't get such message. So I guess that PostgreSQL failed to read
recovery.conf and could not run restore_command because of wrong location
of recovery.conf.
Regards,
wal_keep_segments is only for offline async standby actually.
What if synchronous_commit is set to local or async?
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ch
Increase checkpoint_segments. In this setting, I guess checkpoints run too
frequently in heavy load, and WAL files are removed too aggressively.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
case of a slave failure I could use a weekly backup and let the
> catchup mode do the rest? Or does that only work if you use WAL archive?
Or increase wal_keep_segments to high so that all WAL files which the
standby requests
are guaranteed to exist in the pg_xlog directory of the master.
Regard
e and implement
the patch.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, Apr 12, 2012 at 12:56 AM, Fujii Masao wrote:
> On Wed, Apr 11, 2012 at 3:31 PM, 乔志强 wrote:
>> So in sync streaming replication, if master delete WAL before sent to the
>> only standby, all transaction will fail forever,
>> "the master tries to avoid a PANIC err
icular standby should no longer be included?
Probably the latter. So as Robert pointed out, we need neat API to register
and drop the standby. Though I have no good idea about this..
BTW, I have another idea about wal_keep_segments problem.
http://archives.postgresql.org/message-id/AANLkTinN=xspoo
; pgstat.c:3807
>
> I searched and to fix it it was recommended to disable autovacuum, I did it
> and it worked, but how can I fix it without disabling autovacuum?.
This might be alleviated by setting stats_temp_directory to point to a ramdisk.
Regards,
--
Fujii Masao
--
Sent via pgs
searched the behavior a bit; in particular I believe this can be
> adjusted with the sequence CACHE setting.
No. That behavior is caused by the hard-coded value SEQ_LOG_VALS
(= 32 in sequence.c) rather than CACHE setting.
Regards,
--
Fujii Masao
--
Sent via pgsql-general mailing list (pgsql-
me behaviour as
> Henry.
> I'm trying to find out if Mac OS belongs to those platforms that doesn't
> allow adjustment of the TCP keepalive parameters from userspace, and if so,
> how i can change the systems settings as root.
Do you use TCP/IP socket when you execute SHOW AL
frequently, they cannot be applied until
the log file fills.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi,
On Thu, Jan 29, 2009 at 12:23 AM, Jason Long
wrote:
> Is pg_clearxlogtail going to be in contrib or integrated in some other way?
I also hope so. The related topic was discussed before.
http://archives.postgresql.org/pgsql-hackers/2009-01/msg00639.php
Regards,
--
Fujii Masao
NIP
Hi,
On Tue, Feb 24, 2009 at 5:16 AM, John R Pierce wrote:
> is it looking like the simple replication will make it into 8.4?
You mean the built-in synchronous replication feature? If so, no.
It was decided that synch-rep will be postponed to 8.5.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH
ically renamed recovery.done by
postgres at the end of recovery, which would prevent
accidentally restarting warm-standby. So, you don't need to
delete or rename recovery.conf by hand after recovery.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software C
87 matches
Mail list logo
