Thread

Commits

  1. Remove duplicate code in brin_memtuple_initialize

  1. Yet another (minor) fix in BRIN

    Tomas Vondra <tomas.vondra@enterprisedb.com> — 2020-11-08T01:23:14Z

    Hi,
    
    While rebasing some of the BRIN patches, I noticed some of the code in
    brin_memtuple_initialize is duplicated. This happened in 8bf74967dab
    which moved some of the code from brin_new_memtuple, not removing the
    shared pieces. In practice this is benign, of course.
    
    Barring objections I'll get the attached fix committed and backpatched.
    
    
    regards
    
    -- 
    Tomas Vondra
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
    
  2. Re: Yet another (minor) fix in BRIN

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2020-11-08T01:51:37Z

    On 2020-Nov-08, Tomas Vondra wrote:
    
    > While rebasing some of the BRIN patches, I noticed some of the code in
    > brin_memtuple_initialize is duplicated. This happened in 8bf74967dab
    > which moved some of the code from brin_new_memtuple, not removing the
    > shared pieces. In practice this is benign, of course.
    > 
    > Barring objections I'll get the attached fix committed and backpatched.
    
    LGTM, thanks for noticing.
    
    
    
    
    
  3. Re: Yet another (minor) fix in BRIN

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-11-08T03:45:26Z

    Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
    > On 2020-Nov-08, Tomas Vondra wrote:
    >> While rebasing some of the BRIN patches, I noticed some of the code in
    >> brin_memtuple_initialize is duplicated. This happened in 8bf74967dab
    >> which moved some of the code from brin_new_memtuple, not removing the
    >> shared pieces. In practice this is benign, of course.
    >> 
    >> Barring objections I'll get the attached fix committed and backpatched.
    
    > LGTM, thanks for noticing.
    
    The weekend before stable-branch releases is probably not the best
    time to be pushing "minor" fixes into those branches.  I got my
    fingers burned today, and so did Peter.  Don't follow our example ;-)
    
    			regards, tom lane
    
    
    
    
  4. Re: Yet another (minor) fix in BRIN

    Michael Paquier <michael@paquier.xyz> — 2020-11-08T11:34:55Z

    On Sat, Nov 07, 2020 at 10:45:26PM -0500, Tom Lane wrote:
    > The weekend before stable-branch releases is probably not the best
    > time to be pushing "minor" fixes into those branches.  I got my
    > fingers burned today, and so did Peter.  Don't follow our example ;-)
    
    You could just apply your stuff after the version is tagged (not
    stamped as there could be urgent bug fixes between the stamp time and
    the tag time, like packaing issues).
    --
    Michael
    
  5. Re: Yet another (minor) fix in BRIN

    Tomas Vondra <tomas.vondra@enterprisedb.com> — 2020-11-08T15:47:17Z

    On 11/8/20 12:34 PM, Michael Paquier wrote:
    > On Sat, Nov 07, 2020 at 10:45:26PM -0500, Tom Lane wrote:
    >> The weekend before stable-branch releases is probably not the best
    >> time to be pushing "minor" fixes into those branches.  I got my
    >> fingers burned today, and so did Peter.  Don't follow our example ;-)
    > 
    > You could just apply your stuff after the version is tagged (not
    > stamped as there could be urgent bug fixes between the stamp time and
    > the tag time, like packaing issues).
    
    Yeah, that's what I was planning to do - I was not suggesting I'll push
    this right away. Or at least I did not mean to. Sorry if that was not
    quite clear.
    
    
    regards
    
    -- 
    Tomas Vondra
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company