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
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 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
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
[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
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
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 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
> >
Ü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
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
>
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
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
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:
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?
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/
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] (
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
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/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
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
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
"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
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:/
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 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
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 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
27 matches
Mail list logo
