At Wed, 1 Jan 2020 23:46:02 -0800, Noah Misch wrote in
> On Wed, Dec 25, 2019 at 10:39:32AM +0900, Kyotaro Horiguchi wrote:
> > I'm not sure which is better. If we say we know that
> > repalloc(AllocSetRealloc) doesn't free memory at all, there's no point
> > in calling repalloc for shrinking and
On Wed, Dec 25, 2019 at 10:39:32AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 24 Dec 2019 11:57:39 -0800, Noah Misch wrote in
> > On Mon, Dec 23, 2019 at 07:41:49PM +0900, Kyotaro Horiguchi wrote:
> > > If we regard repalloc as far faster than FileOpen/FileClose or we care
> > > about only increas
At Tue, 24 Dec 2019 11:57:39 -0800, Noah Misch wrote in
> On Mon, Dec 23, 2019 at 07:41:49PM +0900, Kyotaro Horiguchi wrote:
> > If I understand it correctly, it is mentioning the number of the all
> > segment files in a fork, not the length of md_seg_fds arrays at a
> > certain moment. But actua
On Mon, Dec 23, 2019 at 07:41:49PM +0900, Kyotaro Horiguchi wrote:
> At Sun, 22 Dec 2019 12:21:00 -0800, Noah Misch wrote in
> > On Sun, Dec 22, 2019 at 01:19:30AM -0800, Noah Misch wrote:
> > > An alternative would be to call
> > > _fdvec_resize() after every FileClose(), like mdtruncate() does;
Hello.
At Sun, 22 Dec 2019 12:21:00 -0800, Noah Misch wrote in
> On Sun, Dec 22, 2019 at 01:19:30AM -0800, Noah Misch wrote:
> > I am inclined to fix this by decrementing md_num_open_segs before modifying
> > md_seg_fds (second attachment).
>
> That leaked memory, since _fdvec_resize() assumes
On Mon, Dec 23, 2019 at 09:33:29AM +1300, Thomas Munro wrote:
> On Sun, Dec 22, 2019 at 10:19 PM Noah Misch wrote:
> > Assert(segno == reln->md_num_open_segs[forknum]);
> > _fdvec_resize(reln, forknum, segno + 1);
>
> Oh yeah, I spotted that part too but didn't follow up.
>
> htt
On Sun, Dec 22, 2019 at 10:19 PM Noah Misch wrote:
> Assert(segno == reln->md_num_open_segs[forknum]);
> _fdvec_resize(reln, forknum, segno + 1);
Oh yeah, I spotted that part too but didn't follow up.
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BNBw%2BuSzxF1os-SO6gUuw%3
On Sun, Dec 22, 2019 at 01:19:30AM -0800, Noah Misch wrote:
> I am inclined to fix this by decrementing md_num_open_segs before modifying
> md_seg_fds (second attachment).
That leaked memory, since _fdvec_resize() assumes md_num_open_segs is also the
allocated array length. The alternative is loo
Forking thread "WAL logging problem in 9.4.3?" for this tangent:
On Mon, Dec 09, 2019 at 06:04:06PM +0900, Kyotaro Horiguchi wrote:
> I don't understand why mdclose checks for (v->mdfd_vfd >= 0) of open
> segment but anyway mdimmedsync is believing that that won't happen and
> I follow the assumpt
