On Fri, Mar 15, 2019 at 3:25 PM Amit Kapila wrote:
>
> I have committed the latest version of this patch. I think we can
> wait for a day or two see if there is any complain from buildfarm or
> in general and then we can close this CF entry.
>
Closed this CF entry.
--
With Regards,
Amit Kapila
On Fri, Mar 15, 2019 at 3:40 PM John Naylor wrote:
>
> On Fri, Mar 15, 2019 at 5:55 PM Amit Kapila wrote:
> > I have committed the latest version of this patch. I think we can
> > wait for a day or two see if there is any complain from buildfarm or
> > in general and then we can close this CF en
On Fri, Mar 15, 2019 at 5:55 PM Amit Kapila wrote:
> I have committed the latest version of this patch. I think we can
> wait for a day or two see if there is any complain from buildfarm or
> in general and then we can close this CF entry. IIRC, this was the
> last patch in the series, right?
G
On Thu, Mar 14, 2019 at 7:46 PM Amit Kapila wrote:
>
> On Thu, Mar 14, 2019 at 12:37 PM John Naylor
> wrote:
> >
> > On Thu, Mar 14, 2019 at 2:17 PM Amit Kapila wrote:
> > >
> > > 1. Added an Assert in new_cluster_needs_fsm() that old cluster version
> > > should be >= 804 as that is where fsm s
On Thu, Mar 14, 2019 at 12:37 PM John Naylor
wrote:
>
> On Thu, Mar 14, 2019 at 2:17 PM Amit Kapila wrote:
> >
> > 1. Added an Assert in new_cluster_needs_fsm() that old cluster version
> > should be >= 804 as that is where fsm support has been added.
>
> There is already an explicit check for 80
On Thu, Mar 14, 2019 at 2:17 PM Amit Kapila wrote:
>
> 1. Added an Assert in new_cluster_needs_fsm() that old cluster version
> should be >= 804 as that is where fsm support has been added.
There is already an explicit check for 804 in the caller, and the HEAD
code is already resilient to FSMs no
On Thu, Mar 14, 2019 at 7:08 AM John Naylor wrote:
>
> > [segfault problems]
>
> This now seems spurious. I ran make distclean, git pull, reapplied the
> patch (leaving out the gettimeofday() calls), and now my upgrade perf
> test works with default compiler settings. Not sure what happened, but
>
> [segfault problems]
This now seems spurious. I ran make distclean, git pull, reapplied the
patch (leaving out the gettimeofday() calls), and now my upgrade perf
test works with default compiler settings. Not sure what happened, but
hopefully we can move forward.
--
John Naylorh
On Wed, Mar 13, 2019 at 7:42 PM John Naylor wrote:
>
> On Wed, Mar 13, 2019 at 8:18 PM Amit Kapila wrote:
> > > First, I had a problem: On MacOS with their "gcc" wrapper around
> > > clang, I got a segfault 11 when compiled with no debugging symbols.
> > >
> >
> > Did you get this problem with th
On Wed, Mar 13, 2019 at 8:18 PM Amit Kapila wrote:
> > First, I had a problem: On MacOS with their "gcc" wrapper around
> > clang, I got a segfault 11 when compiled with no debugging symbols.
> >
>
> Did you get this problem with the patch or both with and without the
> patch? If it is only with
On Wed, Mar 13, 2019 at 4:57 PM John Naylor wrote:
>
> On Fri, Mar 8, 2019 at 7:43 PM Amit Kapila wrote:
>
> > Have you done any performance testing of this patch? I mean to say
> > now that we added a new stat call for each table, we should see if
> > that has any impact. Ideally, that should
On Fri, Mar 8, 2019 at 7:43 PM Amit Kapila wrote:
> Have you done any performance testing of this patch? I mean to say
> now that we added a new stat call for each table, we should see if
> that has any impact. Ideally, that should be compensated by the fact
> that we are now not transferring *
On Sun, Mar 10, 2019 at 7:47 PM John Naylor wrote:
>
> On Fri, Mar 8, 2019 at 7:43 PM Amit Kapila wrote:
>
> > Have you done any performance testing of this patch? I mean to say
> > now that we added a new stat call for each table, we should see if
> > that has any impact. Ideally, that should
On Thu, Mar 7, 2019 at 7:13 PM Amit Kapila wrote:
>
> On Sat, Feb 23, 2019 at 1:24 PM John Naylor
> wrote:
> >
> > On Thu, Feb 21, 2019 at 9:27 PM Alvaro Herrera
> > wrote:
> > >
> > > I think this test is going to break on nonstandard block sizes. While
> > > we don't promise that all tests
On Fri, Mar 8, 2019 at 7:43 PM Amit Kapila wrote:
> Few minor comments:
> 1.
> warning C4715: 'new_cluster_needs_fsm': not all control paths return a value
>
> Getting this new warning in the patch.
Hmm, I don't get that in a couple versions of gcc. Your compiler must
not know that pg_fatal() can
On Fri, Mar 8, 2019 at 5:13 PM Amit Kapila wrote:
>
>
> Few minor comments:
..
>
> 2.
> +
> + /* Transfer any VM files if we can trust their
> contents. */
> if (vm_crashsafe_match)
>
> 3. Can we add a note about this in the Notes section of pg_upgrade
> documentation [1]?
>
> This comment line
On Wed, Mar 6, 2019 at 5:19 PM John Naylor wrote:
>
> On Fri, Jan 25, 2019 at 9:50 AM Amit Kapila wrote:
> > Once we agree on the code, we need to test below scenarios:
> > (a) upgrade from all supported versions to the latest version
> > (b) upgrade standby with and without using rsync.
>
> Alth
On Mon, Jan 28, 2019 at 2:33 AM John Naylor wrote:
>
> On Sat, Jan 26, 2019 at 2:14 PM Amit Kapila wrote:
> >
> > I think there is some value in using the information from
> > this function to skip fsm files, but the code doesn't appear to fit
> > well, how about moving this check to new function
On Sat, Feb 23, 2019 at 1:24 PM John Naylor wrote:
>
> On Thu, Feb 21, 2019 at 9:27 PM Alvaro Herrera
> wrote:
> >
> > I think this test is going to break on nonstandard block sizes. While
> > we don't promise that all tests work on such installs (particularly
> > planner ones), it seems fairly
On Fri, Jan 25, 2019 at 9:50 AM Amit Kapila wrote:
> Once we agree on the code, we need to test below scenarios:
> (a) upgrade from all supported versions to the latest version
> (b) upgrade standby with and without using rsync.
Although the code hasn't been reviewed yet, I went ahead and tested
On 26/02/2019 16:20, Alvaro Herrera wrote:
> On 2019-Feb-23, John Naylor wrote:
>
>> On Fri, Feb 22, 2019 at 3:59 AM Amit Kapila wrote:
>>> The reason for not pushing much on making the test pass for
>>> nonstandard block sizes is that when I tried existing tests, there
>>> were already some fail
On 2019-Feb-23, John Naylor wrote:
> On Fri, Feb 22, 2019 at 3:59 AM Amit Kapila wrote:
> > The reason for not pushing much on making the test pass for
> > nonstandard block sizes is that when I tried existing tests, there
> > were already some failures.
>
> FWIW, I currently see 8 failures (att
On Fri, Feb 22, 2019 at 3:59 AM Amit Kapila wrote:
> The reason for not pushing much on making the test pass for
> nonstandard block sizes is that when I tried existing tests, there
> were already some failures.
FWIW, I currently see 8 failures (attached).
--
John Naylorhttps://
On Thu, Feb 21, 2019 at 9:27 PM Alvaro Herrera wrote:
>
> I think this test is going to break on nonstandard block sizes. While
> we don't promise that all tests work on such installs (particularly
> planner ones), it seems fairly easy to cope with this one -- just use a
> record size expressed a
On 2019-Feb-22, Peter Geoghegan wrote:
> I find it suspicious that there is another crash in pageinspect's
> brin_page_items(), since like amcheck, pageinspect is a contrib module
> that relies on BLCKSZ when allocating a local temp buffer.
Ah. Maybe they just weren't rebuilt.
--
Álvaro Herrer
On Fri, Feb 22, 2019 at 8:04 AM Alvaro Herrera wrote:
> Wow, there's a lot less tests failing there than I thought there would
> be. That increases hope that we can someday have them pass. +1 on not
> making things worse.
>
> I think the crash in the amcheck test should be studied, one way or
>
On 2019-Feb-22, Amit Kapila wrote:
> On Fri, Feb 22, 2019 at 1:57 AM Alvaro Herrera
> wrote:
> >
> > I think this test is going to break on nonstandard block sizes. While
> > we don't promise that all tests work on such installs (particularly
> > planner ones),
>
> The reason for not pushing m
On Thu, Feb 21, 2019 at 9:59 PM Amit Kapila wrote:
> The reason for not pushing much on making the test pass for
> nonstandard block sizes is that when I tried existing tests, there
> were already some failures.
Sure, but let's not make things worse.
--
Robert Haas
EnterpriseDB: http://www.ente
On Fri, Feb 22, 2019 at 1:57 AM Alvaro Herrera wrote:
>
> I think this test is going to break on nonstandard block sizes. While
> we don't promise that all tests work on such installs (particularly
> planner ones),
>
The reason for not pushing much on making the test pass for
nonstandard block s
I think this test is going to break on nonstandard block sizes. While
we don't promise that all tests work on such installs (particularly
planner ones), it seems fairly easy to cope with this one -- just use a
record size expressed as a fraction of current_setting('block_size').
So instead of "102
On Thu, Feb 21, 2019 at 6:39 PM Alvaro Herrera wrote:
>
> On 2019-Feb-21, Amit Kapila wrote:
>
> > On Wed, Feb 20, 2019 at 8:08 PM Alvaro Herrera
> > wrote:
> > >
> > > Please remember to keep serial_schedule in sync.
> >
> > I don't understand what you mean by this? It is already present in
>
On 2019-Feb-21, Amit Kapila wrote:
> On Wed, Feb 20, 2019 at 8:08 PM Alvaro Herrera
> wrote:
> >
> > Please remember to keep serial_schedule in sync.
>
> I don't understand what you mean by this? It is already present in
> serial_schedule. In parallel_schedule, we are just moving this test
>
On Thu, Feb 21, 2019 at 7:58 AM Amit Kapila wrote:
> So here you are inserting 4-byte integer and 1024-bytes variable
> length record. So the tuple length will be tuple_header (24-bytes) +
> 4-bytes for integer + 4-bytes header for variable length data + 1024
> bytes of actual data. So, the leng
On Mon, Feb 11, 2019 at 10:48 PM John Naylor
wrote:
>
> On 2/9/19, Amit Kapila wrote:
> > On Tue, Feb 5, 2019 at 3:25 PM John Naylor
> > wrote:
> >>
> >> On Tue, Feb 5, 2019 at 4:04 AM Amit Kapila
> >> wrote:
> > This is certainly a good test w.r.t code coverage of new code, but I
> > have few
On Wed, Feb 20, 2019 at 8:08 PM Alvaro Herrera wrote:
>
> Please remember to keep serial_schedule in sync.
>
I don't understand what you mean by this? It is already present in
serial_schedule. In parallel_schedule, we are just moving this test
to one of the parallel groups. Do we need to take
Please remember to keep serial_schedule in sync.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, Feb 11, 2019 at 10:48 PM John Naylor
wrote:
>
> On 2/9/19, Amit Kapila wrote:
> > On Tue, Feb 5, 2019 at 3:25 PM John Naylor
> > wrote:
> >>
> >> On Tue, Feb 5, 2019 at 4:04 AM Amit Kapila
> >> wrote:
> > This is certainly a good test w.r.t code coverage of new code, but I
> > have few
On Wed, Feb 20, 2019 at 6:09 PM Amit Kapila wrote:
> I have modified the patch for the above observations and added a
> commit message as well, see if it looks okay to you.
Looks good to me, thanks.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On Mon, Feb 11, 2019 at 10:48 PM John Naylor
wrote:
>
> On 2/9/19, Amit Kapila wrote:
>
> > Shall we add a note to the docs of pg_freespacemap and
> > pgstattuple_approx indicating that for small relations, FSM won't be
> > created, so these functions won't give appropriate value?
>
> I've given
On 2/9/19, Amit Kapila wrote:
> On Tue, Feb 5, 2019 at 3:25 PM John Naylor
> wrote:
>>
>> On Tue, Feb 5, 2019 at 4:04 AM Amit Kapila
>> wrote:
> This is certainly a good test w.r.t code coverage of new code, but I
> have few comments:
> 1. The size of records in test still depends on alignment (
On Tue, Feb 5, 2019 at 3:25 PM John Naylor wrote:
>
> On Tue, Feb 5, 2019 at 4:04 AM Amit Kapila wrote:
> >
> > On Mon, Feb 4, 2019 at 2:27 PM John Naylor
> > wrote:
> > >
> > > 1. Earlier, I had a test to ensure that free space towards the front
> > > of the relation was visible with no FSM. I
On Tue, Feb 5, 2019 at 4:04 AM Amit Kapila wrote:
>
> On Mon, Feb 4, 2019 at 2:27 PM John Naylor
> wrote:
> >
> > 1. Earlier, I had a test to ensure that free space towards the front
> > of the relation was visible with no FSM. In [1], I rewrote it without
> > using vacuum, so we can consider ad
On Mon, Feb 4, 2019 at 2:27 PM John Naylor
wrote:
>
> On Mon, Feb 4, 2019 at 8:41 AM Amit Kapila
wrote:
> >
> > The change seems to have worked. All the buildfarm machines that were
> > showing the failure are passed now.
>
> Excellent!
>
> Now that the buildfarm is green as far as this patch go
On Mon, Feb 4, 2019 at 8:41 AM Amit Kapila wrote:
> > Yeah that can also work, but we still need to be careful about the
> > alignment of that one tuple, otherwise, there will could be different
> > free space on the fifth page. The probably easier way could be to use
> > an even number of intege
On Mon, Feb 4, 2019 at 10:29 AM Amit Kapila wrote:
>
> On Mon, Feb 4, 2019 at 10:18 AM John Naylor
> wrote:
> >
> > On Mon, Feb 4, 2019 at 4:17 AM Amit Kapila wrote:
> > > This one seems to be FSM test portability issue (due to different page
> > > contents, maybe). Looking into it, John, see
On Mon, Feb 4, 2019 at 10:18 AM John Naylor wrote:
>
> On Mon, Feb 4, 2019 at 4:17 AM Amit Kapila wrote:
> > This one seems to be FSM test portability issue (due to different page
> > contents, maybe). Looking into it, John, see if you are around and
> > have some thoughts on it.
>
> Maybe we ca
On Mon, Feb 4, 2019 at 4:17 AM Amit Kapila wrote:
> This one seems to be FSM test portability issue (due to different page
> contents, maybe). Looking into it, John, see if you are around and
> have some thoughts on it.
Maybe we can use the same plpgsql loop as fsm.sql that exits after 1
tuple h
On Mon, Feb 4, 2019 at 9:24 AM Amit Kapila wrote:
> On Mon, Feb 4, 2019 at 8:47 AM Amit Kapila wrote:
>
> One more similar failure:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2019-02-04%2003%3A20%3A01
>
> So, basically, this is due to difference in the number of tuples t
On Mon, Feb 4, 2019 at 8:47 AM Amit Kapila wrote:
>
> On Mon, Feb 4, 2019 at 12:39 AM John Naylor
> wrote:
> >
> > On Sun, Feb 3, 2019 at 2:06 PM Amit Kapila wrote:
> > >
> > > On Thu, Jan 31, 2019 at 6:03 PM Amit Kapila
> > > wrote:
> > > This doesn't get applied cleanly after recent commit
On Mon, Feb 4, 2019 at 12:39 AM John Naylor wrote:
>
> On Sun, Feb 3, 2019 at 2:06 PM Amit Kapila wrote:
> >
> > On Thu, Jan 31, 2019 at 6:03 PM Amit Kapila wrote:
> > This doesn't get applied cleanly after recent commit 0d1fe9f74e.
> > Attached is a rebased version. I have checked once that th
On Sun, Feb 3, 2019 at 2:06 PM Amit Kapila wrote:
>
> On Thu, Jan 31, 2019 at 6:03 PM Amit Kapila wrote:
> This doesn't get applied cleanly after recent commit 0d1fe9f74e.
> Attached is a rebased version. I have checked once that the changes
> done by 0d1fe9f74e don't impact this patch. John, s
On Thu, Jan 31, 2019 at 6:03 PM Amit Kapila wrote:
> On Thu, Jan 31, 2019 at 2:02 PM John Naylor
> wrote:
> >
> >
> > FYI, the second comment is still present in v20.
> >
>
> oops, forgot to include in commit after making a change, done now.
>
This doesn't get applied cleanly after recent commi
On Sat, Feb 2, 2019 at 7:30 AM Amit Kapila wrote:
>
> On Mon, Jan 28, 2019 at 4:40 PM Amit Kapila wrote:
> >
> > On Mon, Jan 28, 2019 at 10:03 AM John Naylor
> > wrote:
>
> In the past few days, we have done a further analysis of each problem
> and tried to reproduce it. We are successful in ge
On Mon, Jan 28, 2019 at 4:40 PM Amit Kapila wrote:
>
> On Mon, Jan 28, 2019 at 10:03 AM John Naylor
> wrote:
> >
> > On Mon, Jan 28, 2019 at 4:53 AM Amit Kapila wrote:
> > > There are a few buildfarm failures due to this commit, see my email on
> > > pgsql-committers. If you have time, you can
On Thu, Jan 31, 2019 at 9:18 PM John Naylor wrote:
>
> On Thu, Jan 31, 2019 at 4:06 PM Amit Kapila wrote:
> > I don't think that moving fsm tests to brin would be a good approach.
> > We want to have a separate test for each access method. I think if we
> > want to do something to avoid portabil
On Thu, Jan 31, 2019 at 4:06 PM Amit Kapila wrote:
> I don't think that moving fsm tests to brin would be a good approach.
> We want to have a separate test for each access method. I think if we
> want to do something to avoid portability issues, maybe we can do what
> Masahiko San has just sugge
On Thu, Jan 31, 2019 at 7:23 PM John Naylor wrote:
>
> On Thu, Jan 31, 2019 at 1:52 PM John Naylor
> wrote:
> >
> > On Thu, Jan 31, 2019 at 1:43 PM Amit Kapila wrote:
> > > > I have an idea -- instead of adding a bunch of records and hoping that
> > > > the relation size and free space is consi
On Thu, Jan 31, 2019 at 6:41 AM Amit Kapila wrote:
>
> On Wed, Jan 30, 2019 at 10:41 PM Masahiko Sawada
> wrote:
> >
> > On Wed, Jan 30, 2019 at 4:33 AM Amit Kapila wrote:
> > >
> > > On Tue, Jan 29, 2019 at 8:12 PM John Naylor
> > > wrote:
> > > >
> > > > On Tue, Jan 29, 2019 at 11:56 AM Ami
On Thu, Jan 31, 2019 at 1:52 PM John Naylor wrote:
>
> On Thu, Jan 31, 2019 at 1:43 PM Amit Kapila wrote:
> > > I have an idea -- instead of adding a bunch of records and hoping that
> > > the relation size and free space is consistent across platforms, how
> > > about we revert to the original t
On Thu, Jan 31, 2019 at 1:43 PM Amit Kapila wrote:
> > I have an idea -- instead of adding a bunch of records and hoping that
> > the relation size and free space is consistent across platforms, how
> > about we revert to the original test input, and add a BRIN index? That
> > should have a FSM ev
On Thu, Jan 31, 2019 at 2:12 PM John Naylor wrote:
>
> On Thu, Jan 31, 2019 at 6:41 AM Amit Kapila wrote:
> >
> > On Wed, Jan 30, 2019 at 10:41 PM Masahiko Sawada
> > wrote:
> > >
> > > The modified page.sql test could fail if the block size is more than
> > > 8kB?
> >
> > That's right, but I d
On Thu, Jan 31, 2019 at 2:02 PM John Naylor wrote:
>
> On Thu, Jan 31, 2019 at 6:37 AM Amit Kapila wrote:
> >
> > On Wed, Jan 30, 2019 at 8:11 PM John Naylor
> > wrote:
> > >
> > > That's probably a good idea to limit risk. I just very basic tests
> > > now, and vacuum before every relation siz
On Thu, Jan 31, 2019 at 6:41 AM Amit Kapila wrote:
>
> On Wed, Jan 30, 2019 at 10:41 PM Masahiko Sawada
> wrote:
> >
> > The modified page.sql test could fail if the block size is more than
> > 8kB?
>
> That's right, but I don't think current regression tests will work for
> block size greater t
On Thu, Jan 31, 2019 at 6:37 AM Amit Kapila wrote:
>
> On Wed, Jan 30, 2019 at 8:11 PM John Naylor
> wrote:
> >
> > That's probably a good idea to limit risk. I just very basic tests
> > now, and vacuum before every relation size check to make sure any FSM
> > extension (whether desired or not)
On Wed, Jan 30, 2019 at 10:41 PM Masahiko Sawada wrote:
>
> On Wed, Jan 30, 2019 at 4:33 AM Amit Kapila wrote:
> >
> > On Tue, Jan 29, 2019 at 8:12 PM John Naylor
> > wrote:
> > >
> > > On Tue, Jan 29, 2019 at 11:56 AM Amit Kapila
> > > wrote:
> > >
> > > > You can find this change in attache
On Wed, Jan 30, 2019 at 8:11 PM John Naylor wrote:
>
> On Wed, Jan 30, 2019 at 2:11 PM Amit Kapila wrote:
> > This is much better than the earlier version of test and there is no
> > dependency on the vacuum. However, I feel still there is some
> > dependency on how the rows will fit in a page a
On Wed, Jan 30, 2019 at 4:33 AM Amit Kapila wrote:
>
> On Tue, Jan 29, 2019 at 8:12 PM John Naylor
> wrote:
> >
> > On Tue, Jan 29, 2019 at 11:56 AM Amit Kapila
> > wrote:
> >
> > > You can find this change in attached patch. Then, I ran the make
> > > check in src/bin/pgbench multiple times
On Wed, Jan 30, 2019 at 2:11 PM Amit Kapila wrote:
> This is much better than the earlier version of test and there is no
> dependency on the vacuum. However, I feel still there is some
> dependency on how the rows will fit in a page and we have seen some
> related failures due to alignment stuff
On Wed, Jan 30, 2019 at 3:26 PM John Naylor wrote:
>
> On Wed, Jan 30, 2019 at 4:33 AM Amit Kapila wrote:
> > There are two more failures which we need to something about.
> > 1. Make fsm.sql independent of vacuum without much losing on coverage
> > of newly added code. John, I guess you have an
On Wed, Jan 30, 2019 at 4:33 AM Amit Kapila wrote:
> There are two more failures which we need to something about.
> 1. Make fsm.sql independent of vacuum without much losing on coverage
> of newly added code. John, I guess you have an idea, see if you can
> take care of it, otherwise, I will see
On Tue, Jan 29, 2019 at 8:12 PM John Naylor wrote:
>
> On Tue, Jan 29, 2019 at 11:56 AM Amit Kapila wrote:
>
> > You can find this change in attached patch. Then, I ran the make
> > check in src/bin/pgbench multiple times using test_conc_insert.sh.
> > You can vary the number of times the test s
On Tue, Jan 29, 2019 at 11:56 AM Amit Kapila wrote:
> You can find this change in attached patch. Then, I ran the make
> check in src/bin/pgbench multiple times using test_conc_insert.sh.
> You can vary the number of times the test should run, if you are not
> able to reproduce it with this.
>
>
On Tue, Jan 29, 2019 at 5:20 PM Masahiko Sawada wrote:
>
> On Tue, Jan 29, 2019 at 9:29 AM Amit Kapila wrote:
> >
>
> I'd suspect the alignment of integer. In my environemnt, the tuple
> actual size is 28 bytes but the aligned size is 32 bytes (=
> MAXALIGN(28)), so we can store 226 tuples to sin
On Tue, Jan 29, 2019 at 9:29 AM Amit Kapila wrote:
>
> On Tue, Jan 29, 2019 at 12:37 AM John Naylor
> wrote:
> >
> > On Mon, Jan 28, 2019 at 12:10 PM Amit Kapila
> > wrote:
> >
> > > 2.
> > > @@ -15,13 +15,9 @@
> > > SELECT octet_length(get_raw_page('test_rel_forks', 'main', 100)) AS
> > > ma
On Tue, Jan 29, 2019 at 5:59 AM Amit Kapila wrote:
>
> On Tue, Jan 29, 2019 at 12:37 AM John Naylor
> wrote:
> > > I think here you need to clear the map if it exists or clear it
> > > unconditionally, the earlier one would be better.
> >
> > Ok, maybe all callers should call it unconditonally, b
On Tue, Jan 29, 2019 at 12:37 AM John Naylor
wrote:
>
> On Mon, Jan 28, 2019 at 12:10 PM Amit Kapila wrote:
>
> > 2.
> > @@ -15,13 +15,9 @@
> > SELECT octet_length(get_raw_page('test_rel_forks', 'main', 100)) AS
> > main_100;
> > ERROR: block number 100 is out of range for relation "test_rel_
On Mon, Jan 28, 2019 at 12:10 PM Amit Kapila wrote:
>
> On Mon, Jan 28, 2019 at 10:03 AM John Naylor
> wrote:
> >
> 1.
> @@ -26,7 +26,7 @@
> pg_relation_size('fsm_check_size', 'fsm') AS fsm_size;
> heap_size | fsm_size
> ---+--
> - 24576 |0
> + 32768 |0
> "Amit" == Amit Kapila writes:
Amit> All of these seems to run with fsync=off. Is it possible that
Amit> vacuum has updated FSM, but the same is not synced to disk and
Amit> when we try to read it, we didn't get the required page?
No.
fsync never affects what programs see while the syst
On Mon, Jan 28, 2019 at 4:40 PM Amit Kapila wrote:
>
> On Mon, Jan 28, 2019 at 10:03 AM John Naylor
> wrote:
> >
> > On Mon, Jan 28, 2019 at 4:53 AM Amit Kapila
wrote:
> > > There are a few buildfarm failures due to this commit, see my email on
> > > pgsql-committers. If you have time, you can
On Mon, Jan 28, 2019 at 10:03 AM John Naylor
wrote:
>
> On Mon, Jan 28, 2019 at 4:53 AM Amit Kapila wrote:
> > There are a few buildfarm failures due to this commit, see my email on
> > pgsql-committers. If you have time, you can also once look into
> > those.
>
> I didn't see anything in common
On Mon, Jan 28, 2019 at 10:03 AM John Naylor
wrote:
>
> On Mon, Jan 28, 2019 at 4:53 AM Amit Kapila wrote:
> > There are a few buildfarm failures due to this commit, see my email on
> > pgsql-committers. If you have time, you can also once look into
> > those.
>
> I didn't see anything in common
On Mon, Jan 28, 2019 at 4:53 AM Amit Kapila wrote:
> There are a few buildfarm failures due to this commit, see my email on
> pgsql-committers. If you have time, you can also once look into
> those.
I didn't see anything in common with the configs of the failed
members. None have a non-default B
On Mon, Jan 28, 2019 at 9:16 AM John Naylor wrote:
>
> On Mon, Jan 28, 2019 at 3:53 AM Amit Kapila wrote:
> > On Thu, Jan 24, 2019 at 9:14 AM Amit Kapila wrote:
> > > Sure, apart from this I have run pgindent on the patches and make some
> > > changes accordingly. Latest patches attached (only
On Mon, Jan 28, 2019 at 3:53 AM Amit Kapila wrote:
> On Thu, Jan 24, 2019 at 9:14 AM Amit Kapila wrote:
> > Sure, apart from this I have run pgindent on the patches and make some
> > changes accordingly. Latest patches attached (only second patch has
> > some changes). I will take one more pass
On Thu, Jan 24, 2019 at 9:14 AM Amit Kapila wrote:
>
> Sure, apart from this I have run pgindent on the patches and make some
> changes accordingly. Latest patches attached (only second patch has
> some changes). I will take one more pass on Monday morning (28th Jan)
> and will commit unless you
On Sat, Jan 26, 2019 at 2:14 PM Amit Kapila wrote:
>
> On Sat, Jan 26, 2019 at 5:05 AM John Naylor
> wrote:
> >
> > So, in v19 we check pg_class.relpages and if it's
> > a heap and less than or equal the threshold we call stat on the 0th
> > segment to verify.
> >
>
> Okay, but the way logic is
On Sat, Jan 26, 2019 at 5:05 AM John Naylor wrote:
>
> On Thu, Jan 24, 2019 at 5:19 AM Amit Kapila wrote:
> >
> Performance testing is probably a good idea anyway, but I went ahead
> and implemented your next idea:
>
> > The other alternative is we can fetch pg_class.relpages and rely on
> > that
On Thu, Jan 24, 2019 at 9:50 PM Amit Kapila wrote:
>
> On Fri, Jan 25, 2019 at 1:03 AM John Naylor
> wrote:
> >
> > On Wed, Jan 23, 2019 at 11:17 PM Amit Kapila
> > wrote:
> > > I think what doc means to say is
> > > that it copies any unlinked files present in primary's new cluster
> > > (whi
On Thu, Jan 24, 2019 at 5:19 AM Amit Kapila wrote:
>
> 1.
> + if ((maps[mapnum].relkind != RELKIND_RELATION &&
> + maps[mapnum].relkind != RELKIND_TOASTVALUE) ||
> + first_seg_size > HEAP_FSM_CREATION_THRESHOLD * BLCKSZ ||
> + GET_MAJOR_VERSION(new_cluster.major_version) <= 1100)
> + (void) transf
On Fri, Jan 25, 2019 at 1:03 AM John Naylor wrote:
>
> On Wed, Jan 23, 2019 at 11:17 PM Amit Kapila wrote:
> > I think what doc means to say is
> > that it copies any unlinked files present in primary's new cluster
> > (which in your case will be data2).
>
> In that case, I'm still confused why t
On Wed, Jan 23, 2019 at 11:17 PM Amit Kapila wrote:
>
> On Thu, Jan 24, 2019 at 3:39 AM John Naylor
> wrote:
> > mkdir -p data1 data2 standby
> >
> > echo 'heap' > data1/foo
> > echo 'fsm' > data1/foo_fsm
> >
> > # simulate streaming replication
> > rsync --archive data1 standby
> >
> > # simula
On Thu, Jan 24, 2019 at 9:46 AM Amit Kapila wrote:
>
> On Thu, Jan 24, 2019 at 3:39 AM John Naylor
> wrote:
> >
Few comments related to pg_upgrade patch:
1.
+ if ((maps[mapnum].relkind != RELKIND_RELATION &&
+ maps[mapnum].relkind != RELKIND_TOASTVALUE) ||
+ first_seg_size > HEAP_FSM_CREATION_
On Thu, Jan 24, 2019 at 3:39 AM John Naylor wrote:
>
> On Mon, Jan 21, 2019 at 6:32 AM Amit Kapila wrote:
> > Also, another case to think in this regard is the upgrade for standby
> > servers, if you read below paragraph from the user manual [1], you
> > will see what I am worried about?
> >
> >
On Wed, Jan 23, 2019 at 9:18 PM John Naylor wrote:
>
> On Wed, Jan 23, 2019 at 7:09 AM Amit Kapila wrote:
> > I think the first two patches (a) removal of dead code in bootstrap
> > and (b) the core patch to avoid creation of FSM file for the small
> > table are good now. I have prepared the pat
On Mon, Jan 21, 2019 at 6:32 AM Amit Kapila wrote:
> Also, another case to think in this regard is the upgrade for standby
> servers, if you read below paragraph from the user manual [1], you
> will see what I am worried about?
>
> "What this does is to record the links created by pg_upgrade's lin
On Wed, Jan 23, 2019 at 7:09 AM Amit Kapila wrote:
> I think the first two patches (a) removal of dead code in bootstrap
> and (b) the core patch to avoid creation of FSM file for the small
> table are good now. I have prepared the patches along with commit
> message. There is no change except f
On Sun, Jan 20, 2019 at 5:19 AM John Naylor wrote:
>
> I have a test for in-range and out-of-range for each relation fork.
>
I think the first two patches (a) removal of dead code in bootstrap
and (b) the core patch to avoid creation of FSM file for the small
table are good now. I have prepared
On Mon, Jan 21, 2019 at 6:32 AM Amit Kapila wrote:
> So we won't allow transfer of FSM files if their size is below
> HEAP_FSM_CREATION_THRESHOLD. What will be its behavior in link mode?
> It seems that the old files will remain there. Will it create any
> problem when we try to create the files
On Sun, Jan 20, 2019 at 5:19 AM John Naylor wrote:
>
Review of v16-0002-During-pg_upgrade-conditionally-skip-transfer-of:
- * Copy/link any fsm and vm files, if they exist
+ *
Copy/link any fsm and vm files, if they exist and if they would
+ * be created in the
new cluster.
*/
- transfer_relfi
On Sat, Jan 19, 2019 at 8:06 AM Amit Kapila wrote:
>
> On Thu, Jan 17, 2019 at 11:13 PM John Naylor
> Few more comments:
> 1.
> I think we should not allow to create FSM for toast tables as well
> till there size reaches HEAP_FSM_CREATION_THRESHOLD. If you try below
> test, you can see that FSM w
1 - 100 of 178 matches
Mail list logo
