Re: [HACKERS] Patches I'm thinking of pushing shortly

On Sat, Aug 12, 2017 at 3:24 AM, Tom Lane wrote: > I have some patches sitting around in my workspace that I think are > non-controversial, and so I was considering just pushing them once > the tree opens for v11 development. If anyone thinks they need > further review, I'll

Re: [HACKERS] POC: Sharing record typmods between backends

Robert Haas writes: > On Sat, Aug 12, 2017 at 11:30 PM, Andres Freund wrote: >> That seems to involve a lot more than this though, given that currently >> the stats collector data doesn't entirely have to be in memory. I've >> seen sites with a lot of

Re: [HACKERS] POC: Sharing record typmods between backends

On Sat, Aug 12, 2017 at 11:30 PM, Andres Freund wrote: > That seems to involve a lot more than this though, given that currently > the stats collector data doesn't entirely have to be in memory. I've > seen sites with a lot of databases with quite some per-database stats >

Re: [HACKERS] POC: Sharing record typmods between backends

On 2017-08-12 22:52:57 -0400, Robert Haas wrote: > On Fri, Aug 11, 2017 at 9:55 PM, Andres Freund wrote: > > Well, most of the potential usecases for dsmhash I've heard about so > > far, don't actually benefit much from incremental growth. In nearly all > > the implementations

Re: [HACKERS] Comment in snapbuild.c file

Alvaro Herrera wrote: > Masahiko Sawada wrote: > > Hi all, > > > > In snapbuild.c file, there is a comment as follows. > > > >* NB: Because of that xmax can be lower than xmin, because we only > >* increase xmax when a catalog modifying transaction commits. While odd > >* looking,

Re: [HACKERS] POC: Sharing record typmods between backends

On Fri, Aug 11, 2017 at 9:55 PM, Andres Freund wrote: > Well, most of the potential usecases for dsmhash I've heard about so > far, don't actually benefit much from incremental growth. In nearly all > the implementations I've seen incremental move ends up requiring more >

Re: [HACKERS] More race conditions in logical replication

On Sun, Aug 13, 2017 at 10:25 AM, Noah Misch wrote: > Committed. These counts broke three times in the v10 release cycle. It's too > bad this defect doesn't cause an error when building the docs. That's another argument for generating the table dynamically. Thanks for the

Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests

On Sun, Aug 13, 2017 at 1:09 AM, Tom Lane wrote: > Michael Paquier writes: >> On Wed, Aug 9, 2017 at 3:39 PM, Tom Lane wrote: >>> Michael Paquier writes: Let's do that please. Merging both was my

Re: [HACKERS] More race conditions in logical replication

On Sat, Aug 12, 2017 at 05:38:29PM +0900, Michael Paquier wrote: > On Thu, Aug 10, 2017 at 4:22 PM, Michael Paquier > wrote: > > On Tue, Aug 8, 2017 at 8:11 PM, Alvaro Herrera > > wrote: > >> Here's a patch. It turned to be a bit larger than

Re: [HACKERS] POC: Sharing record typmods between backends

Thanks for your feedback. Here are two parts that jumped out at me. I'll address the other parts in a separate email. On Sat, Aug 12, 2017 at 1:55 PM, Andres Freund wrote: >> This is complicated, and in the category that I would normally want a >> stack of heavy unit tests

Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests

Michael Paquier writes: > On Wed, Aug 9, 2017 at 3:39 PM, Tom Lane wrote: >> Michael Paquier writes: >>> Let's do that please. Merging both was my first feeling when >>> refactoring this test upthread. Should I send a

Re: [HACKERS] pg_stat_statements query normalization, and the 'in' operator

unixway.dr...@gmail.com writes: > Given the following list of queries: >create table foo (id serial, bar integer); >select * from foo where id in (1); >select * from foo where id in (2,3); >select * from foo where id in (1,3,5); >select * from foo where id in (select id from

Re: [HACKERS] why not parallel seq scan for slow functions

On Thu, Aug 10, 2017 at 1:07 AM, Robert Haas wrote: > On Tue, Aug 8, 2017 at 3:50 AM, Amit Kapila wrote: >> Right. >> >> I see two ways to include the cost of the target list for parallel >> paths before rejecting them (a) Don't reject parallel

[HACKERS] Regressions failures with libxml2 on ArchLinux

Hi all, It's been one month since I have done some serious development with Archlinux (I was abroad and away from the laptop dedicated to that), and surprise, I can see failures in the PG regression tests, like the following short extract (result compared to expected/xml.out): SELECT

[HACKERS] Re: [COMMITTERS] pgsql: Don't force-assign transaction id when exporting a snapshot.

On 14/06/17 20:57, Andres Freund wrote: > Don't force-assign transaction id when exporting a snapshot. > > Previously we required every exported transaction to have an xid > assigned. That was used to check that the exporting transaction is > still running, which in turn is needed to guarantee

Re: [HACKERS] More race conditions in logical replication

On Thu, Aug 10, 2017 at 4:22 PM, Michael Paquier wrote: > On Tue, Aug 8, 2017 at 8:11 PM, Alvaro Herrera > wrote: >> Here's a patch. It turned to be a bit larger than I initially expected. > > Álvaro, 030273b7 did not get things completely