On 6 Jan 2011, at 24:27, Chris Browne wrote:
Next to that, UUID's are generated by computers. I have no doubts that
the numeric space that makes up a UUID allows for collision chances as
low as described, but are computers capable of generating those
numbers sufficiently random that they
Next to that, UUID's are generated by computers. I have no doubts that
the numeric space that makes up a UUID allows for collision chances as
low as described, but are computers capable of generating those
numbers sufficiently random that they actually achieve that low a
chance? I think
On 2011-01-05, Scott Ribe scott_r...@elevated-dev.com wrote:
On Jan 5, 2011, at 9:01 AM, Tom Lane wrote:
In practical use I think the odds of a collision are *far* higher than
you are suggesting, unless the UUID generation is being done with a lot
more care than is likely if the user takes
We are about to build a new database server, our plan is to use Debian.
Is there documentation of recommended server configurations for Linux,
such as kernel parameters, preferred file system, etc that work best
with postgresql?
I'm not talking about the pg configuration, which I have seen a
I don't think that it makes sense to look at PG tuning and server
tuning as two separate tasks. XFS was recently benchmarked using
bonnie++ by Greg Smith, with interesting results:
http://blog.2ndquadrant.com/en/2010/04/the-return-of-xfs-on-linux.html
That said, my guess is that the majority of
Hi,
I have postgres 9.0.2 server with a 2.4GB database.
After pg_dump of the database, the size increased with aprox 200MB ... why?
I make some tests and the total_relation_size is increased, but the
relation_size not.
thanks
Birta Levente
--
Sent via pgsql-general mailing list
On Jan 6, 2011, at 2:51 AM, Jasen Betts wrote:
Who was it that decided on 32 bits for IP addresses?
Nice try, but that was rather long before the IETF existed ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
--
Sent via pgsql-general
Thanks Filip Rembiałkowski, that's exactly what I want.
2011/1/6 Filip Rembiałkowski plk.zu...@gmail.com
2011/1/5 flying eagle eaglein...@gmail.com
I want to get all the dependencies of a table, I know how to get the index
list using sql, but I don't know how to get the list of objects who
On Thu, Jan 6, 2011 at 4:20 AM, Sim Zacks s...@compulab.co.il wrote:
We are about to build a new database server, our plan is to use Debian.
Is there documentation of recommended server configurations for Linux, such
as kernel parameters, preferred file system, etc that work best with
On Jan 6, 2011, at 1:52 AM, Stuart Bishop wrote:
If you are looking at these extreme
improbabilities, your SERIAL isn't guaranteed unique either when you
take into account cosmic rays flipping the right bits in your ECC
memory or on your disk platter.
Yes, that's rather the point, the
Hello,
I've a quite severe issue with dblink, whereas asynchronous sent
transaction are not immediately visible for the next operations.
I'm using dblink_send_query to distribute large aggregation on multiple
processors from within stored procedures.
Someting like:
function step1()
As a followup, I'd like to point out that you can probably get more
performance wise from hardware upgrades than from tuning your OS.
Something as simple as an $800 caching RAID controller can make a
workstation class machine into a monster performer, going from 250 tps
to 3000 tps with one simple
On Wed, Jan 5, 2011 at 6:08 PM, u235sentinel u235senti...@gmail.com wrote:
I'm tracking a problem with our tables being bloated and was curious if
someone regularly kills autovacuum jobs, will autovacuum later reattempt to
vacuum the table it was killed under?
I've made autovacuum more
In response to Scott Ribe scott_r...@elevated-dev.com:
On Jan 6, 2011, at 1:52 AM, Stuart Bishop wrote:
If you are looking at these extreme
improbabilities, your SERIAL isn't guaranteed unique either when you
take into account cosmic rays flipping the right bits in your ECC
memory or
On Thu, Jan 6, 2011 at 9:38 AM, Scott Marlowe scott.marl...@gmail.com wrote:
As a followup, I'd like to point out that you can probably get more
performance wise from hardware upgrades than from tuning your OS.
Something as simple as an $800 caching RAID controller can make a
Totally agree
It's 9.0.2 on Centos
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/walreceiver-getting-bad-data-tp3329916p3330573.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
On Jan 6, 2011, at 8:14 AM, Bill Moran wrote:
I don't give a fuck how small the chance of conflict is, the only
viable option for that chance is 0. Period. Any argument to the
contrary is stupid, asinine and outright negligent.
Do you give a fuck about the chance that bits will flip in the
On Thursday 06 January 2011 7:14:00 am Bill Moran wrote:
In response to Scott Ribe scott_r...@elevated-dev.com:
On Jan 6, 2011, at 1:52 AM, Stuart Bishop wrote:
If you are looking at these extreme
improbabilities, your SERIAL isn't guaranteed unique either when you
take into account
On Jan 6, 2011, at 8:19 AM, Michael Satterwhite wrote:
That would be a matter of incompetent administration. *NOTHING* can protect
against that.
Well, no, not necessarily. It might well be a goal (in fact, is a goal with
some software that I'm developing), that users/admins don't have to
Birta,
After pg_dump of the database, the size increased with aprox 200MB ...
How are you dumping the database? Are you using -Fc on the command line, or
are you dumping to a text file? I have nothing to quantify my comment, but
it seems possible that with a database of that size, the
On Wed, Jan 5, 2011 at 3:43 PM, Bill Moran wmo...@potentialtech.com wrote:
Despite the fact that the chance of a collision is very, very small, there
is no easy way to fix it if it happens. Zero. It can't be done without
shutting the system down, recalling all the remote devices and manually
wmo...@potentialtech.com (Bill Moran) writes:
If the chance of a duplicate is 1 in a hundred gazillion, then I can
still hit a dupe the VERY FIRST TIME I USE IT.
I'm writing software that is intended to be used to save lives in the
event of an earthquake or flood or cosmic ray flipping bits
dennis.jenkins...@gmail.com (dennis jenkins) writes:
The UUID itself is 128 bits. Some of those bits are pre-determined.
I don't recall, but I think that a normal UUID has 121 bits of
randomness.
That doesn't match RFC 4122 very well...
It indicates 5 forms of UUIDs:
1) Time-based, where
On Jan 6, 2011, at 9:31 AM, Chris Browne wrote:
The reasonable choices for a would-be artificial primary key seem to be
1 and 3; in a distributed system, I'd expect to prefer 1, as the time +
host data are likely to eliminate the oh, it might just randomly match
problem.
In some contexts, 1
It is need tip in doc which version of perl must be installed. Error
message tells nothing. For example Postgres 8.4 works only with perl
5.10.
--
Sent from my mobile device
pasman
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
It was recently brought to my attention that in my enthusiasm to
have my point of view understood, that I may have been crude,
or self-important or something else that people find offensive.
My apologies to anyone who was offended, and to anyone who considers
this thread a bikeshed or flamewar
On 6 Jan 2011, at 17:51, Chris Browne wrote:
wmo...@potentialtech.com (Bill Moran) writes:
If your system is sufficiently negligently designed that this particular
conflict causes it to kill people, then I wouldn't be too inclined to
point at this issue with UUIDs being the Real Problem with
dal...@solfertje.student.utwente.nl (Alban Hertroys) writes:
On 6 Jan 2011, at 17:51, Chris Browne wrote:
wmo...@potentialtech.com (Bill Moran) writes:
If your system is sufficiently negligently designed that this particular
conflict causes it to kill people, then I wouldn't be too inclined
Josh Kupershmidt schmi...@gmail.com writes:
From this description, it sounds like you're trying to shortcut the
process of bringing your old primary server (server A) up-to-date with
the currently-running server (server B). In order to bring server A
up-to-date with B, you'll need to follow
Shoma S Achar shoma.pra...@gmail.com writes:
I would like to know where I could find the latest available Latch patch. If
anyone knows, please share this information.
I guess you would find it there:
http://git.postgresql.org/gitweb?p=postgresql.gita=searchh=HEADst=commits=latch
Regards,
On 06/01/11 18:07, pasman pasmański wrote:
It is need tip in doc which version of perl must be installed. Error
message tells nothing. For example Postgres 8.4 works only with perl
5.10.
Are you sure that's the case? Could it be that you're using a
pre-compiled version of plperl?
--
In response to Chris Browne cbbro...@acm.org:
It seems to me that using serially assigned values, along with manually
assigned server IDs, to construct a would-be-unique value, is likely to
introduce quite a lot *more risk* of system failure than would the use
of UUIDs.
First off, server
On Jan 6, 2011, at 3:52 AM, Stuart Bishop wrote:
Maybe I should start a business in providing UUID collision insurance?
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
-M
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
On Thursday 06 January 2011 5:58:13 am Birta Levente wrote:
Hi,
I have postgres 9.0.2 server with a 2.4GB database.
After pg_dump of the database, the size increased with aprox 200MB ... why?
I make some tests and the total_relation_size is increased, but the
relation_size not.
thanks
On Thu, Jan 6, 2011 at 6:20 AM, Sim Zacks s...@compulab.co.il wrote:
We are about to build a new database server, our plan is to use Debian.
Is there documentation of recommended server configurations for Linux, such
as kernel parameters, preferred file system, etc that work best with
Hey guys and gals,
As the originator of this topic, I've received a lot of good answers,
opinions, and advice. Thank you.
I'm not sure that more conversation on this will go anywhere but down. It
seems that UUID vs. Integer is one of those 'values' subjects, like:
Sexual practices
On 6 Jan 2011, at 20:36, Chris Browne wrote:
Infinite? The probability can't conceivably exceed 1.
Don't start picking om words please, infinitely small or infinitesimal is
obviously what I meant to write there.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and
[a meta-question for all the below is what's a good link for hairy SQL?]
A while ago I worked on a project where we had some hairy SQL collapsing
multiple rows of pseudo-rdf triples (columns subject,predicate, and
object) into one flattened row in which a hard-coded case/max (I forget
the
On 1/6/2011 5:50 PM, Kenneth Tilton wrote:
[a meta-question for all the below is what's a good link for hairy SQL?]
A while ago I worked on a project where we had some hairy SQL
collapsing multiple rows of pseudo-rdf triples (columns
subject,predicate, and object) into one flattened row in
Is there much of a likelihood for the release of an Alpha 3 one-click installer?
--
Regards,
Richard Broersma Jr.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi pgSQL peeps!
I'm stumped on this question for over 3 days now.
I need to run a stored function in Database A (sf DBa) which calls a
stored function in Database B (sf DBb).
Here's sf DBa:
CREATE OR REPLACE FUNCTION sp_update_serialnumber(pserialnumber character
varying, pActivityId
41 matches
Mail list logo
