[PATCH] Check snapshot argument of index_beginscan and family

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Sven Klemm <sven(at)timescale(dot)com>
Subject: [PATCH] Check snapshot argument of index_beginscan and family
Date: 2022-11-28 10:07:42
Message-ID: CAJ7c6TPxitD4vbKyP-mpmC1XwyHdPPqvjLzm+VpB88h8LGgneQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

A colleague of mine (cc'ed) reported that he was able to pass a NULL
snapshot to index_beginscan() and it even worked to a certain degree.

I took my toy extension [1] and replaced the argument with NULL as an
experiment:

```
eax=# CREATE EXTENSION experiment;
CREATE EXTENSION
eax=# SELECT phonebook_lookup_index('Alice');
phonebook_lookup_index
------------------------
-1
(1 row)

eax=# SELECT phonebook_insert('Bob', 456);
phonebook_insert
------------------
1
(1 row)

eax=# SELECT phonebook_lookup_index('Alice');
phonebook_lookup_index
------------------------
-1
(1 row)

eax=# SELECT phonebook_insert('Alice', 123);
phonebook_insert
------------------
2
(1 row)

eax=# SELECT phonebook_lookup_index('Alice');
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
```

So evidently it really works as long as the index doesn't find any
matching rows.

This could be really confusing for the extension authors so here is a
patch that adds corresponding Asserts().

[1]: https://github.com/afiskon/postgresql-extensions/tree/main/005-table-access

--
Best regards,
Aleksander Alekseev

Attachment Content-Type Size
v1-0001-Check-snapshot-argument-of-index_beginscan-and-fa.patch application/octet-stream 1.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2022-11-28 10:23:29 Re: [PATCH] Check snapshot argument of index_beginscan and family
Previous Message Sergey Shinderuk 2022-11-28 09:59:27 Re: Bug in row_number() optimization