| From: | mike(at)mikebrancato(dot)com |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(dot)com> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: RLS creates inaccurate limit and offset results |
| Date: | 2025-11-11 22:46:28 |
| Message-ID: | E13131DB-28E5-4F05-A9D8-D54F886230C2@mikebrancato.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> On Nov 11, 2025, at 5:10 PM, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>
> LIMIT and OFFSET without ORDER BY are not guaranteed to return consistent results even without RLS. RLS may cause it be more obvious, however.
If I understand the documentation (https://www.postgresql.org/docs/current/queries-limit.html) inconsistent results for different LIMIT / OFFSET values is only a known issue when selecting different subsets of data. Here, I’m seeing inconsistent results on the same subset of data. e.g. OFFSET 0 and OFFSET 1 return the same row without changing the overall query / WHERE clause or LIMIT. This claim seems to hold true without RLS, but with RLS, it adds at least this inconsistent edge case. If this is acceptable, I’d suggest documenting this as a known limitation of RLS that doesn’t require different LIMIT/OFFSET values and different subsets to result in inconsistently ordered data - I’d suspect its due to the POLICY checks that occur with accessing that table.
I ran across this with some failing integration tests for a personal project. Adding RLS started to make some API calls return incorrect information for edge cases that worked previously without RLS.
—
Mike Brancato
| From | Date | Subject | |
|---|---|---|---|
| Next Message | BharatDB | 2025-11-12 05:53:10 | Re: BUG #19095: Test if function exit() is used fail when linked static |
| Previous Message | Christophe Pettus | 2025-11-11 22:10:23 | Re: RLS creates inaccurate limit and offset results |