Just to let everyone know that I haven't forgotten this. I just don't have any time to spend on it. The problem still occurs.
2013/2/20 Peter Kroon <plakr...@gmail.com> > I've migrated everything to Linux and I'm able to continue my work. > I'll get back on this next week. > > > 2013/2/19 Lou Picciano <loupicci...@comcast.net> > >> Sorry, Peter - I think I'd suggest something different. Start at the >> beginning; do this testing directly from the CLI (psql) on each of the >> machines, and compare results... I'd be curious, specifically, to see if >> you see any of those string length restrictions you've alluded to when >> using the CLI. >> >> At this point, it's not clear whether you're testing (various versions?) >> of pgAdmin(?) or (various versions?) of libpq? >> >> >> Lou Picciano >> >> ----- Original Message ----- >> From: Peter Kroon <plakr...@gmail.com> >> To: Pavel Stehule <pavel.steh...@gmail.com> >> Cc: Lou Picciano <loupicci...@comcast.net>, Michael Paquier < >> michael.paqu...@gmail.com>, pgsql-bugs@postgresql.org >> Sent: Tue, 19 Feb 2013 16:50:25 -0000 (UTC) >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >> >> >you can test your queries from pgAdmin SQL executor >> I have already done so. >> >> I'll look into the logs. >> >> >> 2013/2/19 Pavel Stehule <pavel.steh...@gmail.com> >> >>> >>> 2013/2/19 Peter Kroon <plakr...@gmail.com>: >>> >>try to use pgAdminIII >>> >>> > >>> >>> > Could you be more specific? >>> >>> you can test your queries from pgAdmin SQL executor >>> >>> >>> but it is strange error - try to look to postgresql and system logs >>> >>> >>> Pavel >>> >>> >>> > >>> >>> > >>> >>> > 2013/2/19 Pavel Stehule <pavel.steh...@gmail.com> >>> >>> >> >>> >>> >> 2013/2/19 Peter Kroon <plakr...@gmail.com>: >>> >>> >> > Where can I check and/or alter this? >>> >>> >> >>> >>> >> try to use pgAdminIII >>> >>> >> >>> >>> >> Regards >>> >>> >> >>> >>> >> Pavel >>> >>> >> >>> >>> >> > >>> >>> >> > >>> >>> >> > 2013/2/19 Lou Picciano <loupicci...@comcast.net> >>> >>> >> >> >>> >>> >> >> I wonder if there's a difference in the implementation(s) of >>> readline >>> >>> >> >> buffering? >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> ----- Original Message ----- >>> >>> >> >> From: Peter Kroon <plakr...@gmail.com> >>> >>> >> >> To: Lou Picciano <loupicci...@comcast.net> >>> >>> >> >> Cc: Michael Paquier <michael.paqu...@gmail.com>, >>> >>> >> >> pgsql-bugs@postgresql.org >>> >>> >> >> Sent: Tue, 19 Feb 2013 15:28:47 -0000 (UTC) >>> >>> >> >> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >>> >>> >> >> >>> >>> >> >> Exceeding length 4679 is a problem. Query results(length) equal or >>> >>> >> >> below >>> >>> >> >> this number succeed. >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> 2013/2/19 Peter Kroon <plakr...@gmail.com> >>> >>> >> >>> >>> >>> >> >>> When there are more then 88 rows in the table like 595 I can run >>> the >>> >>> >> >>> query with success when using: WHERE id BETWEEN 1 AND 88; >>> >>> >> >>> >>> >>> >> >>> Using LIMIT 88 fails -> returns nothing >>> >>> >> >>> Selecting all fails as well. >>> >>> >> >>> >>> >>> >> >>> >>> >>> >> >>> 2013/2/19 Peter Kroon <plakr...@gmail.com> >>> >>> >> >>>> >>> >>> >> >>>> When there are in __table_to_table more than 88 rows nothing gets >>> >>> >> >>>> returned, otherwise the query rolls out fine. >>> >>> >> >>>> >>> >>> >> >>>> >>> >>> >> >>>> >>> >>> >> >>>> 2013/2/19 Peter Kroon <plakr...@gmail.com> >>> >>> >> >>>>> >>> >>> >> >>>>> It appears to be a Windows issue only. >>> >>> >> >>>>> I'll try to post some code. >>> >>> >> >>>>> >>> >>> >> >>>>> >>> >>> >> >>>>> 2013/2/19 Lou Picciano <loupicci...@comcast.net> >>> >>> >> >>>>>> >>> >>> >> >>>>>> Seems your testing from different environments like that could >>> >>> >> >>>>>> easily >>> >>> >> >>>>>> add any mix of libpq client libraries into the equation (??) >>> >>> >> >>>>>> (Are both test machines running the same version of pgAdmin? >>> and >>> >>> >> >>>>>> are >>> >>> >> >>>>>> both connecting using the libpq installed with them?) >>> >>> >> >>>>>> >>> >>> >> >>>>>> We have plenty of experience with clients reporting varying >>> >>> >> >>>>>> behavior >>> >>> >> >>>>>> from our 'applications', when it turns out they've 'hooked >>> into' an >>> >>> >> >>>>>> unexpected version of the libpq client without, for example, >>> SSL >>> >>> >> >>>>>> support >>> >>> >> >>>>>> built in, or Kerberos, or... This often happens after the >>> client >>> >>> >> >>>>>> has >>> >>> >> >>>>>> unwittingly modified his environment in some way, sometimes >>> after >>> >>> >> >>>>>> installing >>> >>> >> >>>>>> software. >>> >>> >> >>>>>> >>> >>> >> >>>>>> While the 'support libraries' issues above have no bearing on >>> your >>> >>> >> >>>>>> case, of course, I certainly don't know enough to know that the >>> >>> >> >>>>>> different >>> >>> >> >>>>>> versions of libpq don't present xmlagg output differently! >>> >>> >> >>>>>> >>> >>> >> >>>>>> The experts here will weigh in. >>> >>> >> >>>>>> >>> >>> >> >>>>>> Lou Picciano >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> ----- Original Message ----- >>> >>> >> >>>>>> From: Peter Kroon <plakr...@gmail.com> >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> Sent: Tue, 19 Feb 2013 11:52:37 -0000 (UTC) >>> >>> >> >>>>>> Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >>> >>> >> >>>>>> >>> >>> >> >>>>>> > When I'm on the sql machine via localhost or 192.168.1.100 >>> I'm >>> >>> >> >>>>>> > getting results. >>> >>> >> >>>>>> >>> >>> >> >>>>>> I mean when I'm physically behind the machine and login via >>> pgadmin >>> >>> >> >>>>>> using localhost or 192.168.1.100 then I get results. >>> >>> >> >>>>>> When I'm on another machine and login via >>> pgadmin(192.168.1.100) >>> >>> >> >>>>>> then >>> >>> >> >>>>>> I get no results. >>> >>> >> >>>>>> Not sure what to think of this... >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> 2013/2/19 Peter Kroon <plakr...@gmail.com> >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> >Don't you have for example problems with the client >>> application >>> >>> >> >>>>>>> > you >>> >>> >> >>>>>>> > use? >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> Yes, with 1 table only. I'm not getting any results. >>> >>> >> >>>>>>> When I'm on the sql machine via localhost or 192.168.1.100 I'm >>> >>> >> >>>>>>> getting results. >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> 2013/2/19 Michael Paquier <michael.paqu...@gmail.com> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon < >>> plakr...@gmail.com> >>> >>> >> >>>>>>>> wrote: >>> >>> >> >>>>>>>>> >>> >>> >> >>>>>>>>> Also no result with FROM __my_table LIMIT 1; >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> I'm having correct results with PG 9.2 by using either >>> xmlagg or >>> >>> >> >>>>>>>> xmlelement. >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> For example: >>> >>> >> >>>>>>>> postgres=# SELECT xmlelement(name el_name, id) FROM __table >>> LIMIT >>> >>> >> >>>>>>>> 1; >>> >>> >> >>>>>>>> xmlelement >>> >>> >> >>>>>>>> ---------------------- >>> >>> >> >>>>>>>> <el_name>1</el_name> >>> >>> >> >>>>>>>> Or: >>> >>> >> >>>>>>>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM >>> >>> >> >>>>>>>> __table; >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> xmlagg >>> >>> >> >>>>>>>> ------------------------------------------ >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> <el_name>1</el_name><el_name>2</el_name> >>> >>> >> >>>>>>>> (1 row) >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> Btw, such simple tests would have failed on the buildfarm for >>> >>> >> >>>>>>>> regression xml.sql, so this looks to be an error in your >>> >>> >> >>>>>>>> environment. >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> Don't you have for example problems with the client >>> application >>> >>> >> >>>>>>>> you >>> >>> >> >>>>>>>> use? >>> >>> >> >>>>>>>> -- >>> >>> >> >>>>>>>> Michael >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>>> >>> >>> >> >>>>> >>> >>> >> >>>> >>> >>> >> >>> >>> >>> >> >> >>> >>> >> >> >>> >>> >> > >>> >>> > >>> >>> > >>> >> >> >> >
