CommitFest 2009-09, two weeks on
in [PgSql]
|
From: Tom Lane on 30 Sep 2009 16:52 Joe Conway <mail(a)joeconway.com> writes: > The issue is not so much technical as it is philosophical. > The patch basically forces all use of libpq by dblink to be asynchronous > (internally) so that a cancel can be sensed and passed down to the > remote side and everything cleaned up. Possibly the right thing to do, > but dblink already allows the use of async queries, and the current > synchronous method uses standard libpq calls. If all of this is really > necessary, doesn't every libpq client have the same issue? Well, only the ones that want to implement cancel and don't have access to the app's own signal handling functions. (Which suggests that a possible answer is to allow dblink to hook into the SIGINT catcher, but frankly hooks in that location scare me ...) I would argue that it's not necessarily a good idea at all: one of the typical uses for dblink is to fake "autonomous transactions", and in that application I don't think you *want* a cancel to propagate to the other session. If we did put this behavior into all dblink operations, we'd need a way to turn it off. Since dblink_cancel_query is already available, people who do want cancels to propagate have the ability to do that. I'm inclined to think that this is complexity we don't need. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Itagaki Takahiro on 30 Sep 2009 22:00 Joe Conway <mail(a)joeconway.com> wrote: > The patch basically forces all use of libpq by dblink to be asynchronous > (internally) so that a cancel can be sensed and passed down to the > remote side and everything cleaned up. Possibly the right thing to do, > but dblink already allows the use of async queries, and the current > synchronous method uses standard libpq calls. The point is *memory leak* in dblink when a query is canceled or become time-out. I think it is a bug, and my patch could fix it. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Itagaki Takahiro on 30 Sep 2009 22:11 Magnus Hagander <magnus(a)hagander.net> wrote: > I can certainly review the win32 encoding patch, but I was rather > hoping for some comments from others on if we're interested in a win32 > only solution, or if we want something more generic. Should we just go > with the win32-only one for now? Yes, because Windows is only platform that supports UTF-16 encoding natively. I believe my patch is the best solution for Windows even if we have another approach for other platforms. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 1 Oct 2009 07:48 On Thu, Oct 1, 2009 at 04:11, Itagaki Takahiro <itagaki.takahiro(a)oss.ntt.co.jp> wrote: > > Magnus Hagander <magnus(a)hagander.net> wrote: > >> I can certainly review the win32 encoding patch, but I was rather >> hoping for some comments from others on if we're interested in a win32 >> only solution, or if we want something more generic. Should we just go >> with the win32-only one for now? > > Yes, because Windows is only platform that supports UTF-16 encoding natively. > I believe my patch is the best solution for Windows even if we have another > approach for other platforms. Actually, I think a better argument is that since Windows will *never* accept UTF8 logging, and that's what most databases will be in, much of this patch will be required anyway. So I should probably review and get this part in while we think about other solutions *as well* for other platforms. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Michael Meskes on 1 Oct 2009 08:27
On Wed, Sep 30, 2009 at 12:34:23PM -0400, Tom Lane wrote: > qualified to review them. (I don't actually think we have anybody > except Michael who's really familiar with ecpg.) I'm afraid I'm simply not able to spend much time on this in the near future as I'm simply too busy atm. I spend some time on these the last time, but wasn't even able to see how Zoltan changed the points we mentioned back then, but I'm sure he has. As already noted the patches stack on each other. There doesn't seem to be a technical reason for this at least not for some of those dependencies. With the first patch changing the grammar file and thus taking quite some reviewing effort this slows things down even more because one needs more effort to review for instance the sqlda addition, although that one seems to be quite easy to review. All of this is written from the top of my head, so please bear with me if I missed any changes in the patches. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes(a)jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |