Bruce Momjian wrote:
> On Thu, Jan 24, 2013 at 08:43:37PM -0300, Alvaro Herrera wrote:
>> Bruce Momjian escribió:
>>> On Tue, Sep 4, 2012 at 02:01:54PM -0400, Bruce Momjian wrote:
On Tue, Sep 4, 2012 at 12:49:40PM -0500, Kevin Grittner wrote:
> Bruce Momjian wrote:
>> On Tue, Sep 4, 2
On 25/01/13 13:49, Tom Lane wrote:
Mark Kirkwood writes:
On 25/01/13 13:06, Tom Lane wrote:
Unless libR can be coerced into not screwing up our signal handlers,
I'd say that PL/R is broken beyond repair. That would be unfortunate.
It looks like Joe has run into something similar with libR
Mark Kirkwood writes:
> On 25/01/13 13:06, Tom Lane wrote:
>> Unless libR can be coerced into not screwing up our signal handlers,
>> I'd say that PL/R is broken beyond repair. That would be unfortunate.
> It looks like Joe has run into something similar with libR stealing
> SIGINT, he reinstal
On 25/01/13 13:06, Tom Lane wrote:
Mark Kirkwood writes:
If I have done this right, then this is the trace for the 1st message...
from my wandering through the calls here it looks like a normal commit,
and something goes a bit weird as SI messages are being processed...
Seems like the critica
On 2013-01-24 19:06:21 -0500, Tom Lane wrote:
> Mark Kirkwood writes:
> > If I have done this right, then this is the trace for the 1st message...
> > from my wandering through the calls here it looks like a normal commit,
> > and something goes a bit weird as SI messages are being processed...
Mark Kirkwood writes:
> If I have done this right, then this is the trace for the 1st message...
> from my wandering through the calls here it looks like a normal commit,
> and something goes a bit weird as SI messages are being processed...
Seems like the critical bit is here:
> #11 0x7f4
On 2012-04-09 15:37:09 -0300, Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of lun abr 09 15:13:10 -0300 2012:
> > On Mon, Apr 09, 2012 at 10:10:34AM -0400, Robert Haas wrote:
>
> > > This complaint appears to be accurate. I think we should go ahead and
> > > remove that mentio
On Thu, Jan 24, 2013 at 08:43:37PM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
> >
> > On Tue, Sep 4, 2012 at 02:01:54PM -0400, Bruce Momjian wrote:
> > > On Tue, Sep 4, 2012 at 12:49:40PM -0500, Kevin Grittner wrote:
> > > > Bruce Momjian wrote:
> > > > > On Tue, Sep 4, 2012 at 12:
Bruce Momjian escribió:
>
> On Tue, Sep 4, 2012 at 02:01:54PM -0400, Bruce Momjian wrote:
> > On Tue, Sep 4, 2012 at 12:49:40PM -0500, Kevin Grittner wrote:
> > > Bruce Momjian wrote:
> > > > On Tue, Sep 4, 2012 at 12:11:53PM -0500, Kevin Grittner wrote:
> > >
> > > >> What do you think woul
On 25/01/13 10:36, Tom Lane wrote:
Mark Kirkwood writes:
Doh! Yes of course, sorry for the noise. I was busy thinking that the
issue could be tied up with sinval and plan caching (if there is any) in
plr and got excited about seeing something in gdb...and didn't think
carefully about why what I
On Tue, Sep 4, 2012 at 02:01:54PM -0400, Bruce Momjian wrote:
> On Tue, Sep 4, 2012 at 12:49:40PM -0500, Kevin Grittner wrote:
> > Bruce Momjian wrote:
> > > On Tue, Sep 4, 2012 at 12:11:53PM -0500, Kevin Grittner wrote:
> >
> > >> What do you think would be the right thing to do with it at t
On Thu, Jan 24, 2013 at 04:51:04PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Would someone make the doc change outlined above? Thanks.
>
> Sorry, I'd nearly forgotten about this issue. Will see about fixing the
> docs. (It looks like some of the comments in execMain.c could use work
>
Bruce Momjian writes:
> Would someone make the doc change outlined above? Thanks.
Sorry, I'd nearly forgotten about this issue. Will see about fixing the
docs. (It looks like some of the comments in execMain.c could use work
too.)
regards, tom lane
--
Sent via pgsql
On 01/24/2013 10:36 PM, Tom Lane wrote:
> Mark Kirkwood writes:
>> Doh! Yes of course, sorry for the noise. I was busy thinking that the
>> issue could be tied up with sinval and plan caching (if there is any) in
>> plr and got excited about seeing something in gdb...and didn't think
>> careful
Mark Kirkwood writes:
> Doh! Yes of course, sorry for the noise. I was busy thinking that the
> issue could be tied up with sinval and plan caching (if there is any) in
> plr and got excited about seeing something in gdb...and didn't think
> carefully about why what I was seeing was not a bug a
On 25/01/13 10:18, Tom Lane wrote:
Mark Kirkwood writes:
Sorry - the others are getting a SIGUSR1 too (just was not so obvious).
SIGUSR1 is not a bug, it's expected cross-session signaling behavior.
regards, tom lane
Doh! Yes of course, sorry for the noise. I was
Mark Kirkwood writes:
> Sorry - the others are getting a SIGUSR1 too (just was not so obvious).
SIGUSR1 is not a bug, it's expected cross-session signaling behavior.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to y
On 25/01/13 10:12, Mark Kirkwood wrote:
On 25/01/13 04:14, Joe Conway wrote:
On 01/24/2013 05:21 AM, Mark Kirkwood wrote:
I admit - it sounds unlikely. However a simple scenario (attached) gives
rise to:
This is the wrong place for the bug report on PL/R I think, but I'll
take a look.
Joe
On 25/01/13 04:14, Joe Conway wrote:
On 01/24/2013 05:21 AM, Mark Kirkwood wrote:
I admit - it sounds unlikely. However a simple scenario (attached) gives
rise to:
This is the wrong place for the bug report on PL/R I think, but I'll
take a look.
Joe
FYI - 8.4 shows the same behaviour as 9
On Wed, Aug 29, 2012 at 01:13:51PM +, Rajeev rastogi wrote:
>
> From: pgsql-bugs-ow...@postgresql.org [pgsql-bugs-ow...@postgresql.org] on
> behalf of Bruce Momjian [br...@momjian.us]
> Sent: Wednesday, August 29, 2012 8:46 AM
> To: Tom Lane
> Cc: Rober
On 01/24/2013 08:01 PM, Mark Kirkwood wrote:
> Ah right - sorry, I did a quick look for a mail list on the plr web site
> and didn't spot anything.
No problem. It is plr-general on pgfoundry:
http://pgfoundry.org/mail/?group_id=1000247
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Lin
Ah right - sorry, I did a quick look for a mail list on the plr web site
and didn't spot anything.
Thanks
Mark
On 25/01/13 04:14, Joe Conway wrote:
On 01/24/2013 05:21 AM, Mark Kirkwood wrote:
I admit - it sounds unlikely. However a simple scenario (attached) gives
rise to:
This is the wro
Andres Freund writes:
> Tom, any other committer: I am happy to provide a <= 9.1 version of the
> patch because plpython has been noticeably restructured in 9.1=>9.2, but
> I am not sure if that helps you at all.
We need to back-patch to any branch where this is broken. If the patch
would change
On 2013-01-24 11:40:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
> > ISTM the caching code for plpythonu trigger functions has been broken
> > for some time. The bug seem to be that PLy_procedure_get looks up the
> > function in a separ
Andres Freund writes:
> On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
> ISTM the caching code for plpythonu trigger functions has been broken
> for some time. The bug seem to be that PLy_procedure_get looks up the
> function in a separate cache for trigger functions (PLy_trigger_cache)
> bu
Quoting Devrim GÜNDÜZ at 23/01/2013-21:11:09(+0200):
>
> Hi,
>
> On Tue, 2013-01-22 at 17:13 +, georgi-georgiev-pg...@japannext.co.jp
> wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference: 7823
> > Logged by: Georgi Georgiev
> > Email address:
On Wed, Jan 23, 2013 at 5:11 PM, Josh Kupershmidt wrote:
> Note, I believe that explanation is a bit lacking, i.e a plain.
> \d
> is quite different from
> \d *
> both in the format of the output, and that the latter displays
> pg_catalog tables. At any rate, you can use:
> \dtv *.*
> for al
On 01/24/2013 05:21 AM, Mark Kirkwood wrote:
> I admit - it sounds unlikely. However a simple scenario (attached) gives
> rise to:
This is the wrong place for the bug report on PL/R I think, but I'll
take a look.
Joe
> WARNING: AbortTransaction while in COMMIT state
> PANIC: cannot abort tran
On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
> I've found a bug in plpythonu resulting in a "cache lookup" failure.
> Here's the SQL to reproduce (thanks Andres):
>
> CREATE EXTENSION plpythonu;
> CREATE OR REPLACE FUNCTION t() RETURNS trigger AS 'pass' LANGUAGE
> 'plpythonu';
> CREATE
I've found a bug in plpythonu resulting in a "cache lookup" failure.
Here's the SQL to reproduce (thanks Andres):
CREATE EXTENSION plpythonu;
CREATE OR REPLACE FUNCTION t() RETURNS trigger AS 'pass' LANGUAGE 'plpythonu';
CREATE TABLE a();
CREATE TABLE b();
CREATE TRIGGER check_quota AFTER INS
Jeff Janes escribió:
> Since back-branch releases are coming up, I think fe3b5eb08 and it's
> analogues in all branches should be reverted.
Yes, I have this on my list of things to do before the next minor
release.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Developm
31 matches
Mail list logo
