On 12 March 2013 21:59, John R Pierce 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
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 redundan
On 10 March 2013 02:19, Scott Marlowe 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 just about as fast as
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
separ
On 3 March 2013 22:56, John R Pierce 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 use slaves and/or
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
realis
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 (pgsql-general@postgres
On 26 March 2012 16:41, Thom Brown 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
would be an arg
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 prod
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:
http://www.postgresql.or
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:
http://www.postgre
btw, HOT was introduced in 8.3.
On 6 December 2011 14:51, Daniel Migowski 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 fields of the ta
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 add
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
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
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
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
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:
http://ww
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 subscrip
On 11 November 2011 12:25, Gregg Jaskiewicz 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
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 ma
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)
To
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 list
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 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
On 26 September 2011 14:39, Merlin Moncure 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 ability to para
You can always store it divided in the database into two columns.
Gist could also work for you.
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
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)
-
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
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
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 i
35 matches
Mail list logo
