[DPE-8747] Handle persistent storage in set_up_database to prevent ObjectInUse errors

[marceloneppel]

Issue

The charm fails with "directory already in use as a tablespace" error when running on persistent storage for the temp storage after a reboot in the host machine.

Solution

The issue occurred because the method assumed tmpfs storage and would rename the existing 'temp' tablespace and try to create a new one at the same location. With persistent storage, the directory remains in use by the renamed tablespace, causing PostgreSQL to reject the CREATE TABLESPACE command.

Changes:

• Add is_tmpfs() utility function to detect filesystem type via /proc/mounts
• Modify set_up_database() to differentiate between tmpfs and persistent storage:
  • tmpfs: Preserve existing behavior (rename + recreate for empty directory)
  • persistent: Only fix permissions, keep existing tablespace
• Extract tablespace handling into _handle_temp_tablespace_on_reboot() helper method to reduce cyclomatic complexity
• Add comprehensive test coverage (7 new tests for is_tmpfs, 1 for persistent storage handling)
• Update existing tests to mock filesystem detection This ensures the library works correctly with both tmpfs and persistent storage configurations for the temp tablespace.

Bumps version to 16.1.5.

Checklist

• I have added or updated any relevant documentation.
• I have cleaned any remaining cloud resources from my accounts.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 50.89%. Comparing base (5559a77) to head (5c8e58c).
⚠️ Report is 1 commits behind head on 16/edge.

❌ Your project status has failed because the head coverage (50.89%) is below the target coverage (70.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff             @@
##           16/edge      #54      +/-   ##
===========================================
+ Coverage    49.42%   50.89%   +1.47%     
===========================================
  Files            4        4              
  Lines          864      890      +26     
  Branches       101      105       +4     
===========================================
+ Hits           427      453      +26     
  Misses         417      417              
  Partials        20       20              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[onkolahmet]

LGTM! Just added some comments for clarity.

[onkolahmet]

Just a small thought, on persistent storage, we're assuming the existing tablespace is still valid. Should we add a sanity check that it's still at temp_location? Or is this guaranteed by design? In other words, could we include the actual temp_location path in the log message? Would make debugging easier.

[marceloneppel]

Good suggestion. Added the temp_location to the log message on 32416d3.

Regarding "is this guaranteed by design": Yes, the tablespace location is guaranteed to be at temp_location by design. PostgreSQL maintains this in its catalog, and the charm always uses the same path. The edge case where the tablespace doesn't exist yet (reboot during initialization) is already handled by the early return at line 1121.

[onkolahmet]

How do we handle if two renames somehow happen in the same second? Probably super rare, but maybe worth documenting?

[marceloneppel]

Good suggestion. Added documentation explaining why timestamp collision cannot occur: be8f00e.

Two renames cannot happen in the same second because consuming charms ensure leader-only execution (see postgresql-operator example), and PostgreSQL serializes operations through exclusive locks on the tablespace object.