Class V3PGReplicationStream

java.lang.Object
org.postgresql.core.v3.replication.V3PGReplicationStream
All Implemented Interfaces:
AutoCloseable, PGReplicationStream

public class V3PGReplicationStream extends Object implements PGReplicationStream
  • Field Details

    • POSTGRES_EPOCH_2000_01_01

      public static final long POSTGRES_EPOCH_2000_01_01
      See Also:
  • Constructor Details

    • V3PGReplicationStream

      public V3PGReplicationStream(CopyDual copyDual, LogSequenceNumber startLSN, long updateIntervalMs, ReplicationType replicationType)
      Parameters:
      copyDual - bidirectional copy protocol
      startLSN - the position in the WAL that we want to initiate replication from usually the currentLSN returned by calling pg_current_wal_lsn()for v10 above or pg_current_xlog_location() depending on the version of the server
      updateIntervalMs - the number of millisecond between status packets sent back to the server. A value of zero disables the periodic status updates completely, although an update will still be sent when requested by the server, to avoid timeout disconnect.
      replicationType - LOGICAL or PHYSICAL
  • Method Details

    • read

      public @Nullable ByteBuffer read() throws SQLException
      Description copied from interface: PGReplicationStream

      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.

      Specified by:
      read in interface PGReplicationStream
      Returns:
      not null byte array received by replication protocol, return ByteBuffer wrap around received byte array with use offset, so, use ByteBuffer.array() carefully
      Throws:
      SQLException - when some internal exception occurs during read from stream
    • readPending

      public @Nullable ByteBuffer readPending() throws SQLException
      Description copied from interface: PGReplicationStream

      Read next WAL record from backend. This method does not block and in contrast to PGReplicationStream.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 than CommonOptions.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.

      Specified by:
      readPending in interface PGReplicationStream
      Returns:
      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.
      Throws:
      SQLException - when some internal exception occurs during read from stream
    • getLastReceiveLSN

      public LogSequenceNumber getLastReceiveLSN()
      Description copied from interface: PGReplicationStream

      Parameter updates by execute PGReplicationStream.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 PGReplicationStream.read() or PGReplicationStream.readPending(), to get the LSN corresponding to the received record.

      Specified by:
      getLastReceiveLSN in interface PGReplicationStream
      Returns:
      NOT NULL LSN position that was receive last time via PGReplicationStream.read() method
    • getLastFlushedLSN

      public LogSequenceNumber getLastFlushedLSN()
      Description copied from interface: PGReplicationStream

      Last flushed LSN sent in update message to backend. Parameter updates only via PGReplicationStream.setFlushedLSN(LogSequenceNumber)

      It is safe to call this method in a thread different than the main thread.

      Specified by:
      getLastFlushedLSN in interface PGReplicationStream
      Returns:
      NOT NULL location of the last WAL flushed to disk in the standby.
    • getLastAppliedLSN

      public LogSequenceNumber getLastAppliedLSN()
      Description copied from interface: PGReplicationStream

      Last applied lsn sent in update message to backed. Parameter updates only via PGReplicationStream.setAppliedLSN(LogSequenceNumber)

      It is safe to call this method in a thread different than the main thread.

      Specified by:
      getLastAppliedLSN in interface PGReplicationStream
      Returns:
      not null location of the last WAL applied in the standby.
    • setFlushedLSN

      public void setFlushedLSN(LogSequenceNumber flushed)
      Description copied from interface: PGReplicationStream

      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.

      Specified by:
      setFlushedLSN in interface PGReplicationStream
      Parameters:
      flushed - NOT NULL location of the last WAL flushed to disk in the standby.
      See Also:
    • setAppliedLSN

      public void setAppliedLSN(LogSequenceNumber applied)
      Description copied from interface: PGReplicationStream

      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.

      Specified by:
      setAppliedLSN in interface PGReplicationStream
      Parameters:
      applied - NOT NULL location of the last WAL applied in the standby.
      See Also:
    • forceUpdateStatus

      public void forceUpdateStatus() throws SQLException
      Description copied from interface: PGReplicationStream
      Force send last received, flushed and applied LSN status to backend. You cannot send LSN status explicitly because PGReplicationStream sends the status to backend periodically by configured interval via CommonOptions.getStatusInterval()
      Specified by:
      forceUpdateStatus in interface PGReplicationStream
      Throws:
      SQLException - when some internal exception occurs during read from stream
      See Also:
    • isClosed

      public boolean isClosed()
      Specified by:
      isClosed in interface PGReplicationStream
      Returns:
      true if replication stream was already close, otherwise return false
    • close

      public void close() throws SQLException
      Description copied from interface: PGReplicationStream

      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

      Specified by:
      close in interface AutoCloseable
      Specified by:
      close in interface PGReplicationStream
      Throws:
      SQLException - when some internal exception occurs during end streaming