Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

To: Masahiko Sawada <sawada.mshk@gmail.com>

Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2017-12-13T07:30:48Z

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 →

Allow page lock to conflict among parallel group members.
- 3ba59ccc896e 13.0 landed
Allow relation extension lock to conflict among parallel group members.
- 85f6b49c2c53 13.0 landed
Add assert to ensure that page locks don't participate in deadlock cycle.
- 72e78d831ab5 13.0 landed
Assert that we don't acquire a heavyweight lock on another object after
- 15ef6ff4b985 13.0 landed
Fix unsafe usage of strerror(errno) within ereport().
- 81256cd05f07 11.0 cited

On 2017-12-13 16:02:45 +0900, Masahiko Sawada wrote:
> When we add extra blocks on a relation do we access to the disk? I
> guess we just call lseek and write and don't access to the disk. If so
> the performance degradation regression might not be much.

Usually changes in the file size require the filesystem to perform
metadata operations, which in turn requires journaling on most
FSs. Which'll often result in synchronous disk writes.

Greetings,

Andres Freund