Scot Kreienkamp writes:
> There wasn't any output from the initdb other than OK.
> [root@dvrv5030 9.1]# /etc/init.d/postgresql-9.1 initdb --lc-collate=C
> Initializing database: [ OK ]
Um. This isn't running initdb: this is running the package's initscript
a
Dave,
The WAL files were copied using rsync. It seems there is no problem to copy the
file over to secondary nodes. It is the primary node somehow keeps more and
more old WAL files in the pg_xlog directory.
Regards,
Dong
From: davecra...@gmail.com [dave
Hello,
>
> Some of the features currently under development right now will make
> this sort of thing easier to build into the core database. For
> example, the recent "Command Triggers" feature submission will make
> it easier to catch DDL changes as well as queries for this sort of
thing.
Tha
There wasn't any output from the initdb other than OK.
[root@dvrv5030 9.1]# /etc/init.d/postgresql-9.1 initdb --lc-collate=C
Initializing database: [ OK ]
[root@dvrv5030 9.1]# /etc/init.d/postgresql-9.1 start
Starting postgresql-9.1 service:
Dong,
How are you copying the wal logs over to the secondary ? Since this is
loosely coupled I am wondering how the master would be effected by
load.
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Tue, Dec 13, 2011 at 12:42 AM, Dong Han wrote:
> Dear all,
>
>
>
> We hav
Dear all,
We have setup log shipping replication between primary node and 2 secondary
nodes with Postgresql version 8.4.8. From the data replication points of view,
everything is fine. However, under heavy data modification load - we have an
extremely busy system, we saw WAL files keep accumul
Chris Angelico writes:
> 1) Set a bit:
> UPDATE tablename SET flags=flags|8 WHERE id=1234
> 2) Clear a bit:
> UPDATE tablename SET flags=flags&~8 WHERE id=1234
> However, the second statement fails; the Postgres parser tries to find
> a single "&~" operator, instead of using the unary ~ and then
On 13/12/2011 12:18 AM, Sogard, Michael (DPS) wrote:
A little more information that may help, the service works fine as a
local user. The problem only happens when we try to start it as a
network user on the domain. As far as registering the service goes, I
am not sure of the details of the ins
Greetings! Apologies if this is the wrong place to ask this question.
I'm using Postgres (just upgraded from 9.1.1 to 9.1.2 but I don't
think it's significant) for some work that includes maintaining a
bitfield. The most common operations on this field are:
1) Set a bit:
UPDATE tablename SET flag
On 12/12/2011 12:37 PM, Scot Kreienkamp wrote:
Nope no clusters. I never got past the initial install and configure.
All I did was install, initdb, alter a few things in postgresql.conf (nothing
relating to locale) and pg_hba.conf, start postgres using the init script, and
run the query
On 12/12/2011 12:37 PM, Scot Kreienkamp wrote:
Nope no clusters. I never got past the initial install and configure.
All I did was install, initdb, alter a few things in postgresql.conf (nothing
relating to locale) and pg_hba.conf, start postgres using the init script, and
run the query
Nope no clusters. I never got past the initial install and configure.
All I did was install, initdb, alter a few things in postgresql.conf (nothing
relating to locale) and pg_hba.conf, start postgres using the init script, and
run the query to check the collation setting. Nothing more.
S
On 12/12/2011 12:15 PM, Adrian Klaver wrote:
On 12/12/2011 10:49 AM, Scot Kreienkamp wrote:
Hey guys,
In PG 8.x, when I did an initdb with --lc-collate=c it was always
effective in setting it server wide so it would apply to all databases.
However, in 9.1.2, when I run initdb like so: /etc/init
On 12/12/2011 10:49 AM, Scot Kreienkamp wrote:
Hey guys,
In PG 8.x, when I did an initdb with --lc-collate=c it was always
effective in setting it server wide so it would apply to all databases.
However, in 9.1.2, when I run initdb like so: /etc/init.d/postgresql-9.1
initdb --lc-collate=C, it do
> Andreas Brandl writes:
> >> The planner doesn't use n_live_tup;
>
> > I'm just curious: where does the planner take the (approximate)
> > row-count from?
>
> It uses the tuple density estimated by the last vacuum or analyze
> (viz,
> reltuples/relpages) and multiplies that by the current relat
Hey guys,
In PG 8.x, when I did an initdb with --lc-collate=c it was always effective in
setting it server wide so it would apply to all databases. However, in 9.1.2,
when I run initdb like so: /etc/init.d/postgresql-9.1 initdb --lc-collate=C,
it doesn't seem to have any effect.
[root@dvrv50
Hallo,
psql latex output format needs to differentiate between a newline and a
tabularnewline.
the problem arises when u have a field value that contains a newline
character, when this field is not the first column, then all the data
after this newline comes in the first column..
u can try this
> Please also remove postgresql90-libs.i386
Thanks a lot. Works perfect now.
Best regards
Wojtek
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Like most problems, this was stupidity on my part!
I had an old test copy of postgres running on the same port of this windows
laptop, so of course I was connecting to that instead of the SSH tunnel
that was set up by Putty.
Problem solved, thanks for the help
On Thu, Dec 8, 2011 at 3:40 PM, C
On Mon, Dec 12, 2011 at 12:23 PM, Andreas Kretschmer
wrote:
> - you should use 9.1.2, not 9.1.1 ;-)
I don't think it's available yet in Debian repositories. I can only
use whatever packages they've compiled in their repositories.
> - use the pg_dumpall from the new version to make the dump, for
Le 12 décembre 2011 18:12, Carlos Mennens a écrit :
> I've finally received my new virtual database server (Debian Linux) &
> this weekend I'll be rolling my new PostgreSQL server online. My
> question is I've never migrated production data from 8.4.8 to 9.1.1. I
> would like to find out from the
Carlos Mennens wrote:
> I've finally received my new virtual database server (Debian Linux) &
> this weekend I'll be rolling my new PostgreSQL server online. My
> question is I've never migrated production data from 8.4.8 to 9.1.1. I
> would like to find out from the community what exactly is the
I've finally received my new virtual database server (Debian Linux) &
this weekend I'll be rolling my new PostgreSQL server online. My
question is I've never migrated production data from 8.4.8 to 9.1.1. I
would like to find out from the community what exactly is the
recommended process in moving m
The application log has this entry:
The description for Event ID ( 0 ) in Source ( PostgreSQL ) cannot be found.
The local computer may not have the necessary registry information or message
DLL files to display messages from a remote computer. You may be able to use
the /AUXSOURCE= flag to retr
Thanks a lot.
Worked fine with .
CREATE DATABASE danny
Template template0
LC_CTYPE = 'C'
LC_COLLATE = 'C';
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Monday, December 12, 2011 6:07 PM
To: Abraham, Danny
Cc: Adrian Klaver; pgsql-general@postgresql.org
Subje
On Monday, December 12, 2011 7:55:37 am Abraham, Danny wrote:
> This is exactly what I am trying to do -
> To find a CREATE DATABASE statement that will produce a database that has a
> binary sorting.
http://www.postgresql.org/docs/9.0/interactive/sql-createdatabase.html
CREATE DATABASE name
[
"Abraham, Danny" writes:
> This is exactly what I am trying to do -
> To find a CREATE DATABASE statement that will produce a database that has a
> binary sorting.
Setting its LC_COLLATE to "C" ought to do that.
BTW, as of 9.1 you can control this at finer granularity than database
level, see t
Thanks for the support guys, if nothing else, this week has been memorable. :)
It seems I lied on my entry--my little brother didn't have my old
capsule models. They were actually still back in my childhood bedroom:
http://twitpic.com/7sc0jv The covered in dust thing was still correct
though :)
N
This is exactly what I am trying to do -
To find a CREATE DATABASE statement that will produce a database that has a
binary sorting.
Thanks
Danny
-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@gmail.com]
Sent: Monday, December 12, 2011 5:53 PM
To: pgsql-general@postgresql
On Sunday, December 11, 2011 8:17:41 am Abraham, Danny wrote:
> On PG 9.0.4, Windows, Encoding and Collate WIN1252 trying to get a
> database to sort according to the ascii order. Example:
> Select t from test order by t
> Should be exactly like
> Select t from test order by ascii(t).
>
> Can it
On Dec 12, 2011, at 9:00 PM, Sogard, Michael (DPS) wrote:
> We are running Postgresql 9.0 64-bit on a Windows Server 2003 machine.
> Whenever we try to start the postgresql-x64-9.0 service, we eventually get
> the error “The postgresql-x64-9.0 service on Local Computer started and
> stopped.”
On Sunday, December 11, 2011 8:30:35 am Abraham, Danny wrote:
> What's wrong with locale WIN1252 ?
>
> Running successfully initdb, but strange warnings show ...
>
>
> The files belonging to this database system will be owned by user "EMPG".
> This user must also own the server process.
>
> The
On Sun, Dec 11, 2011 at 9:10 PM, Craig Ringer wrote:
> On 12/12/2011 09:15 AM, David Johnston wrote:
>>
>> Use a WITH clause on the SELECT statement.
>
> Note that WITH is an optimisation fence, so if you're relying on Pg pushing
> WHERE clauses down into subqueries or anything like that you may f
This message has been digitally signed by the sender.
Re___GENERAL__Problem_installing_PG9_1_using_yum.eml
Description: Binary data
-
Hi-Tech Gears Ltd, Gurgaon, India
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
We are running Postgresql 9.0 64-bit on a Windows Server 2003 machine. Whenever
we try to start the postgresql-x64-9.0 service, we eventually get the error
"The postgresql-x64-9.0 service on Local Computer started and stopped." The
user account trying to start the service has administrator right
On Mon, 2011-12-12 at 16:26 +0100, Wojciech Strzałka wrote:
>
> Thanks Devrim - it's a little better now but still not perfect :)
> There is some problem with libpq messages.
Please also remove postgresql90-libs.i386
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://ww
> On Sun, 2011-12-11 at 09:17 -0800, wstrzalka wrote:
>> Error: Package postgresql90-devel needs postgresql90 =
>> 9.0.1-4PGDG.rhel5, this is not available.
> Please remove postgresql90-devel.i386 prior to installation.
> We don't push -devel.i386 packages to x86_64 repos anymore.
> Regards,
Le 12 décembre 2011 14:25, Mark Morgan Lloyd
a écrit :
> Rob Sargent wrote:
>>
>> On 12/06/2011 01:56 PM, Glyn Astill wrote:
>>>
>>> __
>>>
From: Merlin Moncure
To: Joe Miller Cc: pgsql-general@postgresql.org
Sent: Tuesday, 6 December 2011, 17:30
S
Rob Sargent wrote:
On 12/06/2011 01:56 PM, Glyn Astill wrote:
__
From: Merlin Moncure
To: Joe Miller
Cc: pgsql-general@postgresql.org
Sent: Tuesday, 6 December 2011, 17:30
Subject: Re: [GENERAL] PostgreSQL DBA in SPCE
On Tue, Dec 6, 2011 at 10:56 AM, J
On Sat, Dec 10, 2011 at 9:28 PM, Craig Ringer wrote:
>
> One thing I think would be interesting for this would be to identify slow
> queries (without doing detailed plan timing) and flag them for more
> detailed timing if they're run again within time. I suspect this would
> only be practical wi
On 12/09/2011 08:54 PM, Greg Smith wrote:
I decided about a year ago that further work on using Systemtap was a
black hole: time goes in, nothing really usable on any production
server seems to come out.
My off-list e-mail this weekend has, quite rightly, pointed out that
this cheap shot is
On 12/11/2011 11:39 PM, Jayadevan M wrote:
At the db level, Oracle provides "Database replay" feature. that lets
you replay the production server events in the development/test
environment.
http://docs.oracle.com/cd/B28359_01/server.111/e12253/dbr_intro.htm
Won't something like this be useful i
Le 12 décembre 2011 01:42, Stefan Keller a écrit :
> I'd like to clear the PostgreSQL cache (e.g. for benchmarking purposes).
> And I'd like to preload all tuples of a table (say mytable_one) into the
> cache.
>
> AFAIK there is no way to force all caches to be cleared in PostgreSQL
> with an SQL
43 matches
Mail list logo
