On ons, 2010-06-23 at 07:17 -0400, Robert Haas wrote:
> I can reproduce this, here. The problem seems to be that plpython
> only build either plpython2.so or plython3.so, but both languages
> expect a call handler called plython_call_handler. So once we load
> the shared library for one language,
Robert Haas writes:
> On Thu, Jun 24, 2010 at 1:38 PM, Simon Riggs wrote:
>> On Thu, 2010-06-24 at 11:15 -0400, Tom Lane wrote:
>>> It might be a good idea to add a sentence to the documentation, though,
>>> just pointing out that these control client-side keepalive probes rather
>>> than server-
On Thu, Jun 24, 2010 at 1:38 PM, Simon Riggs wrote:
> On Thu, 2010-06-24 at 11:15 -0400, Tom Lane wrote:
>> Florian Pflug writes:
>> > On Jun 24, 2010, at 16:45 , Robert Haas wrote:
>> >> I think the existing names are fine - people should understand that
>> >> "options" means "server-side option
On Thu, Jun 24, 2010 at 2:37 PM, Mike Fowler wrote:
> Thanks Robert, I've managed to resolve this make making a type cast inside
> gram.y. However, it now seems that the function itself can not be found.
> I've made an entry in pg_proc.h, but when running psql I'm getting the
> following:
>
> xmlt
On 6/24/10 11:03 AM, Joshua D. Drake wrote:
> On Thu, 2010-06-24 at 10:34 -0700, Josh Berkus wrote:
>> On 06/24/2010 09:04 AM, Joshua D. Drake wrote:
>>> Hello,
>>>
>>> We need to make sure and send out multiple announcements of this. At
>>> least 2 during the month of July.
>> Ach. I drafted an a
Robert Haas wrote:
I usually troubleshoot things like this by setting a breakpoint in
elog_start or elog_finish. Then you can see where it's blowing up.
Off the top of my head, I would guess you've added a node type whose
structure definition doesn't begin with NodeTag, or else you've got a
mem
On Thu, 2010-06-24 at 10:34 -0700, Josh Berkus wrote:
> On 06/24/2010 09:04 AM, Joshua D. Drake wrote:
> > Hello,
> >
> > We need to make sure and send out multiple announcements of this. At
> > least 2 during the month of July.
>
> Ach. I drafted an annoucement ... did I ever send it out?
Not s
On Thu, Jun 24, 2010 at 1:40 PM, Simon Riggs wrote:
> On Thu, 2010-06-24 at 10:30 -0400, Robert Haas wrote:
>
>> It lets you set
>> the TCP keepalive parameters on the server side, whereas what this
>> patch does is let you set them on the client side. Only setting them
>> on the client side will
On Thu, 2010-06-24 at 10:30 -0400, Robert Haas wrote:
> It lets you set
> the TCP keepalive parameters on the server side, whereas what this
> patch does is let you set them on the client side. Only setting them
> on the client side will allow the client to notice when the server has
> gone away.
On Thu, 2010-06-24 at 11:15 -0400, Tom Lane wrote:
> Florian Pflug writes:
> > On Jun 24, 2010, at 16:45 , Robert Haas wrote:
> >> I think the existing names are fine - people should understand that
> >> "options" means "server-side options" and that anything else is a
> >> client-side option. Ho
On 06/24/2010 09:04 AM, Joshua D. Drake wrote:
Hello,
We need to make sure and send out multiple announcements of this. At
least 2 during the month of July.
Ach. I drafted an annoucement ... did I ever send it out?
If not, will do so immediately.
--
-- Josh
On Wed, Jun 23, 2010 at 10:49 AM, Robert Haas wrote:
> On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I can reproduce this, here. The problem seems to be that plpython
>>> only build either plpython2.so or plython3.so, but both languages
>>> expect a call handler c
Hello,
We need to make sure and send out multiple announcements of this. At
least 2 during the month of July.
JD
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
--
Sent via pgs
Hmm,
k, then I don't know exactly what happens. I have some values in my composite
type. The size of the index tuple (if coming from one table and being copied to
the target table) is about 15x bytes. Otherwise, if I insert the same tuple
directly, it is about 12kb. So, I don't know exactly what
Florian Pflug writes:
> On Jun 24, 2010, at 16:45 , Robert Haas wrote:
>> I think the existing names are fine - people should understand that
>> "options" means "server-side options" and that anything else is a
>> client-side option. However, if there's a strong consensus the other
>> way and som
On Jun 24, 2010, at 16:45 , Robert Haas wrote:
> On Thu, Jun 24, 2010 at 10:40 AM, Florian Pflug wrote:
>> On Jun 24, 2010, at 16:30 , Robert Haas wrote:
>>> On Thu, Jun 24, 2010 at 10:13 AM, Tom Lane wrote:
Simon Riggs writes:
> There isn't any need at at all for this. We can already a
Carsten Kropf writes:
> However, it is a little bit strange, that I get toasted values (when
> inserting from another table) and untoasted values, if I insert items
> directly. Could anybody please explain this to me?
Huh? An index will never ever get passed an externally-toasted value.
See th
Oh,
thanks. I didn't know about index tables not having access to associated toast
values. The index access method is (at least in the textual part) similar to
GIN, however, I needed to do some changes to it. Saving the whole document is
actually only important for vacuum. I think, I will find s
On Thu, Jun 24, 2010 at 10:40 AM, Florian Pflug wrote:
> On Jun 24, 2010, at 16:30 , Robert Haas wrote:
>> On Thu, Jun 24, 2010 at 10:13 AM, Tom Lane wrote:
>>> Simon Riggs writes:
There isn't any need at at all for this. We can already add options on
the libpq connection line.
>>>
>>>
Greg Stark writes:
> I think it's going to be an uphill battle convincing TCP that we know
> better than the TCP spec about how aggressive it should be about
> throwing errors and killing connections. Once we have TCP keepalives
> set low enough -- assuming the OS will allow it to be set much lowe
On Jun 24, 2010, at 16:30 , Robert Haas wrote:
> On Thu, Jun 24, 2010 at 10:13 AM, Tom Lane wrote:
>> Simon Riggs writes:
>>> On Wed, 2010-06-23 at 21:54 +, Robert Haas wrote:
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, an
Magnus Hagander writes:
> On Thu, Jun 24, 2010 at 15:39, Heikki Linnakangas
> wrote:
>> On 24/06/10 14:41, Magnus Hagander wrote:
>>> Our versioning policy
>>> (http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy)
>>> says that we EOL 7.4 and 8.0 "July 2010". Does that mean July 1st
On Thu, Jun 24, 2010 at 10:13 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On Wed, 2010-06-23 at 21:54 +, Robert Haas wrote:
>>> This adds four additional connection parameters to libpq: keepalives,
>>> keepalives_idle, keepalives_count, and keepalives_interval.
>>> keepalives default to on,
Carsten Kropf writes:
> I have a strange issue using a custom built index structure. My index access
> method support document type composed of words (as tsvector) and points
> (1-dimensional arrays of them). For internal reasons, I have to save the
> documents as a whole inside my structure (f
Simon Riggs writes:
> On Wed, 2010-06-23 at 21:54 +, Robert Haas wrote:
>> This adds four additional connection parameters to libpq: keepalives,
>> keepalives_idle, keepalives_count, and keepalives_interval.
>> keepalives default to on, per discussion, but can be turned off by
>> specifying ke
On Thu, Jun 24, 2010 at 15:39, Heikki Linnakangas
wrote:
> On 24/06/10 14:41, Magnus Hagander wrote:
>>
>> Our versioning policy
>> (http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy)
>> says that we EOL 7.4 and 8.0 "July 2010". Does that mean July 1st or
>> July 31st?
>
> Probably
On 24/06/10 14:41, Magnus Hagander wrote:
Our versioning policy
(http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy)
says that we EOL 7.4 and 8.0 "July 2010". Does that mean July 1st or
July 31st?
Probably means one more minor release, and that's it.
--
Heikki Linnakangas
En
2010-06-24 14:13 keltezéssel, Michael Meskes írta:
I think, yes, it does make sense. Because we are talking
about porting a whole lot of COBOL applications.
COBOL???
Yes, OpenCOBOL...
The ESQL/C or ECPG connector was already written
the Informix quirks in mind, so it fetches only o
On Jun 24, 2010, at 2:13 PM, Michael Meskes wrote:
>> I think, yes, it does make sense. Because we are talking
>> about porting a whole lot of COBOL applications.
>
> COBOL???
>
yes, COBOL :).
it is much more common than people think.
it is not the first COBOL request for PostgreSQL hitting my
Greg Stark wrote:
> we'll find that other timeouts are longer than we expect too. TCP
> Keepalives won't come into it at all if there is any unacked data
> pending -- TCP *will* detect that case but it might take longer
> than you want too and you won't be able to lower it.
If memory servers a
On Thu, Jun 24, 2010 at 12:04:30PM +0300, Heikki Linnakangas wrote:
> Is there a reason not to enable it by default? I'm a bit worried
> that it will receive no testing if it's not always on.
Yes, there is a reason, namely that you don't need it in native mode at all.
ECPG can read as many records
> I think, yes, it does make sense. Because we are talking
> about porting a whole lot of COBOL applications.
COBOL???
> The ESQL/C or ECPG connector was already written
> the Informix quirks in mind, so it fetches only one record
> at a time passing it to the application. And similar performance
On Wed, Jun 23, 2010 at 04:42:37PM -0400, Bruce Momjian wrote:
> I assume our ecpg version supports >1 fetch values, even in Informix
> mode. Does it make sense to add lots of code to our ecpg then?
Yes, it does. The big question that zoltan and I haven't figured out yet, is
whether it makes sens
On Tue, Jun 22, 2010 at 6:04 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> What does bother me is the fact that we are engineering a critical
>> aspect of our system reliability around vendor-specific
>> implementation details of the TCP stack, and that if any version
>> of any operating sy
Our versioning policy
(http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy)
says that we EOL 7.4 and 8.0 "July 2010". Does that mean July 1st or
July 31st?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing lis
On Thu, Jun 24, 2010 at 03:14, Robert Haas wrote:
> On Tue, Jun 22, 2010 at 12:32 PM, Magnus Hagander wrote:
>> I looked around quickly earlier when we chatted about this, and I
>> think I found an API call to change them for a socket as well - but a
>> Windows specific one, not the ones you'd fi
2010-06-24 11:04 keltezéssel, Heikki Linnakangas írta:
On 24/06/10 10:27, Böszörményi Zoltán wrote:
And this readahead is not on by default, it's only activated
by "ecpg -r fetch_readahead".
Is there a reason not to enable it by default? I'm a bit worried that
it will receive no testing if it
On 24/06/10 10:27, Böszörményi Zoltán wrote:
And this readahead is not on by default, it's only activated
by "ecpg -r fetch_readahead".
Is there a reason not to enable it by default? I'm a bit worried that it
will receive no testing if it's not always on.
--
Heikki Linnakangas
Enterprise
Hi,
2010-06-23 22:42 keltezéssel, Bruce Momjian írta:
Boszormenyi Zoltan wrote:
Hi,
we improved ECPG quite a lot in 9.0 because we worked and
still working with an Informix to PostgreSQL migration project.
We came across a pretty big performance problem that can be seen in
every "naive" a
Hi *,
I have a strange issue using a custom built index structure. My index access
method support document type composed of words (as tsvector) and points
(1-dimensional arrays of them). For internal reasons, I have to save the
documents as a whole inside my structure (for proper reorganisations
On Wed, 2010-06-23 at 21:54 +, Robert Haas wrote:
> Log Message:
> ---
> Add TCP keepalive support to libpq.
I misunderstood the earlier discussion on this and didn't realise you
were considering committing in this way. For me, this is two patches,
not one. I object to one and like the
41 matches
Mail list logo
