On 27 November 2017 at 09:06, Tom Lane wrote:
> Simon Riggs writes:
>> On 27 November 2017 at 06:42, Tom Lane wrote:
>>> Sold, will make it so.
>
>> So you will like this next patch also, since there is related code
>> above that stanza.
>
> Looks reasonable to me, but I wonder whether BLCKSZ is
Simon Riggs writes:
> On 27 November 2017 at 06:42, Tom Lane wrote:
>> Sold, will make it so.
> So you will like this next patch also, since there is related code
> above that stanza.
Looks reasonable to me, but I wonder whether BLCKSZ is a good initial
setting. Since the data length is only u
On 27 November 2017 at 06:42, Tom Lane wrote:
> Simon Riggs writes:
>> On 27 November 2017 at 05:53, Tom Lane wrote:
>>> Well, let's not overthink this, because anything under 8K is going to
>>> be rounded up to the next power of 2 anyway by aset.c. Based on this
>>> point I'd say that BLCKSZ/2
Pad XLogReaderState's main_data buffer more aggressively.
Originally, we palloc'd this buffer just barely big enough to hold the
largest xlog record seen so far. It turns out that that can result in
valgrind complaints, because some compilers will emit code that assumes
it can safely fetch paddin
Pad XLogReaderState's main_data buffer more aggressively.
Originally, we palloc'd this buffer just barely big enough to hold the
largest xlog record seen so far. It turns out that that can result in
valgrind complaints, because some compilers will emit code that assumes
it can safely fetch paddin
Pad XLogReaderState's main_data buffer more aggressively.
Originally, we palloc'd this buffer just barely big enough to hold the
largest xlog record seen so far. It turns out that that can result in
valgrind complaints, because some compilers will emit code that assumes
it can safely fetch paddin
Pad XLogReaderState's main_data buffer more aggressively.
Originally, we palloc'd this buffer just barely big enough to hold the
largest xlog record seen so far. It turns out that that can result in
valgrind complaints, because some compilers will emit code that assumes
it can safely fetch paddin
Simon Riggs writes:
> On 27 November 2017 at 05:53, Tom Lane wrote:
>> Well, let's not overthink this, because anything under 8K is going to
>> be rounded up to the next power of 2 anyway by aset.c. Based on this
>> point I'd say that BLCKSZ/2 or BLCKSZ/4 would be reasonable candidates
>> for th
On 27 November 2017 at 05:53, Tom Lane wrote:
> Simon Riggs writes:
>> On 27 November 2017 at 04:46, Tom Lane wrote:
>>> Well, I'm concerned about the possibility of a lot of palloc thrashing
>>> if the first bunch of records it reads happen to have steadily increasing
>>> sizes. However, rathe
Simon Riggs writes:
> On 27 November 2017 at 04:46, Tom Lane wrote:
>> Well, I'm concerned about the possibility of a lot of palloc thrashing
>> if the first bunch of records it reads happen to have steadily increasing
>> sizes. However, rather than doubling, it might be sufficient to set a
>> r
On 27 November 2017 at 04:46, Tom Lane wrote:
> Simon Riggs writes:
>> On 26 November 2017 at 08:46, Tom Lane wrote:
>>> I've confirmed that the attached is sufficient to stop the valgrind crash
>>> on my machine. But as I said, I think we should be more aggressive at
>>> resizing the buffer, t
Make has_sequence_privilege support WITH GRANT OPTION
The various has_*_privilege() functions all support an optional
WITH GRANT OPTION added to the supported privilege types to test
whether the privilege is held with grant option. That is, all except
has_sequence_privilege() variations. Fix that.
Make has_sequence_privilege support WITH GRANT OPTION
The various has_*_privilege() functions all support an optional
WITH GRANT OPTION added to the supported privilege types to test
whether the privilege is held with grant option. That is, all except
has_sequence_privilege() variations. Fix that.
Make has_sequence_privilege support WITH GRANT OPTION
The various has_*_privilege() functions all support an optional
WITH GRANT OPTION added to the supported privilege types to test
whether the privilege is held with grant option. That is, all except
has_sequence_privilege() variations. Fix that.
Make has_sequence_privilege support WITH GRANT OPTION
The various has_*_privilege() functions all support an optional
WITH GRANT OPTION added to the supported privilege types to test
whether the privilege is held with grant option. That is, all except
has_sequence_privilege() variations. Fix that.
Make has_sequence_privilege support WITH GRANT OPTION
The various has_*_privilege() functions all support an optional
WITH GRANT OPTION added to the supported privilege types to test
whether the privilege is held with grant option. That is, all except
has_sequence_privilege() variations. Fix that.
Make has_sequence_privilege support WITH GRANT OPTION
The various has_*_privilege() functions all support an optional
WITH GRANT OPTION added to the supported privilege types to test
whether the privilege is held with grant option. That is, all except
has_sequence_privilege() variations. Fix that.
Simon Riggs writes:
> On 26 November 2017 at 08:46, Tom Lane wrote:
>> I've confirmed that the attached is sufficient to stop the valgrind crash
>> on my machine. But as I said, I think we should be more aggressive at
>> resizing the buffer, to reduce resize cycles. I'm inclined to start out
>>
On 25 November 2017 at 12:25, Tom Lane wrote:
> I wrote:
>> For me, this patch fixes the valgrind failures inside generation.c
>> itself, but I still see one more in the test_decoding run: ...
>> Not sure what to make of this: the stack traces make it look unrelated
>> to the GenerationContext cha
On 25 November 2017 at 02:35, Andrew Dunstan
wrote:
>
>
> On 11/23/2017 03:06 PM, Tom Lane wrote:
>>
>> I think it's a legitimate complaint that postmaster.log wasn't captured
>> in this failure, but that's a buildfarm script oversight and hardly
>> Andres' fault.
>>
>
> A fix for this will be in
On 26 November 2017 at 08:46, Tom Lane wrote:
> I wrote:
>> Instead I propose that we should make sure that the palloc request size
>> for XLogReaderState->main_data is always maxalign'd. The existing
>> behavior in DecodeXLogRecord of palloc'ing it only just barely big
>> enough for the current
21 matches
Mail list logo
