Re: Fix pg_buffercache document

On Fri, 8 May 2020 at 13:36, Amit Kapila wrote: > > On Thu, May 7, 2020 at 4:02 PM Amit Kapila wrote: > > > > On Thu, May 7, 2020 at 2:53 PM Masahiko Sawada > > wrote: > > > > > > > > > > > There is a typo in the patch (queris/queries). How about if slightly > > > > reword it as "Since buffer

Re: Back-patch is necessary? Re: Don't try fetching future segment of a TLI.

On 2020/05/07 17:57, Amit Kapila wrote: On Thu, May 7, 2020 at 12:13 PM Fujii Masao wrote: On 2020/05/02 20:40, Amit Kapila wrote: I don't see any obvious problem with the changed code but we normally don't backpatch performance improvements. I can see that the code change here appears

Re: Implementing Incremental View Maintenance

On Fri, May 8, 2020 at 9:13 AM Tatsuo Ishii wrote: > >> Hi, > >> > >> Attached is the latest patch (v15) to add support for Incremental > Materialized > >> View Maintenance (IVM). It is possible to apply to current latest > master branch. > > I have tried to use IVM against TPC-DS

Re: Logical replication subscription owner

On 2020-May-07, Tom Lane wrote: > FWIW, I would argue that LOGIN permits logging in on a regular SQL > connection, while REPLICATION should permit logging in on a > replication connection, and there's no reason for either to depend on > or require the other. I agree with this. > >> Also- what

Re: Fix pg_buffercache document

On Thu, May 7, 2020 at 4:02 PM Amit Kapila wrote: > > On Thu, May 7, 2020 at 2:53 PM Masahiko Sawada > wrote: > > > > > > > > There is a typo in the patch (queris/queries). How about if slightly > > > reword it as "Since buffer manager locks are not taken to copy the > > > buffer state data

Re: PG 13 release notes, first draft

On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote: > On Wed, May 6, 2020 at 10:20:57PM -0700, Noah Misch wrote: > > On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote: > > > On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote: > > > > On Mon, May 04, 2020 at

Re: Logical replication subscription owner

Alvaro Herrera writes: > I'd welcome input from other people on this issue; only now I noticed > that it's buried in pgsql-docs, so CCing pgsql-hackers now. FWIW, I would argue that LOGIN permits logging in on a regular SQL connection, while REPLICATION should permit logging in on a replication

Re: +(pg_lsn, int8) and -(pg_lsn, int8) operators

At Fri, 8 May 2020 11:31:42 +0900, Fujii Masao wrote in > >> You mean that pg_lsn_pli() and pg_lsn_mii() should emit an error like > >> "the number of bytes to add/subtract cannnot be NaN" when NaN is > >> specified? > > The function is called while executing an expression, so "NaN cannot > >

Re: PG 13 release notes, first draft

On Fri, May 8, 2020 at 2:06 AM Bruce Momjian wrote: > On Fri, May 8, 2020 at 12:32:16AM +0900, Amit Langote wrote: > > c8434d64c implements a new feature whereby, to use partitionwise join, > > partition bounds of the tables being joined no longer have to match > > exactly. I think it might be

Re: PG 13 release notes, first draft

On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote: > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html > > It still needs markup, word wrap, and indenting. The community doc > build should

Re: 2pc leaks fds

At Thu, 7 May 2020 19:28:55 -0400, Alvaro Herrera wrote in > On 2020-Apr-27, Kyotaro Horiguchi wrote: > > > At Fri, 24 Apr 2020 11:48:46 -0400, Alvaro Herrera > > wrote in > > > Sorry for the ambiguity, I didn't meant I minded that this conflicts > > with my patch or I don't want this to

Re: +(pg_lsn, int8) and -(pg_lsn, int8) operators

On 2020/05/08 10:00, Kyotaro Horiguchi wrote: At Thu, 7 May 2020 13:17:01 +0900, Fujii Masao wrote in On 2020/05/07 11:21, Kyotaro Horiguchi wrote: +static bool +numericvar_to_uint64(const NumericVar *var, uint64 *result) Other numricvar_to_xxx() functions return an integer value that

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Hi Ashutosh: Appreciate for your comments! On Thu, May 7, 2020 at 7:26 PM Ashutosh Bapat wrote: > Hi Andy, > Sorry for delay in review. I understand no one has obligation to do that, and it must take reviewer's time and more, so really appreciated for it! Hope I can provide more kindly

Re: Logical replication subscription owner

I'd welcome input from other people on this issue; only now I noticed that it's buried in pgsql-docs, so CCing pgsql-hackers now. On 2020-Apr-23, Stephen Frost wrote: > Greetings, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Alvaro Herrera writes: > > > I had it in my mind that LOGIN was

Re: Why are wait events not reported even though it reads/writes a timeline history file?

On 2020/05/07 21:24, Michael Paquier wrote: On Thu, May 07, 2020 at 04:51:16PM +0900, Fujii Masao wrote: Yeah, so I updated the patch so that ferror() is called only when fgets() returns NULL. Attached is the updated version of the patch. Thanks for the new patch. LGTM. Pushed. Thanks!

Re: Implementing Incremental View Maintenance

>> Hi, >> >> Attached is the latest patch (v15) to add support for Incremental >> Materialized >> View Maintenance (IVM). It is possible to apply to current latest master >> branch. I have tried to use IVM against TPC-DS (http://www.tpc.org/tpcds/) queries. TPC-DS models decision support

Re: +(pg_lsn, int8) and -(pg_lsn, int8) operators

At Thu, 7 May 2020 13:17:01 +0900, Fujii Masao wrote in > > > On 2020/05/07 11:21, Kyotaro Horiguchi wrote: > > +static bool > > +numericvar_to_uint64(const NumericVar *var, uint64 *result) > > Other numricvar_to_xxx() functions return an integer value that means > > success by 0 and failure

Improving estimates for TPC-H Q2

Hi, I've been re-running the TPC-H benchmark, to remind myself the common issues with OLAP workloads, and one of the most annoying problems seems to be the misestimates in Q2. The query is not particularly complex, although it does have a correlated subquery with an aggregate, but it's one of

Re: 2pc leaks fds

On 2020-Apr-27, Kyotaro Horiguchi wrote: > At Fri, 24 Apr 2020 11:48:46 -0400, Alvaro Herrera > wrote in > Sorry for the ambiguity, I didn't meant I minded that this conflicts > with my patch or I don't want this to be committed. It is easily > rebased on this patch. What I was anxious about

Re: Incremental sorts and EXEC_FLAG_REWIND

On 5/7/20 5:07 PM, Tomas Vondra wrote: > On Thu, May 07, 2020 at 03:58:47PM -0400, James Coleman wrote: >> On Thu, May 7, 2020 at 2:57 PM Jonathan S. Katz >> wrote: >>> >>> ... >>> >>> With Beta 1 just around the corner[1], I wanted to check in to see if >>> this was closer to being committed so

Re: pg_restore error message

Em qui., 7 de mai. de 2020 às 18:54, Euler Taveira < euler.tave...@2ndquadrant.com> escreveu: > Hi, > > While investigating a pg_restore error, I stumbled upon a message that is > not so useful. > > pg_restore: error: could not close data file: No such file or directory > > Which file? File name

pg_restore error message

Hi, While investigating a pg_restore error, I stumbled upon a message that is not so useful. pg_restore: error: could not close data file: No such file or directory Which file? File name should be printed too like in the error check for cfopen_read a few lines above. Regards, -- Euler

Re: [PATCH] fix GIN index search sometimes losing results

Pavel Borisov writes: > It appeared than GIN index sometimes lose results if simultaneously: > 1 if query operand contains weight marks > 2 if weight-marked operand is negated by ! operator > 3 if there are only logical (not phrase) operators from this negation > towards the root of query tree.

Re: Incremental sorts and EXEC_FLAG_REWIND

On Thu, May 07, 2020 at 03:58:47PM -0400, James Coleman wrote: On Thu, May 7, 2020 at 2:57 PM Jonathan S. Katz wrote: ... With Beta 1 just around the corner[1], I wanted to check in to see if this was closer to being committed so we could close off the open item[2] prior the beta release.

Re: Incremental sorts and EXEC_FLAG_REWIND

On Thu, May 7, 2020 at 2:57 PM Jonathan S. Katz wrote: > > On 4/24/20 6:57 PM, Tomas Vondra wrote: > > On Fri, Apr 24, 2020 at 04:35:02PM -0400, James Coleman wrote: > >> On Sun, Apr 19, 2020 at 12:14 PM James Coleman wrote: > >>> > >>> On Wed, Apr 15, 2020 at 2:04 PM James Coleman wrote: > >>>

Re: Incremental sorts and EXEC_FLAG_REWIND

On 4/24/20 6:57 PM, Tomas Vondra wrote: > On Fri, Apr 24, 2020 at 04:35:02PM -0400, James Coleman wrote: >> On Sun, Apr 19, 2020 at 12:14 PM James Coleman wrote: >>> >>> On Wed, Apr 15, 2020 at 2:04 PM James Coleman wrote: >>> > >>> > On Wed, Apr 15, 2020 at 11:02 AM James Coleman >>> wrote:

Re: PG 13 release notes, first draft

Hi Bruce, On Mon, May 4, 2020 at 8:16 PM Bruce Momjian wrote: > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html I see that you have an entry for the deduplication feature: "More efficiently store

Re: pg_basebackup misses to report checksum error

On Thu, May 7, 2020 at 10:25 AM Stephen Frost wrote: > Greetings, > > * Ashwin Agrawal (aagra...@pivotal.io) wrote: > > On Wed, May 6, 2020 at 3:02 PM Robert Haas > wrote: > > > On Wed, May 6, 2020 at 5:48 PM Ashwin Agrawal > wrote: > > > > If pg_basebackup is not able to read BLCKSZ content

Re: PG 13 release notes, first draft

On 05/07/20 09:46, Bruce Momjian wrote: > Ah, very good point. New text is: > > Allow Unicode escapes, e.g., E'\u', in databases that do not > use UTF-8 encoding (Tom Lane) > > The Unicode characters must be available in the database encoding. > ... > > I am only using

Re: pg_basebackup misses to report checksum error

Greetings, * Ashwin Agrawal (aagra...@pivotal.io) wrote: > On Wed, May 6, 2020 at 3:02 PM Robert Haas wrote: > > On Wed, May 6, 2020 at 5:48 PM Ashwin Agrawal wrote: > > > If pg_basebackup is not able to read BLCKSZ content from file, then it > > > just emits a warning "could not verify

Re: pg_basebackup misses to report checksum error

On Wed, May 6, 2020 at 3:02 PM Robert Haas wrote: > On Wed, May 6, 2020 at 5:48 PM Ashwin Agrawal wrote: > > If pg_basebackup is not able to read BLCKSZ content from file, then it > > just emits a warning "could not verify checksum in file "" block > > X: read buffer size X and page size

Re: PG 13 release notes, first draft

On Thu, May 7, 2020 at 2:46 AM Bruce Momjian wrote: > > Allow CREATE INDEX to specify the GiST signature length and maximum > number of integer ranges (Nikita Glukhov) > Should we specify which particular opclasses are affected? Or at least mention it affects core and

Re: PG 13 release notes, first draft

On Fri, May 8, 2020 at 12:32:16AM +0900, Amit Langote wrote: > On Thu, May 7, 2020 at 9:48 PM Bruce Momjian wrote: > > On Thu, May 7, 2020 at 12:06:33AM +0900, Amit Langote wrote: > > > +Author: Etsuro Fujita > > > +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases. > > > +Author:

Re: PG 13 release notes, first draft

On Thu, May 7, 2020 at 11:30:40PM +0900, Amit Langote wrote: > On Thu, May 7, 2020 at 11:12 PM Bruce Momjian wrote: > > Well, her name was there already for a later commit that was not > > backpatched, so I just moved her name earlier. The fact that her name > > was moved earlier because of

Re: Should smgrdounlink() be removed?

On Thu, May 7, 2020 at 4:33 AM Michael Paquier wrote: > So this gives the attached. Any thoughts? That seems fine. -- Peter Geoghegan

Re: tablespace_map code cleanup

On Wed, May 6, 2020 at 11:15 AM Robert Haas wrote: > Oh, good point. v2 attached. Here's v3, with one more small cleanup. I noticed tblspc_map_file is initialized to NULL and then unconditionally reset to the return value of makeStringInfo(), and then later tested to see whether it is NULL. It

Re: PG 13 release notes, first draft

On Thu, May 7, 2020 at 9:48 PM Bruce Momjian wrote: > On Thu, May 7, 2020 at 12:06:33AM +0900, Amit Langote wrote: > > +Author: Etsuro Fujita > > +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases. > > +Author: Tom Lane > > +2020-04-07 [981643dcd] Allow partitionwise join to

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

Rebased onto 1ad23335f36b07f4574906a8dc66a3d62af7c40c >From 698026f6365a324bf52c5985d549f71b52ada567 Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Mon, 16 Mar 2020 14:12:55 -0500 Subject: [PATCH v17 01/10] Document historic behavior of links to directories.. Backpatch to 9.5: pg_stat_file

Re: PG 13 release notes, first draft

On Thu, May 7, 2020 at 11:12 PM Bruce Momjian wrote: > On Thu, May 7, 2020 at 09:49:49AM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > OK, I have moved her name to be first. FYI, this commit was backpatched > > > back through PG 11, though the commit message doesn't mention that. > >

Re: PG 13 release notes, first draft

On Thu, May 7, 2020 at 09:49:49AM -0400, Tom Lane wrote: > Bruce Momjian writes: > > OK, I have moved her name to be first. FYI, this commit was backpatched > > back through PG 11, though the commit message doesn't mention that. > > If it was back-patched, it should not be appearing in the v13

Re: PG 13 release notes, first draft

Bruce Momjian writes: > On Thu, May 7, 2020 at 08:29:55AM +0200, Fabien COELHO wrote: >> After looking again at the release notes, I do really think that significant >> documentation changes do not belong to the "Source code" section but should >> be in separate "Documentation" section, and that

Re: PG 13 release notes, first draft

Bruce Momjian writes: > OK, I have moved her name to be first. FYI, this commit was backpatched > back through PG 11, though the commit message doesn't mention that. If it was back-patched, it should not be appearing in the v13 release notes at all, surely? regards, tom

Re: PG 13 release notes, first draft

On Wed, May 6, 2020 at 04:01:44PM -0400, Chapman Flack wrote: > On 05/05/20 10:31, Bruce Momjian wrote: > > On Tue, May 5, 2020 at 09:20:39PM +0800, John Naylor wrote: > >> ... This patch is > >> about the server encoding, which formerly needed to be utf-8 for > >> non-ascii characters. (I think

Re: PG 13 release notes, first draft

On Wed, May 6, 2020 at 10:20:57PM -0700, Noah Misch wrote: > On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote: > > On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote: > > > On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote: > > > > Allow skipping of WAL for new

[PATCH] fix GIN index search sometimes losing results

Hi, all It appeared than GIN index sometimes lose results if simultaneously: 1 if query operand contains weight marks 2 if weight-marked operand is negated by ! operator 3 if there are only logical (not phrase) operators from this negation towards the root of query tree. e.g.

Re: PG compilation error with Visual Studio 2015/2017/2019

Amit Kapila writes: > On Thu, May 7, 2020 at 11:57 AM Tom Lane wrote: >> Monday is a back-branch release wrap day. > How can I get the information about release wrap day? The minor > release dates are mentioned on the website [1], but this information > is not available. Do we keep it

Re: min_wal_size > max_wal_size is accepted

Hi, Le jeu. 7 mai 2020 à 11:13, Marc Rechté > a écrit : Hello, It is possible to startup an instance with min > max, without the system complaining: mrechte=# show min_wal_size ; 2020-05-07 11:12:11.422 CEST [11098] LOG:  durée : 0.279 ms

Re: PG 13 release notes, first draft

On Thu, May 7, 2020 at 11:25:47AM +0500, Andrey M. Borodin wrote: > > > > 7 мая 2020 г., в 04:35, Bruce Momjian написал(а): > > > > On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote: > >> > >> > >>> 5 мая 2020 г., в 08:16, Bruce Momjian написал(а): > >>> > >>> I have

Re: PG 13 release notes, first draft

On Wed, May 6, 2020 at 07:31:14PM -0500, Justin Pryzby wrote: > On Wed, May 06, 2020 at 07:35:34PM -0400, Bruce Momjian wrote: > > On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote: > > > I'm not sure, but probably it worth mentioning in "General performance" > > > section that

Re: min_wal_size > max_wal_size is accepted

Hi, Le jeu. 7 mai 2020 à 11:13, Marc Rechté a écrit : > Hello, > > It is possible to startup an instance with min > max, without the system > complaining: > > mrechte=# show min_wal_size ; > > 2020-05-07 11:12:11.422 CEST [11098] LOG: durée : 0.279 ms > > min_wal_size > > -- > >

Re: PG 13 release notes, first draft

On Thu, May 7, 2020 at 08:29:55AM +0200, Fabien COELHO wrote: > > Hello Bruce, > > > > > > * "DOCUMENT THE DEFAULT GENERATION METHOD" > > > > > => The default is still to generate data client-side. > > > > > > > > My point is that the docs are not clear about this. > > > > > > Indeed. > > >

Re: PG 13 release notes, first draft

On Thu, May 7, 2020 at 08:48:49AM -0400, Bruce Momjian wrote: > I think trying to put this all into one item is too complex, but I did > merge two of the items together, so we have two items now: I ended up adjusting the wording again, so please review the commit or the website:

Re: PG 13 release notes, first draft

On Thu, May 7, 2020 at 12:06:33AM +0900, Amit Langote wrote: > Hi Bruce, > > On Tue, May 5, 2020 at 12:16 PM Bruce Momjian wrote: > > > > I have committed the first draft of the PG 13 release notes. You can > > see them here: > > > > https://momjian.us/pgsql_docs/release-13.html > > >

Re: Why are wait events not reported even though it reads/writes a timeline history file?

On Thu, May 07, 2020 at 04:51:16PM +0900, Fujii Masao wrote: > Yeah, so I updated the patch so that ferror() is called only > when fgets() returns NULL. Attached is the updated version of > the patch. Thanks for the new patch. LGTM. -- Michael signature.asc Description: PGP signature

Re: do {} while (0) nitpick

On 5/6/20 6:39 PM, David Steele wrote: > On 5/6/20 6:28 PM, Andrew Dunstan wrote: >> On 5/6/20 3:24 PM, Tom Lane wrote: >> >>> BTW, I looked around and could not find a package-provided ppport.h >>> at all on my Red Hat systems.  What package is it in? >> >> perl-Devel-PPPort contains a perl

Re: Postgres Windows build system doesn't work with python installed in Program Files

Em qui., 7 de mai. de 2020 às 02:04, Victor Wagner escreveu: > В Thu, 7 May 2020 09:14:33 +0900 > Michael Paquier пишет: > > > On Wed, May 06, 2020 at 03:58:15PM -0300, Ranier Vilela wrote: > > > Hacking pgbison.pl, to print PATH, shows that the path inside > > > pgbison.pl, returned to being

Re: Should smgrdounlink() be removed?

On Thu, May 07, 2020 at 04:57:00PM +0900, Fujii Masao wrote: > On 2020/05/07 13:49, Michael Paquier wrote: >> On Thu, May 07, 2020 at 09:48:35AM +0530, vignesh C wrote: >> > I could not find any code reference to smgrdounlink, I feel it can be >> > removed. >> >> The last use of smgrdounlink()

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Hi Andy, Sorry for delay in review. Your earlier patches are very large and it requires some time to review those. I didn't finish reviewing those but here are whatever comments I have till now on the previous set of patches. Please see if any of those are useful to the new set. +/* + * Return

Re: [Proposal] Global temporary tables

> 2020年4月29日 下午7:46，tushar 写道： > > On 4/29/20 8:52 AM, 曾文旌 wrote: >> Fixed the error message to make the expression more accurate. In v33. > > Thanks wenjing > > Please refer this scenario , where getting an error while performing cluster > o/p > > 1) > > X terminal - > > postgres=#

Re: PG compilation error with Visual Studio 2015/2017/2019

On Thu, May 7, 2020 at 11:57 AM Tom Lane wrote: > > Amit Kapila writes: > > Thanks, Juan and Davinder for verifying the latest patches. I think > > this patch is ready to commit unless someone else has any comments. I > > will commit and backpatch this early next week (probably on Monday) > >

Re: Fix pg_buffercache document

On Thu, May 7, 2020 at 2:53 PM Masahiko Sawada wrote: > > On Thu, 7 May 2020 at 18:12, Amit Kapila wrote: > > > > On Thu, May 7, 2020 at 2:23 PM Masahiko Sawada > > wrote: > > > > > > Hi, > > > > > > The following description in pg_buffercace is no longer true. > > > > > > When the

Re: Fix pg_buffercache document

On Thu, 7 May 2020 at 18:12, Amit Kapila wrote: > > On Thu, May 7, 2020 at 2:23 PM Masahiko Sawada > wrote: > > > > Hi, > > > > The following description in pg_buffercace is no longer true. > > > > When the pg_buffercache view is accessed, internal buffer manager > > locks are taken for long

min_wal_size > max_wal_size is accepted

Hello, It is possible to startup an instance with min > max, without the system complaining: mrechte=# show min_wal_size ; 2020-05-07 11:12:11.422 CEST [11098] LOG: durée : 0.279 ms min_wal_size -- 128MB (1 ligne) mrechte=# show max_wal_size ; 2020-05-07 11:12:12.814

Re: Fix pg_buffercache document

On Thu, May 7, 2020 at 2:23 PM Masahiko Sawada wrote: > > Hi, > > The following description in pg_buffercace is no longer true. > > When the pg_buffercache view is accessed, internal buffer manager > locks are taken for long enough to copy all the buffer state data that > the view will display.

Re: Back-patch is necessary? Re: Don't try fetching future segment of a TLI.

On Thu, May 7, 2020 at 12:13 PM Fujii Masao wrote: > > On 2020/05/02 20:40, Amit Kapila wrote: > > > > I don't see any obvious problem with the changed code but we normally > > don't backpatch performance improvements. I can see that the code > > change here appears to be straight forward so it

Fix pg_buffercache document

Hi, The following description in pg_buffercace is no longer true. When the pg_buffercache view is accessed, internal buffer manager locks are taken for long enough to copy all the buffer state data that the view will display. This ensures that the view produces a consistent set of results, while

Re: PG compilation error with Visual Studio 2015/2017/2019

On Thu, May 7, 2020 at 11:57 AM Tom Lane wrote: > > Amit Kapila writes: > > Thanks, Juan and Davinder for verifying the latest patches. I think > > this patch is ready to commit unless someone else has any comments. I > > will commit and backpatch this early next week (probably on Monday) > >

Re: Feedback on table expansion hook (including patch)

that sounds really really useful. i can see a ton of use cases for that. we also toyed with the idea recently of having pluggable FSM strategies. that one could be quite useful as well. regards, hans > On 07.05.2020, at 10:11, Erik Nordström wrote: > > Hi, > > I am

Feedback on table expansion hook (including patch)

Hi, I am looking for feedback on the possibility of adding a table expansion hook to PostgreSQL (see attached patch). The motivation for this is to allow extensions to optimize table expansion. In particular, TimescaleDB does its own table expansion in order to apply a number of optimizations,

Re: Should smgrdounlink() be removed?

On 2020/05/07 13:49, Michael Paquier wrote: On Thu, May 07, 2020 at 09:48:35AM +0530, vignesh C wrote: I could not find any code reference to smgrdounlink, I feel it can be removed. The last use of smgrdounlink() was b416691. I have just looked at Debian Code Search and github, and could

Re: Why are wait events not reported even though it reads/writes a timeline history file?

On 2020/05/02 11:24, Michael Paquier wrote: On Fri, May 01, 2020 at 12:04:56PM +0900, Fujii Masao wrote: I applied cosmetic changes to the patch (attached). Barring any objection, I will push this patch (also back-patch to v10 where wait-event for timeline file was added). Sorry for

Re: xid wraparound danger due to INDEX_CLEANUP false

On Thu, 7 May 2020 at 15:40, Masahiko Sawada wrote: > > On Thu, 7 May 2020 at 03:28, Peter Geoghegan wrote: > > > > On Wed, May 6, 2020 at 2:28 AM Masahiko Sawada > > wrote: > > > I've attached the patch fixes this issue. > > > > > > With this patch, we don't skip only index cleanup phase when

Re: Back-patch is necessary? Re: Don't try fetching future segment of a TLI.

On 2020/05/02 20:40, Amit Kapila wrote: On Thu, Apr 30, 2020 at 7:46 PM Fujii Masao wrote: On 2020/04/08 1:49, Fujii Masao wrote: On 2020/04/07 20:21, David Steele wrote: On 4/7/20 3:48 AM, Kyotaro Horiguchi wrote: At Tue, 7 Apr 2020 12:15:00 +0900, Fujii Masao wrote in This

Re: xid wraparound danger due to INDEX_CLEANUP false

On Thu, 7 May 2020 at 03:28, Peter Geoghegan wrote: > > On Wed, May 6, 2020 at 2:28 AM Masahiko Sawada > wrote: > > I've attached the patch fixes this issue. > > > > With this patch, we don't skip only index cleanup phase when > > performing an aggressive vacuum. The reason why I don't skip only

Re: PG 13 release notes, first draft

Hello Bruce, * "DOCUMENT THE DEFAULT GENERATION METHOD" => The default is still to generate data client-side. My point is that the docs are not clear about this. Indeed. Can you fix it? Sure. Attached patch adds an explicit sentence about it, as it was only hinted about in the

Re: PG compilation error with Visual Studio 2015/2017/2019

Amit Kapila writes: > Thanks, Juan and Davinder for verifying the latest patches. I think > this patch is ready to commit unless someone else has any comments. I > will commit and backpatch this early next week (probably on Monday) > unless I see more comments. Monday is a back-branch release

Re: PG 13 release notes, first draft

> 7 мая 2020 г., в 04:35, Bruce Momjian написал(а): > > On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote: >> >> >>> 5 мая 2020 г., в 08:16, Bruce Momjian написал(а): >>> >>> I have committed the first draft of the PG 13 release notes. You can >>> see them here: >>> >>>

Re: +(pg_lsn, int8) and -(pg_lsn, int8) operators

On 2020/05/07 13:15, Fujii Masao wrote: On 2020/05/02 11:29, Michael Paquier wrote: On Thu, Apr 30, 2020 at 11:40:59PM +0900, Fujii Masao wrote: Also the number of bytes can be added into and substracted from LSN using the +(pg_lsn,numeric) and -(pg_lsn,numeric) operators, respectively.