インタフェース PGReplicationStream
- すべてのスーパーインタフェース:
AutoCloseable
- 既知の実装クラスのリスト:
V3PGReplicationStream
read()
method. It means that
process wal record should be fast as possible, because during process wal record lead to
disconnect by timeout from server.-
メソッドの概要
修飾子とタイプメソッド説明void
close()
Stop replication changes from server and free resources.void
Force send last received, flushed and applied LSN status to backend.Last applied lsn sent in update message to backed.Last flushed LSN sent in update message to backend.Parameter updates by executeread()
method.boolean
isClosed()
@Nullable ByteBuffer
read()
Read next wal record from backend.@Nullable ByteBuffer
Read next WAL record from backend.void
setAppliedLSN
(LogSequenceNumber applied) Inform backend which LSN has been applied on standby.void
setFlushedLSN
(LogSequenceNumber flushed) Set flushed LSN.
-
メソッドの詳細
-
read
Read next wal record from backend. It method can be block until new message will not get from server.
A single WAL record is never split across two XLogData messages. When a WAL record crosses a WAL page boundary, and is therefore already split using continuation records, it can be split at the page boundary. In other words, the first main WAL record and its continuation records can be sent in different XLogData messages.
- 戻り値:
- not null byte array received by replication protocol, return ByteBuffer wrap around
received byte array with use offset, so, use
ByteBuffer.array()
carefully - 例外:
SQLException
- when some internal exception occurs during read from stream
-
readPending
Read next WAL record from backend. This method does not block and in contrast to
read()
. If message from backend absent return null. It allow periodically check message in stream and if they absent sleep some time, but it time should be less thanCommonOptions.getStatusInterval()
to avoid disconnect from the server.A single WAL record is never split across two XLogData messages. When a WAL record crosses a WAL page boundary, and is therefore already split using continuation records, it can be split at the page boundary. In other words, the first main WAL record and its continuation records can be sent in different XLogData messages.
- 戻り値:
- byte array received by replication protocol or NULL if pending message from server
absent. Returns ByteBuffer wrap around received byte array with use offset, so, use
ByteBuffer.array()
carefully. - 例外:
SQLException
- when some internal exception occurs during read from stream
-
getLastReceiveLSN
LogSequenceNumber getLastReceiveLSN()Parameter updates by execute
read()
method.It is safe to call this method in a thread different than the main thread. However, usually this method is called in the main thread after a successful
read()
orreadPending()
, to get the LSN corresponding to the received record.- 戻り値:
- NOT NULL LSN position that was receive last time via
read()
method
-
getLastFlushedLSN
LogSequenceNumber getLastFlushedLSN()Last flushed LSN sent in update message to backend. Parameter updates only via
setFlushedLSN(LogSequenceNumber)
It is safe to call this method in a thread different than the main thread.
- 戻り値:
- NOT NULL location of the last WAL flushed to disk in the standby.
-
getLastAppliedLSN
LogSequenceNumber getLastAppliedLSN()Last applied lsn sent in update message to backed. Parameter updates only via
setAppliedLSN(LogSequenceNumber)
It is safe to call this method in a thread different than the main thread.
- 戻り値:
- not null location of the last WAL applied in the standby.
-
setFlushedLSN
Set flushed LSN. This parameter will be sent to backend on next update status iteration. Flushed LSN position help backend define which WAL can be recycled.
It is safe to call this method in a thread different than the main thread. The updated value will be sent to the backend in the next status update run.
- パラメータ:
flushed
- NOT NULL location of the last WAL flushed to disk in the standby.- 関連項目:
-
setAppliedLSN
Inform backend which LSN has been applied on standby. Feedback will send to backend on next update status iteration.
It is safe to call this method in a thread different than the main thread. The updated value will be sent to the backend in the next status update run.
- パラメータ:
applied
- NOT NULL location of the last WAL applied in the standby.- 関連項目:
-
forceUpdateStatus
Force send last received, flushed and applied LSN status to backend. You cannot send LSN status explicitly becausePGReplicationStream
sends the status to backend periodically by configured interval viaCommonOptions.getStatusInterval()
- 例外:
SQLException
- when some internal exception occurs during read from stream- 関連項目:
-
isClosed
boolean isClosed()- 戻り値:
true
if replication stream was already close, otherwise returnfalse
-
close
Stop replication changes from server and free resources. After that connection can be reuse to another queries. Also after close current stream they cannot be used anymore.
Note: This method can spend much time for logical replication stream on postgresql version 9.6 and lower, because postgresql have bug - during decode big transaction to logical form and during wait new changes postgresql ignore messages from client. As workaround you can close replication connection instead of close replication stream. For more information about it problem see mailing list thread Stopping logical replication protocol
- 定義:
close
インタフェース内AutoCloseable
- 例外:
SQLException
- when some internal exception occurs during end streaming
-