Jim,
I agree about splitting the utilities, except that I think the database
should be able to generate UUIDs somehow.
There is a GUID add-in, and someone is working on a 2nd one. UUIDs are
not part of the SQL standard, and we've only seen sporadic demand for
them (and different types each
Josh Berkus wrote:
Jim,
I agree about splitting the utilities, except that I think the database
should be able to generate UUIDs somehow.
There is a GUID add-in, and someone is working on a 2nd one. UUIDs
are not part of the SQL standard, and we've only seen sporadic demand
for them (and
On Fri, Jun 30, 2006 at 08:53:28AM +0200, Thomas Hallgren wrote:
Josh Berkus wrote:
I agree about splitting the utilities, except that I think the database
should be able to generate UUIDs somehow.
There is a GUID add-in, and someone is working on a 2nd one. UUIDs
are not part of the
On Fri, Jun 30, 2006 at 04:04:19AM -0400, [EMAIL PROTECTED] wrote:
Martijn van Oosterhout wrote:
It seems to me that maybe the backend should include a 16-byte fixed
length object (after all, we've got 1, 2, 4 and 8 bytes already) and
then people can use that to build whatever they
On 6/30/06, Tom Lane [EMAIL PROTECTED] wrote:
I don't know the kernel nearly well enough to guess if these are related
...
The sl_log_* tables are indexed on xid, where the relations between
values are not exactly stable. When having high enough activity on
one node or having nodes with XIDs
I have no messages since yesterday evening. Any problems with
mailing list ?
Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow
On Fri, 30 Jun 2006, Oleg Bartunov wrote:
I have no messages since yesterday evening. Any problems with
mailing list ?
Not that I've seen ... been alot of posts going back and forth ... and
yours definitely went through ...
Marc G. Fournier Hub.Org Networking Services
Marko Kreen [EMAIL PROTECTED] writes:
The sl_log_* tables are indexed on xid, where the relations between
values are not exactly stable. When having high enough activity on
one node or having nodes with XIDs on different enough positions
funny things happen.
Yeah, that was one of the first
I trawled through the first, larger dump you sent me, and found multiple
index entries pointing to quite a few heap tuples:
Occurrences block item
2 43961 1
2 43961 2
2 43961 3
2 43961 4
On 6/30/2006 9:55 AM, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
The sl_log_* tables are indexed on xid, where the relations between
values are not exactly stable. When having high enough activity on
one node or having nodes with XIDs on different enough positions
funny things
On 6/30/06, Jan Wieck [EMAIL PROTECTED] wrote:
With the final implementation of log switching, the problem of xxid
wraparound will be avoided entirely. Every now and then slony will
switch from one to another log table and when the old one is drained and
logically empty, it is truncated, which
Teodor Sigaev wrote:
Tom did commit a patch a while ago which made a huge difference in
index creation time for tsearch by changing one routine. I don't know
if it got backpatched, so it might be worth checking people are working
on the same version.
I saw that patch, but I still think that
On 6/30/2006 11:17 AM, Marko Kreen wrote:
On 6/30/06, Jan Wieck [EMAIL PROTECTED] wrote:
With the final implementation of log switching, the problem of xxid
wraparound will be avoided entirely. Every now and then slony will
switch from one to another log table and when the old one is drained
Jan Wieck [EMAIL PROTECTED] writes:
On 6/30/2006 11:17 AM, Marko Kreen wrote:
If the xxid-s come from different DB-s, then there can still be problems.
How so? They are allways part of a multi-key index having the
originating node ID first.
Really?
create table @[EMAIL PROTECTED] (
Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
I'll get back to you with kernel build information tomorrow. We'll also
try to talk to some kernel hackers about this.
Some googling turned up recent discussions about race conditions in
Linux NFS code:
On 6/30/2006 11:55 AM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
On 6/30/2006 11:17 AM, Marko Kreen wrote:
If the xxid-s come from different DB-s, then there can still be problems.
How so? They are allways part of a multi-key index having the
originating node ID first.
Really?
Brad Nicholson wrote:
Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
I'll get back to you with kernel build information tomorrow. We'll also
try to talk to some kernel hackers about this.
Some googling turned up recent discussions about race conditions in
Linux NFS code:
Brad Nicholson [EMAIL PROTECTED] writes:
It may or may not be the same issue, but for what it's worth, we've seen
the same sl_log_1 corruption on AIX 5.1 and 5.3
Hm, on what filesystem, and what PG version(s)?
I'm not completely satisfied by the its-a-kernel-bug theory, because if
it were
Tom Lane wrote:
Brad Nicholson [EMAIL PROTECTED] writes:
It may or may not be the same issue, but for what it's worth, we've seen
the same sl_log_1 corruption on AIX 5.1 and 5.3
Hm, on what filesystem, and what PG version(s)?
I'm not completely satisfied by the its-a-kernel-bug theory,
Jan Wieck [EMAIL PROTECTED] writes:
You're right ... forgot about that one.
However, transactions from different origins are NEVER selected together
and it wouldn't make sense to compare their xid's anyway. So the index
might return index tuples for rows from another origin, but the
Ühel kenal päeval, R, 2006-06-30 kell 12:05, kirjutas Jan Wieck:
On 6/30/2006 11:55 AM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
On 6/30/2006 11:17 AM, Marko Kreen wrote:
If the xxid-s come from different DB-s, then there can still be problems.
How so? They are allways
On Fri, Jun 30, 2006 at 10:38:49AM +0200, Martijn van Oosterhout wrote:
On Fri, Jun 30, 2006 at 04:04:19AM -0400, [EMAIL PROTECTED] wrote:
It seems to me that maybe the backend should include a 16-byte fixed
length object (after all, we've got 1, 2, 4 and 8 bytes already) and
then
Greg Stark [EMAIL PROTECTED] writes:
I'm not sure why it's not pulling up from the left side of the left join
though. That might be a bug. What PG version is this exactly?
In fact it doesn't even pull it up out of a regular join. I looked into this
when it was first brought up on IRC and as
On Fri, Jun 30, 2006 at 12:39:52PM -0400, [EMAIL PROTECTED] wrote:
Only this could be used to create other types too, for cryptographic
functions for example. PostgreSQL doesn't have any type generators yet,
so I'm unsure whether a patch creating one would be accepted for core.
Not sure
[EMAIL PROTECTED] writes:
It depends how it is used. If the memory location needs to be
allocated, for the value to be used only a few times, the overhead of
allocation and redirection can be more expensive. If many though, than
the reduction in value copying can make the pointer faster.
Here's how we solved the XID indexing problem at Skype. We took
Slony-s xxid module and made it output 8-byte numbers by keeping
track of wraparound count. Thus having stable relationship
between values.
It would be good to have such functionality officially in PostgreSQL
so that all
On Thu, 2006-06-29 at 21:47 -0400, Tom Lane wrote:
One easy thing that would be worth trying is to build with
--enable-cassert and see if any Asserts get provoked during the
A couple other things to try, given that you can provoke the failure
fairly easily:
. . .
1. In studying the code, it
Marc Munro [EMAIL PROTECTED] writes:
We tried all of these suggestions and still get the problem. Nothing
interesting in the log file so I guess the Asserts did not fire.
Not surprising, it was a long shot that any of those things were really
broken. But worth testing.
We are going to try
On Jun 23, 2006, at 9:47 , Michael Glaesemann wrote:
# select '41 mon'::interval / 10;
?column?
4 mons 2 days 24:00:00
My understanding is that as month_remainder is a float (as is
month_remainder_days), month_remainder_days may be equal to 24
hours after
29 matches
Mail list logo
