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 lik
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;--g
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?
N
-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,
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.
-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_siz
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 choic
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
>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:
>
> 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 sur
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
-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
>
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_logfil
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
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
upd
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 tha
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
> returne
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
> Sele
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
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
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 Picci
>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
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/o
>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 er
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 C
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
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:
ht
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 f
28 matches
Mail list logo
