On Sat, Apr 14, 2012 at 5:30 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 12, 2012 at 10:34 PM, Fujii Masao masao.fu...@gmail.com 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
On Sat, Apr 14, 2012 at 7:25 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Apr 14, 2012 at 5:30 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 12, 2012 at 10:34 PM, Fujii Masao masao.fu...@gmail.com wrote:
I can see a usecase for having a pg_size_pretty(numeric) as an option.
On Mon, Mar 12, 2012 at 10:34 PM, Fujii Masao masao.fu...@gmail.com 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
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 indicated
On Sat, Mar 10, 2012 at 3:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 12:38 PM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Mar 9, 2012 at 18:18, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Fri, Mar 9, 2012 at 15:37, Tom
On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm. I think thousands is an overestimate,
Fujii Masao masao.fu...@gmail.com writes:
On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Mar 13, 2012 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Mar 4, 2012 at 8:26 PM, Magnus Hagander mag...@hagander.net wrote:
On Sun, Feb 26, 2012 at 00:53, Euler Taveira de Oliveira
eu...@timbira.com 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,
Fujii Masao masao.fu...@gmail.com 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
On Fri, Mar 9, 2012 at 9:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com 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
I wrote:
Fujii Masao masao.fu...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 9, 2012 at 9:37 AM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Mar 9, 2012 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Fujii Masao masao.fu...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 9, 2012 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us 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',
On Fri, Mar 9, 2012 at 16:37, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 9, 2012 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Actually ... now that I look at it, isn't it completely bogus to be
using numeric for the result of
On Fri, Mar 9, 2012 at 15:37, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com 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
Magnus Hagander mag...@hagander.net writes:
On Fri, Mar 9, 2012 at 15:37, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Mar 9, 2012 at 18:18, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Fri, Mar 9, 2012 at 15:37, Tom Lane t...@sss.pgh.pa.us wrote:
Why would it be useful to use pg_size_pretty on xlog locations?
-1 because of the large expense of
On Fri, Mar 9, 2012 at 12:38 PM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Mar 9, 2012 at 18:18, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Fri, Mar 9, 2012 at 15:37, Tom Lane t...@sss.pgh.pa.us wrote:
Why would it be useful to use pg_size_pretty
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 pretty deep
Peter Eisentraut pete...@gmx.net 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
On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net 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
Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net 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
On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
Yeah, the use of XLogFile to mean something other than, well a file in
the xlog, is greatly annoying.. I guess we
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm. I think thousands is an overestimate, but yeah the logic could be
greatly simplified. However, I'm not
On Fri, Mar 9, 2012 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 9, 2012 at 2:34 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm. I think thousands is an overestimate,
On Sun, Feb 26, 2012 at 00:53, Euler Taveira de Oliveira
eu...@timbira.com 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
On Tue, Feb 28, 2012 at 07:21, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Feb 26, 2012 at 8:53 AM, Euler Taveira de Oliveira
eu...@timbira.com 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
On Sun, Feb 26, 2012 at 8:53 AM, Euler Taveira de Oliveira
eu...@timbira.com 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
On Fri, Feb 10, 2012 at 09:32, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Feb 10, 2012 at 7:00 AM, Euler Taveira de Oliveira
eu...@timbira.com 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
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 7:00 AM, Euler Taveira de Oliveira
eu...@timbira.com 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
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 reproduced
On Wed, Feb 8, 2012 at 2:29 AM, Euler Taveira de Oliveira
eu...@timbira.com 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
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 *'
On Sun, Jan 22, 2012 at 1:13 AM, Euler Taveira de Oliveira
eu...@timbira.com 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.
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 attached
On 20 December 2011 10:27, Magnus Hagander mag...@hagander.net 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...
On Tue, Dec 6, 2011 at 1:19 PM, Euler Taveira de Oliveira
eu...@timbira.com 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
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 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
On Sat, Jan 14, 2012 at 8:18 PM, Greg Smith g...@2ndquadrant.com 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
On Tue, Dec 20, 2011 at 14:08, Euler Taveira de Oliveira
eu...@timbira.com wrote:
On 20-12-2011 07:27, Magnus Hagander wrote:
On Tue, Dec 6, 2011 at 19:06, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
On 06-12-2011
Magnus Hagander mag...@hagander.net 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
On Fri, Dec 23, 2011 at 10:05 AM, Tom Lane t...@sss.pgh.pa.us 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
On 12/23/2011 10:05 AM, Tom Lane wrote:
Magnus Hagandermag...@hagander.net 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 23, 2011 at 10:05 AM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Dec 23, 2011 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 23, 2011 at 10:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I too think a datatype is overkill, if we're only planning on providing
one function.
Are there any other
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 23, 2011 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Dec 23, 2011 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 23, 2011 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Even if there are several, what exact advantage does a datatype offer
over representing LSN values as numerics?
On Tue, Dec 6, 2011 at 19:06, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
On 06-12-2011 13:11, Robert Haas wrote:
On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander mag...@hagander.net wrote:
I've been considering
On 20-12-2011 07:27, Magnus Hagander wrote:
On Tue, Dec 6, 2011 at 19:06, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
On 06-12-2011 13:11, Robert Haas wrote:
On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander
On Dec 6, 2011, at 12:06 PM, Robert Haas wrote:
On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
On 06-12-2011 13:11, Robert Haas wrote:
On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander mag...@hagander.net wrote:
I've been considering similar things, as you
On Tue, Dec 13, 2011 at 12:48 PM, Jim Nasby j...@nasby.net 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
On Tue, Dec 6, 2011 at 05:19, Euler Taveira de Oliveira
eu...@timbira.com 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
On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander mag...@hagander.net 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
On 06-12-2011 07:14, Magnus Hagander wrote:
On Tue, Dec 6, 2011 at 05:19, Euler Taveira de Oliveira
eu...@timbira.com 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
On 06-12-2011 13:11, Robert Haas wrote:
On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander mag...@hagander.net 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
On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
On 06-12-2011 13:11, Robert Haas wrote:
On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander mag...@hagander.net wrote:
I've been considering similar things, as you can find in the archives,
but what I was thinking
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
61 matches
Mail list logo
