Ok,
So by that token (more drives the better), I should have raid 5 (or
whichever will work) with all 6 drives in it ?
I was thinking about splitting it up like this. I have 6 drives (and one
spare). Combine them into 3 separate logical drives in mirrored
configuration (for some hardware
On 12 March 2013 21:59, John R Pierce pie...@hogranch.com wrote:
On 3/12/2013 2:31 PM, Gregg Jaskiewicz wrote:
I was basically under impression that separating WAL is a big plus. On
top of that, having separate partition to hold some other data - will do
too.
But it sounds - from what you
On 10 March 2013 02:19, Scott Marlowe scott.marl...@gmail.com wrote:
First get a baseline for how things work with just pg_xlog on one
small set (RAID 1 is often plenty) and RAID-10 on all the rest with
all the data (i.e. base directory) there. With a fast HW RAID
controller this is often
Performance related question.
With Linux (centos 6.3+), 64bit, ext4 in mind, how would you guys go about
distributing write load across disks.
Lets say I have quite few disks, and I can partition them the way I want,
in mirror configuration (to get some hardware failure resilience). Should I
Hi guys,
I'm looking into setting up an HA scalable DB cluster.
So far my tests with streaming replication proof that it is very very good
indeed.
However, problem seems to be on the connection pooling side. Ideally, we
would love to have single point of connection to the cluster, but I do
On 3 March 2013 22:56, John R Pierce pie...@hogranch.com wrote:
did you look at pgbouncer ? thats the simple pooler for postgres, and its
quite robust, because its so simple.
Yes, it is one of the solutions I do consider. Having applications decide
whether they should write to master, or
They seem to claim up to 70% speed gain.
Did anyone proved it, tested it - with PostgreSQL in particular ?
They seem to run the same way as RHEL do, ie - you can download it for
free, but pay for repo access. (thus updates).
--
GJ
--
Sent via pgsql-general mailing list
Folks,
I'm testing some code on 9.2dev (trunk), and I've noticed that
postgresql seems to be fussy about language case when creating a
function.
So for instance:
create function foo() returns int AS $$ BEGIN return 1; END; $$
LANGUAGE 'PLpgSQL';
Will be fine on 8.3 (my current version used in
On 26 March 2012 16:41, Thom Brown t...@linux.com wrote:
Probably something to do with this:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=67dc4eed42186ba6a2456578899bfd38d003201a
Sounds very plausible.
Would you call it a regression ? I would say so, but not sure what
What is a likelihood of a deadlock occurring, caused (or helped by)
auto vacuum.
This is on 8.3.
The table with deadlocks was quite busy with updates, etc.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
Its because of pg_upgrade, 'in place' upgrade capabilities that are in
pg since 8.4. For that to work you need both old and new (current) set
of postgresql binaries. Etc.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
btw, HOT was introduced in 8.3.
On 6 December 2011 14:51, Daniel Migowski dmigow...@ikoffice.de wrote:
Continuing this talk on general, as requested by Craig.
I have a functional Index on a table that is relative expensive to calculate.
Now I noticed on every update of even index-unrelated
Get a lawyer that knows this stuff.
Whilst asking around is good, if you want serious answer - you can't
count on bunch of people on the list.
Within GPL there are also variants, like LGPL, AGPL, etc. There are
some lawyers that specialize in opensource, ask them.
Most people here should have
for the future it is better to just use text type, and: check
length(field) 35;
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
partition your table if it is too big.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
increase your checkpoint segments
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
What if power supply goes ?
What if someone trips on the cable, and both servers go ?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
NVM the implementation, but ability to clone the database without
disconnects would be very good for backups and testing.
We also create loads of templates, so that would make it more practical.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
I know it's a no-no to respond to my own posts, but here's what I'm
going to do.
I'll test newer revisions of 8.3 and also 9.1 in the out-of-disk-space
scenario and report back :P
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
pg_dump -Fc already compresses, no need to pipe through gzip
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
So I have a strange issue on one of our live systems.
\d+ table shows me the FKs with cascaded deletes, but querying
pg_trigger doesn't show me any specific triggers for the FK.
Is that possible ? Or am I missing something here?
The psql version is 8.3.7 .
--
GJ
--
Sent via pgsql-general
On 11 November 2011 12:25, Gregg Jaskiewicz gryz...@gmail.com wrote:
So I have a strange issue on one of our live systems.
\d+ table shows me the FKs with cascaded deletes, but querying
pg_trigger doesn't show me any specific triggers for the FK.
Is that possible ? Or am I missing something
your transaction had an error, and any query after the first one that
has failed will be ignored.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
what sort of queries you are running against it ? the select * from..
is not really (hopefully) a query you are running from your php app.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
If you don't need the data for more then a transaction, or connection
length - use temporary tables to store ids of data you need to delete.
If those change, or move, or something - it means you are missing PK
on that table.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
speaking of DO INSTEAD, for insert/update case. Try using RETURNING
with that and rules ;) Good luck
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
You're right, rules are perfect for very limited and narrow cases. And
make it very hard to write complicated queries against. (i.e., updates
that only touch few columns, likewise with inserts).
I'm guessing the upside is that rules are faster then triggers.
--
Sent via pgsql-general mailing
So consider this code C++, using libpqxx:
string = INSERT INTO foo(x) VALUES( E' + T.esc_raw(data) + ' );
foo(x) is bytea , before you ask.
On 8.3, it works fine.
On 9.x:
ERROR: invalid byte sequence for encoding UTF8: 0x00 (if \000 is in
the string).
Now, I can take out the E'' and it will
You can always store it divided in the database into two columns.
Gist could also work for you.
On 26 September 2011 14:39, Merlin Moncure mmonc...@gmail.com wrote:
urk -- I have to be honest -- that's a pretty lousy way to send bytea.
Personally, I'd encode the string as hex and send it like this:
INSERT INTO foo(x) VALUES( decode(' + hex_string + '));
libpqxx doesn't have the
You can create your own type, but that means writing bit code in C.
Please, stop the top posting!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Oh, neat.
And I'll call myself wizard. People will think I am one...
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
My apps share same databases, so no good in that. And I am very well
aware of the new feature in 9.0 - but we're stuck in the 8.3 land for
now.
So far I managed to hack together a netstat+awk+other command line
tools to get that information. (in your face - windows server
developers/admins :P)
--
Basically, I got bunch of local processes connecting to postgresql,
need to aggregate some sort of report about number of connections and
its origin every so often.
pg version is 8.3
Any ideas if there's tools to gather that info on linux ?
Netstat is the only one I know, but I have to parse/awk
can you pipe things on windows ?
It's a desktop system after all, but dos had that sort of a feature -
I seem to remember.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
35 matches
Mail list logo
