Brendan Jurd writes:
> I noticed that there are a whole bunch of errmsgs in ArrayCount and
> ReadArrayStr that just say "malformed array literal" with no detail
> message at all. Not very helpful. I'm tempted to improve that on my
> way past.
+1, regardless of whether we end up changing the sem
On 17 March 2013 06:27, Tom Lane wrote:
> What I'm concerned about here is whether these expressions shouldn't
> be yielding different data values:
>
>
> Right now, if we did make them produce what they appear to mean, the
> array I/O functions would have a problem with representing the results:
Alvaro Herrera writes:
> Tom Lane wrote:
>> Another way that we perhaps should consider is to follow the example of
>> XLogInsert and use internally-threaded lists that are typically stored
>> in local arrays in the callers. I've never thought that way was
>> especially beautiful, but it does hav
Boszormenyi Zoltan writes:
> [ 2-lock_timeout-v37.patch ]
Applied after a fair amount of additional hacking.
I was disappointed to find that the patch introduced a new race
condition into timeout.c, or at least broke a safety factor that had
been there. The argument why enable_timeout() could
Simon Riggs writes:
> On 15 March 2013 13:08, Andres Freund wrote:
>> I commented on this before, I personally think this property makes fletcher a
>> not so good fit for this. Its not uncommon for parts of a block being
>> all-zero
>> and many disk corruptions actually change whole runs of byte
Tom Lane wrote:
> Another way that we perhaps should consider is to follow the example of
> XLogInsert and use internally-threaded lists that are typically stored
> in local arrays in the callers. I've never thought that way was
> especially beautiful, but it does have the advantage of being an i
On 15 March 2013 13:08, Andres Freund wrote:
> On 2013-03-15 14:32:57 +0200, Ants Aasma wrote:
>> On Wed, Mar 6, 2013 at 1:34 PM, Heikki Linnakangas
>> wrote:
>> > Fletcher's checksum is good in general, I was mainly worried about
>> > truncating the Fletcher-64 into two 8-bit values. I can't spo
Brendan Jurd writes:
> On 17 March 2013 05:19, Tom Lane wrote:
>> Perhaps not. I think for most uses, a 1-D zero-length array would be
>> just as good. I guess what I'd want to know is whether we also need
>> to support higher-dimensional zero-size arrays, and if so, what does
>> the I/O syntax
On 17 March 2013 05:19, Tom Lane wrote:
> Brendan Jurd writes:
>> On 16 March 2013 09:07, Tom Lane wrote:
>>> The thing is that that syntax creates an array of zero dimensions,
>>> not one that has 1 dimension and zero elements.
>
>> I'm going to ask the question that immediately comes to mind:
2013/3/16 Tom Lane :
> Brendan Jurd writes:
>> On 16 March 2013 09:07, Tom Lane wrote:
>>> The thing is that that syntax creates an array of zero dimensions,
>>> not one that has 1 dimension and zero elements.
>
>> I'm going to ask the question that immediately comes to mind: Is there
>> anything
On 2013/03/17, at 0:35, Fujii Masao wrote:
> On Wed, Mar 13, 2013 at 9:04 PM, Michael Paquier
> wrote:
>> I have been working on improving the code of the 2 patches:
>
> I found pg_dump dumps even the invalid index. But pg_dump should
> ignore the invalid index?
> This problem exists even witho
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> On the whole though, I don't see anything wrong with pointer-and-count.
> I don't really believe that there's ever going to be a need to enable
> more than a couple of timeouts simultaneously, so I don't want an overly
> complicated data structure for it.
A
On Mar 16, 2013, at 11:19 AM, Tom Lane wrote:
> Perhaps not. I think for most uses, a 1-D zero-length array would be
> just as good. I guess what I'd want to know is whether we also need
> to support higher-dimensional zero-size arrays, and if so, what does
> the I/O syntax for those look like?
Brendan Jurd writes:
> On 16 March 2013 09:07, Tom Lane wrote:
>> The thing is that that syntax creates an array of zero dimensions,
>> not one that has 1 dimension and zero elements.
> I'm going to ask the question that immediately comes to mind: Is there
> anything good at all about being able
Stephen Frost writes:
> * Boszormenyi Zoltan (z...@cybertec.at) wrote:
>> Stephen Frost was against the array pointer/count variant,
>> it was done that way earlier. Let me redo it again. :-)
> I still don't particularly like the array approach, and see the
> array+count approach as worse (seems
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
> Stephen Frost was against the array pointer/count variant,
> it was done that way earlier. Let me redo it again. :-)
I still don't particularly like the array approach, and see the
array+count approach as worse (seems like a higher chance that the c
2013-03-16 17:42 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan writes:
2013-03-15 18:53 keltezéssel, Tom Lane írta:
Also, I'm not really enamored of the choice to use List* infrastructure
for enable_timeouts().
Changed. However, the first member of the structure is
"TimeoutId id" and a sensi
Boszormenyi Zoltan writes:
> 2013-03-15 18:53 keltezéssel, Tom Lane írta:
>> Also, I'm not really enamored of the choice to use List* infrastructure
>> for enable_timeouts().
> Changed. However, the first member of the structure is
> "TimeoutId id" and a sensible end-of-array value can be -1.
> S
2013-03-15 18:53 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan writes:
[ 2-lock_timeout-v33.patch ]
I looked at this patch a bit. I don't understand why you've chosen to
alter the API of the enable_timeout variants to have a bool result that
says "I didn't bother to process the timeout becau
On Wed, Mar 13, 2013 at 9:04 PM, Michael Paquier
wrote:
> I have been working on improving the code of the 2 patches:
I found pg_dump dumps even the invalid index. But pg_dump should
ignore the invalid index?
This problem exists even without REINDEX CONCURRENTLY patch. So we might need to
impleme
On 16 March 2013 09:07, Tom Lane wrote:
> "David E. Wheeler" writes:
>> This surprised me:
>
>> david=# select array_length('{}'::text[], 1);
>> array_length
>> --
>>[null]
>
>> I had expecte dit to retur 0. I might expect NULL for a NULL param, but not
>> on
21 matches
Mail list logo
