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
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
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 Universi
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 (http:/
"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
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 ha
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 t
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:
>
> http://threebit.net/
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-bu
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? The
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
> >
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
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
[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. 64
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 replicatio
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 cod
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 t
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 r
27 matches
Mail list logo
