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, pActivi
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
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 w
[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 ex
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
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 a
On Thu, Jan 6, 2011 at 6:20 AM, Sim Zacks 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
> postgresql?
>
> I'm no
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.
>
> t
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
In response to Chris Browne :
>
> 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 IDs are not ra
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?
--
Richar
Shoma S Achar 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.git&a=search&h=HEAD&st=commit&s=latch
Regards,
--
Dimitri Fontai
Josh Kupershmidt 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 *all* the steps o
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 inc
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 wi
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
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 subscr
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 context
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, wher
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 bi
On Wed, Jan 5, 2011 at 3:43 PM, Bill Moran 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
> reconciling the prob
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 additi
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 wo
On Thursday 06 January 2011 7:14:00 am Bill Moran wrote:
> In response to Scott Ribe :
> > 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 flippi
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 th
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 make
On Thu, Jan 6, 2011 at 9:38 AM, Scott Marlowe 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 here. Throwing hardwa
In response to Scott Ribe :
> 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 platte
On Wed, Jan 5, 2011 at 6:08 PM, u235sentinel 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 aggressive and given mor
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
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()
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 pro
On Thu, Jan 6, 2011 at 4:20 AM, Sim Zacks 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
> postgresql?
This real
Thanks Filip Rembiałkowski, that's exactly what I want.
2011/1/6 Filip Rembiałkowski
>
>
> 2011/1/5 flying eagle
>
> 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 using a
>> function, for example
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 mailin
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 (pgsql-
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 l
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
On 2011-01-05, Scott Ribe 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 these sorts of claims
>>> 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?
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 th
41 matches
Mail list logo
