Hi,
Which is the quickest way to troubleshot the message "
LOG: configuration file "/postgresql.conf" contains errors;
unaffected changes were applied"" ?
I made a couple of changes a few days ago, and did not reload Today I made
some more changes and did a pg_ctl reload.
Is there an optio
Jayadevan M writes:
> Which is the quickest way to troubleshot the message "
> LOG: configuration file "/postgresql.conf" contains errors;
> unaffected changes were applied"" ?
There should be log message(s) before that one complaining about the
specific problems.
re
Thanks. This is what I have. May be it is not really an error?
2013-10-18 12:23:54.996 IST,,,8855,,523c23ea.2297,20,,2013-09-20 16:01:06
IST,,0,LOG,0,"received SIGHUP, reloading configuration files",""
2013-10-18 12:23:54.996 IST,,,8855,,523c23ea.2297,21,,2013-09-20 16:01:06
IST,,0,LOG
On Fri, Oct 18, 2013 at 2:01 PM, Jayadevan M wrote:
> Thanks. This is what I have. May be it is not really an error?
>
> 2013-10-18 12:23:54.996 IST,,,8855,,523c23ea.2297,20,,2013-09-20 16:01:06
> IST,,0,LOG,0,"received SIGHUP, reloading configuration files",""
> 2013-10-18 12:23:54.99
Le mardi 15 octobre 2013 à 08:52 -0700, ginkgo36 a écrit :
> 1. I want to sort string follow anphabet and I used this query:
> select string_agg(x, ';') from (select
> trim(unnest(regexp_split_to_array('ECD FORM; BODY; PREDILUTED; CHROMO-GENIC;
> AUTO;RABBIT; FORMAT',';'))) x order by x) a;
>
> -
Thank you for your reply.
In my opinion, that is ugly to the point of uselessness. I think I would
rather just use simple integer arithmetic. It will be easier for others to
understand.
RobR
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Thursday, October
Rob Richardson writes:
> In my opinion, that is ugly to the point of uselessness.
Indeed :-(
For some reason, there's no constructor function to make a box from four
floats. But there is a box constructor that takes two points, as well
as a point constructor that takes two floats; so you could
On Fri, Oct 18, 2013 at 10:05 AM, Tom Lane wrote:
> Rob Richardson writes:
>> In my opinion, that is ugly to the point of uselessness.
>
> Indeed :-(
>
> For some reason, there's no constructor function to make a box from four
> floats. But there is a box constructor that takes two points, as we
On 10/18/2013 08:07 AM, Helen Griffiths wrote:
Hello.
I've got a table set up on server B to store the logs from server A, as
outlined in
http://www.postgresql.org/docs/8.4/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG
Every day, I set \encoding SQL_ASCII on server B (ser
Hello.
I've got a table set up on server B to store the logs from server A, as
outlined in
http://www.postgresql.org/docs/8.4/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG
The table is defined as follows:
postgres=# \d maincluster_log
Table "public.mainc
On Fri, 18 Oct 2013 17:05:07 +0200
Tom Lane wrote:
> For some reason, there's no constructor function to make a box from
> four floats. But there is a box constructor that takes two points,
> as well as a point constructor that takes two floats; so you could do
> something like
>
> box(poi
"D'Arcy J.M. Cain" writes:
> ... In fact, this seems to work already if
> quotes are added:
> box('(0, 1), (2, 3)')
Well, that's just another spelling for a box literal, which is exactly
what the OP *doesn't* want, since he's trying to construct a box value
from non-constant values.
Hi,
When we create an index, i believe the postgres engine it self update it's
catalog about the index availability.
"ANALYZE" helps you to find the right plan according to the number of rows
got selected. I don't think, "ANALYZE" take care of updating the index
entries.
I might be wrong here, h
dinesh kumar writes:
> When we create an index, i believe the postgres engine it self update it's
> catalog about the index availability.
ANALYZE normally collects statistics about the contents of table columns.
Thus, adding (or removing) an index does not create any reason to
re-ANALYZE.
Howeve
Thanks Victor. The states were idle indeed but my application was not
getting the results from that connections back. I have just found that
there were 2 of the threads issuing queries to the same connection in
parallel.
That was the origin of the problem indeed.
Best Regards,
Svetlin Manavski
Hey,
Can you check the line 424855 in the file maincluster-20131011.csv .
Yo may have a comma in unprotected field, or empty field, or wrong end
line, etc.
Cheers,
Rémi -C
2013/10/18 Adrian Klaver
> On 10/18/2013 08:07 AM, Helen Griffiths wrote:
>
>> Hello.
>>
>> I've got a table set up on s
Hi,
On 18 Říjen 2013, 17:06, akp geek wrote:
> when I issue the top command on solaris, what ever I have posted is
> exactly
> getting.
>
> top -n
> load averages: 11.4, 10.8, 10.2;up 680+21:31:46
> 15:05:21
> 137 processes: 123 sleeping, 14 on cpu
> CPU states: 82.0% idle,
Would a simple multi-column index be considered an 'expression' in this
context, meaning that an ANALYZE should be issued after the creation of such an
index?
---
Pete Yunker
Vice President of Data Products
Home Junction, Inc.
On Oct 18, 2013, at 11:42 AM, Tom Lane wrote:
> dinesh kumar writ
Pete Yunker writes:
> Would a simple multi-column index be considered an 'expression' in this
> context, meaning that an ANALYZE should be issued after the creation of such
> an index?
No. Of course, if one of its columns were an expression, then that would
be of interest for ANALYZE.
There h
It looks to me like there's one extra column in the line. There are 8
fields after "detail" in the log line but only 7 fields after "detail" in
the table.
On Fri, Oct 18, 2013 at 8:17 AM, Adrian Klaver wrote:
> On 10/18/2013 08:07 AM, Helen Griffiths wrote:
>
>> Hello.
>>
>> I've got a table set
I am running Postgres 9.3 on RedHat Linux 5.6.
During the transaction data is deleted from our database, then an analyze is
performed.
If I analyze our database during a transaction and the transaction fails
(rollback occurs), with the table statistics rollback to their original
values?
--
Vie
Hi,
In 9.2 docs, the first link (i18ngurus) in the further reading section here:
http://www.postgresql.org/docs/9.2/static/multibyte.html
seems to be broken. Should it be updated/removed?
(I see it's removed in 9.3 docs)
--
Amit Langote
--
Sent via pgsql-general mailing list (pgsql-general@p
On Fri, 18 Oct 2013, Adrian Klaver wrote:
This came up before recently in this thread:
http://www.postgresql.org/message-id/CADK3HHJNEWKD9gNyXmjv9ABbn+37rY3Mvp9=1j7msg9ypob...@mail.gmail.com
To cut to the chase, in that case the OP found:
"Ok, I found the offending line. It was not the pgadmi
Your welcome;
Best wishes for fixes =)
Cheers,
Rémi-C
2013/10/18 Helen Griffiths
> On Fri, 18 Oct 2013, Adrian Klaver wrote:
>
> This came up before recently in this thread:
>>
>> http://www.postgresql.org/**message-id/**CADK3HHJNEWKD9gNyXmjv9ABbn+**
>> 37rY3Mvp9=1j7msg9YpoBBBw@mail.**gmail
On 10/18/13 12:28 PM, bobJobS wrote:
> If I analyze our database during a transaction and the transaction fails
> (rollback occurs), with the table statistics rollback to their original
> values?
Yes.
ANALYZE isn't really that special. It reads data from some tables, does
some math on it, and wr
I thought this was interesting, and wanted to make sure I understood what
is going on, but the more tests I run the more confused I get.
if I take the exact set up outlined by Mosche I get the same results in 9.3
(as expected) , but if I insert one row before I run the sql the CTE is
executed and
ajeli...@gmail.com wrote
> but if I insert one row before I run the sql the CTE is
> executed and I get a new row in the table. I was hoping that I would see
> a
> difference in the explain, but the explain with an empty table where the
> CTE is *not* executed is identical to the explain where the
On Wed, Oct 16, 2013 at 7:14 PM, Rowan Collins wrote:
> On 17/10/2013 00:06, Merlin Moncure wrote:
>
> That being said, I do think it might be better behavior (and still
> technically correct per the documentation) if volatile query
> expressions were force-evaluated.
>
>
> This sounds reasonable
Merlin Moncure-2 wrote
> If you wanted to structure the query so that the function was run only
> 10 times, that could be done trivially by moving the limit inside the
> CTE.
It is not trivial if you want to wrap the CTE expression into a VIEW and the
caller of the view only wishes to see/evaluate
On Fri, Oct 18, 2013 at 4:08 PM, David Johnston wrote:
> And why is volatile so special here? A stable function seems just as good a
> candidate for this behavior and even an immutable one.
Absolutely disagree with this. Stable operations do not have side
effects and volatile operations do (or
I'm on Debian Wheezy running postgres 9.3
both boxes are identical.
I see in log file on slaves:
LOG: could not receive data from client: Connection reset by peer
OpenSSL is the same version on master and slaves. The libssl is also too.
I set ssl_renegotiation=0. So not sure why i'm seeing
>Would help to include the explain(s). Did you ANALYZE after the insert; if
>not the planner probably still thought the table was empty (thus the
>matching explain) but upon execution realized it had records and thus
needed
>to run the CTE.
I did not do an ANALYZE after the insert, I think the pl
Merlin Moncure-2 wrote
> Regardless, the point at hand is whether specific plan semantics down
> the chain can control whether or not volatile expressions should run.
> Clearly, at least to me, they should not.
I don't personally see any solid reason to reject the always evaluate CTEs
with volatil
33 matches
Mail list logo
