On Sat, Apr 14, 2012 at 7:25 AM, Fujii Masao wrote:
> On Sat, Apr 14, 2012 at 5:30 AM, Robert Haas wrote:
>> On Mon, Mar 12, 2012 at 10:34 PM, Fujii Masao wrote:
> I can see a usecase for having a pg_size_pretty(numeric) as an option.
> Not necessarily a very big one, but a >0 one.
On Sat, Apr 14, 2012 at 5:30 AM, Robert Haas wrote:
> On Mon, Mar 12, 2012 at 10:34 PM, Fujii Masao wrote:
I can see a usecase for having a pg_size_pretty(numeric) as an option.
Not necessarily a very big one, but a >0 one.
>>>
>>> +1.
>>
>> +1, too.
>
> I did some beautification of thi
On Mon, Mar 12, 2012 at 10:34 PM, Fujii Masao wrote:
>>> I can see a usecase for having a pg_size_pretty(numeric) as an option.
>>> Not necessarily a very big one, but a >0 one.
>>
>> +1.
>
> +1, too.
I did some beautification of this patch. I think the attached version
is cleaner and easier to
On Tue, Mar 13, 2012 at 12:03 PM, Tom Lane wrote:
> Fujii Masao writes:
>> On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane wrote:
>>> The main actual simplification would be in getting rid of the "hole"
>>> at the end of each 4GB worth of WAL, cf this bit in xlog_internal.h:
>>> If we can't get rid of
Fujii Masao writes:
> On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane wrote:
>> The main actual simplification would be in getting rid of the "hole"
>> at the end of each 4GB worth of WAL, cf this bit in xlog_internal.h:
>> If we can't get rid of that and have a continuous 64-bit WAL address
>> space t
On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas wrote:
>>> On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane wrote:
Hm. I think "thousands" is an overestimate, but yeah the logic could be
greatly simplified. However, I'm n
On Sat, Mar 10, 2012 at 3:23 AM, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 12:38 PM, Magnus Hagander wrote:
>> On Fri, Mar 9, 2012 at 18:18, Tom Lane wrote:
>>> Magnus Hagander writes:
On Fri, Mar 9, 2012 at 15:37, Tom Lane wrote:
> Why would it be useful to use pg_size_pretty on xl
On Fri, Mar 09, 2012 at 03:04:23PM -0500, Tom Lane wrote:
> The main actual simplification would be in getting rid of the "hole"
> at the end of each 4GB worth of WAL, cf this bit in xlog_internal.h:
>
> /*
> * We break each logical log file (xlogid value) into segment files of the
> * size indi
On Fri, Mar 9, 2012 at 3:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas wrote:
>>> On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane wrote:
Hm. I think "thousands" is an overestimate, but yeah the logic could be
greatly simplified. However, I'm no
Robert Haas writes:
> On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas wrote:
>> On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane wrote:
>>> Hm. I think "thousands" is an overestimate, but yeah the logic could be
>>> greatly simplified. However, I'm not sure we could avoid breaking the
>>> existing naming
On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane wrote:
>> Peter Eisentraut writes:
Yeah, the use of XLogFile to mean something other than, well a file in
the xlog, is greatly annoying.. I guess we could change it, but it
goes pretty de
Tom Lane wrote:
> Peter Eisentraut writes:
>> The whole thing was built around the lack of 64 bit integers. If
>> we bit the bullet and changed the whole thing to be just a single
>> 64-bit counter, we could probably delete thousands of lines of
>> code.
>
> Hm. I think "thousands" is an ove
On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>>> Yeah, the use of XLogFile to mean something other than, well a file in
>>> the xlog, is greatly annoying.. I guess we could change it, but it
>>> goes pretty deep in the system so it's not a small change...
>
>> The wh
Peter Eisentraut writes:
>> Yeah, the use of XLogFile to mean something other than, well a file in
>> the xlog, is greatly annoying.. I guess we could change it, but it
>> goes pretty deep in the system so it's not a small change...
> The whole thing was built around the lack of 64 bit integers.
On fre, 2012-03-09 at 18:13 +0100, Magnus Hagander wrote:
> > and confusing XLogFileSize with XLogSegSize. Not the best choice of
> > names.
>
> Yeah, the use of XLogFile to mean something other than, well a file in
> the xlog, is greatly annoying.. I guess we could change it, but it
> goes prett
On Fri, Mar 9, 2012 at 12:38 PM, Magnus Hagander wrote:
> On Fri, Mar 9, 2012 at 18:18, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Fri, Mar 9, 2012 at 15:37, Tom Lane wrote:
Why would it be useful to use pg_size_pretty on xlog locations?
-1 because of the large expense of bigin
On Fri, Mar 9, 2012 at 18:18, Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Mar 9, 2012 at 15:37, Tom Lane wrote:
>>> Why would it be useful to use pg_size_pretty on xlog locations?
>>> -1 because of the large expense of bigint->numeric->whatever conversion
>>> that would be added to exis
Magnus Hagander writes:
> On Fri, Mar 9, 2012 at 15:37, Tom Lane wrote:
>> Why would it be useful to use pg_size_pretty on xlog locations?
>> -1 because of the large expense of bigint->numeric->whatever conversion
>> that would be added to existing uses.
> Given the expense, perhaps we need to d
On Fri, Mar 9, 2012 at 15:37, Tom Lane wrote:
> Fujii Masao writes:
>> Euler proposed one more patch upthread, which replaces pg_size_pretty(bigint)
>> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
>> succeeds. It's also worth committing this patch?
>
> Why would it
On Fri, Mar 9, 2012 at 16:37, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 9:55 AM, Tom Lane wrote:
>>> Actually ... now that I look at it, isn't it completely bogus to be
>>> using numeric for the result of pg_xlog_location_diff?
>
>> rhaas=# select pg_xlog_location_diff('fff
Robert Haas writes:
> On Fri, Mar 9, 2012 at 9:55 AM, Tom Lane wrote:
>> Actually ... now that I look at it, isn't it completely bogus to be
>> using numeric for the result of pg_xlog_location_diff?
> rhaas=# select pg_xlog_location_diff('/0', '0/0')::int8;
> ERROR: bigint out of range
On Fri, Mar 9, 2012 at 9:55 AM, Tom Lane wrote:
> I wrote:
>> Fujii Masao writes:
>>> Euler proposed one more patch upthread, which replaces
>>> pg_size_pretty(bigint)
>>> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
>>> succeeds. It's also worth committing this p
Robert Haas writes:
> On Fri, Mar 9, 2012 at 9:37 AM, Tom Lane wrote:
>> Why would it be useful to use pg_size_pretty on xlog locations?
> The point is that it would be useful to use it on the difference
> between two xlog locations,
Um, that is exactly the claim I was questioning. Why is that
I wrote:
> Fujii Masao writes:
>> Euler proposed one more patch upthread, which replaces pg_size_pretty(bigint)
>> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
>> succeeds. It's also worth committing this patch?
> Why would it be useful to use pg_size_pretty on xlo
On Fri, Mar 9, 2012 at 9:37 AM, Tom Lane wrote:
> Fujii Masao writes:
>> Euler proposed one more patch upthread, which replaces pg_size_pretty(bigint)
>> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
>> succeeds. It's also worth committing this patch?
>
> Why would
Fujii Masao writes:
> Euler proposed one more patch upthread, which replaces pg_size_pretty(bigint)
> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
> succeeds. It's also worth committing this patch?
Why would it be useful to use pg_size_pretty on xlog locations?
-1
On Sun, Mar 4, 2012 at 8:26 PM, Magnus Hagander wrote:
> On Sun, Feb 26, 2012 at 00:53, Euler Taveira de Oliveira
> wrote:
>> On 25-02-2012 09:23, Magnus Hagander wrote:
>>> Do we even *need* the validate_xlog_location() function? If we just
>>> remove those calls, won't we still catch all the in
On Tue, Feb 28, 2012 at 07:21, Fujii Masao wrote:
> On Sun, Feb 26, 2012 at 8:53 AM, Euler Taveira de Oliveira
> wrote:
>> On 25-02-2012 09:23, Magnus Hagander wrote:
>>> Do we even *need* the validate_xlog_location() function? If we just
>>> remove those calls, won't we still catch all the incor
On Sun, Feb 26, 2012 at 00:53, Euler Taveira de Oliveira
wrote:
> On 25-02-2012 09:23, Magnus Hagander wrote:
>> Do we even *need* the validate_xlog_location() function? If we just
>> remove those calls, won't we still catch all the incorrectly formatted
>> ones in the errors of the sscanf() calls
On Sun, Feb 26, 2012 at 8:53 AM, Euler Taveira de Oliveira
wrote:
> On 25-02-2012 09:23, Magnus Hagander wrote:
>> Do we even *need* the validate_xlog_location() function? If we just
>> remove those calls, won't we still catch all the incorrectly formatted
>> ones in the errors of the sscanf() cal
On 25-02-2012 09:23, Magnus Hagander wrote:
> Do we even *need* the validate_xlog_location() function? If we just
> remove those calls, won't we still catch all the incorrectly formatted
> ones in the errors of the sscanf() calls? Or am I too deep into
> weekend-mode and missing something obvious?
On Fri, Feb 10, 2012 at 09:32, Fujii Masao wrote:
> On Fri, Feb 10, 2012 at 7:00 AM, Euler Taveira de Oliveira
> wrote:
>> On 08-02-2012 09:35, Fujii Masao wrote:
>>
>> Fujii, new patch attached. Thanks for your tests.
>
> Thanks for the new patch!
>
>>> But another problem happened. When I chang
On Fri, Feb 10, 2012 at 7:00 AM, Euler Taveira de Oliveira
wrote:
> On 08-02-2012 09:35, Fujii Masao wrote:
>
> Fujii, new patch attached. Thanks for your tests.
Thanks for the new patch!
>> But another problem happened. When I changed pg_proc.h so that the unused
>> OID was assigned to pg_xlog_
On 08-02-2012 09:35, Fujii Masao wrote:
Fujii, new patch attached. Thanks for your tests.
> But another problem happened. When I changed pg_proc.h so that the unused
> OID was assigned to pg_xlog_location_diff(), and executed the above again,
> I encountered the segmentation fault:
>
I reproduce
On Wed, Feb 8, 2012 at 2:29 AM, Euler Taveira de Oliveira
wrote:
> On 26-01-2012 06:19, Fujii Masao wrote:
>
> Thanks for your review. Comments below.
>
>> When I compiled the source with xlogdiff.patch, I got the following warnings.
>>
>> xlogfuncs.c:511:2: warning: format '%lX' expects argument
On 26-01-2012 06:19, Fujii Masao wrote:
Thanks for your review. Comments below.
> When I compiled the source with xlogdiff.patch, I got the following warnings.
>
> xlogfuncs.c:511:2: warning: format '%lX' expects argument of type
> 'long unsigned int *', but argument 3 has type 'uint64 *' [-Wfor
On Sun, Jan 22, 2012 at 1:13 AM, Euler Taveira de Oliveira
wrote:
> On 23-12-2011 12:05, Tom Lane wrote:
>> I too think a datatype is overkill, if we're only planning on providing
>> one function. Just emit the values as numeric and have done.
>>
> Here it is. Output changed to numeric.
Thanks!
On 23-12-2011 12:05, Tom Lane wrote:
> I too think a datatype is overkill, if we're only planning on providing
> one function. Just emit the values as numeric and have done.
>
Here it is. Output changed to numeric. While the output was int8 I could use
pg_size_pretty but now I couldn't. I attache
On 20 December 2011 10:27, Magnus Hagander wrote:
> Doing it in numeric should be perfectly fine. The only real reason to
> pick int8 over in this context would be performance, but it's not like
> this is something that's going to be called in really performance
> critical paths...
FYI, my group
On Sat, Jan 14, 2012 at 8:18 PM, Greg Smith wrote:
> On 01/14/2012 09:12 AM, Euler Taveira de Oliveira wrote:
>
>> But I must adjust the patch based on the thread comments (basically,
>> numeric output). I have a new patch but need to test it before submitting
>> it.
>> I'll post this weekend.
>>
On 01/14/2012 09:12 AM, Euler Taveira de Oliveira wrote:
But I must adjust the patch based on the thread comments (basically,
numeric output). I have a new patch but need to test it before submitting it.
I'll post this weekend.
It's now at https://commitfest.postgresql.org/action/patch_view?id=
On 14-01-2012 11:06, Fujii Masao wrote:
> I think that this function is very useful. Can you add the patch into
> CommitFest 2012-1 ?
>
Sure. But I must adjust the patch based on the thread comments (basically,
numeric output). I have a new patch but need to test it before submitting it.
I'll post
On Tue, Dec 6, 2011 at 1:19 PM, Euler Taveira de Oliveira
wrote:
> Hi,
>
> A while ago when blogging about WAL [1], I noticed a function to deal with
> xlog location arithmetic is wanted. I remembered Depez [2] mentioning it and
> after some questions during trainings and conferences I decided to
On Fri, Dec 23, 2011 at 10:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Dec 23, 2011 at 10:18 AM, Tom Lane wrote:
>>> Even if there are several, what exact advantage does a datatype offer
>>> over representing LSN values as numerics? It seems to me to be adding
>>> complication and e
Robert Haas writes:
> On Fri, Dec 23, 2011 at 10:18 AM, Tom Lane wrote:
>> Even if there are several, what exact advantage does a datatype offer
>> over representing LSN values as numerics? It seems to me to be adding
>> complication and extra code (I/O converters at least) for very little
>> ga
On Fri, Dec 23, 2011 at 10:18 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Dec 23, 2011 at 10:05 AM, Tom Lane wrote:
>>> I too think a datatype is overkill, if we're only planning on providing
>>> one function.
>
>> Are there any other functions we ought to provide?
>
> Even if there are
Robert Haas writes:
> On Fri, Dec 23, 2011 at 10:05 AM, Tom Lane wrote:
>> I too think a datatype is overkill, if we're only planning on providing
>> one function.
> Are there any other functions we ought to provide?
Even if there are several, what exact advantage does a datatype offer
over rep
On 12/23/2011 10:05 AM, Tom Lane wrote:
Magnus Hagander writes:
At this point, my question is: do we want to support the lsn data type idea or
a basic function that implements the difference between LSNs?
Personally I think a function is enough - it solves the only case that
I've actually se
On Fri, Dec 23, 2011 at 10:05 AM, Tom Lane wrote:
> I too think a datatype is overkill, if we're only planning on providing
> one function.
Are there any other functions we ought to provide?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
Magnus Hagander writes:
>> At this point, my question is: do we want to support the lsn data type idea
>> or
>> a basic function that implements the difference between LSNs?
> Personally I think a function is enough - it solves the only case that
> I've actually seen. But a datatype would be a m
On Tue, Dec 20, 2011 at 14:08, Euler Taveira de Oliveira
wrote:
> On 20-12-2011 07:27, Magnus Hagander wrote:
>> On Tue, Dec 6, 2011 at 19:06, Robert Haas wrote:
>>> On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
>>> wrote:
On 06-12-2011 13:11, Robert Haas wrote:
> On Tue, De
On 20-12-2011 07:27, Magnus Hagander wrote:
> On Tue, Dec 6, 2011 at 19:06, Robert Haas wrote:
>> On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
>> wrote:
>>> On 06-12-2011 13:11, Robert Haas wrote:
On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander
wrote:
> I've been cons
On Tue, Dec 6, 2011 at 19:06, Robert Haas wrote:
> On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
> wrote:
>> On 06-12-2011 13:11, Robert Haas wrote:
>>> On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander wrote:
I've been considering similar things, as you can find in the archives,
On Tue, Dec 13, 2011 at 12:48 PM, Jim Nasby wrote:
> I've often wondered about adding uint2/4/8... I suspect it's actually pretty
> uncommon for people to put negative numbers into int fields, since one of
> their biggest uses seems to be surrogate keys.
>
> I realize that this opens a can of wo
On Dec 6, 2011, at 12:06 PM, Robert Haas wrote:
> On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
> wrote:
>> On 06-12-2011 13:11, Robert Haas wrote:
>>> On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander wrote:
I've been considering similar things, as you can find in the archives,
>>
On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
wrote:
> On 06-12-2011 13:11, Robert Haas wrote:
>> On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander wrote:
>>> I've been considering similar things, as you can find in the archives,
>>> but what I was thinking of was converting the number
On 06-12-2011 13:11, Robert Haas wrote:
> On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander wrote:
>> I've been considering similar things, as you can find in the archives,
>> but what I was thinking of was converting the number to just a plain
>> bigint, then letting the user apply whatever arithme
On 06-12-2011 07:14, Magnus Hagander wrote:
> On Tue, Dec 6, 2011 at 05:19, Euler Taveira de Oliveira
> wrote:
>> Hi,
>>
>> A while ago when blogging about WAL [1], I noticed a function to deal with
>> xlog location arithmetic is wanted. I remembered Depez [2] mentioning it and
>> after some quest
On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander wrote:
> I've been considering similar things, as you can find in the archives,
> but what I was thinking of was converting the number to just a plain
> bigint, then letting the user apply whatever arithmetic wanted at the
> SQL level. I never got ar
On Tue, Dec 6, 2011 at 05:19, Euler Taveira de Oliveira
wrote:
> Hi,
>
> A while ago when blogging about WAL [1], I noticed a function to deal with
> xlog location arithmetic is wanted. I remembered Depez [2] mentioning it and
> after some questions during trainings and conferences I decided to tr
Hi,
A while ago when blogging about WAL [1], I noticed a function to deal with
xlog location arithmetic is wanted. I remembered Depez [2] mentioning it and
after some questions during trainings and conferences I decided to translate
my shell script function in C.
The attached patch implements the
61 matches
Mail list logo
