jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-6279) Recovery Agent fails on PostgreSQL 9.5+ on Linux
Date Thu, 01 Jun 2017 13:34:04 GMT

    [ https://issues.apache.org/jira/browse/OAK-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032986#comment-16032986
] 

Julian Reschke commented on OAK-6279:
-------------------------------------

It is correct that the collation order is critical; for PostgreSQL I'm indeed testing with
"C" (and that happens to be documented in the Javadoc for RDBDocumentStore...).

That said, I'm surprised that "UTF-8" behaves differently (will need to read the PostgreSQL
docs), and I also agree that the way the code fails isn't helpful.



> Recovery Agent fails on PostgreSQL 9.5+ on Linux
> ------------------------------------------------
>
>                 Key: OAK-6279
>                 URL: https://issues.apache.org/jira/browse/OAK-6279
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.6.1
>         Environment: RDB store on PostgreSQL 9.5 and 9.6 running on Linux
>            Reporter: GianMaria Romanato
>            Assignee: Julian Reschke
>
> When Jackrabbit OAK crashes at the next restart it will use the LastRevRecoveryAgent
to perform recovery.
> The recovery procedure does not work when RDB is used and the database is PostgreSQL
running on a Linux machine. However, the recovery works as expected  when RDB is used and
the database is PostgreSQL running on Windows or MacOS.
> After some investigation I noticed that on Windows and MacOS newly created PostgreSQL
databases default to "C" collation, while on Linux "UTF-8" collation is the default. 
> Based on my tests, the recovery agent works also on Linux if the database is created
with collation set to "C". In other words, somehow the recovery agent fails unless database
collation is set to "C".
> According to the official PostgreSQL documentation:
> 'The C and POSIX collations both specify "traditional C" behavior, in which only the
ASCII letters "A" through "Z" are treated as letters, and sorting is done strictly by character
code byte values.'
> On Linux, if collation is not "C" the recovery will lead to error message:
> OakMerge0004: Following exceptions occurred during the bulk update 
> > operations: [org.apache.jackrabbit.oak.plugins.document.ConflictException: 
> By stepping a bit into the code I believe the problem is related to error:
> "both setting and then reading of clusterId failed"
> and it originates in method:
> org.apache.jackrabbit.oak.plugins.identifier.ClusterRepositoryInfo.getOrCreateId(NodeStore)
> where a CommitFailedException is caught and the flow proceeds to the lines of code preceded
by comment: "// this should not happen"



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message