(2013/06/12 1:26), Andres Freund wrote:
On 2013-06-11 19:20:57 +0300, Heikki Linnakangas wrote:
On 11.06.2013 19:04, Joshua Berry wrote:
Hiroshi Inoue has developed the attached patch to correct the issue that
was reported. More of the dialogue can be found in the pgsql-odbc list.
I tried to
Hiroshi Inoue writes:
> OK I made a test C program which reproduces the crash.
> The program uses libpq and a hack.
Oh, thank you, I was just about to go spend an hour doing that ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To m
Hiroshi Inoue writes:
> (2013/06/12 1:26), Andres Freund wrote:
>> I'd guess creating a SQL level WITH HOLD cursor and then fetching that
>> via the extended protocol, outside the transaction, should do the trick.
> OK I made a test C program which reproduces the crash.
> The program uses libpq a
Hiroshi, Tom, and Andres,
On Thu, Jun 13, 2013 at 12:16 PM, Tom Lane wrote:
> Hiroshi Inoue writes:
> > OK I made a test C program which reproduces the crash.
> > The program uses libpq and a hack.
>
> I've committed a fix for this. Thanks again for the test case.
>
Many thanks for your time
The following bug has been logged on the website:
Bug reference: 8228
Logged by: David Johnston
Email address: david.g.johns...@gmail.com
PostgreSQL version: 9.0.13
Operating system: Ubuntu Linux 10.04
Description:
The following query results in "SQL Error: ERROR: set
david.g.johns...@gmail.com writes:
> The following query results in "SQL Error: ERROR: set-valued function called
> in context that cannot accept a set"
> SELECT *, CASE WHEN id = 2 THEN
> (regexp_matches(input_string,'^0*([1-9]\d+)$'))[1] ELSE input_string
> END::varchar(30) AS o_l2_a
> FROM (
>
The following bug has been logged on the website:
Bug reference: 8229
Logged by: Matthew Schumacher
Email address: mat...@aptalaska.com
PostgreSQL version: 9.2.4
Operating system: Slackware Linux 14.0 x86_64
Description:
I have a slackware 14.0 host, and have added ns
David Johnston writes:
> The issue with the regexp_matches call generally is that absence of a "g"
> modifier means that the set-returning function will never return a set. It
> would seem to make more sense to not make that a modifier but instead have
> one function defined to return a set (i.e.
On Thu, Jun 13, 2013 at 4:02 PM, Tom Lane wrote:
> david.g.johns...@gmail.com writes:
> > The following query results in "SQL Error: ERROR: set-valued function
> called
> > in context that cannot accept a set"
>
> > SELECT *, CASE WHEN id = 2 THEN
> > (regexp_matches(input_string,'^0*([1-9]\d+)$'
j...@pgexperts.com writes:
> What happens is that we change various logging options in postgresql.conf,
> then reload, and every so often, the settings don't seem to take effect even
> though they are logged as being changed.
FWIW, the "parameter changed" messages are logged when the postmaster
pr
On Jun 13, 2013, at 4:50 PM, Tom Lane wrote:
> j...@pgexperts.com writes:
>> What happens is that we change various logging options in postgresql.conf,
>> then reload, and every so often, the settings don't seem to take effect even
>> though they are logged as being changed.
>
> FWIW, the "para
Jeff Frost writes:
> On Jun 13, 2013, at 4:50 PM, Tom Lane wrote:
>> ... So one theory about this would be that those processes
>> aren't absorbing the GUC updates, perhaps because the SIGHUP signals the
>> postmaster should be sending them are getting lost.
> Interestingly, it will often pick
Tom Lane wrote:
> j...@pgexperts.com writes:
> > What happens is that we change various logging options in postgresql.conf,
> > then reload, and every so often, the settings don't seem to take effect even
> > though they are logged as being changed.
>
> FWIW, the "parameter changed" messages are l
On Jun 13, 2013, at 5:16 PM, Tom Lane wrote:
> Jeff Frost writes:
>> On Jun 13, 2013, at 4:50 PM, Tom Lane wrote:
>>> ... So one theory about this would be that those processes
>>> aren't absorbing the GUC updates, perhaps because the SIGHUP signals the
>>> postmaster should be sending them a
Jeff Frost writes:
> What I don't understand is the new log file being created from the new
> log_filename setting but then nothing being logged into it. Is it the
> postmaster which creates that file? I would've thought it would be
> the logger process?
Hm, I hadn't focused on that --- that *i
On Jun 13, 2013, at 7:48 PM, Tom Lane wrote:
> Jeff Frost writes:
>> What I don't understand is the new log file being created from the new
>> log_filename setting but then nothing being logged into it. Is it the
>> postmaster which creates that file? I would've thought it would be
>> the log
16 matches
Mail list logo
