Re: Speed up transaction completion faster after many relations are accessed in a transaction
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, "Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>, Andres Freund <andres@anarazel.de>, Simon Riggs <simon@2ndquadrant.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2019-09-25T21:08:05Z
Lists: pgsql-hackers
On 2019-Sep-03, Tsunakawa, Takayuki wrote: > From: Alvaro Herrera [mailto:alvherre@2ndquadrant.com] > > Hmm ... is this patch rejected, or is somebody still trying to get it to > > committable state? David, you're listed as committer. > > I don't think it's rejected. It would be a pity (mottainai) to refuse > this, because it provides significant speedup despite its simple > modification. I don't necessarily disagree with your argumentation, but Travis is complaining thusly: gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -Wall -Werror -I../../../../src/include -I/usr/include/x86_64-linux-gnu -D_GNU_SOURCE -c -o lock.o lock.c 1840lock.c:486:1: error: conflicting types for ‘TryShrinkLocalLockHash’ 1841 TryShrinkLocalLockHash(long numLocksHeld) 1842 ^ 1843lock.c:351:20: note: previous declaration of ‘TryShrinkLocalLockHash’ was here 1844 static inline void TryShrinkLocalLockHash(void); 1845 ^ 1846<builtin>: recipe for target 'lock.o' failed Please fix. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Reorder LOCALLOCK structure members to compact the size
- 28988a84cf19 12.0 landed
-
Be more careful to not lose sync in the FE/BE protocol.
- 2b3a8b20c2da 9.5.0 cited