Re: pgsql: Add kqueue(2) support to the WaitEventSet API.

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Thomas Munro <tmunro(at)postgresql(dot)org>
Cc: pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
Date: 2020-03-16 11:54:43
Message-ID: CAPpHfdu4XVQxhqyO697U5idP8w8=MrPo=cWah+4DFhmAu018dA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wed, Feb 5, 2020 at 7:59 AM Thomas Munro <tmunro(at)postgresql(dot)org> wrote:
> Add kqueue(2) support to the WaitEventSet API.
>
> Use kevent(2) to wait for events on the BSD family of operating
> systems and macOS. This is similar to the epoll(2) support added
> for Linux by commit 98a64d0bd.

I'm not sure if it was already reported in this thread (it seems to be
not at the first glance), but I've discovered following issue on macos
10.13.6. If backend is under lldb and does XactLockTableWait(), then
it does proc_exit(1).

The full reproduction case is following.

s1# create table test (id serial primary key, value int);
s1# insert into test values (1,1);
s1# begin;
s1# update test set value = value + 1 where id = 1;

lldb attached to s2: b proc_exit
s2# update test set value = value + 1 where id = 1;

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
* frame #0: 0x000000010f9a7f5b postgres`proc_exit(code=1) at ipc.c:107
frame #1: 0x000000010f9aa3b9
postgres`WaitEventSetWaitBlock(set=0x00007fabdd847c90, cur_timeout=-1,
occurred_events=0x00007ffee0796c10, nevents=1) at latch.c:1427
frame #2: 0x000000010f9a9a43
postgres`WaitEventSetWait(set=0x00007fabdd847c90, timeout=-1,
occurred_events=0x00007ffee0796c10, nevents=1,
wait_event_info=50331652) at latch.c:1237
frame #3: 0x000000010f9a93b5
postgres`WaitLatchOrSocket(latch=0x00000001197eacc4, wakeEvents=33,
sock=-1, timeout=-1, wait_event_info=50331652) at latch.c:428
frame #4: 0x000000010f9a91c1
postgres`WaitLatch(latch=0x00000001197eacc4, wakeEvents=33, timeout=0,
wait_event_info=50331652) at latch.c:368
frame #5: 0x000000010f9d65b6
postgres`ProcSleep(locallock=0x00007fabdd01d5d8,
lockMethodTable=0x000000010fdb5cf8) at proc.c:1286
frame #6: 0x000000010f9c2af9
postgres`WaitOnLock(locallock=0x00007fabdd01d5d8,
owner=0x00007fabdf0056d0) at lock.c:1766
frame #7: 0x000000010f9c13a1
postgres`LockAcquireExtended(locktag=0x00007ffee0797140, lockmode=5,
sessionLock=false, dontWait=false, reportMemoryError=true,
locallockp=0x0000000000000000) at lock.c:1048
frame #8: 0x000000010f9c08b5
postgres`LockAcquire(locktag=0x00007ffee0797140, lockmode=5,
sessionLock=false, dontWait=false) at lock.c:713
frame #9: 0x000000010f9bef32 postgres`XactLockTableWait(xid=511,
rel=0x000000011031e148, ctid=0x00007ffee0797394, oper=XLTW_Update) at
lmgr.c:658
frame #10: 0x000000010f4e9cab
postgres`heap_update(relation=0x000000011031e148,
otid=0x00007ffee0797818, newtup=0x00007fabdd847a48, cid=0,
crosscheck=0x0000000000000000, wait=true, tmfd=0x00007ffee07976f0,
lockmode=0x00007ffee07976d8) at heapam.c:3239
frame #11: 0x000000010f4f9353
postgres`heapam_tuple_update(relation=0x000000011031e148,
otid=0x00007ffee0797818, slot=0x00007fabdc828558, cid=0,
snapshot=0x00007fabdc818170, crosscheck=0x0000000000000000, wait=true,
tmfd=0x00007ffee07976f0, lockmode=0x00007ffee07976d8,
update_indexes=0x00007ffee07976d6) at heapam_handler.c:326
frame #12: 0x000000010f7ba73d
postgres`table_tuple_update(rel=0x000000011031e148,
otid=0x00007ffee0797818, slot=0x00007fabdc828558, cid=0,
snapshot=0x00007fabdc818170, crosscheck=0x0000000000000000, wait=true,
tmfd=0x00007ffee07976f0, lockmode=0x00007ffee07976d8,
update_indexes=0x00007ffee07976d6) at tableam.h:1293
frame #13: 0x000000010f7b8952
postgres`ExecUpdate(mtstate=0x00007fabdc826ca8,
tupleid=0x00007ffee0797818, oldtuple=0x0000000000000000,
slot=0x00007fabdc828558, planSlot=0x00007fabdc828408,
epqstate=0x00007fabdc826da0, estate=0x00007fabdc826920,
canSetTag=true) at nodeModifyTable.c:1336
frame #14: 0x000000010f7b6d5a
postgres`ExecModifyTable(pstate=0x00007fabdc826ca8) at
nodeModifyTable.c:2246
frame #15: 0x000000010f780e82
postgres`ExecProcNodeFirst(node=0x00007fabdc826ca8) at
execProcnode.c:444
frame #16: 0x000000010f779332
postgres`ExecProcNode(node=0x00007fabdc826ca8) at executor.h:245
frame #17: 0x000000010f7751b1
postgres`ExecutePlan(estate=0x00007fabdc826920,
planstate=0x00007fabdc826ca8, use_parallel_mode=false,
operation=CMD_UPDATE, sendTuples=false, numberTuples=0,
direction=ForwardScanDirection, dest=0x00007fabdd843840,
execute_once=true) at execMain.c:1646
frame #18: 0x000000010f775072
postgres`standard_ExecutorRun(queryDesc=0x00007fabdd81ff20,
direction=ForwardScanDirection, count=0, execute_once=true) at
execMain.c:364
frame #19: 0x000000010f774e42
postgres`ExecutorRun(queryDesc=0x00007fabdd81ff20,
direction=ForwardScanDirection, count=0, execute_once=true) at
execMain.c:308
frame #20: 0x000000010f9eb63e
postgres`ProcessQuery(plan=0x00007fabdd8447a8, sourceText="update test
set value = value + 1 where id = 1;", params=0x0000000000000000,
queryEnv=0x0000000000000000, dest=0x00007fabdd843840,
qc=0x00007ffee0797d70) at pquery.c:160
frame #21: 0x000000010f9ea71d
postgres`PortalRunMulti(portal=0x00007fabdd823720, isTopLevel=true,
setHoldSnapshot=false, dest=0x00007fabdd843840,
altdest=0x00007fabdd843840, qc=0x00007ffee0797d70) at pquery.c:1265
frame #22: 0x000000010f9e9d92
postgres`PortalRun(portal=0x00007fabdd823720,
count=9223372036854775807, isTopLevel=true, run_once=true,
dest=0x00007fabdd843840, altdest=0x00007fabdd843840,
qc=0x00007ffee0797d70) at pquery.c:779
frame #23: 0x000000010f9e5279
postgres`exec_simple_query(query_string="update test set value = value
+ 1 where id = 1;") at postgres.c:1236
frame #24: 0x000000010f9e43b8 postgres`PostgresMain(argc=1,
argv=0x00007fabdd01fe78, dbname="postgres", username="smagen") at
postgres.c:4295
frame #25: 0x000000010f9147a0
postgres`BackendRun(port=0x00007fabde000320) at postmaster.c:4510
frame #26: 0x000000010f913b9a
postgres`BackendStartup(port=0x00007fabde000320) at postmaster.c:4202
frame #27: 0x000000010f912aea postgres`ServerLoop at postmaster.c:1727
frame #28: 0x000000010f9104fa postgres`PostmasterMain(argc=3,
argv=0x00007fabdbd009b0) at postmaster.c:1400
frame #29: 0x000000010f7fae19 postgres`main(argc=3,
argv=0x00007fabdbd009b0) at main.c:210
frame #30: 0x00007fff69069015 libdyld.dylib`start + 1

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Geoghegan 2020-03-16 19:00:42 pgsql: nbtree: Pass down MAXALIGN()'d itemsz for new item.
Previous Message Thomas Munro 2020-03-16 04:24:25 pgsql: Simplify the effective_io_concurrency setting.

Browse pgsql-hackers by date

  From Date Subject
Next Message Asim R P 2020-03-16 12:00:00 Re: Replication & recovery_min_apply_delay
Previous Message Hugh McMaster 2020-03-16 11:49:05 Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library