Обсуждение: pgsql: Fix memory leak in PLySequence_ToJsonbValue()
Fix memory leak in PLySequence_ToJsonbValue() PyObject returned from PySequence_GetItem() is not released. Similar code in PLyMapping_ToJsonbValue() is correct, becauseaccording to Python documentation PyList_GetItem() and PyTuple_GetItem() return a borrowed reference while PySequence_GetItem() returns new reference. contrib/jsonb_plpython is new in PostgreSQL 11, no backpatch is needed. Author: Nikita Glukhov Discussion: https://postgr.es/m/6001af16-b242-2527-bc7e-84b8a959163b%40postgrespro.ru Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/dad8bed04ab98ada84ecd58ace6f59839aa161c4 Modified Files -------------- contrib/jsonb_plpython/jsonb_plpython.c | 2 ++ 1 file changed, 2 insertions(+)
On Fri, Jun 15, 2018 at 3:07 PM Alexander Korotkov <akorotkov@postgresql.org> wrote: > PyObject returned from PySequence_GetItem() is not released. Similar code in PLyMapping_ToJsonbValue() is correct, becauseaccording to Python documentation I'm sorry for misformatting commit message. I'll be more careful about that in future. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> I'm sorry for misformatting commit message. I'll be more careful
> about that in future.
Maybe I just lack caffeine, but I don't see anything especially
wrong with what you wrote?
regards, tom lane
On Fri, Jun 15, 2018 at 4:46 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Alexander Korotkov <a.korotkov@postgrespro.ru> writes: > > I'm sorry for misformatting commit message. I'll be more careful > > about that in future. > > Maybe I just lack caffeine, but I don't see anything especially > wrong with what you wrote? It doesn't contain something particular wrong, but it's just badly formatted. As I can see, we're keeping lines in commit messages no longer than 80 characters when possible. I've commit message with 158 characters line for no reason. It was just because I wrote this commit message with word wrapping enabled. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> On Fri, Jun 15, 2018 at 4:46 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Maybe I just lack caffeine, but I don't see anything especially
>> wrong with what you wrote?
> It doesn't contain something particular wrong, but it's just badly
> formatted. As I can see, we're keeping lines in commit messages no
> longer than 80 characters when possible. I've commit message with 158
> characters line for no reason. It was just because I wrote this
> commit message with word wrapping enabled.
Ah, it wrapped in my mail app so I didn't notice.
FWIW, I actually try to keep commit log lines to 75 characters, because
that's what displays nicely in "git log". Links such as Discussion:
tags tend to run over, but there's little to be done about that as long
as gmail insists on such ridiculously long message IDs :-(
regards, tom lane
On Fri, Jun 15, 2018 at 5:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alexander Korotkov <a.korotkov@postgrespro.ru> writes: > > On Fri, Jun 15, 2018 at 4:46 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Maybe I just lack caffeine, but I don't see anything especially > >> wrong with what you wrote? > > > It doesn't contain something particular wrong, but it's just badly > > formatted. As I can see, we're keeping lines in commit messages no > > longer than 80 characters when possible. I've commit message with 158 > > characters line for no reason. It was just because I wrote this > > commit message with word wrapping enabled. > > Ah, it wrapped in my mail app so I didn't notice. > > FWIW, I actually try to keep commit log lines to 75 characters, because > that's what displays nicely in "git log". Ok, thank you for the information. I'll also try to keep it to 75 characters. > Links such as Discussion: > tags tend to run over, but there's little to be done about that as long > as gmail insists on such ridiculously long message IDs :-( Agree, not much can be done unless we invent some URL shortener for mailing lists archives. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
On Fri, Jun 15, 2018 at 05:43:15PM +0300, Alexander Korotkov wrote: > On Fri, Jun 15, 2018 at 5:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Alexander Korotkov <a.korotkov@postgrespro.ru> writes: > > > On Fri, Jun 15, 2018 at 4:46 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >> Maybe I just lack caffeine, but I don't see anything especially > > >> wrong with what you wrote? > > > > > It doesn't contain something particular wrong, but it's just badly > > > formatted. As I can see, we're keeping lines in commit messages no > > > longer than 80 characters when possible. I've commit message with 158 > > > characters line for no reason. It was just because I wrote this > > > commit message with word wrapping enabled. > > > > Ah, it wrapped in my mail app so I didn't notice. > > > > FWIW, I actually try to keep commit log lines to 75 characters, because > > that's what displays nicely in "git log". > > Ok, thank you for the information. I'll also try to keep it to 75 characters. > > > Links such as Discussion: > > tags tend to run over, but there's little to be done about that as long > > as gmail insists on such ridiculously long message IDs :-( > > Agree, not much can be done unless we invent some URL shortener for > mailing lists archives. Perhaps we could acquire the short.pg domain and run it off that. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes:
> On Fri, Jun 15, 2018 at 05:43:15PM +0300, Alexander Korotkov wrote:
>> On Fri, Jun 15, 2018 at 5:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Links such as Discussion:
>>> tags tend to run over, but there's little to be done about that as long
>>> as gmail insists on such ridiculously long message IDs :-(
>> Agree, not much can be done unless we invent some URL shortener for
>> mailing lists archives.
> Perhaps we could acquire the short.pg domain and run it off that.
We're already using postgr.es, so it's not going to get much shorter
just from mucking with the domain part. We'd need to set up some
abbreviation for the message-ID part, which I'm not for. It would
add more overhead to writing commit log entries (to create or find
out the right abbreviation), and it would make it harder to go back
and forth between the commit log and local mail archives, and it'd
be yet another Thing We Have To Keep Running Forever.
regards, tom lane
On 6/15/18 10:43, Alexander Korotkov wrote: >> FWIW, I actually try to keep commit log lines to 75 characters, because >> that's what displays nicely in "git log". > Ok, thank you for the information. I'll also try to keep it to 75 characters. This popular blog post recommends 72 characters and has some other guidelines as well: https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Jun 15, 2018 at 10:25:27AM -0400, Tom Lane wrote:
> Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
>> It doesn't contain something particular wrong, but it's just badly
>> formatted. As I can see, we're keeping lines in commit messages no
>> longer than 80 characters when possible. I've commit message with 158
>> characters line for no reason. It was just because I wrote this
>> commit message with word wrapping enabled.
>
> Ah, it wrapped in my mail app so I didn't notice.
>
> FWIW, I actually try to keep commit log lines to 75 characters, because
> that's what displays nicely in "git log". Links such as Discussion:
> tags tend to run over, but there's little to be done about that as long
> as gmail insists on such ridiculously long message IDs :-(
Here is a trick I have learnt to use with my emacs configuration for
commit messages:
;; Git settings: auto-fill-mode for commits with dedicated mode.
(define-derived-mode git-commit-mode text-mode "GitCommit"
"Mode for writing git commit files."
(setq fill-column 72)
(auto-fill-mode +1)
(set (make-local-variable 'comment-start-skip) "#.*$"))
(add-to-list 'auto-mode-alist
'("/\\(?:COMMIT\\|NOTES\\|TAG\\|PULLREQ\\)_EDITMSG\\'"
. git-commit-mode))
This forces any commit messages written to be within 72 characters, so
you have one thing less to think about. Just be careful to keep
discussion links into one line.
--
Michael
Вложения
On Fri, Jun 15, 2018 at 11:01:26AM -0400, Tom Lane wrote: > David Fetter <david@fetter.org> writes: >> Perhaps we could acquire the short.pg domain and run it off that. > > We're already using postgr.es, so it's not going to get much shorter > just from mucking with the domain part. We'd need to set up some > abbreviation for the message-ID part, which I'm not for. It would > add more overhead to writing commit log entries (to create or find > out the right abbreviation), and it would make it harder to go back > and forth between the commit log and local mail archives, and it'd > be yet another Thing We Have To Keep Running Forever. I am also -1 for any kind of message-id shorteners in the commit messages. I cannot say for others, but sometimes I work offline with only the git history and a cold copy of Postgres archives, meaning that depending on an external source to get the raw message IDs would break that. -- Michael
Вложения
On 17.06.18 11:02, Michael Paquier wrote: > Here is a trick I have learnt to use with my emacs configuration for > commit messages: > ;; Git settings: auto-fill-mode for commits with dedicated mode. > (define-derived-mode git-commit-mode text-mode "GitCommit" A git-commit-mode already exists. It used to be a separate module, but now it's part of magit. So if you install magit, you get that automatically. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services