Horton

Re: SQL Property Graph Queries (SQL/PGQ)

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

View thread
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: Junwang Zhao <zhjwpku@gmail.com>
Cc: Vik Fearing <vik@postgresfriends.org>, Ajay Pal <ajay.pal.k@gmail.com>, Imran Zaheer <imran.zhir@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-11T07:21:40Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix some typos and make small stylistic improvements

  2. Cleanup users and roles in graph_table_rls test

  3. Dump labels in reproducible order

  4. SQL Property Graph Queries (SQL/PGQ)

  5. Factor out constructSetOpTargetlist() from transformSetOperationTree()

  6. Sort out table_open vs. relation_open in rewriter

  7. Rename grammar nonterminal to simplify reuse

  8. Make ecpg parse.pl more robust with braces

  9. Don't lock partitions pruned by initial pruning

  10. Remove pg_regex_collation

  11. Use auxv to check for CRC32 instructions on ARM.

  12. Fix inappropriate uses of atol()

  13. Remove unnecessary array object_classes[] in dependency.c

Attachments

Hi Junwang,

On Wed, Feb 26, 2025 at 8:04 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
.
>
> I added a trivial fix(v12-0014) that called table_open/table_close in
> rewriteGraphTable, it now passed the regression test and cirrus ci test,
> but I'm not sure it's the correct fix.
>
> I hope Ashutosh can chime in and take a look at this problem.

Looks like the first patch has grown some conflicts. Here's set of
rebased patches. There are two main things missing from this patchset

1. Junwang's patches - Extremely sorry, didn't get time to include
your patches. Junwang, you may want to post whole patchset rebased on
attached patch set. I hope to review and incorporate your patches some
time soon.

2. Following Assertion is failing, the assertion was added recently.
TRAP: failed Assert("IsParallelWorker() ||
CheckRelationOidLockedByMe(rte->relid, AccessShareLock, true)"), File:
"../../coderoot/pg/src/backend/executor/execMain.c", Line: 695, PID:
303994
postgres: ashutosh regression [local]
SELECT(ExceptionalCondition+0xbe)[0x5c838c5d7114]
postgres: ashutosh regression [local]
SELECT(ExecCheckPermissions+0xf8)[0x5c838c11fb9c]
postgres: ashutosh regression [local] SELECT(+0x38223f)[0x5c838c12023f]
postgres: ashutosh regression [local]
SELECT(standard_ExecutorStart+0x2f8)[0x5c838c11f223]
postgres: ashutosh regression [local] SELECT(ExecutorStart+0x69)[0x5c838c11ef22]
postgres: ashutosh regression [local] SELECT(PortalStart+0x368)[0x5c838c3d991a]
postgres: ashutosh regression [local] SELECT(+0x63458e)[0x5c838c3d258e]
postgres: ashutosh regression [local] SELECT(PostgresMain+0x9eb)[0x5c838c3d7cf0]
postgres: ashutosh regression [local] SELECT(+0x630178)[0x5c838c3ce178]
postgres: ashutosh regression [local]
SELECT(postmaster_child_launch+0x137)[0x5c838c2da677]
postgres: ashutosh regression [local] SELECT(+0x5431b4)[0x5c838c2e11b4]
postgres: ashutosh regression [local] SELECT(+0x54076a)[0x5c838c2de76a]
postgres: ashutosh regression [local]
SELECT(PostmasterMain+0x15f8)[0x5c838c2de04d]
postgres: ashutosh regression [local] SELECT(main+0x3a1)[0x5c838c1b12be]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7eda9ea29d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7eda9ea29e40]
postgres: ashutosh regression [local] SELECT(_start+0x25)[0x5c838be7c025]
2025-03-11 11:40:01.696 IST postmaster[303081] LOG: client backend
(PID 303994) was terminated by signal 6: Aborted
2025-03-11 11:40:01.696 IST postmaster[303081] DETAIL: Failed process
was running: select * from atpgv1;
I tried to investigate the Assertion, it's failing for property graph
RTE which is turned into subquery RTE. It has the right lock mode set,
but I haven't been able to figure out where the lock is supposed to be
taken or where it's released. If we just prepare the failing query and
execute the prepared statement, it does not trip the assertion. Will
investigate it more.



-- 
Best Wishes,
Ashutosh Bapat