Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Mm.. The problem only occurs on a specific table in my DB. --__my_table has 512 rows SELECT * FROM __my_table; --gives me result SELECT --xmlagg( xmlelement(name el_name, id ) --) FROM __my_table;--gives me result When un-commenting the xmlagg I get no result. otherwise the output will look like: "1" "2" "3" etc 2013/2/19 Peter Kroon > Hi Michael, > > This should have been the expected result on both machines: > --- > > (1 row) > > I've just rebooted "PostgreSQL 9.2.3 on x86_64-unknown-linux-gnu, > compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit" and I'm > getting the expected result. > > Thanks for helping. > > Best, > > Peter Kroon > > > 2013/2/19 Michael Paquier > >> Hi, >> >> With your query and such tables: >> create table __table (id int); >> insert into __table values (1),(2); >> create table __table_to_table (id int, table_id int); >> insert into __table_to_table values (1, 1),(2, 2); >> >> I am getting consistent results with 9.2.1 and 9.2.3 on my Linux box, >> hence: >> xmlelement >> --- >> >> (1 row) >> >> Could you be more explicit about the result you expect and the output >> differences you see between those versions? >> Regards, >> -- >> Michael >> > >
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Also no result with FROM __my_table LIMIT 1; 2013/2/19 Peter Kroon > Mm.. > The problem only occurs on a specific table in my DB. > > --__my_table has 512 rows > > SELECT * FROM __my_table; --gives me result > > SELECT > --xmlagg( > xmlelement(name el_name, > id > ) > --) > FROM __my_table;--gives me result > > When un-commenting the xmlagg I get no result. otherwise the output will > look like: > "1" > "2" > "3" > etc > > > 2013/2/19 Peter Kroon > >> Hi Michael, >> >> This should have been the expected result on both machines: >> --- >> >> (1 row) >> >> I've just rebooted "PostgreSQL 9.2.3 on x86_64-unknown-linux-gnu, >> compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit" and I'm >> getting the expected result. >> >> Thanks for helping. >> >> Best, >> >> Peter Kroon >> >> >> 2013/2/19 Michael Paquier >> >>> Hi, >>> >>> With your query and such tables: >>> create table __table (id int); >>> insert into __table values (1),(2); >>> create table __table_to_table (id int, table_id int); >>> insert into __table_to_table values (1, 1),(2, 2); >>> >>> I am getting consistent results with 9.2.1 and 9.2.3 on my Linux box, >>> hence: >>> xmlelement >>> --- >>> >>> (1 row) >>> >>> Could you be more explicit about the result you expect and the output >>> differences you see between those versions? >>> Regards, >>> -- >>> Michael >>> >> >> >
Re: [BUGS] BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
sari.thi...@usit.uio.no writes: > ==> * this checks if the new file name is different from the old one. > In my case it is still the same name and so the new log lines will be > appended to the current file, not truncated like I expected. > I think this is the wrong behaviour, what do you think? No, that behavior is intentional. Otherwise you'd lose log data earlier than the configuration specifies. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2013 10:54 AM, Tom Lane wrote: > sari.thi...@usit.uio.no writes: >> ==> * this checks if the new file name is different from the old >> one. In my case it is still the same name and so the new log >> lines will be appended to the current file, not truncated like I >> expected. I think this is the wrong behaviour, what do you >> think? > > No, that behavior is intentional. Otherwise you'd lose log data > earlier than the configuration specifies. > > regards, tom lane > > Hei Tom Well, the "problem" is there even with log_rotation_age = 0 and log_rotation_size = 0. If the behavior we are talking about is intentional, why do be have pg_rotate_logfile() if we can not manually override with this function log_rotation_age and log_rotation_size? When rotating log files you can control 3 things, and they define or should define different aspects of the rotation: 1) When to rotate - --- When to rotate the log file can be defined to happen automatically by log_rotation_age and/or log_rotation_size, or it can be done manually by pg_rotate_logfile(). 2) Name of the log file - The name of the log file can be: - - always the same - - always different - - can be defined so it will be recycled after a while. 3) Use truncation or not when creating a log file. - -- This is or should be independent of 1) and 2). It only defines if the log file we are going to start using will start from scratch or not if it already exists regardless of the log file name. This is how we see log rotation in a logical way. Actual behavior - --- The actual behavior of log rotation in postgreSQL does not follow this logic and in our humble opinion it is inconsistent and not clear. Truncation only works if: - - The old and new log file names are different. - - A new file is being opened due to time-based rotation, not during size-based rotation. Log rotation is in general done so the active log file does not grow indefinitely. PostgreSQL is versatile enough to allow you to activate or not truncation. If truncation is activated, it should work independently of when we rotate, how we activate the rotation and the name of the log file. We are almost there, the actual behavior can be fixed without a lot of work. Think about this usercase. You are using a log file name that does not change over time (i.e. postgreSQL.log) and you want to rotate this file so it does not grow indefinitely (you activate log_truncate_on_rotation). Then you can provoke the rotation with log_rotation_age, log_rotation_size or pg_rotate_logfile(). This does not work nowadays. The only way of rotating in this case will be to stop postgres, delete/rename the log file and start postgres again. What you do with an old file after a rotation is another question. Here PostgreSQL is versatile enough to let you define the name of the log file in many ways so you can control if the number of "old" files grow indefinitely or not. Thanks for your time. regards, - -- Rafael Martinez Guerrero Center for Information Technology University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlEjUNkACgkQBhuKQurGihQh5gCfcAmF6h1WAfcicvHx5jCeEdWO zpIAn3Vjf1DLdAY4jaaZWqyOCBxKmll/ =5dRj -END PGP SIGNATURE- -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
Rafael Martinez writes: > If the behavior we are talking about is intentional, why do be have > pg_rotate_logfile() if we can not manually override with this function > log_rotation_age and log_rotation_size? It works fine as long as the filename pattern is such that a new file would be selected. If we didn't have this filter, then a rotation operation would wipe out *current* log entries, even those that were made a millisecond ago. That can't possibly be a good idea. Any rotation scheme ought to provide for recent entries to survive at least until you've rotated through whichever other log files you have. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2013 11:21 AM, Tom Lane wrote: > Rafael Martinez writes: >> If the behavior we are talking about is intentional, why do be >> have pg_rotate_logfile() if we can not manually override with >> this function log_rotation_age and log_rotation_size? > > It works fine as long as the filename pattern is such that a new > file would be selected. > > If we didn't have this filter, then a rotation operation would wipe > out *current* log entries, even those that were made a millisecond > ago. That can't possibly be a good idea. Any rotation scheme ought > to provide for recent entries to survive at least until you've > rotated through whichever other log files you have. > > regards, tom lane Well, postgreSQL is versatile enough to allow you to decide many aspects of log rotation. It should be the user who decide what will happen with log data after and during a rotation. I agree that using a filename pattern such that a new file would be selected is a god idea, but it is not the only way of doing this and it should not be the only way. What if the user wants to use the same log file name all the time, not archive old data and not to have a log file that grows indefinitely? This should be a valid option because it is a valid and used scenario when administrating databases. What if we want/need to truncate the log file before postgres has to change the file name according to the log_filename definition? If the alternative to not lose some log entries while we are rotating the log file, it is to stop postgres, truncate the log file manually and start postgres again, I prefer to lose some log entries. This should not be a problem as long as this is documented and the user decides to do it this way. And you still have the option of not losing any entries and archive the old file if you want. But one thing should not prevent the other. regards, - -- Rafael Martinez Guerrero Center for Information Technology University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlEjWt4ACgkQBhuKQurGihTIpQCeJcOmKfnFDMqYllW2YUsywKVl BxgAoIF+R14GNlvNLNSgxR0lUDDQN23M =zrAw -END PGP SIGNATURE- -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
Rafael Martinez writes: > Well, postgreSQL is versatile enough to allow you to decide many > aspects of log rotation. It should be the user who decide what will > happen with log data after and during a rotation. TBH, I don't think the rotation configuration options need to cater for stupid choices, and what you're describing sounds like a stupid choice. Why wouldn't you configure, say, a finite set of daily- or hourly-named files? Even just ping-ponging between two log files would be enough to prevent the scenario where you lose the freshest log entries. If you don't care about keeping even the latest entries, then you don't need a log at all, much less rotation --- just pipe it to /dev/null. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 -- 1 Or: postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; xmlagg -- 12 (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
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
>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 > > > On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 > -- > 1 > Or: > postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; > xmlagg > -- > > 12 > (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 >
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 > >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 > >> >> >> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 >> -- >> 1 >> Or: >> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >> xmlagg >> -- >> >> 12 >> (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 >> > >
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
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 Sent: Tue, 19 Feb 2013 11:52:37 - (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 >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 On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 -- 1 Or: postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; xmlagg -- 12 (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
Re: [BUGS] BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2013 12:12 PM, Tom Lane wrote: > TBH, I don't think the rotation configuration options need to cater > for stupid choices, and what you're describing sounds like a stupid > choice. Why wouldn't you configure, say, a finite set of daily- or > hourly-named files? Even just ping-ponging between two log files > would be enough to prevent the scenario where you lose the freshest > log entries. > > If you don't care about keeping even the latest entries, then you > don't need a log at all, much less rotation --- just pipe it to > /dev/null. > > regards, tom lane Tom, I think we are talking past each other here. The point here is that if you need to run pg_rotate_logfile() manually is because something has happened in your system and you have taken the decision of running manually a log rotation that truncates the log file. Think about this usercase from real live: log_filename= 'postgres_%m.log' log_truncate_on_rotation = on log_rotation_age = 0 log_rotation_size = 0 We run pg_rotate_logfile() from cron every first day of the month at 00:00:01. This will give us 12 files that contain the logdata for the month defined in the file name and they will we recycled after one year because of the truncate parameter. Think now that because an error in an application, or because we have activated full logs for a period of time for debug purpouses, the size of the active log file has grown to a point where we have to take accion to avoid other problems (diskspace, parsing time, etc). We should be able to run pg_rotate_logfile() i.e. in the middle of the month and get the active logfile truncated if we are using log_truncate_on_rotation = on. Don't you think? In the way pg_rotate_logfile() and log_truncate_on_rotation = on work today, we have to stop postgres to truncate the log file if an unexpected situation happens and this is not always possible in a production system. If we need to run pg_rotate_logfile() manually in the middle of the month and we don't want to lose the data in the file that is going to be truncated, we will have to take a manual copy of it before running pg_rotate_logfile(). This is a real life administration problem that I have seen many times in different systems. We want and need logdata and to pipe it to /dev/null is not an option to us. truncate_on_rotation for us outside the development world of postgres, means that, the file will get truncated on rotation independently of the filename schema used. Thanks for your time. regards, - -- Rafael Martinez Guerrero Center for Information Technology University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlEjcLcACgkQBhuKQurGihRXAQCghoRbIbWVWqb7vhAXY1nDcLEQ n1QAn0e3me49/jWclcQ8iLKn2uL0A/mM =NShe -END PGP SIGNATURE- -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
On 19.02.2013 14:31, Rafael Martinez wrote: In the way pg_rotate_logfile() and log_truncate_on_rotation = on work today, we have to stop postgres to truncate the log file if an unexpected situation happens and this is not always possible in a production system. If we need to run pg_rotate_logfile() manually in the middle of the month and we don't want to lose the data in the file that is going to be truncated, we will have to take a manual copy of it before running pg_rotate_logfile(). You can rm the log file, then do pg_rotate_logfile(). No need to stop the system. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
It appears to be a Windows issue only. I'll try to post some code. 2013/2/19 Lou Picciano > 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 > Sent: Tue, 19 Feb 2013 11:52:37 - (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 > >> >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 >> >>> >>> >>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 >>> -- >>> 1 >>> Or: >>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >>> >>> >>> >>> xmlagg >>> -- >>> >>> 12 >>> (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 >>> >> >> > >
Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Hello 2013/2/16 Pavel Stehule : > 2013/2/16 Tom Lane : >> Bruce Momjian writes: >>> On Fri, Feb 15, 2013 at 04:06:12PM -0600, Dave Rolsky wrote: Fair enough. It should probably an option to add "if exists", at least. I can't imagine I'm the only using this tool to ship database updates around to different machines, some of which may not have new tables. I'd really like to be able to know when the restore fails versus when it succeeds but is noisy. >> >>> All I can say is I don't remember anyone asking for this in the past. >> >> I think it has come up before. I wouldn't object to a pg_dump option to >> add IF EXISTS to all the drop commands (though changing the default >> behavior would be more controversial). Don't intend to spend my own >> time on it though ... > > we use this feature more than one year. > > I'll send patch at Monday here is patch, that we use about one year - originally for 9.1 - I did port to 9.3 Regards Pavel > > Regards > > Pavel Stehule > > > >> >> regards, tom lane >> >> >> -- >> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-bugs conditional-drops.patch Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
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 > It appears to be a Windows issue only. > I'll try to post some code. > > > 2013/2/19 Lou Picciano > >> 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 >> Sent: Tue, 19 Feb 2013 11:52:37 - (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 >> >>> >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 >>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 -- 1 Or: postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; xmlagg -- 12 (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 >>> >>> >> >> >
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
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 > 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 > >> It appears to be a Windows issue only. >> I'll try to post some code. >> >> >> 2013/2/19 Lou Picciano >> >>> 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 >>> Sent: Tue, 19 Feb 2013 11:52:37 - (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 >>> >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 > > > On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 > -- > 1 > Or: > postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; > > > > xmlagg > -- > > 12 > (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 > >>> >>> >> >
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 > 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 > >> 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 >> >>> It appears to be a Windows issue only. >>> I'll try to post some code. >>> >>> >>> 2013/2/19 Lou Picciano >>> 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 Sent: Tue, 19 Feb 2013 11:52:37 - (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 > >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 > >> >> >> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 >> -- >> 1 >> Or: >> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >> >> >> >> xmlagg >> -- >> >> 12 >> (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 >> > > >>> >> >
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
Where can I check and/or alter this? 2013/2/19 Lou Picciano > I wonder if there's a difference in the implementation(s) of readline > buffering? > > > - Original Message - > From: Peter Kroon > To: Lou Picciano > Cc: Michael Paquier , pgsql-bugs@postgresql.org > Sent: Tue, 19 Feb 2013 15:28:47 - (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 > >> 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 >> >>> 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 >>> It appears to be a Windows issue only. I'll try to post some code. 2013/2/19 Lou Picciano > 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 > > > > > Sent: Tue, 19 Feb 2013 11:52:37 - (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 > >> >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 >> >>> >>> >>> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 >>> -- >>> 1 >>> Or: >>> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; >>> >>> >>> >>> xmlagg >>> -- >>> >>> 12 >>> (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 >>> >> >> > > >>> >> > >
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
I wonder if there's a difference in the implementation(s) of readline buffering? - Original Message - From: Peter Kroon To: Lou Picciano Cc: Michael Paquier , pgsql-bugs@postgresql.org Sent: Tue, 19 Feb 2013 15:28:47 - (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 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 nothingSelecting all fails as well. 2013/2/19 Peter Kroon 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 It appears to be a Windows issue only.I'll try to post some code. 2013/2/19 Lou Picciano 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 Sent: Tue, 19 Feb 2013 11:52:37 - (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 >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 On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 -- 1 Or: postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; xmlagg -- 12 (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
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
2013/2/19 Peter Kroon : > Where can I check and/or alter this? try to use pgAdminIII Regards Pavel > > > 2013/2/19 Lou Picciano >> >> I wonder if there's a difference in the implementation(s) of readline >> buffering? >> >> >> - Original Message - >> From: Peter Kroon >> To: Lou Picciano >> Cc: Michael Paquier , pgsql-bugs@postgresql.org >> Sent: Tue, 19 Feb 2013 15:28:47 - (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 >>> >>> 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 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 > > It appears to be a Windows issue only. > I'll try to post some code. > > > 2013/2/19 Lou Picciano >> >> 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 >> >> >> >> >> Sent: Tue, 19 Feb 2013 11:52:37 - (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 >>> >>> >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 On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon 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 -- 1 Or: postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM __table; xmlagg -- 12 (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 >>> >>> >> >> > >>> >> >> > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
>try to use pgAdminIII Could you be more specific? 2013/2/19 Pavel Stehule > 2013/2/19 Peter Kroon : > > Where can I check and/or alter this? > > try to use pgAdminIII > > Regards > > Pavel > > > > > > > 2013/2/19 Lou Picciano > >> > >> I wonder if there's a difference in the implementation(s) of readline > >> buffering? > >> > >> > >> - Original Message - > >> From: Peter Kroon > >> To: Lou Picciano > >> Cc: Michael Paquier , > pgsql-bugs@postgresql.org > >> Sent: Tue, 19 Feb 2013 15:28:47 - (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 > >>> > >>> 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 > > 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 > > > > It appears to be a Windows issue only. > > I'll try to post some code. > > > > > > 2013/2/19 Lou Picciano > >> > >> 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 > >> > >> > >> > >> > >> Sent: Tue, 19 Feb 2013 11:52:37 - (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 > >>> > >>> >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 > > > > On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon > 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 > -- > 1 > Or: > postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM > __table; > > > > xmlagg > -- > > 12 > (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 > >>> > >>> > >> > >> > > > > >>> > >> > >> > > >
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
2013/2/19 Peter Kroon : >>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 >> >> 2013/2/19 Peter Kroon : >> > Where can I check and/or alter this? >> >> try to use pgAdminIII >> >> Regards >> >> Pavel >> >> > >> > >> > 2013/2/19 Lou Picciano >> >> >> >> I wonder if there's a difference in the implementation(s) of readline >> >> buffering? >> >> >> >> >> >> - Original Message - >> >> From: Peter Kroon >> >> To: Lou Picciano >> >> Cc: Michael Paquier , >> >> pgsql-bugs@postgresql.org >> >> Sent: Tue, 19 Feb 2013 15:28:47 - (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 >> >>> >> >>> 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 >> >> 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 >> > >> > It appears to be a Windows issue only. >> > I'll try to post some code. >> > >> > >> > 2013/2/19 Lou Picciano >> >> >> >> 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 >> >> >> >> >> >> >> >> >> >> Sent: Tue, 19 Feb 2013 11:52:37 - (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 >> >>> >> >>> >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 >> >> >> >> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon >> 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 >> -- >> 1 >> Or: >> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM >> __table; >> >> >> >> xmlagg >> -- >> >> 12 >> (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 >> >>> >> >>> >> >> >> >>
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 > 2013/2/19 Peter Kroon : > >>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 > >> > >> 2013/2/19 Peter Kroon : > >> > Where can I check and/or alter this? > >> > >> try to use pgAdminIII > >> > >> Regards > >> > >> Pavel > >> > >> > > >> > > >> > 2013/2/19 Lou Picciano > >> >> > >> >> I wonder if there's a difference in the implementation(s) of readline > >> >> buffering? > >> >> > >> >> > >> >> - Original Message - > >> >> From: Peter Kroon > >> >> To: Lou Picciano > >> >> Cc: Michael Paquier , > >> >> pgsql-bugs@postgresql.org > >> >> Sent: Tue, 19 Feb 2013 15:28:47 - (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 > >> >>> > >> >>> 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 > >> > >> 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 > >> > > >> > It appears to be a Windows issue only. > >> > I'll try to post some code. > >> > > >> > > >> > 2013/2/19 Lou Picciano > >> >> > >> >> 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 > >> >> > >> >> > >> >> > >> >> > >> >> Sent: Tue, 19 Feb 2013 11:52:37 - (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 > >> >>> > >> >>> >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 > >> > >> > >> > >> 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 > >> -- > >> 1 > >> Or: > >> postgres=# SELECT xmlagg(xmlelement(name el_name, id)) FROM > >> __table; > >> > >> > >> > >> xmlagg > >>
Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3
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 To: Pavel Stehule Cc: Lou Picciano , Michael Paquier , pgsql-bugs@postgresql.org Sent: Tue, 19 Feb 2013 16:50:25 - (UTC) Subject: Re: [BUGS] Nested xmlagg doesn't give a result 9.2.3 >you can test your queries from pgAdmin SQL executorI have already done so. I'll look into the logs. 2013/2/19 Pavel Stehule 2013/2/19 Peter Kroon : >>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 >> >> 2013/2/19 Peter Kroon : >> > Where can I check and/or alter this? >> >> try to use pgAdminIII >> >> Regards >> >> Pavel >> >> > >> > >> > 2013/2/19 Lou Picciano >> >> >> >> I wonder if there's a difference in the implementation(s) of readline >> >> buffering? >> >> >> >> >> >> - Original Message - >> >> From: Peter Kroon >> >> To: Lou Picciano >> >> Cc: Michael Paquier , >> >> pgsql-bugs@postgresql.org >> >> Sent: Tue, 19 Feb 2013 15:28:47 - (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 >> >>> >> >>> 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 >> >> 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 >> > >> > It appears to be a Windows issue only. >> > I'll try to post some code. >> > >> > >> > 2013/2/19 Lou Picciano >> >> >> >> 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 >> >> >> >> >> >> >> >> >> >> Sent: Tue, 19 Feb 2013 11:52:37 - (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 >> >>> >> >>> >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 >> >> >> >> On Tue, Feb 19, 2013 at 5:50 PM, Peter Kroon >> wrote: >> > >> > Also no result with FROM __my_table LIMIT 1; >> >> I'm having correct results with PG 9.2 by using either xmlagg or >
[BUGS] BUG #7891: ODBC error on SQL_REAL
The following bug has been logged on the website: Bug reference: 7891 Logged by: Alain Reymond Email address: alain.reym...@ceia.com PostgreSQL version: 9.2.3 Operating system: Centos 5.9 (32 bits) Description: Hello, I use Postgresql 9.2.3 under Centos 5.9. (32 bits). We access our database through unixodbc (unixODBC-2.2.11-10.el5.i386). I have defined a table CREATE TABLE rresultats ( numbil integer, numparam smallint, mesure smallint, dev real ) I access the table via esql for cobol. When I try to insert a record in the table, I get a sqlcode = -7 in return. It seems that SQL_REAL is not properly mapped to the comp-1 in cobol ( = float in C). Here is the logfile : [ODBC][19186][SQLBindParameter.c][193] Entry: Statement = 0x83227c8 Param Number = 4 Param Type = 1 C Type = 7 SQL_C_FLOAT SQL Type = 7 SQL_REAL Col Def = 7 Scale = 0 Rgb Value = 0x83225a8 Value Max = 4 StrLen Or Ind = 0x83225a4 [ODBC][19186][SQLBindParameter.c][339] Exit:[SQL_SUCCESS] [ODBC][19186][SQLExecute.c][183] Entry: Statement = 0x83227c8 [ODBC][19186][SQLExecute.c][344] Exit:[SQL_ERROR] DIAG [S1000] ERREUR: syntaxe en entrée invalide pour le type real : « 15,5 » au caractère 141; Error while executing the query [ODBC][19186][SQLError.c][342] Entry: Statement = 0x83227c8 SQLState = 0x82e434a Native = 0xbfa1e540 Message Text = 0x82e4350 Buffer Length = 1023 Text Len Ptr = 0xbfa1e546 [ODBC][19186][SQLError.c][379] Exit:[SQL_SUCCESS] SQLState = S1000 Native = 0xbfa1e540 -> 7 Message Text = [[unixODBC]ERREUR: syntaxe en entrée invalide pour le type real : « 15,5 » au caractère 141; Error while executing the query] I tried with double precision : same thing. Curiously, we have a version using unixODBC-2.2.11-7.1 and Posgresql 8.4 and have no problem... Regards -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7897: RPM fails to set up links for all the tools
The following bug has been logged on the website: Bug reference: 7897 Logged by: Mike Baranczak Email address: mbaranc...@gmail.com PostgreSQL version: 9.2.3 Operating system: centos 6.3 Description: Installed 9.2.3-2PGDG.rhel6 from the PG repo, as described here: http://wiki.postgresql.org/wiki/YUM_Installation I expected all the tools in /usr/pgsql-9.2/bin/ to be available on the PATH, but pg_ctl, pg_receivexlog and pg_resetxlog are not. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7897: RPM fails to set up links for all the tools
mbaranc...@gmail.com wrote: >The following bug has been logged on the website: > >Bug reference: 7897 >Logged by: Mike Baranczak >Email address: mbaranc...@gmail.com >PostgreSQL version: 9.2.3 >Operating system: centos 6.3 >Description: > >Installed 9.2.3-2PGDG.rhel6 from the PG repo, as described here: >http://wiki.postgresql.org/wiki/YUM_Installation > >I expected all the tools in /usr/pgsql-9.2/bin/ to be available on the >PATH, >but pg_ctl, pg_receivexlog and pg_resetxlog are not. > > > >-- >Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-bugs Hi, The ones that are in $PATH are the ones that can be used with multiple versions, like psql, etc, since we support multiple version installation. Regards, Devrim -- Devrim Gündüz
