> I strongly disagree. The BOM provides a useful and standard way to
> differentiate UTF-8 encoded text files from the random pile of encodings that
> any given file could be.
I agree on the concept, but I'm having a bit of trouble understanding how a
"Byte Order Marker" is useful to an 8-bit
Tom,
As its AIX I don't have top but using topas and comparing it to other processes
running a successful pg_dumpall doesn't get very large at all.
The database only has around 1000 tables and no more than anpther 500 view,
triggers, functions, etc. so its not a big database. There are no BLOBs
On Fri, Sep 21, 2012 at 09:21:36AM +0800, Craig Ringer wrote:
> On 09/20/2012 11:44 PM, Leif Biberg Kristensen wrote:
> > Torsdag 20. september 2012 16.56.16 skrev Alan Millington :
> >>psql". But how am I supposed to remove the byte order mark from a UTF8
> >>file? I thought that the whole point
hubert depesz lubaczewski wrote:
> When I enabled normal stderr logging, with absurdly full
> log_line_prefix, I got this:
> a[psql] u[depesz] d[depesz] r[[local]] h[[local]] p[15444] t[2012-09-13
> 21:49:37 CEST] m[2012-09-13
> 21:49:37.840 CEST] i[SELECT] e[0] c[505238d0.3c54] l[4] s[2012-0
On Fri, Sep 21, 2012 at 11:54:27AM +0200, Albe Laurenz wrote:
> This makes automatic parsing of log files possible:
> if a line starts with a tab, it is a continuation line.
> The tab itself is not part of the message.
why the tab isn't appended for other multi-line messages? like queries
in LOG:
Arvind Singh wrote:
> Our CSV Log contains lot of statements like the following THREE lines.
They appear exactly one after
> the other.
>
> And they number in thousands for a Session (more than ten thousand)
>
>
> 2011-11-11 12:41:31.484
IST,"agent1","pem",524,"localhost:2141",4ebccaa2.20c,754,"
depesz wrote:
>> This makes automatic parsing of log files possible:
>> if a line starts with a tab, it is a continuation line.
>> The tab itself is not part of the message.
> why the tab isn't appended for other multi-line messages? like queries
> in LOG: duration: statement: lines?
I'm not sure
we have been working on a CSV Log parser application in csharp.
we recently discovered that certain log entries or records can span across
multiple lines.
in the sense, that the same activity has more detail in subsequent lines.
For ex, a select,insert query has
A query entry
A Duration en
Arvind Singh wrote:
> we have been working on a CSV Log parser application in csharp.
>
> we recently discovered that certain log entries or records can span
across multiple lines.
>
> in the sense, that the same activity has more detail in subsequent
lines.
Not really, they are different log ent
On 21 September 2012 07:50, Alban Hertroys wrote:
> On 20 Sep 2012, at 20:36, Benedikt Grundmann wrote:
>
> > So named anonymous records / row types seem to be strangely second
> class. Can somebody clarify the restrictions and rationale or even better
> show a way to do the equivalent of (made
On Fri, Sep 21, 2012 at 12:25:09PM +0200, Albe Laurenz wrote:
> So there is a tab prepended.
Sorry, you're right.
Best regards,
depesz
--
The best thing about modern society is how easy it is to avoid contact with it.
http://depesz.c
On Fri, Sep 21, 2012 at 4:18 AM, Benedikt Grundmann
wrote:
>
> On 21 September 2012 07:50, Alban Hertroys wrote:
>>
>> On 20 Sep 2012, at 20:36, Benedikt Grundmann wrote:
>>
>> > So named anonymous records / row types seem to be strangely second
>> > class. Can somebody clarify the restrictions
Hello,
I have two postgresql servers 9.1.5 and 8.4.8 running on ubuntu machine, both
are fresh installs and both has the same configuration files and databases.
I am running queries sequentially on each machine using a database dumped from
a life server , and 9.1 server is much slower than 8
On 09/20/2012 10:27 AM, Alan Millington wrote:
Thank you for the link. I am using Notepad, which inserts the byte order
mark. Following the links a bit further, I gather that the version of
Notepad that I am using may not identify a UTF8 file correctly if the
byte order mark is omitted. Also, as
"Carrington, Matthew (Produban)" writes:
> As its AIX I don't have top but using topas and comparing it to other
> processes running a successful pg_dumpall doesn't get very large at all.
Hmm. Best guess at this point is that there's some specific DDL in your
database that confuses some recent
Yes, (I think) is a Bug, sometimes in some circumstances pg_ctl go down but
postgres server still running.
You can easily reproduce.
Go to "task manager", kill the process "pg_ctl" (simulate some kind of crash
or something else).
Now go to services management and try to start again. Start command
> select * from (values (1, 2, 3)) x (a, b, c);
> select x.* from (values (1, 2, 3)) x (a, b, c);
And more fun with values:
select a, b, c from (values (1, 2, 3), (4, 5, 6), (7, 8, 9)) x (a, b, c);
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
-
Another PostgreSQL Diff Tool 2.4 released
-
Another PostgreSQL Diff Tool (also known as apgdiff) is free PostgreSQL
database schema diff tool.
Project homepage: http://apgdiff.startnet.biz/
Release information
---
This release brings sever
On Thu, Sep 20, 2012 at 1:46 PM, Victor Yegorov wrote:
> Take a look at this part of the documentation:
> http://www.postgresql.org/docs/current/interactive/routine-vacuuming.html#VACUUM-FOR-SPACE-RECOVERY
>
> The “missing” entries belong to the tuples that you have DELETEd/UPDATEd and
> that are
On Fri, Sep 21, 2012 at 7:32 AM, salah jubeh wrote:
> Hello,
>
> I have two postgresql servers 9.1.5 and 8.4.8 running on ubuntu machine,
> both are fresh installs and both has the same configuration files and
> databases.
>
> I am running queries sequentially on each machine using a database du
2012/9/21 Jeff Janes
> To start with, it can be as you say where the ctid and its tuple are
> interesting to someone, but not to you. But eventually the tuple is
> not interesting to anyone, and its space can be reused. But the ctid
> is still needed (to inform stragglers that it's correspondin
On Fri, Sep 21, 2012 at 8:32 AM, salah jubeh wrote:
> Hello,
>
> I have two postgresql servers 9.1.5 and 8.4.8 running on ubuntu machine,
> both are fresh installs and both has the same configuration files and
> databases.
>
> I am running queries sequentially on each machine using a database du
On Fri, Sep 21, 2012 at 12:39 PM, Benedikt Grundmann
wrote:
> On 21 September 2012 14:04, Merlin Moncure wrote:
>>
>> On Fri, Sep 21, 2012 at 4:18 AM, Benedikt Grundmann
>> wrote:
>> >
>> > On 21 September 2012 07:50, Alban Hertroys wrote:
>> >>
>> >> On 20 Sep 2012, at 20:36, Benedikt Grundman
If its not too much work, swap them around and retest to see if its really the
DB/version or the machine.
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Scott Marlowe
Sent: Friday, September 21, 2012 3:01 PM
To: salah
One thing I sometimes forget to do after loading up an empty DB with data is to
run "analyze". I usually "remember" once I see poor query performance, run the
analyze, and its fixed.
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org]
On Fri, Sep 21, 2012 at 2:23 PM, Merlin Moncure wrote:
> On Fri, Sep 21, 2012 at 12:39 PM, Benedikt Grundmann
> wrote:
>> On 21 September 2012 14:04, Merlin Moncure wrote:
>>>
>>> On Fri, Sep 21, 2012 at 4:18 AM, Benedikt Grundmann
>>> wrote:
>>> >
>>> > On 21 September 2012 07:50, Alban Hertro
On Fri, Sep 21, 2012 at 11:41 AM, Victor Yegorov wrote:
>
> It seems that this also matches your explanation, correct me if I'm wrong.
I think that the explanations do generally match. But, just because
you observe that the ctid space has not been reused (like the OP did),
does not mean that the
On Fri, Sep 21, 2012 at 12:45 PM, Jeff Janes wrote:
> On Fri, Sep 21, 2012 at 11:41 AM, Victor Yegorov wrote:
>>
>> It seems that this also matches your explanation, correct me if I'm wrong.
>
> In general, doing "select ctid..." is a poor way of figuring out
> where the space in your database i
On Sun, Sep 2, 2012 at 10:08 PM, Peter Eisentraut wrote:
> On Wed, 2012-08-29 at 10:31 -0700, Aleksey Tsalolikhin wrote:
>> What is the difference between C and en_US.UTF8, please?
>
> There are many differences, but here is a simple one:
>
> $ (echo a; echo A; echo b; echo B) | LC_ALL=C sort
> ..
On Fri, Sep 21, 2012 at 11:30 AM, Jeff Janes wrote:
> At that point the ctid can be re-used, but only if someone actually
> wants a "new" ctid on that page. An ordinary vacuum will not close up
> the gaps on un-used ctids. Only a vaccum full will do that.
There are a couple of ways to do that e
Has there been any discussion regarding adding a time-limited version of
NOWAIT, say: "WAITONLY 50" (milliseconds), when dealing the explicit LOCK
TABLE or the SELECT.FOR(SHARE|UPDATE) commands?
David J.
On 09/21/12 7:43 PM, David Johnston wrote:
Has there been any discussion regarding adding a time-limited version
of NOWAIT, say: “WAITONLY 50” (milliseconds), when dealing the
explicit LOCK TABLE or the SELECT…FOR(SHARE|UPDATE) commands?
is this a feature in any other major databases?
is this
If one releases an extension with say a version number of 0.1 and then
releases one with important changes at 0.2, how is the best way to manage
these changes? I couldn't find anything in the docs to discuss this issue.
Am I missing something?
Specifically for pg_message_queue, for 0.2 I would l
On Sep 22, 2012, at 0:08, John R Pierce wrote:
> On 09/21/12 7:43 PM, David Johnston wrote:
>> Has there been any discussion regarding adding a time-limited version of
>> NOWAIT, say: “WAITONLY 50” (milliseconds), when dealing the explicit LOCK
>> TABLE or the SELECT…FOR(SHARE|UPDATE) commands?
On Fri, Sep 21, 2012 at 7:43 PM, David Johnston wrote:
> Has there been any discussion regarding adding a time-limited version of
> NOWAIT, say: “WAITONLY 50” (milliseconds), when dealing the explicit LOCK
> TABLE or the SELECT…FOR(SHARE|UPDATE) commands?
I think you could do this by issuing
35 matches
Mail list logo
