Hi,
On Wed, 2011-01-05 at 18:08 -0700, 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?
In 8.3+, autovacuum kills itself if when it c
>
> > 2: Operation system will refuse me to create thousand threads and,
> anyway,
> > database will return responds averagely just when all of them will be
> > accomplished.
>
> I don't know how I can help you, since you haven't explained the
> architecture of your application very well.
>
It do
On Wed, Jan 05, 2011 at 07:46:18PM -0700, Scott Ribe wrote:
> And if somebody clones the disk to a new machine, but leaves the old one in
> service? Or do you use the MAC address and hope that's unique?
>
Excellent questions, and exactly the sort (as I was arguing elsewhere
in this thread) one h
On Wed, Jan 05, 2011 at 07:44:29PM -0700, Scott Ribe wrote:
> In order for a collision to matter, really in order for there to *be* a
> collision, the duplicate pair has to be collected in one place.
Not at the time of generation, though. They only have to end up in
the same place at once. Fo
I'm getting an error like this in the log a couple times a day on on my hot
standby server. Any suggestions?
23964 2011-01-04 05:23:00 EST [47]LOG: invalid record length at
6E53/46E8A010
23535 2011-01-04 05:23:00 EST [2]FATAL: terminating walreceiver process
due to administrator command
c
On Wed, Jan 05, 2011 at 06:22:08PM -0500, Chris Browne wrote:
> But it seems to me that some of the analytics are getting a little *too*
> paranoid, on the "perhaps UUIDs are the wrong answer" side of the
> column.
That could be. I was simply noting that there are cases where one
could legitimate
On Jan 5, 2011, at 4:11 PM, Michael Satterwhite wrote:
> Each machine would have a unique machine_id. This would guarantee uniqueness
> and be very easy to maintain.
And if somebody clones the disk to a new machine, but leaves the old one in
service? Or do you use the MAC address and hope that'
On Jan 5, 2011, at 3:03 PM, Andrew Sullivan wrote:
> ...the example was not that UUIDs are being generated and collected
> in one place at that rate, but that they're being generated in several
> independent places at a time...
In order for a collision to matter, really in order for there to *be*
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 more worker threads. Yet
for some reason we're not keeping u
2011/1/6 Вячеслав Блинников :
> 1: Didn't figured out what it does mean - can you explain it better?
http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D0%B0%D1%84%D0%BE%D1%80_(%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0)
> 2: Operation system will refuse me to create thousand
a...@crankycanuck.ca (Andrew Sullivan) writes:
> On Wed, Jan 05, 2011 at 12:41:43PM -0700, Scott Ribe wrote:
>> I'm not sidestepping the point at all.
>
> You may be missing it, however, because. . .
>
>> The point is that the finiteness of the space is a red herring. The
>> space is large enough t
dal...@solfertje.student.utwente.nl (Alban Hertroys) writes:
>>> From wikipedia, "only after generating 1 billion UUIDs every second for
>> the next 100 years, the probability of creating just one duplicate would
>> be about 50%. The probability of one duplicate would be about 50% if
>> every perso
1: Didn't figured out what it does mean - can you explain it better?
2: Operation system will refuse me to create thousand threads and, anyway,
database will return responds averagely just when all of them will be
accomplished.
3: I never close a connection once it was created, so any pool will n
On 6 January 2011 00:32, dennis jenkins wrote:
> On Wed, Jan 5, 2011 at 1:03 PM, Bill Moran
> wrote:
> >
> > But the point (that you are trying to sidestep) is that the UUID
> namespace
> > is finite, so therefore you WILL hit a problem with conflicts at some
> point.
> > Just because that point
Pooled id.. child machine connects to main and says give 1 of ids,
main increments counter by 1, child allocates in given pool.
On Wed, 5 Jan 2011 17:11:35 -0600, Michael Satterwhite
wrote:
Once multiple machines are linked to maintain the database, this has
a flaw in
it as a series i
On Wed, Jan 5, 2011 at 1:03 PM, Bill Moran wrote:
>
> But the point (that you are trying to sidestep) is that the UUID namespace
> is finite, so therefore you WILL hit a problem with conflicts at some point.
> Just because that point is larger than most people have to concern themselves
> with isn
On 01/05/2011 03:39 PM, Alban Hertroys wrote:
>>> From wikipedia, "only after generating 1 billion UUIDs every second for
>> the next 100 years, the probability of creating just one duplicate would
>> be about 50%. The probability of one duplicate would be about 50% if
>> every person on earth ow
>> From wikipedia, "only after generating 1 billion UUIDs every second for
> the next 100 years, the probability of creating just one duplicate would
> be about 50%. The probability of one duplicate would be about 50% if
> every person on earth owns 600 million UUIDs."
Even if the chances of one
2011/1/5 Вячеслав Блинников :
> The whole thing is:
> - server connect to the database and wait for incoming connections
> - when incoming connection occurs, server request the database for some data
> about connected client - server must do it asynchronously and without
> creating any threads just
On Wed, Jan 05, 2011 at 12:41:43PM -0700, Scott Ribe wrote:
> I'm not sidestepping the point at all.
You may be missing it, however, because. . .
> The point is that the finiteness of the space is a red herring. The
> space is large enough that there's no chance of collision in any
> realistic sc
On 01/05/2011 01:43 PM, Bill Moran wrote:
> In response to Rob Sargent :
>>>
>>> In our case (and I expect it's the case with most people considering UUIDs)
>>> we're talking about independent devices that occasionally synchronize
>>> data between themselves. These devices need to generate a uni
The whole thing is:
- server connect to the database and wait for incoming connections
- when incoming connection occurs, server request the database for some data
about connected client - server must do it asynchronously and without
creating any threads just for connected client (there can be more
In response to Rob Sargent :
> >
> > In our case (and I expect it's the case with most people considering UUIDs)
> > we're talking about independent devices that occasionally synchronize
> > data between themselves. These devices need to generate a unique ID
> > of some sort without having to che
On 05/01/2011 19:41, Scott Ribe wrote:
to every atom in the observable universe, or 10^51 UUIDs to every
atom in the total universe using high-end estimates of the size of
the non-observable universe)?
Is that taking dark matter into account? :-)
Ray.
--
Raymond O'Donnell :: Galway :: Ireland
On Jan 5, 2011, at 1:13 PM, Raymond O'Donnell wrote:
> Is that taking dark matter into account? :-)
It's not clear to me ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
2011/1/5 Вячеслав Блинников :
> Database connection using "libpq":
> So, generally speaking, I need:
> - send multiple queries using "PQsendQuery()" (or what else)
> - bind some data (void*) to each qeury
> - obtain results using "PQgetResult()" (or what else) and to know which data
> is bound to e
On Wed, Jan 5, 2011 at 05:49, tuanhoanganh wrote:
> I have error when build plperl
>
> 1>-- Build started: Project: plperl, Configuration: Release Win32 --
> 1>Generate DEF file
> 1>Not re-generating PLPERL.DEF, file already exists.
> 1>Linking...
> 1> Creating library Release\plperl\plp
On 01/05/2011 11:57 AM, Bill Moran wrote:
> In response to Rob Sargent :
>
>>
>>
>> On 01/05/2011 08:55 AM, Bill Moran wrote:
>>> In response to Scott Ribe :
>>>
On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
> Beyond that, the namespace size for a UUID is so incomprehensibly huge
>
On Jan 5, 2011, at 12:03 PM, Bill Moran wrote:
> For crying out loud. If you're going to pick me apart with numbers, then
> actually do it with some intelligence.
If you're going to get nasty, at least try to be accurate.
> I could easily counter your argument by upping the numbers to 500,000
>
Yes, the ID is generated before the database is contacted, in my case anyway.
The type of UUID that I want is a hybrid, so I would have to write a stored
procedure and then a trigger upon insert to get the UUID. Not rocket science, I
just have more on my plate than I can handle. So PHP is my 'ma
On Jan 5, 2011, at 11:31 AM, Radosław Smogura wrote:
> The true is that probability
> that in two coin drops we will get two reverses is 1/4, but true is, too, as
> Newton said, it's 1/3, because if in 1st drop we don't get reverse we don't
> need to drop again.
Nonsense. You don't stop genera
In response to Scott Ribe :
> On Jan 5, 2011, at 8:55 AM, Bill Moran wrote:
>
> > That statement demonstrates a lack of investigation and/or consideration
> > of the circumstances.
>
> No, it doesn't.
>
> > However, if there are 5000 devices generating 100 UUIDs per hour, and you'll
> > be keep
In response to Rob Sargent :
>
>
> On 01/05/2011 08:55 AM, Bill Moran wrote:
> > In response to Scott Ribe :
> >
> >> On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
> >>
> >>> Beyond that, the namespace size for a UUID is so incomprehensibly huge
> >>> that the chance of two randomly generated U
Scott Ribe Wednesday 05 January 2011 17:33:51
> On Jan 5, 2011, at 9:19 AM, Leif Biberg Kristensen wrote:
> > I can't help thinking of the «Birthday Paradox»:
> Yes, the calculation of the probability of a collision is the same for the
> "birthday paradox" as for random UUID collisions.
Depends o
Database connection using "libpq":
So, generally speaking, I need:
- send multiple queries using "PQsendQuery()" (or what else)
- bind some data (void*) to each qeury
- obtain results using "PQgetResult()" (or what else) and to know which data
is bound to each result (correspondence between queries
2011/1/5 Вячеслав Блинников :
> I intended to put queries into queue (along with callback and param data)
> and after fetching each result via "PQgetResult()" obtain callback and param
> from the queue, but documentation says that "PQexec can return only one
> PGresult structure. If the submitted q
Hello!
I connect to PostgreSQL database in my C++ program via libpq and I need to
implement the function like "void SendQuery(char* queryString, void
(*callback)(void*))" which will .
But how to bind the callback function data (and some parameters) to database
request?
I intended to put queries int
On Jan 5, 2011, at 10:30 AM, Radosław Smogura wrote:
> 128bits is huge for now, but what will happen in next 2,3 years?
It will still be large. When you get up to around 100 trillion UUIDs, you'll be
getting up to around a 1 in a billion chance of a single collision. Before you
claim that we'll
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:
>
> CREATE OR REPLACE FUNCTION reverse_last_64(TEXT) RETURNS TEXT AS $$
> SELECT
> array_to_st
Original Message
Subject: Re: [GENERAL] UUID column as pimrary key?
Date: Wed, 5 Jan 2011 10:11:49 -0700
From: Scott Ribe
To: Adrian Klaver
On Jan 5, 2011, at 9:57 AM, Adrian Klaver wrote:
Maybe or maybe not:)
So... If you choose to use a name-based UUID, *and* you do a
Sorry for not citation...
When I was talking about "almost unique", I was meaning that the UUID is
random so there is no guarantee that you will not generate two indencital
UUIDs even in subsequent calls, but it has low probability (you have
greater chances to win in LOTTO).
128bits is hug
On 01/05/2011 08:29 AM, 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 a
On Wed, Jan 5, 2011 at 3:03 PM, Mike Christensen wrote:
> 2011/1/5 Grzegorz Jaśkiewicz :
>> On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe
>> wrote:
>>> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>>>
* simple to generate, and 128bit random is almost globally unique,
>>>
>>> Almost? Sho
On Jan 5, 2011, at 9:19 AM, Leif Biberg Kristensen wrote:
> I can't help thinking of the «Birthday Paradox»:
Yes, the calculation of the probability of a collision is the same for the
"birthday paradox" as for random UUID collisions.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevate
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 at face
> value.
Eh? The user taking su
On Wednesday 5. January 2011 16.05.29 Bill Moran wrote:
> Beyond that, the namespace size for a UUID is so incomprehensibly huge
> that the chance of two randomly generated UUIDs having the same value
> is incomprehensibly unlikely ... it is, however, not a 100% guarantee.
I can't help thinking
On Jan 5, 2011, at 8:55 AM, Bill Moran wrote:
> That statement demonstrates a lack of investigation and/or consideration
> of the circumstances.
No, it doesn't.
> However, if there are 5000 devices generating 100 UUIDs per hour, and you'll
> be keeping those records for 10+ years, the chances of
pasman pasmański wrote:
> Hi. I propose new feature - allow archive command to copy part of not
> full filled wal segment. It need new parameter %b - number of bytes
> used in segment . Then one can use head or dd to archive wal and
> reduce network traffic to standby server.
Use streaming repli
I don't believe the EAL certification is valid for the community
version of PostgreSQL.
From the EAL certification report:
"PostgreSQL Certified Version is a relational database management
system, which is applicable to enterprise business. It is an enhanced
version of the open source PostgreSQL a
On 01/05/2011 08:55 AM, Bill Moran wrote:
> In response to Scott Ribe :
>
>> On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
>>
>>> Beyond that, the namespace size for a UUID is so incomprehensibly huge
>>> that the chance of two randomly generated UUIDs having the same value
>>> is incomprehensib
Scott Ribe writes:
> On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
>> Beyond that, the namespace size for a UUID is so incomprehensibly huge
>> that the chance of two randomly generated UUIDs having the same value
>> is incomprehensibly unlikely
> Yes, as in: it is *far* more likely that all of y
In response to Scott Ribe :
> On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
>
> > Beyond that, the namespace size for a UUID is so incomprehensibly huge
> > that the chance of two randomly generated UUIDs having the same value
> > is incomprehensibly unlikely
>
> Yes, as in: it is *far* more lik
Hi. I propose new feature - allow archive command to copy part of not
full filled wal segment. It need new parameter %b - number of bytes
used in segment . Then one can use head or dd to archive wal and
reduce network traffic to standby server.
--
Sent from my mobile device
pasman
On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
> Beyond that, the namespace size for a UUID is so incomprehensibly huge
> that the chance of two randomly generated UUIDs having the same value
> is incomprehensibly unlikely
Yes, as in: it is *far* more likely that all of your team members and all o
On Jan 5, 2011, at 8:03 AM, Mike Christensen wrote:
> As long as all your UUIDs are generated with the same algorithm, they
> are guaranteed to be unique.
There is no requirement that they be generated with the same algorithm in order
to be unique. A MAC/time-based UUID cannot duplicate a random
In response to Scott Ribe :
> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>
> > * simple to generate, and 128bit random is almost globally unique,
>
> Almost? Should be totally unique, as long as your random source is decent
> quality.
This is going off-topic, but I did some research o
On Jan 5, 2011, at 7:55 AM, Grzegorz Jaśkiewicz wrote:
> But I would never rely on that alone. You always have a strategy in
> place, in case there's a duplicate.
That's really unnecessary, basically a total waste of effort.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
2011/1/5 Grzegorz Jaśkiewicz :
> On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe
> wrote:
>> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>>
>>> * simple to generate, and 128bit random is almost globally unique,
>>
>> Almost? Should be totally unique, as long as your random source is decent
>>
On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe wrote:
> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>
>> * simple to generate, and 128bit random is almost globally unique,
>
> Almost? Should be totally unique, as long as your random source is decent
> quality.
But I would never rely on that
On Jan 5, 2011, at 7:28 AM, Radosław Smogura wrote:
> It's simpler to write:
...
> isn't it?
Depends on the situation, the libraries you're using, and so on.
Now, if you're generating records in a distributed system, where your node
might be disconnected when it's creating a record, it is *much
On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
> * simple to generate, and 128bit random is almost globally unique,
Almost? Should be totally unique, as long as your random source is decent
quality.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voic
On 5 January 2011 15:28, Radosław Smogura wrote:
> On Wed, 05 Jan 2011 21:50:11 +1100, Craig Ringer <
> cr...@postnewspapers.com.au> wrote:
>
>> On 01/05/2011 07:31 PM, Radosław Smogura wrote:
>>
>> * you have your id, before executing query, (in contrast to all this
>>> autoincrement) so you ma
On Wed, 05 Jan 2011 21:50:11 +1100, Craig Ringer
wrote:
On 01/05/2011 07:31 PM, Radosław Smogura wrote:
* you have your id, before executing query, (in contrast to all this
autoincrement) so you may put it in dependant rows
Do you mean that with a UUID, you don't need to talk to the database
Thanks for your help. But now facing new problem. While running the "initdb.exe -D ..\data -E UTF-8 --locale=C -U postgres" command the following unknown language printed. This should be in english. Please help me out.Filerna tillhörande databasen kommer att ägas av användaren "Administra
Denna anv
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:
CREATE OR REPLACE FUNCTION reverse_last_64(TEXT) RETURNS TEXT AS $$
SELECT
array_to_string(
ARRAY
( SELECT substring($1,
I have error when build plperl
1>-- Build started: Project: plperl, Configuration: Release Win32 --
1>Generate DEF file
1>Not re-generating PLPERL.DEF, file already exists.
1>Linking...
1> Creating library Release\plperl\plperl.lib and object
Release\plperl\plperl.exp
1>SPI.obj : error L
On 01/05/2011 07:31 PM, Radosław Smogura wrote:
* you have your id, before executing query, (in contrast to all this
autoincrement) so you may put it in dependant rows
Do you mean that with a UUID, you don't need to talk to the database at
all, you can generate an ID with no interaction with
Can PLPerl make ODBC connect.
I have perl test connect. It work well
use DBI;
my $h = DBI->connect(
'dbi:ODBC:DRIVER=SQL
Server;Server=127.0.0.1;Database=TEST;Uid=sa;Pwd=abc123ABC;Port=1433',
'sa',
'abc123ABC',
{ AutoCommit => 1, RaiseError => 1, }
) or die "Did not connect to db.";
On Tue, 4 Jan 2011 11:07:00 -0800 (PST), Dennis Gearon
wrote:
I haven't been able to find anywhere, easily, in the documentation
using google
where a list of allowed data types for primary keys is.
So, UUIDs can be primary keys?
Any issues wtih them on sorting or paging of index tables, etc.?
69 matches
Mail list logo
