Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2026.1

# partitioned-jnl client recovery

The `partitioned-jnl` client type is, like the `partitioned` client type and the `readonly` client type, one of the partitioned Client workspace types. Partitioned means that the client's have list The list of file revisions most recently synced from the depot into the workspace. In other words, the list of files that the client workspace has. is maintained in a `db.have.pt` table on the P4 Server that is independent of the central have table. However, the `partitioned-jnl` client type is unique among the partitioned client types because it is eligible for journaling, recovering, dumping, checkpointing, and replicating.

## Journaling and partitioned-jnl

During journaling, the name of the partitioned have table, `db.have.pt`, is appended with its respective client name in the journal file in this format:
`db.have.pt%pclientname`

For example, `db.have.pt%pmaria_gonzales-linux-ws`
where the underscore `_` replaces an empty space in the `maria gonzales` client name.

When a `partitioned-jnl` client is deleted, its `db.have.pt` table is dropped and the table drop journal note is logged in the journal file as journal note type `31`. To learn more, see Journal notes.

When the records are deleted from the respective `db.have.pt` table, the delete entries are logged in the journal to support `partitioned-jnl` client recovery.

The `db.partition.dropondelete` configurable, if set, prevents the individual records from being deleted. Instead, the `db.have.pt` table is deleted, followed by the respective journal note. The `db.have.pt` table cannot be recovered, but performance is improved for the deletion of the `partitioned-jnl` client.

## Dumping and partitioned-jnl

To dump a single table for a client of type `readonly`, `partitioned`, and `partitioned-jnl`, append the partitioned client name in this format:
`p4d -jd - db.have.pt%pclient`

For example,
`p4d -jd - db.have.pt%pmaria_gonzales-linux-ws`

To dump all the tables for a client of type `partitioned-jnl`, the command is `p4d -jd` or `p4d -jd dumpfile`. This ignores the have tables of clients of type `readonly` and `partitioned` by design because of the three partitioned client types, only `partitioned-jnl` is recovered during the replay operation.

`p4d -jdp` and `p4d -jdpm` are the parallel options for dumping partitioned have tables.

## Checkpointing and partitioned-jnl

To checkpoint `partitioned-jnl` have tables, use the `p4 admin checkpoint` and `p4d -jc` commands.

`p4d -jcp` and `p4d -jcpm` are the parallel options for checkpointing partitioned have tables.

## Recovering and partitioned-jnl

The recovery can be done using a journal file or a checkpoint file.

To recover `partitioned-jnl` have tables, use the `p4d -jr` command.

When the journal file is replayed:

If the value of the `client.readonly.dir` configurable is empty on the server on which the replay is run, the value defaults to the value captured from the journal. However, you can override the default value by appending `o` to `-jr` in the `p4d -jro` command.

If the `client.readonly.dir` configurable is already set, but the journal provides a newer value, the `p4d -jro` command ensures that the journal value overrides the configurable value.

If `p4d -jr` is run in a non-empty directory, `client.readonly.dir` maintains the existing value.

If `p4d -jr` is run in an empty directory, `client.readonly.dir` is set to the value contained within the replay file.

If `p4d -jrF` is run in a non-empty directory, the existing `client.readonly.dir` is overridden.

Note that `p4d -jro` is applicable only for the journal replay.

The parallel option for the replay of partitioned have tables is supported with the `p4d -jrp` command.

For command-line help, use the `p4d -h` command.

## Command interaction with partitioned-jnl db.have tables

Command | Use case
--- | ---
`p4 journaldbchecksums -T "db.have db.have.pt"'` | To write journal notes Entries added to journals and checkpoints that provide information for subsequent users of the journal or checkpoint. For example, replica servers might take action based on the journal notes they process. with table checksums of the have tables of clients of type `readonly`, `partitioned`, and `partitioned-jnl` . `p4 journaldbchecksums -T "db.have db.have.pt%pws1`' results in the error "Cannot use specific partitioned tables in the list."
`p4 journaldbchecksums -u` | To write journal notes with table checksums while ignoring the have tables of clients of type `readonly`, `partitioned`, and `partitioned-jnl` .
`p4 unload` | To delete a partitioned client's have table and add a table drop note to the journal during the unload operation. The operation can be performed on clients of type `readonly`, `partitioned`, and `partitioned-jnl` .
`p4 changes -m max @pclient` | To output the submitted changes for the revisions of the files that are on the specified partitioned client's have list. For example, `p4 changes -m 5 @pmaria_gonzales-linux-ws` outputs the five most recently submitted changes of the specified partitioned client.
`p4 dbverify` and `p4d -xv` | To enable validation and verification of the partitioned have table. This requires that the `db.partition.verify` configurable be set and that the partitioned client associated with the partitioned have table has not been deleted.
`p4d -xx` | To check the `db.working` table against `partitioned-jnl` client have tables along with the existing integrity checks between table pairs.

Your search for returned results