Class V3PGReplicationStream

    • Field Detail

      • POSTGRES_EPOCH_2000_01_01

        public static final long POSTGRES_EPOCH_2000_01_01
        See Also:
        Constant Field Values
    • Constructor Detail

      • 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 Detail

      • read

        public java.nio.ByteBuffer read()
                                 throws java.sql.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:
        java.sql.SQLException - when some internal exception occurs during read from stream
      • readPending

        public java.nio.ByteBuffer readPending()
                                        throws java.sql.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:
        java.sql.SQLException - when some internal exception occurs during read from stream
      • 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:
        PGReplicationStream.forceUpdateStatus()
      • 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:
        PGReplicationStream.forceUpdateStatus()
      • 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 java.sql.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 java.lang.AutoCloseable
        Specified by:
        close in interface PGReplicationStream
        Throws:
        java.sql.SQLException - when some internal exception occurs during end streaming