On Tue, Feb 18, 2020 at 11:33 AM Andres Freund wrote:
>
> On 2020-02-18 11:20:17 +0530, Amit Kapila wrote:
> > Andres, any objections on proceeding with Kuntal's patch for
> > back-branches (10, 9.6 and 9.5)?
>
> Yes. In my past experiments that lead to *terrible* allocator
> performance due to fr
On 2020-02-18 11:20:17 +0530, Amit Kapila wrote:
> Andres, any objections on proceeding with Kuntal's patch for
> back-branches (10, 9.6 and 9.5)?
Yes. In my past experiments that lead to *terrible* allocator
performance due to fragmentation. Like, up to 90% of the time spent in
aset.c. Try a wor
On Fri, Feb 14, 2020 at 4:06 PM Kuntal Ghosh wrote:
>
> On Sun, Feb 9, 2020 at 9:18 AM Amit Kapila wrote:
> >
> > It seems for this we formed a cache of max_cached_tuplebufs number of
> > objects and we don't need to allocate more than that number of tuples
> > of size MaxHeapTupleSize because we
On Fri, Feb 7, 2020 at 5:32 PM Kuntal Ghosh wrote:
>
> On Tue, Feb 4, 2020 at 2:40 PM Amit Kapila wrote:
> >
> > I don't think we can just back-patch that part of code as it is linked
> > to the way we are maintaining a cache (~8MB) for frequently allocated
> > objects. See the comments around t
On Sun, Feb 9, 2020 at 9:18 AM Amit Kapila wrote:
>
> It seems for this we formed a cache of max_cached_tuplebufs number of
> objects and we don't need to allocate more than that number of tuples
> of size MaxHeapTupleSize because we will anyway return that memory to
> aset.c.
>
In the approach su
Hello,
On Sat, Feb 8, 2020 at 1:18 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-02-07 20:02:01 +0100, Tomas Vondra wrote:
> > On Fri, Feb 07, 2020 at 10:33:48AM -0800, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
> > > > And, the issue got reproduced
On Sat, Feb 8, 2020 at 12:10 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
> > I performed the same test in pg11 and reproduced the issue on the
> > commit prior to a4ccc1cef5a04 (Generational memory allocator).
> >
> > ulimit -s 1024
> > ulimit -v 30
>
Hi,
On 2020-02-07 20:02:01 +0100, Tomas Vondra wrote:
> On Fri, Feb 07, 2020 at 10:33:48AM -0800, Andres Freund wrote:
> > Hi,
> >
> > On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
> > > And, the issue got reproduced with the same error:
> > > WARNING: problem in Generation Tuples: number of
Hi,
On 2020-01-11 23:20:56 -0500, Tom Lane wrote:
> Tomas Vondra writes:
> Nah, don't think I believe that: the test inserts a bunch of tuples,
> but they look like they will all be *exactly* the same size.
>
> CREATE TABLE decoding_test(x integer, y text);
> ...
>
> FOR i IN 1..10 LOOP
>
On Fri, Feb 07, 2020 at 10:33:48AM -0800, Andres Freund wrote:
Hi,
On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
And, the issue got reproduced with the same error:
WARNING: problem in Generation Tuples: number of free chunks 0 in
block 0x7fe9e9e74010 exceeds 1018 allocated
That seems lik
Hi,
On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
> I performed the same test in pg11 and reproduced the issue on the
> commit prior to a4ccc1cef5a04 (Generational memory allocator).
>
> ulimit -s 1024
> ulimit -v 30
>
> wal_level = logical
> max_replication_slots = 4
>
> [...]
> After
Hi,
On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
> And, the issue got reproduced with the same error:
> WARNING: problem in Generation Tuples: number of free chunks 0 in
> block 0x7fe9e9e74010 exceeds 1018 allocated
That seems like a problem in generation.c - because this should be
unreacha
On Tue, Feb 4, 2020 at 2:40 PM Amit Kapila wrote:
>
> I don't think we can just back-patch that part of code as it is linked
> to the way we are maintaining a cache (~8MB) for frequently allocated
> objects. See the comments around the definition of
> max_cached_tuplebufs. But probably, we can d
On Tue, Feb 4, 2020 at 10:15 AM Kuntal Ghosh wrote:
>
> On Sun, Jan 12, 2020 at 9:51 AM Tom Lane wrote:
> >
> > Tomas Vondra writes:
> > > On Sat, Jan 11, 2020 at 10:53:57PM -0500, Tom Lane wrote:
> > >> remind me where the win came from, exactly?
> >
> > > Well, the problem is that in 10 we all
On Sun, Jan 12, 2020 at 9:51 AM Tom Lane wrote:
>
> Tomas Vondra writes:
> > On Sat, Jan 11, 2020 at 10:53:57PM -0500, Tom Lane wrote:
> >> remind me where the win came from, exactly?
>
> > Well, the problem is that in 10 we allocate tuple data in the main
> > memory ReorderBuffer context, and wh
On Tue, Jan 14, 2020 at 9:58 AM Amit Kapila wrote:
>
> On Sun, Jan 12, 2020 at 8:18 AM Amit Kapila wrote:
> >
> > On Sat, Jan 11, 2020 at 11:16 AM Tom Lane wrote:
> > >
> >
> > > * The seeming bug in v10 suggests that we aren't testing large enough
> > > logical-decoding cases, or at least aren'
On Sun, Jan 12, 2020 at 8:18 AM Amit Kapila wrote:
>
> On Sat, Jan 11, 2020 at 11:16 AM Tom Lane wrote:
> >
>
> > * The seeming bug in v10 suggests that we aren't testing large enough
> > logical-decoding cases, or at least aren't noticing leaks in that
> > area. I'm not sure what a good design
Tomas Vondra writes:
> On Sat, Jan 11, 2020 at 10:53:57PM -0500, Tom Lane wrote:
>> remind me where the win came from, exactly?
> Well, the problem is that in 10 we allocate tuple data in the main
> memory ReorderBuffer context, and when the transaction gets decoded we
> pfree() it. But in AllocS
On Sat, Jan 11, 2020 at 10:53:57PM -0500, Tom Lane wrote:
Tomas Vondra writes:
On Thu, Jan 09, 2020 at 07:40:12PM -0500, Tom Lane wrote:
It seems reasonably likely to me that this result is telling us about
an actual bug, ie, faulty back-patching of one or more of those fixes
into v10 and perh
Tomas Vondra writes:
> On Thu, Jan 09, 2020 at 07:40:12PM -0500, Tom Lane wrote:
>> It seems reasonably likely to me that this result is telling us about
>> an actual bug, ie, faulty back-patching of one or more of those fixes
>> into v10 and perhaps earlier branches.
> Well, one thing we did in
On Thu, Jan 09, 2020 at 07:40:12PM -0500, Tom Lane wrote:
I wrote:
ReorderBuffer: 223302560 total in 26995 blocks; 7056 free (3 chunks);
223295504 used
The test case is only inserting 50K fairly-short rows, so this seems
like an unreasonable amount of memory to be consuming for tha
On Sat, Jan 11, 2020 at 11:16 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Fri, Jan 10, 2020 at 9:31 AM Amit Kapila wrote:
> >> ... So, we have the below
> >> options:
> >> (a) remove this test entirely from all branches and once we found the
> >> memory leak problem in back-branches, then
Amit Kapila writes:
> On Fri, Jan 10, 2020 at 9:31 AM Amit Kapila wrote:
>> ... So, we have the below
>> options:
>> (a) remove this test entirely from all branches and once we found the
>> memory leak problem in back-branches, then consider adding it again
>> without max_files_per_process restri
On Fri, Jan 10, 2020 at 9:31 AM Amit Kapila wrote:
>
> On Fri, Jan 10, 2020 at 6:10 AM Tom Lane wrote:
> >
> > I wrote:
> > > ReorderBuffer: 223302560 total in 26995 blocks; 7056 free (3
> > > chunks); 223295504 used
> >
> > > The test case is only inserting 50K fairly-short rows, so t
Noah Misch writes:
> On Thu, Jan 09, 2020 at 12:45:41AM -0500, Tom Lane wrote:
>> (1) Why did we get a crash and not some more-decipherable out-of-resources
>> error? Can we improve that experience?
> By default, 32-bit AIX binaries have maxdata:0x. Specifying
> maxdata:0x1000 provi
On Fri, Jan 10, 2020 at 6:10 AM Tom Lane wrote:
>
> I wrote:
> > ReorderBuffer: 223302560 total in 26995 blocks; 7056 free (3
> > chunks); 223295504 used
>
> > The test case is only inserting 50K fairly-short rows, so this seems
> > like an unreasonable amount of memory to be consuming
On Thu, Jan 09, 2020 at 12:45:41AM -0500, Tom Lane wrote:
> Noah Misch writes:
> > Even so, a web search for "extend_brk" led to the answer. By default,
> > 32-bit
> > AIX binaries get only 256M of RAM for stack and sbrk. The new regression
> > test
> > used more than that, hence this crash.
>
I wrote:
> ReorderBuffer: 223302560 total in 26995 blocks; 7056 free (3
> chunks); 223295504 used
> The test case is only inserting 50K fairly-short rows, so this seems
> like an unreasonable amount of memory to be consuming for that; and
> even if you think it's reasonable, it clearly
Amit Kapila writes:
> On Thu, Jan 9, 2020 at 11:15 AM Tom Lane wrote:
>> Noah Misch writes:
>>> Even so, a web search for "extend_brk" led to the answer. By default,
>>> 32-bit
>>> AIX binaries get only 256M of RAM for stack and sbrk. The new regression
>>> test
>>> used more than that, henc
On 2020-Jan-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > Hmm, so why not revert the test only in the back branches, given that
> > it's not so onerous in master?
>
> I grow tired of repeating myself, but: it's purely accidental that this
> test passes in master for the existing set of buildf
Alvaro Herrera writes:
> Hmm, so why not revert the test only in the back branches, given that
> it's not so onerous in master?
I grow tired of repeating myself, but: it's purely accidental that this
test passes in master for the existing set of buildfarm members.
If I have to do so to prove my
On 2020-Jan-09, Amit Kapila wrote:
> In HEAD, we have a guc variable 'logical_decoding_work_mem' by which
> we can control the memory usage of changes and we have used that, but
> for back branches, we don't have such a control.
> After the latest changes by Noah, the tern and mandrill both are
>
On Thu, Jan 9, 2020 at 11:15 AM Tom Lane wrote:
>
> Noah Misch writes:
> > Even so, a web search for "extend_brk" led to the answer. By default,
> > 32-bit
> > AIX binaries get only 256M of RAM for stack and sbrk. The new regression
> > test
> > used more than that, hence this crash.
>
> Hm,
On Thu, Jan 9, 2020 at 11:15 AM Tom Lane wrote:
>
> Noah Misch writes:
> > Even so, a web search for "extend_brk" led to the answer. By default,
> > 32-bit
> > AIX binaries get only 256M of RAM for stack and sbrk. The new regression
> > test
> > used more than that, hence this crash.
>
> Hm,
Noah Misch writes:
> Even so, a web search for "extend_brk" led to the answer. By default, 32-bit
> AIX binaries get only 256M of RAM for stack and sbrk. The new regression test
> used more than that, hence this crash.
Hm, so
(1) Why did we get a crash and not some more-decipherable out-of-res
On Wed, Jan 08, 2020 at 02:50:53PM +0530, Amit Khandekar wrote:
> On Sun, 5 Jan 2020 at 00:21, Noah Misch wrote:
> > The buildfarm client can capture stack traces, but it currently doesn't do
> > so
> > for TAP test suites (search the client code for get_stack_trace). If
> > someone
> > feels l
On Sun, Jan 5, 2020 at 10:29 AM Amit Kapila wrote:
>
> On Sun, Jan 5, 2020 at 12:21 AM Noah Misch wrote:
> >
> > On Fri, Jan 03, 2020 at 02:20:09PM +0530, Amit Khandekar wrote:
> > > On Fri, 3 Jan 2020 at 10:19, Amit Kapila wrote:
> > > > On Fri, Jan 3, 2020 at 8:29 AM Amit Kapila
> > > > wrot
On Sun, 5 Jan 2020 at 00:21, Noah Misch wrote:
> The buildfarm client can capture stack traces, but it currently doesn't do so
> for TAP test suites (search the client code for get_stack_trace). If someone
> feels like writing a fix for that, it would be a nice improvement. Perhaps,
> rather tha
On Sun, Jan 5, 2020 at 12:21 AM Noah Misch wrote:
>
> On Fri, Jan 03, 2020 at 02:20:09PM +0530, Amit Khandekar wrote:
> > On Fri, 3 Jan 2020 at 10:19, Amit Kapila wrote:
> > > On Fri, Jan 3, 2020 at 8:29 AM Amit Kapila
> > > wrote:
> > >> I see one failure in REL_10_STABLE [1] which seems to be
On Fri, Jan 03, 2020 at 02:20:09PM +0530, Amit Khandekar wrote:
> On Fri, 3 Jan 2020 at 10:19, Amit Kapila wrote:
> > On Fri, Jan 3, 2020 at 8:29 AM Amit Kapila wrote:
> >> I see one failure in REL_10_STABLE [1] which seems to be due to this
> >> commit:
> >
> > I tried this test on my CentOs an
On Fri, 3 Jan 2020 at 10:19, Amit Kapila wrote:
>
> On Fri, Jan 3, 2020 at 8:29 AM Amit Kapila wrote:
>>
>> On Thu, Jan 2, 2020 at 5:44 PM Amit Kapila wrote:
>>>
>>> On Tue, Dec 24, 2019 at 2:31 PM Amit Khandekar
>>> wrote:
>>> >
>>> >
>>> > Ok. I tested pg94_95_use_vfd_for_logrep.patch for 9.
On Fri, Jan 3, 2020 at 8:29 AM Amit Kapila wrote:
> On Thu, Jan 2, 2020 at 5:44 PM Amit Kapila
> wrote:
>
>> On Tue, Dec 24, 2019 at 2:31 PM Amit Khandekar
>> wrote:
>> >
>> >
>> > Ok. I tested pg94_95_use_vfd_for_logrep.patch for 9.6 branch, and it
>> > works there. So please use this patch fo
On Thu, Jan 2, 2020 at 5:44 PM Amit Kapila wrote:
> On Tue, Dec 24, 2019 at 2:31 PM Amit Khandekar
> wrote:
> >
> >
> > Ok. I tested pg94_95_use_vfd_for_logrep.patch for 9.6 branch, and it
> > works there. So please use this patch for all the three branches.
> >
>
> Pushed!
>
I see one failure
On Tue, Dec 24, 2019 at 2:31 PM Amit Khandekar wrote:
>
> On Tue, 24 Dec 2019 at 10:41, Amit Kapila wrote:
> >
> > On Fri, Dec 20, 2019 at 9:31 AM Amit Khandekar
> > wrote:
> > > Attached are the patches from master back up to 94 branch.
> > >
> > > PG 9.4 and 9.5 have a common patch to be appl
On Tue, 24 Dec 2019 at 10:41, Amit Kapila wrote:
>
> On Fri, Dec 20, 2019 at 9:31 AM Amit Khandekar wrote:
> > Attached are the patches from master back up to 94 branch.
> >
> > PG 9.4 and 9.5 have a common patch to be applied :
> > pg94_95_use_vfd_for_logrep.patch
> > From PG 9.6 onwards, each v
On Fri, Dec 20, 2019 at 9:31 AM Amit Khandekar wrote:
> Attached are the patches from master back up to 94 branch.
>
> PG 9.4 and 9.5 have a common patch to be applied :
> pg94_95_use_vfd_for_logrep.patch
> From PG 9.6 onwards, each version has a separate patch.
>
> For PG 9.6, there is no logical
On Thu, 19 Dec 2019 at 11:59, Amit Kapila wrote:
>
> On Wed, Dec 18, 2019 at 12:34 PM Amit Khandekar
> wrote:
> >
> > On Tue, 17 Dec 2019 at 17:40, Amit Khandekar wrote:
> > > By the way, the backport patch is turning out to be simpler. It's
> > > because in pre-12 versions, the file offset is
On Wed, Dec 18, 2019 at 12:34 PM Amit Khandekar wrote:
>
> On Tue, 17 Dec 2019 at 17:40, Amit Khandekar wrote:
> > By the way, the backport patch is turning out to be simpler. It's
> > because in pre-12 versions, the file offset is part of the Vfd
> > structure, so all the offset handling is not
On Tue, 17 Dec 2019 at 17:40, Amit Khandekar wrote:
> By the way, the backport patch is turning out to be simpler. It's
> because in pre-12 versions, the file offset is part of the Vfd
> structure, so all the offset handling is not required.
Please have a look at the attached backport patch for P
On Mon, 16 Dec 2019 at 16:52, Amit Kapila wrote:
>
> On Mon, Dec 16, 2019 at 3:26 PM Amit Khandekar wrote:
> >
> > On Sat, 14 Dec 2019 at 11:59, Amit Kapila wrote:
> > >
> > > I have also made minor changes related to below code in patch:
> > > - else if (readBytes != sizeof(ReorderBufferDiskCha
On Mon, Dec 16, 2019 at 3:26 PM Amit Khandekar wrote:
>
> On Sat, 14 Dec 2019 at 11:59, Amit Kapila wrote:
> >
> > I have also made minor changes related to below code in patch:
> > - else if (readBytes != sizeof(ReorderBufferDiskChange))
> > +
> > + file->curOffset += readBytes;
> > +
> > + if (
On Sat, 14 Dec 2019 at 11:59, Amit Kapila wrote:
>
> On Thu, Dec 12, 2019 at 9:50 PM Amit Khandekar wrote:
> >
> > Attached is a v4 patch that also addresses your code comments so far.
> > I have included the test case in 006_logical_decoding.pl. I observed
> > that the test case just adds only a
On Thu, Dec 12, 2019 at 9:50 PM Amit Khandekar wrote:
>
> Attached is a v4 patch that also addresses your code comments so far.
> I have included the test case in 006_logical_decoding.pl. I observed
> that the test case just adds only about 0.5 to 1 sec time. Please
> verify on your env also, and
On Thu, 12 Dec 2019 at 14:18, Amit Kapila wrote:
>
> On Thu, Dec 12, 2019 at 11:53 AM Amit Khandekar
> wrote:
> >
> > On Thu, 12 Dec 2019 at 11:34, Amit Khandekar wrote:
> >
> > > So max_changes_in_memory is the one
> > > that allows us to reduce the number of transactions required, so we
> > >
On Thu, Dec 12, 2019 at 11:53 AM Amit Khandekar wrote:
>
> On Thu, 12 Dec 2019 at 11:34, Amit Khandekar wrote:
>
> > So max_changes_in_memory is the one
> > that allows us to reduce the number of transactions required, so we
> > can cut down on the outer loop iterations and make the test finish
>
On Thu, 12 Dec 2019 at 11:34, Amit Khandekar wrote:
> So max_changes_in_memory is the one
> that allows us to reduce the number of transactions required, so we
> can cut down on the outer loop iterations and make the test finish
> much earlier.
>
> But also note that, we can't use the test suite
On Thu, 12 Dec 2019 at 09:49, Amit Kapila wrote:
>
> On Wed, Dec 11, 2019 at 4:17 PM Amit Khandekar wrote:
> >
> > On Sat, 7 Dec 2019 at 11:37, Amit Kapila wrote:
> > >
> > > On Fri, Dec 6, 2019 at 5:00 PM Amit Khandekar
> > > wrote:
> > > >
> > > > On Fri, 6 Dec 2019 at 15:40, Amit Kapila
>
On Wed, Dec 11, 2019 at 4:17 PM Amit Khandekar wrote:
>
> On Sat, 7 Dec 2019 at 11:37, Amit Kapila wrote:
> >
> > On Fri, Dec 6, 2019 at 5:00 PM Amit Khandekar
> > wrote:
> > >
> > > On Fri, 6 Dec 2019 at 15:40, Amit Kapila wrote:
> > > >
> > > > 1.
> > > > + /* Now that the state fields are i
On Sat, 7 Dec 2019 at 11:37, Amit Kapila wrote:
>
> On Fri, Dec 6, 2019 at 5:00 PM Amit Khandekar wrote:
> >
> > On Fri, 6 Dec 2019 at 15:40, Amit Kapila wrote:
> > >
> > >
> > > Few comments:
> > > --
> > >
> > > 1.
> > > + /* Now that the state fields are initialized, it is
On Wed, Nov 20, 2019 at 1:14 AM Juan José Santamaría Flecha
wrote:
> On Tue, Nov 19, 2019 at 12:49 PM Thomas Munro wrote:
>> On Wed, Nov 20, 2019 at 12:28 AM Amit Khandekar
>> wrote:
>> > On Windows, it is documented that ReadFile() (which is called by
>> > pg_pread) will return false on EOF bu
On Fri, Dec 6, 2019 at 5:00 PM Amit Khandekar wrote:
>
> On Fri, 6 Dec 2019 at 15:40, Amit Kapila wrote:
> >
> >
> > Few comments:
> > --
> >
> > 1.
> > + /* Now that the state fields are initialized, it is safe to return it. */
> > + *iter_state = state;
> > +
> > /* alloca
On Fri, 6 Dec 2019 at 15:40, Amit Kapila wrote:
>
> On Thu, Dec 5, 2019 at 4:20 PM Amit Kapila wrote:
> >
> > On Tue, Dec 3, 2019 at 11:10 AM Amit Khandekar
> > wrote:
> > >
> > >
> > > Done as stated above; attached v3 patch. I have verified that the file
> > > handles do get closed in PG_CATC
On Thu, Dec 5, 2019 at 4:20 PM Amit Kapila wrote:
>
> On Tue, Dec 3, 2019 at 11:10 AM Amit Khandekar wrote:
> >
> >
> > Done as stated above; attached v3 patch. I have verified that the file
> > handles do get closed in PG_CATCH block via
> > ReorderBufferIterTXNFinish().
> >
>
> I couldn't repro
On Tue, Dec 3, 2019 at 11:10 AM Amit Khandekar wrote:
>
> On Wed, 27 Nov 2019 at 14:16, Amit Khandekar wrote:
> > What I found was : We do attempt to close the opened vfds in the
> > PG_CATCH block. In ReorderBufferCommit(), ReorderBufferIterTXNFinish
> > is called both in PG_TRY and PG_CATCH. Th
On Wed, 27 Nov 2019 at 14:16, Amit Khandekar wrote:
> What I found was : We do attempt to close the opened vfds in the
> PG_CATCH block. In ReorderBufferCommit(), ReorderBufferIterTXNFinish
> is called both in PG_TRY and PG_CATCH. This closes all the opened
> vfds. But the issue is : if the erepor
On Tue, 26 Nov 2019 at 12:10, Amit Kapila wrote:
>
> On Tue, Nov 26, 2019 at 11:19 AM Amit Khandekar
> wrote:
> >
> > On Tue, 26 Nov 2019 at 10:49, Amit Kapila wrote:
> > >
> > >
> > > So, what is the next step here? How about if we somehow check whether
> > > the file exists before doing unli
On Tue, Nov 26, 2019 at 11:19 AM Amit Khandekar wrote:
>
> On Tue, 26 Nov 2019 at 10:49, Amit Kapila wrote:
> >
> >
> > So, what is the next step here? How about if we somehow check whether
> > the file exists before doing unlink, say by using stat?
> But the thing is, the behaviour is so much i
On Tue, 26 Nov 2019 at 10:49, Amit Kapila wrote:
>
> On Fri, Nov 22, 2019 at 7:38 PM Amit Khandekar wrote:
> >
> > On Fri, 22 Nov 2019 at 4:26 PM, Amit Kapila wrote:
> >>
> >> I think this is exactly the reason for the problem. In my test [1],
> >> the error "permission denied" occurred when I
On Fri, Nov 22, 2019 at 7:38 PM Amit Khandekar wrote:
>
> On Fri, 22 Nov 2019 at 4:26 PM, Amit Kapila wrote:
>>
>> I think this is exactly the reason for the problem. In my test [1],
>> the error "permission denied" occurred when I second time executed
>> pg_logical_slot_get_changes() which mean
On Fri, Nov 22, 2019 at 4:38 AM Amit Kapila wrote:
> On Thu, Nov 21, 2019 at 8:32 PM Juan José Santamaría Flecha
> wrote:
> >
> > [1] Win10 (1903) MSVC 19.22.27905
> >
>
> I have tested this on Windows7. I am not sure if it is due to a
> different version of windows, but I think we can't rule ou
On Fri, 22 Nov 2019 at 4:26 PM, Amit Kapila wrote:
> On Fri, Nov 22, 2019 at 11:00 AM Amit Khandekar
> wrote:
> >
> > On Fri, 22 Nov 2019 at 09:08, Amit Kapila
> wrote:
> > > Have you tried before that fix , if not, can you once try by
> > > temporarily reverting that fix in your environment an
On Fri, Nov 22, 2019 at 11:00 AM Amit Khandekar wrote:
>
> On Fri, 22 Nov 2019 at 09:08, Amit Kapila wrote:
> > Have you tried before that fix , if not, can you once try by
> > temporarily reverting that fix in your environment and share the
> > output of each step? After you get the error due t
On Fri, 22 Nov 2019 at 09:08, Amit Kapila wrote:
> Have you tried before that fix , if not, can you once try by
> temporarily reverting that fix in your environment and share the
> output of each step? After you get the error due to EOF, check that
> you have .spill files in pg_replslot// and the
On Thu, Nov 21, 2019 at 8:32 PM Juan José Santamaría Flecha
wrote:
>
> On Thu, Nov 21, 2019 at 5:02 AM Amit Kapila wrote:
>>
>> On Wed, Nov 20, 2019 at 5:41 PM Juan José Santamaría Flecha
>> wrote:
>> >
>> > On Wed, Nov 20, 2019 at 9:48 AM Amit Khandekar
>> > wrote:
>> >>
>> >> On Wed, 20 Nov
On Thu, Nov 21, 2019 at 5:02 AM Amit Kapila wrote:
> On Wed, Nov 20, 2019 at 5:41 PM Juan José Santamaría Flecha
> wrote:
> >
> > On Wed, Nov 20, 2019 at 9:48 AM Amit Khandekar
> wrote:
> >>
> >> On Wed, 20 Nov 2019 at 13:10, Amit Kapila
> wrote:
> >> > See comment in pgunlink() "We need to lo
On Wed, Nov 20, 2019 at 2:18 PM Amit Khandekar wrote:
>
> On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
> > See comment in pgunlink() "We need to loop because even though
> > PostgreSQL uses flags that allow unlink while the file is open, other
> > applications might have the file
> > open wit
On Wed, Nov 20, 2019 at 5:41 PM Juan José Santamaría Flecha
wrote:
>
> On Wed, Nov 20, 2019 at 9:48 AM Amit Khandekar wrote:
>>
>> On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
>> > See comment in pgunlink() "We need to loop because even though
>> > PostgreSQL uses flags that allow unlink whi
On Wed, 20 Nov 2019 at 19:24, Alvaro Herrera wrote:
>
> On 2019-Nov-20, Juan José Santamaría Flecha wrote:
>
> > I was not able to reproduce the Permission denied error with current HEAD,
> > until I opened another CMD inside the "pg_replslot/regression_slot" folder.
> > This will be problematic,
On 2019-Nov-20, Juan José Santamaría Flecha wrote:
> I was not able to reproduce the Permission denied error with current HEAD,
> until I opened another CMD inside the "pg_replslot/regression_slot" folder.
> This will be problematic, is the deletion of the folder actually needed?
Yes :-( The cod
On Wed, Nov 20, 2019 at 9:48 AM Amit Khandekar
wrote:
> On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
> > See comment in pgunlink() "We need to loop because even though
> > PostgreSQL uses flags that allow unlink while the file is open, other
> > applications might have the file
> > open with
On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
> See comment in pgunlink() "We need to loop because even though
> PostgreSQL uses flags that allow unlink while the file is open, other
> applications might have the file
> open without those flags.". Can you once see if there is any flag
> that y
On Wed, 20 Nov 2019 at 13:10, Amit Kapila wrote:
>
> On Tue, Nov 19, 2019 at 4:58 PM Amit Khandekar wrote:
> >
> > On Tue, 19 Nov 2019 at 14:07, Amit Kapila wrote:
> > >
> > >
> > > Have you tried by injecting some error? After getting the error
> > > mentioned above in email, when I retried th
On Tue, Nov 19, 2019 at 4:58 PM Amit Khandekar wrote:
>
> On Tue, 19 Nov 2019 at 14:07, Amit Kapila wrote:
> >
> >
> > Have you tried by injecting some error? After getting the error
> > mentioned above in email, when I retried the same query, I got the
> > below message.
> >
> > postgres=# SELE
On Wed, Nov 20, 2019 at 5:44 PM Amit Kapila wrote:
> On Wed, Nov 20, 2019 at 12:28 AM Thomas Munro wrote:
> > + if (GetLastError() == ERROR_HANDLE_EOF)
> > + return 0;
> Yes, this works for me.
Thanks, pushed.
On Tue, Nov 19, 2019 at 4:58 PM Amit Khandekar wrote:
>
> On Tue, 19 Nov 2019 at 14:07, Amit Kapila wrote:
> >
> > On Mon, Nov 18, 2019 at 5:50 PM Amit Khandekar
> > wrote:
> > >
> > > For the API's that use VFDs (like PathNameOpenFile), the files opened
> > > are always recorded in the VfdCach
On Wed, Nov 20, 2019 at 4:54 PM Amit Khandekar wrote:
> - BufFileLoadBuffer() seems to deliberately ignore FileRead()'s return
> value if it is -1
> if (file->nbytes < 0) file->nbytes = 0;
Ok, that's a different problem we need to fix then. But it does
explain how we didn't know. And sure e
On Wed, Nov 20, 2019 at 12:28 AM Thomas Munro wrote:
>
> On Wed, Nov 20, 2019 at 1:14 AM Juan José Santamaría Flecha
> wrote:
> > On Tue, Nov 19, 2019 at 12:49 PM Thomas Munro
> > wrote:
> >> On Wed, Nov 20, 2019 at 12:28 AM Amit Khandekar
> >> wrote:
> >> > On Windows, it is documented that
On Wed, 20 Nov 2019 at 01:05, Thomas Munro wrote:
>
> On Wed, Nov 20, 2019 at 7:58 AM Thomas Munro wrote:
> > On Wed, Nov 20, 2019 at 1:14 AM Juan José Santamaría Flecha
> > > https://devblogs.microsoft.com/oldnewthing/20150121-00/?p=44863
> >
> > !?!
Thanks Juan and Thomas for pointing to these
On Wed, Nov 20, 2019 at 7:58 AM Thomas Munro wrote:
> On Wed, Nov 20, 2019 at 1:14 AM Juan José Santamaría Flecha
> > https://devblogs.microsoft.com/oldnewthing/20150121-00/?p=44863
>
> !?!
One thing I don't understand (besides, apparently, the documentation):
how did this problem escape detectio
On Wed, Nov 20, 2019 at 1:14 AM Juan José Santamaría Flecha
wrote:
> On Tue, Nov 19, 2019 at 12:49 PM Thomas Munro wrote:
>> On Wed, Nov 20, 2019 at 12:28 AM Amit Khandekar
>> wrote:
>> > On Windows, it is documented that ReadFile() (which is called by
>> > pg_pread) will return false on EOF bu
On Tue, Nov 19, 2019 at 12:49 PM Thomas Munro
wrote:
> On Wed, Nov 20, 2019 at 12:28 AM Amit Khandekar
> wrote:
> > On Tue, 19 Nov 2019 at 14:07, Amit Kapila
> wrote:
> > > No, I got this before applying the patch. However, after applying the
> > > patch, I got below error in the same test:
>
On Wed, Nov 20, 2019 at 12:28 AM Amit Khandekar wrote:
> On Tue, 19 Nov 2019 at 14:07, Amit Kapila wrote:
> > No, I got this before applying the patch. However, after applying the
> > patch, I got below error in the same test:
> >
> > postgres=# SELECT 1 from
> > pg_logical_slot_get_changes('reg
On Tue, 19 Nov 2019 at 14:07, Amit Kapila wrote:
>
> On Mon, Nov 18, 2019 at 5:50 PM Amit Khandekar wrote:
> >
> > On Mon, 18 Nov 2019 at 17:20, Amit Kapila wrote:
> > > I see that you have made changes in ReorderBufferRestoreChanges to use
> > > PathNameOpenFile, but not in ReorderBufferSeriali
On Mon, Nov 18, 2019 at 5:50 PM Amit Khandekar wrote:
>
> On Mon, 18 Nov 2019 at 17:20, Amit Kapila wrote:
> > I see that you have made changes in ReorderBufferRestoreChanges to use
> > PathNameOpenFile, but not in ReorderBufferSerializeTXN. Is there a
> > reason for the same? In my test enviro
On Mon, 18 Nov 2019 at 17:52, Amit Kapila wrote:
> I have one more question regarding this patch. It seems to me that
> the files opened via OpenTransientFile or OpenTemporaryFile are
> automatically closed at transaction end(abort), but that doesn't seem
> to be the case for files opened with P
On Mon, Nov 18, 2019 at 5:20 PM Amit Kapila wrote:
>
> On Thu, Oct 3, 2019 at 4:48 PM Amit Khandekar wrote:
> >
> > On Wed, 18 Sep 2019 at 12:24, Amit Khandekar wrote:
> > > Probably, for now at least, what everyone seems to agree is to take my
> > > earlier attached patch forward.
> > >
> > > I
On Mon, 18 Nov 2019 at 17:20, Amit Kapila wrote:
> I see that you have made changes in ReorderBufferRestoreChanges to use
> PathNameOpenFile, but not in ReorderBufferSerializeTXN. Is there a
> reason for the same? In my test environment, with the test provided
> by you, I got the error (reported
On Thu, Oct 3, 2019 at 4:48 PM Amit Khandekar wrote:
>
> On Wed, 18 Sep 2019 at 12:24, Amit Khandekar wrote:
> > Probably, for now at least, what everyone seems to agree is to take my
> > earlier attached patch forward.
> >
> > I am going to see if I can add a TAP test for the patch, and will add
On Wed, 18 Sep 2019 at 12:24, Amit Khandekar wrote:
> Probably, for now at least, what everyone seems to agree is to take my
> earlier attached patch forward.
>
> I am going to see if I can add a TAP test for the patch, and will add
> the patch into the commitfest soon.
Attached is an updated pat
On Tue, 17 Sep 2019 at 21:19, Andres Freund wrote:
> On 2019-09-14 14:34:21 -0400, Tom Lane wrote:
> > Amit Khandekar writes:
> > > Yeah, something like the attached patch. I think this tracking of
> > > offsets would have been cleaner if we add in-built support in VFD. But
> > > yeah, for bank b
1 - 100 of 113 matches
Mail list logo
