Re: [HACKERS] 64-bit queryId?
От | Julien Rouhaud |
---|---|
Тема | Re: [HACKERS] 64-bit queryId? |
Дата | |
Msg-id | CAOBaU_Z4GH-t3waw4Fb50ij3A=VsfnHq9_XmqBD=7_vjC9NEHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] 64-bit queryId? (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] 64-bit queryId?
|
Список | pgsql-hackers |
On Thu, Oct 19, 2017 at 1:08 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Thu, Oct 19, 2017 at 4:12 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Wed, Oct 18, 2017 at 9:20 AM, Julien Rouhaud <rjuju123@gmail.com> wrote: >>> WIth current pgssHashKey definition, there shouldn't be padding bits, >>> so it should be safe. But I wonder if adding an explicit memset() of >>> the key in pgss_store() could avoid extension authors to have >>> duplicate entries if they rely on this code, or prevent future issue >>> in the unlikely case of adding other fields to pgssHashKey. >> >> I guess we should probably add additional comment to the definition of >> pgssHashKey warning of the danger. I'm OK with adding a memset if >> somebody can promise me it will get optimized away by all reasonably >> commonly-used compilers, but I'm not that keen on adding more cycles >> to protect against a hypothetical danger. > > A comment is an adapted answer for me too. I agree, and I'm perfectly fine with adding a comment around pgssHashKey. PFA a patch to warn about the danger. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: