Thank you Alvaro for reviewing the patch!
> On 01-Aug-2020, at 7:22 AM, Alvaro Herrera wrote:
>
> What happens if a replacement string happens to be split in the middle
> by the fgets buffering? I think it'll fail to be replaced. This
> applies to both versions.
Can a string to be replaced be
> On 03-Aug-2020, at 8:36 PM, Alvaro Herrera wrote:
>
> On 2020-Aug-03, Asim Praveen wrote:
>
>> Thank you Alvaro for reviewing the patch!
>>
>>> On 01-Aug-2020, at 7:22 AM, Alvaro Herrera wrote:
>>>
>>> What happens if a replacement
> On 03-Aug-2020, at 8:36 PM, Alvaro Herrera wrote:
>
> On 2020-Aug-03, Asim Praveen wrote:
>
>> Thank you Alvaro for reviewing the patch!
>>
>>> On 01-Aug-2020, at 7:22 AM, Alvaro Herrera wrote:
>>>
>>> What happens if a replacement string
> On 05-Aug-2020, at 7:01 PM, Alvaro Herrera wrote:
>
> On 2020-Aug-05, Asim Praveen wrote:
>
>> Please find attached a StringInfo based solution to this problem. It
>> uses fgetln instead of fgets such that a line is read in full, without
>> ever splitting it.
I would like to revive this thready by submitting a rebased patch to start
streaming replication without waiting for startup process to finish replaying
all WAL. The start LSN for streaming is determined to be the LSN that points
to the beginning of the most recently flushed WAL segment.
The p
> On 09-Aug-2020, at 2:11 PM, Michael Paquier wrote:
>
> I have not really looked at the proposed patch, but it would be good
> to have some documentation.
>
Ah, right. The basic idea is to reuse the logic to allow read-only connections
to also start WAL streaming. The patch borrows a new
> On 10-Aug-2020, at 12:27 PM, Masahiko Sawada
> wrote:
>
> The patch can be applied cleanly to the current HEAD but I got the
> error on building the code with this patch:
>
> xlog.c: In function 'StartupXLOG':
> xlog.c:7315:6: error: too few arguments to function 'RequestXLogStreaming'
> 73
The proposed fix looks good, it resolves the lock contention problem as
intended. +1 from my side.
> On 09-Jul-2020, at 4:22 PM, Fujii Masao wrote:
>
>
> Regarding how to fix, don't we need memory barrier when reading
> sync_standbys_defined? Without that, after SyncRepUpdateSyncStandbysDefine
> On 11-Aug-2020, at 8:57 PM, Robert Haas wrote:
>
> I think this gets to the root of the issue. If we check the flag
> without a lock, we might see a slightly stale value. But, considering
> that there's no particular amount of time within which configuration
> changes are guaranteed to take e
Hi Ashutosh
I stumbled upon this thread today, went through your patch and it looks good.
A minor suggestion in sanity_check_relation():
if (rel->rd_rel->relam != HEAP_TABLE_AM_OID)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> On 12-Aug-2020, at 12:02 PM, Masahiko Sawada
> wrote:
>
> On Wed, 12 Aug 2020 at 14:06, Asim Praveen wrote:
>>
>>
>>
>>> On 11-Aug-2020, at 8:57 PM, Robert Haas wrote:
>>>
>>> I think this gets to the root of the issue. If we c
> On 26-Aug-2020, at 11:10 PM, Fujii Masao wrote:
>
> I added the following comments based on the suggestion by Sawada-san
> upthread. Thought?
>
> + * Since this routine gets called every commit time, it's important to
> + * exit quickly if sync replication is not requested. So we c
> On 28-Aug-2020, at 7:03 AM, Fujii Masao wrote:
>
> On 2020/08/27 15:59, Asim Praveen wrote:
>>
>> +1. May I suggest the following addition to the above comment (feel free to
>> rephrase / reject)?
>> "If sync_standbys_defined was being set from
Let me (rather shamelessly) extract a couple of patches from the
patch set that was already shared in the fault injection framework
proposal [1].
The first patch incorporates a new syntax in isolation spec grammar to
explicitly mark a step that is expected to block (due to reasons other
than locks
> On 16-Sep-2020, at 8:32 AM, Li Japin wrote:
>
> Thanks for clarifying the questions!
>
>> On Sep 15, 2020, at 12:41 PM, Bharath Rupireddy
>> wrote:
>>
>> I think we must ask few questions:
>>
>> 1. What's the major gain we get out of this? Is it that the time to
>> stream gets reduced o
Hello
We are evaluating the use of shared buffers for temporary tables. The
advantage being queries involving temporary tables can make use of parallel
workers.
Challenges:
1. We lose the performance benefit of local buffers.
2. Additional complexity in shared buffer manager - BufferTag needs to
On Thu, May 24, 2018 at 8:19 PM, Tom Lane wrote:
>
> So then you have to think about how to transition smoothly between "rel
> is in local buffers" and "rel is in shared buffers", bearing in mind that
> ever having the same page in two different buffers would be disastrous.
Local buffers would no
Hi Amit
On Mon, May 28, 2018 at 4:25 AM, Amit Kapila wrote:
>
> This is one way, but I think there are other choices as well. We can
> identify and flush all the dirty (local) buffers for the relation
> being accessed parallelly. Now, once the parallel operation is
> started, we won't allow per
18 matches
Mail list logo
