Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'

> Oh. If there's actually a standard somewhere that says it's not > null-terminated, then code that is expecting it to be so is just > wrong. No need to change anything in ecpg, IMO. As I said I haven't checked if this detail is actually in there, but I guess it was because there is a reason why

Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'

Michael Meskes writes: > With "supposed" I was referring to the standard that defines SQLCA. Oh. If there's actually a standard somewhere that says it's not null-terminated, then code that is expecting it to be so is just wrong. No need to change anything in ecpg, IMO.

Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'

> > Why do you think there should be one? My memory might be wrong but > > I > > don't think it's supposed to be a null terminated string. > > That field is defined as char[5] in struct sqlca_t, so the intent is > clearly that it not be null terminated. However, it looks to me like > there'd be a

Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'

Michael Meskes writes: >> In the function ECPGnoticeReceiver, we use the stncpy function copy >> the >> sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as >> the size >> of 5, and the copy size is sizeof(sqlca->sqlstate). However, from the >> previous strcmp function, the sqlstate

Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'

> When we reviewed the ecpg code,we found the array seem not have the > end > character('\0') after using the strncpy function. True. > In the function ECPGnoticeReceiver, we use the stncpy function copy > the > sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as > the size > of

[HACKERS] 【ECPG】strncpy function does not set the end character '\0'

Hi When we reviewed the ecpg code,we found the array seem not have the end character('\0') after using the strncpy function. In the function ECPGnoticeReceiver, we use the stncpy function copy the sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as the size of 5, and the copy si

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

> Given that it's Friday evening in Europe, I'm betting Michael is gone > for the day.  In the interests of getting the buildfarm back to > green, > I'll see if I can fix this. Correct, thanks Tom. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Mes

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

Christian Ullrich writes: > The buildfarm says that sorting is frequently done case-sensitively: Given that it's Friday evening in Europe, I'm betting Michael is gone for the day. In the interests of getting the buildfarm back to green, I'll see if I can fix this. regard

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

* Michael Meskes wrote: The v3 patch looks good to me. I've changed this patch status to Ready for Committer. Thank you all, committed. The buildfarm says that sorting is frequently done case-sensitively: *** 1,2 - josh 1.00 10.00 Ram 00.00 21.00 --- 1,2 Ram 11

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On Aug 25, 2017 10:45 PM, "Michael Meskes" wrote: > > > The v3 patch looks good to me. I've changed this patch status to Ready > > for Committer. > > Thank you all, committed. Thank you very much. Regards, Vinayak Pokale

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

> The v3 patch looks good to me. I've changed this patch status to Ready > for Committer. Thank you all, committed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On 2017/08/25 17:13, Masahiko Sawada wrote: On Fri, Aug 25, 2017 at 4:27 PM, vinayak wrote: On 2017/08/25 16:18, Masahiko Sawada wrote: On Fri, Aug 25, 2017 at 2:57 PM, vinayak wrote: Hi Sawada-san, On 2017/08/25 11:07, Masahiko Sawada wrote: On Fri, Aug 18, 2017 at 5:20 PM, vinayak wr

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On Fri, Aug 25, 2017 at 4:27 PM, vinayak wrote: > > > On 2017/08/25 16:18, Masahiko Sawada wrote: >> >> On Fri, Aug 25, 2017 at 2:57 PM, vinayak >> wrote: >>> >>> Hi Sawada-san, >>> >>> >>> On 2017/08/25 11:07, Masahiko Sawada wrote: On Fri, Aug 18, 2017 at 5:20 PM, vinayak wrote:

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On 2017/08/25 16:18, Masahiko Sawada wrote: On Fri, Aug 25, 2017 at 2:57 PM, vinayak wrote: Hi Sawada-san, On 2017/08/25 11:07, Masahiko Sawada wrote: On Fri, Aug 18, 2017 at 5:20 PM, vinayak wrote: On 2017/06/20 17:35, vinayak wrote: Hi Sawada-san, On 2017/06/20 17:22, Masahiko Sawada

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On Fri, Aug 25, 2017 at 2:57 PM, vinayak wrote: > Hi Sawada-san, > > > On 2017/08/25 11:07, Masahiko Sawada wrote: >> >> On Fri, Aug 18, 2017 at 5:20 PM, vinayak >> wrote: >>> >>> On 2017/06/20 17:35, vinayak wrote: Hi Sawada-san, On 2017/06/20 17:22, Masahiko Sawada wrote: >>

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

Hi Sawada-san, On 2017/08/25 11:07, Masahiko Sawada wrote: On Fri, Aug 18, 2017 at 5:20 PM, vinayak wrote: On 2017/06/20 17:35, vinayak wrote: Hi Sawada-san, On 2017/06/20 17:22, Masahiko Sawada wrote: On Tue, Jun 20, 2017 at 1:51 PM, vinayak wrote: On 2017/06/12 13:09, vinayak wrote: H

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On Fri, Aug 18, 2017 at 5:20 PM, vinayak wrote: > > On 2017/06/20 17:35, vinayak wrote: >> >> Hi Sawada-san, >> >> On 2017/06/20 17:22, Masahiko Sawada wrote: >>> >>> On Tue, Jun 20, 2017 at 1:51 PM, vinayak >>> wrote: On 2017/06/12 13:09, vinayak wrote: Hi, On

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On 2017/06/20 17:35, vinayak wrote: Hi Sawada-san, On 2017/06/20 17:22, Masahiko Sawada wrote: On Tue, Jun 20, 2017 at 1:51 PM, vinayak wrote: On 2017/06/12 13:09, vinayak wrote: Hi, On 2017/06/10 12:23, Vinayak Pokale wrote: Thank you for your reply On Jun 9, 2017 5:39 PM, "Michael Mes

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

Hi Sawada-san, On 2017/06/20 17:22, Masahiko Sawada wrote: On Tue, Jun 20, 2017 at 1:51 PM, vinayak wrote: On 2017/06/12 13:09, vinayak wrote: Hi, On 2017/06/10 12:23, Vinayak Pokale wrote: Thank you for your reply On Jun 9, 2017 5:39 PM, "Michael Meskes" wrote: Could you please add a "

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On Tue, Jun 20, 2017 at 1:51 PM, vinayak wrote: > > > On 2017/06/12 13:09, vinayak wrote: > > Hi, > > On 2017/06/10 12:23, Vinayak Pokale wrote: > > Thank you for your reply > > On Jun 9, 2017 5:39 PM, "Michael Meskes" wrote: >> >> Could you please add a "DO CONTINUE" case to one of the test case

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On 2017/06/12 13:09, vinayak wrote: Hi, On 2017/06/10 12:23, Vinayak Pokale wrote: Thank you for your reply On Jun 9, 2017 5:39 PM, "Michael Meskes" > wrote: > > Could you please add a "DO CONTINUE" case to one of the test cases? Or > add a new one? We would

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

Hi, On 2017/06/10 12:23, Vinayak Pokale wrote: Thank you for your reply On Jun 9, 2017 5:39 PM, "Michael Meskes" > wrote: > > Could you please add a "DO CONTINUE" case to one of the test cases? Or > add a new one? We would need a test case IMO. > Yes I will add t

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

Thank you for your reply On Jun 9, 2017 5:39 PM, "Michael Meskes" wrote: > > Hi, > > > To develop the ECPG application more efficiently and improve > > portability, > > I would like to suggest one minor improvement "WHENEVER condition DO > > CONTINUE" support in ECPG. > > Oracle Pro*C supports WH

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

Hi, > To develop the ECPG application more efficiently and improve > portability, > I would like to suggest one minor improvement "WHENEVER condition DO > CONTINUE" support in ECPG. > Oracle Pro*C supports WHENEVER statement with DO CONTINUE action.[1] > > EXEC SQL WHENEVER SQLERROR CONTINUE; > i

[HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

Hello, To develop the ECPG application more efficiently and improve portability, I would like to suggest one minor improvement "WHENEVER condition *DO CONTINUE*" support in ECPG. Oracle Pro*C supports WHENEVER statement with DO CONTINUE action.[1] EXEC SQL WHENEVER SQLERROR CONTINUE; is not sa

Re: [HACKERS] ECPG: pg_type.h file is not synced

> Bruce Momjian writes: > > > > But I think the "ecpg/ecpglib/pg_type.h" file is currently not > > > > synced > > > > with the above file. > > Should we add some Makefile magic to make sure they stay in sync? > > Not so much that as teach genbki.pl to generate this file too. > I think that might

Re: [HACKERS] ECPG: pg_type.h file is not synced

Bruce Momjian writes: >>> But I think the "ecpg/ecpglib/pg_type.h" file is currently not synced >>> with the above file. > Should we add some Makefile magic to make sure they stay in sync? Not so much that as teach genbki.pl to generate this file too. I think that might be a good idea, but perso

Re: [HACKERS] ECPG: pg_type.h file is not synced

On Tue, May 23, 2017 at 10:25:13AM +0200, Michael Meskes wrote: > Hi, > > > I am looking at ECPG source code. In the "ecpg/ecpglib/pg_type.h" file I > > have seen following comment: > > > > ** keep this in sync with src/include/catalog/pg_type.h* > > > > But I think the "ecpg/ecpglib/pg_type.h"

Re: [HACKERS] ECPG: pg_type.h file is not synced

Hi, > I am looking at ECPG source code. In the "ecpg/ecpglib/pg_type.h" file I > have seen following comment: > > ** keep this in sync with src/include/catalog/pg_type.h* > > But I think the "ecpg/ecpglib/pg_type.h" file is currently not synced > with the above file. > > I have added the remain

[HACKERS] ECPG: pg_type.h file is not synced

Hello, I am looking at ECPG source code. In the "ecpg/ecpglib/pg_type.h" file I have seen following comment: ** keep this in sync with src/include/catalog/pg_type.h* But I think the "ecpg/ecpglib/pg_type.h" file is currently not synced with the above file. I have added the remaining types

Re: [HACKERS] ECPG BUlk insert support using arrays

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Haribabu Kommi > I didn't find any relevant thread about the discussion of Bulk insert support > in ECPG using arrays. Oracle supports the same and details are available > in [1]. > > > I see some

[HACKERS] ECPG BUlk insert support using arrays

Hi All, I didn't find any relevant thread about the discussion of Bulk insert support in ECPG using arrays. Oracle supports the same and details are available in [1]. I see some performance benefits in supporting the same in ECPG also. Does any one worked on this area before? Are there any prob

Re: [HACKERS] ecpg -? option doesn't work in windows

On 08/29/2016 09:10 AM, Haribabu Kommi wrote: ecpg option --help alternative -? doesn't work in windows. In windows, the PG provided getopt_long function is used for reading the provided options. The getopt_long function returns '?' for invalid characters also but it sets optopt option to 0 in c

[HACKERS] ecpg -? option doesn't work in windows

ecpg option --help alternative -? doesn't work in windows. In windows, the PG provided getopt_long function is used for reading the provided options. The getopt_long function returns '?' for invalid characters also but it sets optopt option to 0 in case if the character itself is a '?'. But this w

Re: [HACKERS] ecpg array support, or lack thereof

On Wed, Feb 04, 2015 at 10:07:07AM -0500, Tom Lane wrote: > Michael Meskes would be the authority on that question, so I've cc'd > him to make sure he notices this thread ... Thanks Tom. > > The leaks were in the code that takes a host variable, and converts it > > into a string for sending to t

Re: [HACKERS] ecpg array support, or lack thereof

Heikki Linnakangas writes: > While looking at the memory leaks in ecpg that Coverity warned about and > Michael just fixed, I started wondering if the code is ever used. Michael Meskes would be the authority on that question, so I've cc'd him to make sure he notices this thread ... > The leaks

[HACKERS] ecpg array support, or lack thereof

While looking at the memory leaks in ecpg that Coverity warned about and Michael just fixed, I started wondering if the code is ever used. The leaks were in the code that takes a host variable, and converts it into a string for sending to the server as a query parameter. In particular, it was

Re: [HACKERS] ECPG FETCH readahead

2014-04-16 10:54 keltezéssel, Boszormenyi Zoltan írta: 2014-01-18 18:08 keltezéssel, Boszormenyi Zoltan írta: Hi, Alvaro Herrera wrote: Boszormenyi Zoltan escribió: Rebased patches after the regression test and other details were fixed in the infrastructure part. This thread started in 201

Re: [HACKERS] ECPG FETCH readahead, was: Re: ECPG fixes

2014-01-16 23:42 keltezéssel, Alvaro Herrera írta: Boszormenyi Zoltan escribió: Rebased patches after the regression test and other details were fixed in the infrastructure part. This thread started in 2010, and various pieces have been applied already and some others have changed in nature. W

Re: Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

2014-01-16 22:13 keltezéssel, Alvaro Herrera írta: Alvaro Herrera escribió: Boszormenyi Zoltan escribió: All patches are attached again for completeness. Thanks. I pushed a commit comprising patches 09 through 14. Now also pushed 15 to 17. Thanks very much. -- Sent via pgsql-hackers ma

Re: [HACKERS] ECPG FETCH readahead, was: Re: ECPG fixes

Boszormenyi Zoltan escribió: > Rebased patches after the regression test and other details were fixed > in the infrastructure part. This thread started in 2010, and various pieces have been applied already and some others have changed in nature. Would you please post a new patchset, containing re

Re: Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

Alvaro Herrera escribió: > Boszormenyi Zoltan escribió: > > > All patches are attached again for completeness. > > Thanks. I pushed a commit comprising patches 09 through 14. Now also pushed 15 to 17. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Su

Re: Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

Boszormenyi Zoltan escribió: > All patches are attached again for completeness. Thanks. I pushed a commit comprising patches 09 through 14. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailin

Re: [HACKERS] ECPG regression tests generating warnings

On Sun, Jan 12, 2014 at 08:28:57AM -0800, Kevin Grittner wrote: > desc.pgc:55: WARNING: descriptor ""outdesc"" does not exist > desc.pgc:86: WARNING: descriptor ""outdesc"" does not exist Thanks, I didn't notice, fixed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes do

[HACKERS] ECPG regression tests generating warnings

Since 192b4aacad45c16a8a9341644479125977366dab my `make check-world` runs are generating these two warnings: desc.pgc:55: WARNING: descriptor ""outdesc"" does not exist desc.pgc:86: WARNING: descriptor ""outdesc"" does not exist The referenced file is in the src/interfaces/ecpg/test/sql/ director

Re: [HACKERS] ECPG FETCH readahead, was: Re: ECPG fixes

2013-12-21 14:56 keltezéssel, Peter Eisentraut írta: This patch didn't make it out of the 2013-11 commit fest. You should move it to the next commit fest (probably with an updated patch) before January 15th. Done. Best regards, Zoltán Böszörményi -- -- Zoltán

Re: [HACKERS] ECPG FETCH readahead, was: Re: ECPG fixes

This patch didn't make it out of the 2013-11 commit fest. You should move it to the next commit fest (probably with an updated patch) before January 15th. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailp

Re: Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

On 12/6/13, 9:58 AM, Antonin Houska wrote: > Tested git apply and build again. No warnings. > > The regression test also looks good to me now. > > I'm done with this review. > > (Not sure if I should move it to 'ready for committer' status or the CFM > should do). You should do that, but I'll d

Re: Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

Tested git apply and build again. No warnings. The regression test also looks good to me now. I'm done with this review. (Not sure if I should move it to 'ready for committer' status or the CFM should do). // Antonin Houska (Tony) On 12/06/2013 02:01 PM, Boszormenyi Zoltan wrote: > 2013-12-04

Re: Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

Thanks for the review. 2013-12-03 16:48 keltezéssel, Antonin Houska írta: The changes are very well divided into logical units, so I think I could understand the ideas. I'm not too familiar with the ecpg internals, so consider this at least a coding review. git apply: Clean, except for on

Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

The changes are very well divided into logical units, so I think I could understand the ideas. I'm not too familiar with the ecpg internals, so consider this at least a coding review. git apply: Clean, except for one finding below Build: no errors/warnings Documentation build: no errors/w

[HACKERS] ECPG infrastructure changes, part 4, was: Re: ECPG fixes

2013-11-20 14:41 keltezéssel, Boszormenyi Zoltan írta: 2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta: 2013-11-12 07:01 keltezéssel, Noah Misch írta: On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote: The old contents of my GIT repository was removed so you need to clon

[HACKERS] ECPG infrastructure changes, part 3, was: Re: ECPG fixes

2013-11-20 14:41 keltezéssel, Boszormenyi Zoltan írta: 2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta: 2013-11-12 07:01 keltezéssel, Noah Misch írta: On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote: The old contents of my GIT repository was removed so you need to clon

[HACKERS] ECPG infrastructure changes, part 2, was: Re: ECPG fixes

2013-11-20 14:41 keltezéssel, Boszormenyi Zoltan írta: 2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta: 2013-11-12 07:01 keltezéssel, Noah Misch írta: On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote: The old contents of my GIT repository was removed so you need to clon

ECPG fixes, was: Re: [HACKERS] ECPG FETCH readahead

2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta: 2013-11-12 07:01 keltezéssel, Noah Misch írta: On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote: The old contents of my GIT repository was removed so you need to clone it fresh. https://github.com/zboszor/ecpg-readahead.gi

Re: [HACKERS] ECPG FETCH readahead

On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote: > The old contents of my GIT repository was removed so you need to > clone it fresh. https://github.com/zboszor/ecpg-readahead.git > I won't post the humongous patch again, since sending a 90KB > compressed file to everyone on the

Re: [HACKERS] ECPG FETCH readahead

2013-10-11 00:16 keltezéssel, Alvaro Herrera írta: Boszormenyi Zoltan escribió: 2013-09-10 03:04 keltezéssel, Peter Eisentraut írta: You need to update the dblink regression tests. Done. Dude, this is an humongous patch. I was shocked by it initially, but on further reading, I observed that

Re: [HACKERS] ECPG FETCH readahead

2013-10-11 00:16 keltezéssel, Alvaro Herrera írta: Boszormenyi Zoltan escribió: 2013-09-10 03:04 keltezéssel, Peter Eisentraut írta: You need to update the dblink regression tests. Done. Dude, this is an humongous patch. You *know* that the patch is available in pieces at https://github.co

Re: [HACKERS] ECPG FETCH readahead

Boszormenyi Zoltan escribió: > 2013-09-10 03:04 keltezéssel, Peter Eisentraut írta: > >You need to update the dblink regression tests. > > Done. Dude, this is an humongous patch. I was shocked by it initially, but on further reading, I observed that it's only a huge patch which also does some me

Proposal: UPDATE/DELETE ... WHERE OFFSET n OF cursor_name, was: Re: New ECPG idea, was: Re: [HACKERS] ECPG FETCH readahead

Hi, 2013-08-17 13:02 keltezéssel, Boszormenyi Zoltan írta: [snip, discussion of WHERE CURRENT OF in the ECPG client lib] I had a second thought about it and the client side caching and parser behind the application's back seems to be an overkill. Instead, I propose a different solution, which i

Re: [HACKERS] ECPG FETCH readahead

You need to update the dblink regression tests. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ECPG FETCH readahead

On Wed, 2013-09-04 at 10:06 +0200, Boszormenyi Zoltan wrote: > 2013-08-17 12:08 keltezéssel, Boszormenyi Zoltan írta: > > > > I have put the broken up patchset into a GIT tree of mine at GitHub: > > https://github.com/zboszor/ecpg-readahead/ > > but the huge compressed patch is also attached for re

New ECPG idea, was: Re: [HACKERS] ECPG FETCH readahead

2013-08-17 12:08 keltezéssel, Boszormenyi Zoltan írta: Hi, I am restarting this old thread... :-) 2012-04-24 10:17 keltezéssel, Michael Meskes írta: OK, I will implement #2. Another question popped up: what to do with FETCH ALL? The current readahead window size or temporarily bumping it to sa

[HACKERS] ECPG timestamp '%j'

Michael, While looking at complaints from the Coverity scanner system, it looks like it's detected a case in ECPG where we provide a "day-of-year" format option (%j), but we never actually calculate what the day of year *is*, resulting in an uninitialized value. Other parts of the code

[HACKERS] ecpg prototype mismatch

ECPG's pgtypeslib contains two slightly different prototypes for PGTYPEStimestamp_defmt_scan(), neither of which is in a header file. I propose something like the attached patch, although I'm not sure which header file is the most appropriate one. diff --git a/src/interfaces/ecpg/pgtypeslib/dt.h b

Re: [HACKERS] ECPG FETCH readahead

> OK, I will implement #2. Another question popped up: what to do > with FETCH ALL? The current readahead window size or temporarily > bumping it to say some tens of thousands can be used. We may not > know how much is the "all records". This, although lowers performance, > saves memory. I would s

Re: [HACKERS] ECPG FETCH readahead

Hi, 2012-04-17 06:48 keltezéssel, Michael Meskes írta: On Tue, Apr 17, 2012 at 06:02:34AM +0200, Boszormenyi Zoltan wrote: I listed two scenarios. 1. occasional bump of the readahead window for large requests, for smaller requests it uses the originally set size 2. permanent bump of the rea

Re: [HACKERS] ECPG FETCH readahead

On Tue, Apr 17, 2012 at 06:02:34AM +0200, Boszormenyi Zoltan wrote: > I listed two scenarios. > 1. occasional bump of the readahead window for large requests, >for smaller requests it uses the originally set size > 2. permanent bump of the readahead window for large requests >(larger than p

Re: [HACKERS] ECPG FETCH readahead

2012-04-17 05:52 keltezéssel, Michael Meskes írta: On Mon, Apr 16, 2012 at 07:18:07PM +0200, Boszormenyi Zoltan wrote: OK. I would like to stretch your agreement a little. :-) ... Yeah, you got a point here. By the new FETCH request. Instead of the above, I imagined this: - the runtime notice

Re: [HACKERS] ECPG FETCH readahead

On Mon, Apr 16, 2012 at 07:18:07PM +0200, Boszormenyi Zoltan wrote: > OK. I would like to stretch your agreement a little. :-) > ... Yeah, you got a point here. > By the new FETCH request. Instead of the above, I imagined this: > - the runtime notices that the new request is larger than the curre

Re: [HACKERS] ECPG FETCH readahead

2012-04-16 18:04 keltezéssel, Michael Meskes írta: On Mon, Apr 16, 2012 at 06:24:57AM +0200, Boszormenyi Zoltan wrote: Yes, just like when the readahead window set to 256, FETCH 1024 will iterate through 4 windows or FETCH 64 iterates through the same window 4 times. This is the idea behind the

Re: [HACKERS] ECPG FETCH readahead

On Mon, Apr 16, 2012 at 06:24:57AM +0200, Boszormenyi Zoltan wrote: > Yes, just like when the readahead window set to 256, FETCH 1024 > will iterate through 4 windows or FETCH 64 iterates through the > same window 4 times. This is the idea behind the "readahead window". Really? It's definitely not

Re: [HACKERS] ECPG FETCH readahead

2012-04-16 04:46 keltezéssel, Michael Meskes írta: On Tue, Apr 10, 2012 at 07:56:35PM +0200, Boszormenyi Zoltan wrote: With the above, it would be possible to use a comma separated list of "-r" suboptions, e.g. "-r prepare,questionmarks,readahead=16" in one option. Yes, that sounds like a good

Re: [HACKERS] ECPG FETCH readahead

On Tue, Apr 10, 2012 at 07:56:35PM +0200, Boszormenyi Zoltan wrote: > With the above, it would be possible to use a comma separated list of "-r" > suboptions, e.g. "-r prepare,questionmarks,readahead=16" in one option. Yes, that sounds like a good plan. But of course it's outside the scope of this

Re: [HACKERS] ECPG FETCH readahead

Hi, 2012-04-10 16:55 keltezéssel, Michael Meskes írta: On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote: Only a non-decorated cursor can be overridden, even if a different default readahead window size is specified with e.g. "ecpg -R 8". If ECPGFETCHSZ is not present, 8 will be used,

Re: [HACKERS] ECPG FETCH readahead

2012-04-10 17:34 keltezéssel, Michael Meskes írta: On Tue, Apr 10, 2012 at 05:24:55PM +0200, Boszormenyi Zoltan wrote: OK. Next question: now that both patches are intended to be applied, should I send a unified single patch that contains the previous functionality and the required fixes or a ne

Re: [HACKERS] ECPG FETCH readahead

On Tue, Apr 10, 2012 at 05:24:55PM +0200, Boszormenyi Zoltan wrote: > OK. Next question: now that both patches are intended to be applied, > should I send a unified single patch that contains the previous functionality > and the required fixes or a new one that only contains the last required > fi

Re: [HACKERS] ECPG FETCH readahead

2012-04-10 16:55 keltezéssel, Michael Meskes írta: On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote: Only a non-decorated cursor can be overridden, even if a different default readahead window size is specified with e.g. "ecpg -R 8". If ECPGFETCHSZ is not present, 8 will be used, if EC

Re: [HACKERS] ECPG FETCH readahead

On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote: > > Only a non-decorated cursor can be overridden, even if > > a different default readahead window size is specified with > > e.g. "ecpg -R 8". If ECPGFETCHSZ is not present, 8 will be used, > > if ECPGFETCHSZ is present, its value will b

Re: [HACKERS] ECPG FETCH readahead

On Tue, Apr 10, 2012 at 09:35:21AM +0200, Boszormenyi Zoltan wrote: > So, it's established that a specified READAHEAD N should not > be overridden. Even an explicit READAHEAD 1. > > Only a non-decorated cursor can be overridden, even if > a different default readahead window size is specified with

Re: [HACKERS] ECPG FETCH readahead

2012-04-08 19:38 keltezéssel, Michael Meskes írta: On Sun, Apr 08, 2012 at 06:35:33PM +0200, Boszormenyi Zoltan wrote: Do you want me to change this or will you do it? I am on holiday and will be back to work on wednesday. I don't think waiting till later this week is a real problem. OK.

Re: [HACKERS] ECPG FETCH readahead

On Sun, Apr 08, 2012 at 04:25:01PM +0200, Michael Meskes wrote: > On Sat, Apr 07, 2012 at 11:50:42AM -0400, Noah Misch wrote: > > I do call your attention to a question I raised in my second review: if a > > program contains "DECLARE foo READAHEAD 5 CURSOR FOR ..." and the user runs > > the program

Re: [HACKERS] ECPG FETCH readahead

On Sun, Apr 08, 2012 at 06:35:33PM +0200, Boszormenyi Zoltan wrote: > Do you want me to change this or will you do it? I am on holiday > and will be back to work on wednesday. I don't think waiting till later this week is a real problem. > The possibility to test different readahead window sizes

Re: [HACKERS] ECPG FETCH readahead

2012-04-08 16:25 keltezéssel, Michael Meskes írta: On Sat, Apr 07, 2012 at 11:50:42AM -0400, Noah Misch wrote: Both. The second patch appeared after my first review, based on a comment in that review. I looked at it during my re-review before marking the overall project Ready for Committer. T

Re: [HACKERS] ECPG FETCH readahead

On Sat, Apr 07, 2012 at 11:50:42AM -0400, Noah Misch wrote: > Both. The second patch appeared after my first review, based on a comment in > that review. I looked at it during my re-review before marking the overall > project Ready for Committer. Thanks. > I do call your attention to a question

Re: [HACKERS] ECPG FETCH readahead

On Sat, Apr 07, 2012 at 01:20:08PM +0200, Michael Meskes wrote: > On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote: > > Attached is the new core feature patch. Summary of changes: > > ... > > I also refreshed the second patch that drives all cursors with the new > > ... > > I'm s

Re: [HACKERS] ECPG FETCH readahead

On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote: > Attached is the new core feature patch. Summary of changes: > ... > I also refreshed the second patch that drives all cursors with the new > ... I'm slightly confused here. It seems Zoltan added a second patch *after* Noah marke

Re: [HACKERS] ECPG FETCH readahead

On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote: > 2012-03-29 19:03 keltez?ssel, Noah Misch ?rta: one of the new sections about readahead should somehow reference the hazard around volatile functions. >>> Done. >> I don't see the mention in your latest patch. You do m

Re: [HACKERS] ECPG FETCH readahead

2012-03-29 20:34 keltezéssel, Michael Meskes írta: On Thu, Mar 29, 2012 at 01:03:41PM -0400, Noah Misch wrote: Still, we're looking at dedicated ECPG syntax, quite visible even to folks with no interest in Informix. We have eschewed littering our syntax with compatibility aids, and I like it th

Re: [HACKERS] ECPG FETCH readahead

On Thu, Mar 29, 2012 at 01:03:41PM -0400, Noah Misch wrote: > Still, we're looking at dedicated ECPG syntax, quite visible even to folks > with no interest in Informix. We have eschewed littering our syntax with > compatibility aids, and I like it that way. IMO, an option to the "ecpg" > preproce

Re: [HACKERS] ECPG FETCH readahead

On Thu, Mar 29, 2012 at 12:59:40PM +0200, Boszormenyi Zoltan wrote: > 2012-03-29 02:43 keltez?ssel, Noah Misch ?rta: >> On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote: >>> +toREADAHEAD number. ExplicitREADAHEAD >>> number or >>> +NO READAHEAD turns cursor readahead on >

Re: [HACKERS] ECPG FETCH readahead

2012-03-29 12:59 keltezéssel, Boszormenyi Zoltan írta: 2012-03-29 02:43 keltezéssel, Noah Misch írta: On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote: +the window size may be modified by setting theECPGFETCHSZ +environment variable to a different value. I had in min

Re: [HACKERS] ECPG FETCH readahead

On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote: > Sorry for the delay, I had been busy with other tasks and I rewrote this code > to better cope with unknown result size, scrollable cursors and negative > cursor positions. > > I think all points raised by Noah is addressed: per-

Re: [HACKERS] ECPG FETCH readahead

On Tue, Mar 6, 2012 at 6:06 AM, Noah Misch wrote: > On Tue, Mar 06, 2012 at 07:07:41AM +0100, Boszormenyi Zoltan wrote: >> 2012-03-05 19:56 keltez?ssel, Noah Misch ?rta: >> >> Or how about a new feature in the backend, so ECPG can do >> >>     UPDATE/DELETE ... WHERE OFFSET N OF cursor >> >> and t

Re: [HACKERS] ECPG FETCH readahead

On Tue, Mar 06, 2012 at 07:07:41AM +0100, Boszormenyi Zoltan wrote: > 2012-03-05 19:56 keltez?ssel, Noah Misch ?rta: > >> Or how about a new feature in the backend, so ECPG can do > >> UPDATE/DELETE ... WHERE OFFSET N OF cursor > >> and the offset of computed from the actual cursor position and

Re: [HACKERS] ECPG FETCH readahead

2012-03-05 19:56 keltezéssel, Noah Misch írta: > > Having pondered the matter further, I now agree with Michael that the feature > should stay disabled by default. See my response to him for rationale. > Assuming that conclusion holds, we can recommended a higher value to users who > enable the fe

Re: [HACKERS] ECPG FETCH readahead

On Sun, Mar 04, 2012 at 04:33:32PM +0100, Boszormenyi Zoltan wrote: > 2012-03-02 17:41 keltez?ssel, Noah Misch ?rta: > > On Thu, Dec 29, 2011 at 10:46:23AM +0100, Boszormenyi Zoltan wrote: > > I suggest enabling the feature by default but drastically reducing the > > default > > readahead chunk s

Re: [HACKERS] ECPG FETCH readahead

On Sun, Mar 04, 2012 at 05:16:06PM +0100, Michael Meskes wrote: > On Fri, Mar 02, 2012 at 11:41:05AM -0500, Noah Misch wrote: > > I suggest enabling the feature by default but drastically reducing the > > default > > readahead chunk size from 256 to, say, 5. That still reduces the FETCH > > roun

Re: [HACKERS] ECPG FETCH readahead

On Sun, Mar 04, 2012 at 05:34:50PM +0100, Boszormenyi Zoltan wrote: > The program logic shouldn't change at all. He meant that extra coding effort > is needed if you want manual caching. It requires 2 loops instead of 1 if you > use > FETCH N (N>1). Ah, thanks for the explanation. Michael -- Mi

Re: [HACKERS] ECPG FETCH readahead

2012-03-04 17:16 keltezéssel, Michael Meskes írta: > On Fri, Mar 02, 2012 at 11:41:05AM -0500, Noah Misch wrote: >> We yet lack a consensus on whether native ECPG apps should have access to the >> feature. My 2c is to make it available, because it's useful syntactic sugar. >> If your program indep

  1   2   3   4   5   6   7   >