From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Subject: | Re: HASH_BLOBS hazards (was Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions) |
Date: | 2020-12-14 10:28:18 |
Message-ID: | e7400bd0-1aa3-1c1a-6d81-7dbffb51269f@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-12-13 17:49, Tom Lane wrote:
> 2. Don't allow a default: invent a new HASH_STRING flag, and
> require that hash_create() calls specify exactly one of HASH_BLOBS,
> HASH_STRING, or HASH_FUNCTION. This doesn't completely fix the
> hazard of mindless-copy-and-paste, but I think it might make it
> a little more obvious. Still requires touching a lot of calls.
I think this sounds best, and also expand the documentation of these
flags a bit.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-12-14 10:32:40 | Re: HASH_BLOBS hazards (was Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions) |
Previous Message | Amit Kapila | 2020-12-14 09:46:08 | Re: Misleading comment in prologue of ReorderBufferQueueMessage |