View Issue Details

Jump to NotesJump to History
This issue affects 1 person(s).
 2
IDProjectCategoryView StatusDate SubmittedLast Update
20514Bug reportsSurvey takingpublic2026-05-13 13:252026-05-26 22:49
Reporterhinghang Assigned Toc_schmitz  
PrioritynoneSeverityminor 
Status closedResolutionno change required 
Product Version6.14.x 
Summary20514: Intermittent currval of sequence is not yet defined error during survey response submission on Patroni PostgreSQL cluster
Description

When end-users attempt to submit survey responses, LimeSurvey intermittently fails and throws the following database exception:

currval of sequence "limesurvey[SURVEY_ID]_id_seq" is not yet defined in this session

The issue occurs in bursts affecting a subset of users during a specific period. After a period of time, the issue resolves itself automatically without requiring a manual database or application restart.

Steps To Reproduce

Steps to reproduce

(Replace this text with detailed step-by-step instructions on how to reproduce the issue)

Expected result

(Write here what you expected to happen)

Actual result

(Write here what happened instead)

TagsNo tags attached.
Bug heat2
Complete LimeSurvey version number (& build)6.14.0+250520
I will donate to the project if issue is resolvedNo
Browser
Database type & versionPostgreSQL 16.6 with Patroni 4.0.4
Server OS (if known)
Webserver software & version (if known)
PHP Version8.3.22
Git branch / Pull Request URL

Users monitoring this issue

There are no users monitoring this issue.

Activities

c_schmitz

c_schmitz

2026-05-26 22:49

administrator   ~84914

Closing — this is an infrastructure issue, not a LimeSurvey bug.

The "currval of sequence is not yet defined in this session" error occurs when PostgreSQL session state is lost mid-operation. This happens in Patroni clusters due to connection pooling (e.g., PgBouncer in transaction/statement mode) or primary failover events - both of which reset session-level sequence state.

LimeSurvey uses standard INSERT + lastInsertID(), which is correct per PostgreSQL semantics. The fix is in your infrastructure: use session-mode pooling, or check Patroni logs for failovers correlating with the error bursts.

Issue History

Date Modified Username Field Change
2026-05-13 13:25 hinghang New Issue
2026-05-26 22:49 c_schmitz Assigned To => c_schmitz
2026-05-26 22:49 c_schmitz Status new => closed
2026-05-26 22:49 c_schmitz Resolution open => no change required
2026-05-26 22:49 c_schmitz Note Added: 84914
2026-05-26 22:49 c_schmitz Bug heat 0 => 2