Re: Improving scalability of Parallel Bitmap Heap/Index Scan

On Thu, Jul 14, 2022 at 5:13 PM David Geier wrote: > optimizing the PagetableEntry data structure for size and using a faster sorting algorithm like e.g. radix sort On this note, there has been a proposed (but as far as I know untested) patch to speed up this sort in a much simpler way, in this

Re: EINTR in ftruncate()

On Sat, Jul 16, 2022 at 1:28 AM Tom Lane wrote: > Thomas Munro writes: > > On Fri, Jul 15, 2022 at 9:34 AM Tom Lane wrote: > >> (Someday we oughta go ahead and make our Windows signal API look more > >> like POSIX, as I suggested back in 2015. I'm still not taking > >> point on that, though.)

Re: Handle infinite recursion in logical replication setup

On Sat, Jul 16, 2022 at 9:05 AM vignesh C wrote: > > On Thu, Jul 14, 2022 at 6:42 PM Dilip Kumar wrote: > > > > On Thu, 14 Jul 2022 at 6:34 PM, vignesh C wrote: > >> > >> On Thu, Jul 14, 2022 at 11:26 AM Dilip Kumar wrote: > >> > > >> > On Wed, Jul 13, 2022 at 4:49 PM Dilip Kumar > >> >

Re: Freeing sortgroupatts in use_physical_tlist

On Fri, Jul 15, 2022 at 8:33 PM Tom Lane wrote: > Zhihong Yu writes: > > I was looking at the code in use_physical_tlist(). > > In the code block checking CP_LABEL_TLIST, I noticed that > > the Bitmapset sortgroupatts is not freed before returning from the > method. > > Looking at

Re: Handle infinite recursion in logical replication setup

On Thu, Jul 14, 2022 at 6:42 PM Dilip Kumar wrote: > > On Thu, 14 Jul 2022 at 6:34 PM, vignesh C wrote: >> >> On Thu, Jul 14, 2022 at 11:26 AM Dilip Kumar wrote: >> > >> > On Wed, Jul 13, 2022 at 4:49 PM Dilip Kumar wrote: >> > > >> > > On Tue, Jul 12, 2022 at 2:58 PM vignesh C wrote: >> > >

Re: Freeing sortgroupatts in use_physical_tlist

Zhihong Yu writes: > I was looking at the code in use_physical_tlist(). > In the code block checking CP_LABEL_TLIST, I noticed that > the Bitmapset sortgroupatts is not freed before returning from the method. > Looking at create_foreignscan_plan() (in the same file): >

Re: Commitfest Update

On Fri, Jul 15, 2022 at 05:23:48PM -0700, Jacob Champion wrote: > I agree in principle -- I think, ideally, WoA patches should be > procedurally closed at the end of a commitfest, and carried forward when > the author has actually responded. The problems I can imagine resulting > from this are >

Freeing sortgroupatts in use_physical_tlist

Hi, I was looking at the code in use_physical_tlist(). In the code block checking CP_LABEL_TLIST, I noticed that the Bitmapset sortgroupatts is not freed before returning from the method. Looking at create_foreignscan_plan() (in the same file): bms_free(attrs_used); It seems the

Re: Commitfest Update

On Fri, Jul 15, 2022 at 05:23:48PM -0700, Jacob Champion wrote: > This is important stuff to discuss, for sure, but I also want to revisit > the thing I put on pause, which is to clear out old Reviewer entries to > make it easier for new reviewers to find work to do. If we're not using > Reviewers

Re: Backup command and functions can cause assertion failure and segmentation fault

On Fri, Jul 15, 2022 at 04:46:32PM +0900, Fujii Masao wrote: > On 2022/07/14 17:00, Michael Paquier wrote: >> and it is possible to rely on >> pg_stat_activity.wait_event to be BaseBackupThrottle, which would make > > ISTM that you can also use pg_stat_progress_basebackup.phase. Indeed, as of

Re: Commitfest Update

On Fri, Jul 15, 2022 at 05:23:48PM -0700, Jacob Champion wrote: > On 7/15/22 16:15, Justin Pryzby wrote: > > On Fri, Jul 15, 2022 at 03:17:49PM -0700, Jacob Champion wrote: > >> Also, I would like to see us fold cfbot output into the official CF, > >> rather than do the opposite. > > > > That's

Re: [Commitfest 2022-07] Begins Now

Hi, On 2022-07-15 17:28:06 -0700, Jacob Champion wrote: > On 7/15/22 16:51, Andres Freund wrote: > > I'd make it dependent on whether there have been previous rounds of feedback > > or not. If somebody spent a good amount of time reviewing a patch > > previously, > > but then didn't review the

Re: Select Reference Page - Make Join Syntax More Prominent

On Thu, Jul 7, 2022 at 2:33 PM Tom Lane wrote: > "David G. Johnston" writes: > > Looking again at the SELECT Reference page while helping a novice user I > > was once again annoyed but how the most common query syntax form for the > > FROM clause is buried within a bunch of "how to generate a

Re: [Commitfest 2022-07] Begins Now

On 7/15/22 16:51, Andres Freund wrote: > I'd make it dependent on whether there have been previous rounds of feedback > or not. If somebody spent a good amount of time reviewing a patch previously, > but then didn't review the newest version in the last few weeks, it doesn't > seem useful to

Re: PG15 beta1 sort performance regression due to Generation context change

On Fri, Jul 15, 2022 at 07:27:47PM -0400, Jonathan S. Katz wrote: > > So I agree with Andres here. It seems weird to me to try to document > > this new thing that I caused when we don't really make any attempt to > > document all the other weird stuff with work_mem. > > I can't argue with this. >

Re: Commitfest Update

On 7/15/22 16:15, Justin Pryzby wrote: > On Fri, Jul 15, 2022 at 03:17:49PM -0700, Jacob Champion wrote: >> Also, I would like to see us fold cfbot output into the official CF, >> rather than do the opposite. > > That's been the plan for years :) Is there something other than lack of round tuits

Re: Use -fvisibility=hidden for shared libraries

Hi, On 2022-01-11 15:54:19 -0500, Tom Lane wrote: > I still don't understand what are the conditions for MSVC to complain. > The rule is evidently not that every extern must agree with the function > definition, because for example you added > > +extern PGDLLEXPORT void _PG_init(void); > > in

Re: PG15 beta1 sort performance regression due to Generation context change

On 7/15/22 6:52 PM, Andres Freund wrote: Hi, On 2022-07-15 18:40:11 -0400, Jonathan S. Katz wrote: What I find interesting is the resistance to adding any documentation around this feature to guide users in case they hit the regression. I understand it can be difficult to provide guidance on

Re: [Commitfest 2022-07] Begins Now

Hi, On 2022-07-15 16:42:03 -0700, Jacob Champion wrote: > I started removing stale Reviewers fairly aggressively today, as > discussed in [1], but there was some immediate feedback and I have > paused that process for now. If you're wondering why you are no longer > marked as reviewer on a patch,

Re: [PATCH] Log details for client certificate failures

Hi, On 2022-07-15 14:51:38 -0700, Jacob Champion wrote: > > We already have pg_clean_ascii() and use it for application_name, fwiw. > > That seems much worse than escaping for this particular patch; if your > cert's Common Name is in (non-ASCII) UTF-8 then all you'll see is > "CN=?" in

Re: [Commitfest 2022-07] Begins Now

On 7/8/22 16:42, Jacob Champion wrote: > On 7/1/22 08:08, Jacob Champion wrote: >> It's been July everywhere on Earth for a few hours, so the July >> commitfest is now in progress: >> >> https://commitfest.postgresql.org/38/ Halfway through! We are now at Needs review: 175

Re: PG15 beta1 sort performance regression due to Generation context change

Thank you for the very detailed analysis. Comments inline. On 7/15/22 7:12 PM, David Rowley wrote: On Sat, 16 Jul 2022 at 10:40, Jonathan S. Katz wrote: What I find interesting is the resistance to adding any documentation around this feature to guide users in case they hit the regression. I

Moving RwF patches to a new CF

[changing the subject line, was "[Commitfest 2022-07] Begins Now"] On Fri, Jul 15, 2022 at 1:37 AM Wenjing Zeng wrote: > Please move the Global Temporary table to check next month, that is at 202208. > I need more time to process the existing issue. Hi Wenjing, My current understanding is that

Re: Commitfest Update

On Fri, Jul 15, 2022 at 03:17:49PM -0700, Jacob Champion wrote: > > Also, cfapp has a page for "patches where you are the author", but the cfbot > > doesn't, > > (I assume you mean "reviewer"?) Yes > Also, I would like to see us fold cfbot output into the official CF, > rather than do the

Re: PG15 beta1 sort performance regression due to Generation context change

On Sat, 16 Jul 2022 at 10:40, Jonathan S. Katz wrote: > What I find interesting is the resistance to adding any documentation > around this feature to guide users in case they hit the regression. I > understand it can be difficult to provide guidance on issues related to > adjusting work_mem, but

Re: PG15 beta1 sort performance regression due to Generation context change

Hi, On 2022-07-15 18:40:11 -0400, Jonathan S. Katz wrote: > What I find interesting is the resistance to adding any documentation around > this feature to guide users in case they hit the regression. I understand it > can be difficult to provide guidance on issues related to adjusting > work_mem,

Re: PG15 beta1 sort performance regression due to Generation context change

On 7/15/22 6:40 PM, Jonathan S. Katz wrote: On 7/15/22 4:54 PM, Tom Lane wrote: Tomas Vondra writes: ... My personal opinion is that it's a rare regression. Other optimization patches have similar rare regressions, except that David spent so much time investigating this one it seems more

Re: PG15 beta1 sort performance regression due to Generation context change

On 7/15/22 4:54 PM, Tom Lane wrote: Tomas Vondra writes: ... My personal opinion is that it's a rare regression. Other optimization patches have similar rare regressions, except that David spent so much time investigating this one it seems more serious. Yeah, this. I fear we're making a

Re: Commitfest Update

On 7/15/22 14:57, Justin Pryzby wrote: > On Fri, Jul 08, 2022 at 02:41:52PM -0700, Jacob Champion wrote: > >> If there are no objections, I'll start doing that during next Friday's >> patch sweep. > > I think it's fine to update the cfapp fields to reflect reality... > > ..but a couple updates

Re: Commitfest Update

On Fri, Jul 08, 2022 at 02:41:52PM -0700, Jacob Champion wrote: > On 3/31/22 07:37, Tom Lane wrote: > > Robert Haas writes: > >> On Thu, Mar 31, 2022 at 10:11 AM Tom Lane wrote: > >>> ... Would it be feasible or reasonable > >>> to drop reviewers if they've not commented in the thread in X

Re: [PATCH] Log details for client certificate failures

On 7/15/22 14:19, Andres Freund wrote: > On 2022-07-15 14:01:53 -0700, Jacob Champion wrote: >> On 7/15/22 13:35, Andres Freund wrote: >>> I don't know, but I don't think not caring at all is a good >>> option. Particularly for unauthenticated data I'd say that escaping >>> everything >>> but

Re: [PATCH] Log details for client certificate failures

Andres Freund writes: > We already have pg_clean_ascii() and use it for application_name, fwiw. Yeah, we should just use that. If anyone wants to upgrade the situation for non-ASCII data later, fixing it for all of these cases at once would be appropriate. regards, tom

Re: [PATCH] Log details for client certificate failures

Hi, On 2022-07-15 14:01:53 -0700, Jacob Champion wrote: > On 7/15/22 13:35, Andres Freund wrote: > >> (And do we want to fix it now, regardless?) > > > > Yes. > > Cool. I can get on board with that. > > >> What guarantees are we supposed to be making for log encoding? > > > > I don't know,

Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size

Hi, On 2022-07-08 17:05:49 -0400, Andrew Dunstan wrote: > On 2022-07-05 Tu 15:04, Andrew Dunstan wrote: > > On 2022-07-05 Tu 14:36, Andres Freund wrote: > >> > I think Andrew's beta 2 comment was more about my other architectural > complains around the json expression eval stuff. > >>>

Re: [PATCH] Log details for client certificate failures

On 7/15/22 13:35, Andres Freund wrote: >> (And do we want to fix it now, regardless?) > > Yes. Cool. I can get on board with that. >> What guarantees are we supposed to be making for log encoding? > > I don't know, but I don't think not caring at all is a good > option. Particularly for

Re: PG15 beta1 sort performance regression due to Generation context change

Hi, On 2022-07-15 16:42:14 -0400, Jonathan S. Katz wrote: > On 7/15/22 4:36 PM, Tomas Vondra wrote: > > > > If there does not appear to be a clear path forward, we should at least > > > > document how a user can detect and resolve the issue. > > > > > > To me that doesn't really make sense. We

Re: PG15 beta1 sort performance regression due to Generation context change

Tomas Vondra writes: > ... My personal opinion is that it's a rare regression. Other > optimization patches have similar rare regressions, except that David > spent so much time investigating this one it seems more serious. Yeah, this. I fear we're making a mountain out of a molehill. We have

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 12:59:34PM -0700, David G. Johnston wrote: > On Fri, Jul 15, 2022 at 12:40 PM Justin Pryzby wrote: > > > > | If the expression for any column is not of the correct data type, automatic > type conversion will be attempted. > > That appears to be copied from the INSERT

Re: doc: Bring mention of unique index forced transaction wait behavior outside of the internal section

On Thu, Jul 14, 2022 at 12:18 PM Bruce Momjian wrote: > On Mon, Jul 11, 2022 at 05:22:41PM +0300, Aleksander Alekseev wrote: > > Hi Bruce, > > > > > I was not happy with putting this in the Transaction Isolation section. > > > I rewrote it and put it in the INSERT secion, right before ON

Re: PG15 beta1 sort performance regression due to Generation context change

On 7/15/22 4:36 PM, Tomas Vondra wrote: On 7/13/22 17:32, Andres Freund wrote: Hi, On 2022-07-13 09:23:00 -0400, Jonathan S. Katz wrote: On 7/13/22 12:13 AM, David Rowley wrote: On Tue, 12 Jul 2022 at 17:15, David Rowley wrote: So far only Robert has raised concerns with this regression

Re: PG15 beta1 sort performance regression due to Generation context change

On 7/13/22 17:32, Andres Freund wrote: > Hi, > > On 2022-07-13 09:23:00 -0400, Jonathan S. Katz wrote: >> On 7/13/22 12:13 AM, David Rowley wrote: >>> On Tue, 12 Jul 2022 at 17:15, David Rowley wrote: So far only Robert has raised concerns with this regression for PG15 (see [2]).

Re: [PATCH] Log details for client certificate failures

Hi, On 2022-07-15 13:20:59 -0700, Jacob Champion wrote: > On 7/15/22 12:11, Andres Freund wrote: > > This might have been discussed somewhere, but I'm worried about emitting > > unescaped data from pre-auth clients. What guarantees that subject / issuer > > name only contain printable

Re: [PATCH] Log details for client certificate failures

On 7/15/22 12:11, Andres Freund wrote: > This might have been discussed somewhere, but I'm worried about emitting > unescaped data from pre-auth clients. What guarantees that subject / issuer > name only contain printable ascii-chars? Printing terminal control chars or > such would not be great,

Re: optimize lookups in snapshot [sub]xip arrays

Hi, Sounds worth pursuing. On 2022-07-13 10:09:50 -0700, Nathan Bossart wrote: > The attached patch has some key differences from the previous proposal. > For example, the new patch uses simplehash instead of open-coding a new > hash table. +1 > The attached patch waits until a lookup of

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 12:40 PM Justin Pryzby wrote: > > That appears to be copied from the INSERT page. > What does that mean, if not that data types will be resolved as needed ? > Yep, and the system needs to resolve the type at a point where there is no contextual information and so it

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 12:40 PM Justin Pryzby wrote: > On Fri, Jul 15, 2022 at 12:17:51PM -0700, David G. Johnston wrote: > > On Fri, Jul 15, 2022 at 11:40 AM Alvaro Herrera > wrote: > > > On 2022-Jul-15, Justin Pryzby wrote: > > > > > > > It seems a bit odd that it's impossible to use merge

Re: POC: GROUP BY optimization

On 7/15/22 07:18, David Rowley wrote: > On Thu, 31 Mar 2022 at 12:19, Tomas Vondra > wrote: >> Pushed, after going through the patch once more, running check-world >> under valgrind, and updating the commit message. > > I'm still working in this area and I noticed that db0d67db2 updated >

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 12:17:51PM -0700, David G. Johnston wrote: > On Fri, Jul 15, 2022 at 11:40 AM Alvaro Herrera > wrote: > > On 2022-Jul-15, Justin Pryzby wrote: > > > > > It seems a bit odd that it's impossible to use merge with prepared > > > statements > > > without specifically casting

Re: Move Section 9.27.7 (Data Object Management Functions) to System Information Chapter

On Thu, Jul 14, 2022 at 3:57 PM Tom Lane wrote: > Bruce Momjian writes: > > On Mon, Apr 25, 2022 at 08:33:47AM -0700, David G. Johnston wrote: > >> Both the location and name of the linked to section make no sense to me: > >> https://www.postgresql.org/docs/current/functions-admin.html# > >>

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 11:40 AM Alvaro Herrera wrote: > On 2022-Jul-15, Justin Pryzby wrote: > > > It seems a bit odd that it's impossible to use merge with prepared > statements > > without specifically casting the source types (which I did now to > continue my > > experiment). > > I have no

Re: MERGE and parsing with prepared statements

Alvaro Herrera writes: > On 2022-Jul-15, Justin Pryzby wrote: >> I see now that the same thing can happen with "ON CONFLICT" if used with a >> subselect. >> >> PREPARE p AS INSERT INTO t SELECT a FROM (SELECT $1 AS a)a >> ON CONFLICT (i) DO UPDATE SET i=excluded.i; >> ERROR: column "i" is of

Re: [PATCH] Log details for client certificate failures

Hi, On 2022-07-15 09:46:40 -0700, Jacob Champion wrote: > On 7/15/22 09:34, Peter Eisentraut wrote: > > Committed like that. > > Thanks for all the reviews! This might have been discussed somewhere, but I'm worried about emitting unescaped data from pre-auth clients. What guarantees that

Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

Hi, On 2022-07-15 11:59:41 -0400, Melanie Plageman wrote: > I'm not sure about the idea of prefixing the IOOp and IOPath enums with > Pg_Stat. I could see them being used outside of statistics (though they > are defined in pgstat.h) +1 > From Andres: > > Quoting me (Melanie): > > > Introduce

Re: MERGE and parsing with prepared statements

On 2022-Jul-15, Justin Pryzby wrote: > On Fri, Jul 15, 2022 at 11:25:35AM +0200, Matthias van de Meent wrote: > Thanks for looking into it. Definitely! Thanks, Matthias. > I see now that the same thing can happen with "ON CONFLICT" if used with a > subselect. > > PREPARE p AS INSERT INTO t

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

I ran that original test case with and without the patch. Here are the numbers I'm seeing: master (best of three): postgres=# SELECT count(*) FROM lotsarows; Time: 582.423 ms postgres=# EXPLAIN (ANALYZE, TIMING OFF) SELECT count(*) FROM lotsarows; Time: 616.102 ms postgres=# EXPLAIN (ANALYZE,

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 11:25:35AM +0200, Matthias van de Meent wrote: > On Thu, 14 Jul 2022, 18:26 Justin Pryzby, wrote: > > > > Why is $1 construed to be of type text ? > > The select statement that generates the row type of T `(select $1 CID, > $2 TxV) AS T` does not put type bounds on the

Re: Transparent column encryption

On 7/12/22 11:29, Peter Eisentraut wrote: > > Updated patch, to resolve some merge conflicts. Thank you for working on this; it's an exciting feature. > The CEK key > material is in turn encrypted by an assymmetric key called the column > master key (CMK). I'm not yet understanding

Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths

Hi, On 2022-07-15 11:25:54 +0200, Matthias van de Meent wrote: > On Mon, 14 Mar 2022 at 18:14, Andres Freund wrote: > > > > A random thought I had while thinking about the size limits: We could use > > the > > low bits of the length and xl_prev to store XLR_SPECIAL_REL_UPDATE | > >

interrupt processing during FATAL processing

Hi, One of the problems we found ([1]) when looking at spurious failures of the recovery conflict test ([2]) is that a single backend can FATAL out multiple times. That seems independent enough from that thread that I thought it best to raise separately. The problem is that during the course of

Re: Allowing REINDEX to have an optional name

On Fri, 15 Jul 2022 at 12:25, Simon Riggs wrote: > > On Mon, 4 Jul 2022 at 08:00, Michael Paquier wrote: > > > > On Sun, Jul 03, 2022 at 05:41:31PM -0400, Tom Lane wrote: > > > This is marked as Ready for Committer, but that seems unduly > > > optimistic. > > > > Please note that patch authors

Re: Allowing REINDEX to have an optional name

On Fri, 15 Jul 2022 at 15:03, Tom Lane wrote: > > Alvaro Herrera writes: > > Ah, one theory is that the libpq_pipeline program is getting linked to > > an installed version of libpq that doesn't contain the fixes. Maybe you > > can do `ldd /path/to/libpq_pipeline` and see which copy of libpq.so

Re: [PATCH] Log details for client certificate failures

On 7/15/22 09:34, Peter Eisentraut wrote: > Committed like that. Thanks for all the reviews! --Jacob

Re: [PATCH] Log details for client certificate failures

On 14.07.22 23:09, Jacob Champion wrote: On Thu, Jul 14, 2022 at 1:12 PM Peter Eisentraut wrote: Concretely, I was thinking like the attached top-up patch. The other way can surely be made to work somehow, but this seems much simpler and with fewer questions about the details. Ah, seeing it

Re: [RFC] building postgres with meson -v9

Hi, On 2022-07-13 08:39:45 +0200, Peter Eisentraut wrote: > On 06.07.22 15:21, Andres Freund wrote: > > > - This patch is for unifying the list of languages in NLS, as > > >previously discussed:https://commitfest.postgresql.org/38/3737/ > > There seems little downside to doing so, so ... > >

Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

I am consolidating the various naming points from this thread into one email: >From Horiguchi-san: > A bit different thing, but I felt a little uneasy about some uses of > "pgstat_io_ops". IOOp looks like a neighbouring word of IOPath. On the > other hand, actually iopath is used as an attribute

Re: Adjust ndistinct for eqjoinsel

Zhenghua Lyu writes: > I run TPC-DS benchmark for Postgres and find the join size estimation has > several problems. > For example, Ndistinct is key to join selectivity's estimation, this > value does not take restrictions > of the rel, I hit some cases in the function eqjoinsel, nd

Re: Add function to return backup_label and tablespace_map

Greetings, * Fujii Masao (masao.fu...@oss.nttdata.com) wrote: > On 2022/07/08 23:11, David Steele wrote: > >Looks like I made that more complicated than it needed to be: > > > >select * from pg_backup_stop(...) \gset > >\pset tuples_only on > >\pset format unaligned > >\o

Re: Support load balancing in libpq

> we can assume that one of members is a primary and others are secondary. With plain Postgres this assumption is probably correct. But the main reason I'm interested in this patch was because I would like to be able to load balance across the workers in a Citus cluster. These workers are all

Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns

On Fri, Jul 15, 2022 at 10:43 PM osumi.takami...@fujitsu.com wrote: > > On Thursday, July 14, 2022 10:31 AM Masahiko Sawada > wrote: > > I've attached an updated patch that incorporated comments from Amit and Shi. > Hi, > > > Minor comments for v4. Thank you for the comments! > > (1) typo in

Re: Add 64-bit XIDs into PostgreSQL 15

Hi hackers, > I can agree with you that sending rebased patches too often can be a little > annoying. On the other hand, otherwise, it's just red in Cfbot. I suppose > it's much easier and more comfortable to review the patches that at least > apply cleanly and pass all tests. So if Cfbot is

Re: Doc about how to set max_wal_senders when setting minimal wal_level

On Fri, Jul 15, 2022 at 6:27 AM Japin Li wrote: > > > > > +servers. If setting max_wal_senders to > > +0 consider also reducing the amount of WAL > produced > > +by changing wal_level to > minimal. > > > > I don't think this is great advice. It will encourage people to

Adjust ndistinct for eqjoinsel

Hi, I run TPC-DS benchmark for Postgres and find the join size estimation has several problems. For example, Ndistinct is key to join selectivity's estimation, this value does not take restrictions of the rel, I hit some cases in the function eqjoinsel, nd is much larger than

Re: Allowing REINDEX to have an optional name

Alvaro Herrera writes: > Ah, one theory is that the libpq_pipeline program is getting linked to > an installed version of libpq that doesn't contain the fixes. Maybe you > can do `ldd /path/to/libpq_pipeline` and see which copy of libpq.so it > is picking up? That's pronounced "otool -L" on

Re: SQL/JSON documentation JSON_TABLE

On 2022-07-15 Fr 02:20, Erik Rijkers wrote: > On 7/14/22 17:45, Andrew Dunstan wrote: >> >> >> Here's a patch that deals with most of this. There's one change you >> wanted that I don't think is correct, which I omitted. >> >> [json-docs-fix.patch] > > Thanks, much better. I also agree that the

RE: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns

On Thursday, July 14, 2022 10:31 AM Masahiko Sawada wrote: > I've attached an updated patch that incorporated comments from Amit and Shi. Hi, Minor comments for v4. (1) typo in the commit message "When decoding a COMMIT record, we check both the list and the ReorderBuffer to see if if the

Re: Doc about how to set max_wal_senders when setting minimal wal_level

On Fri, 15 Jul 2022 at 08:49, Bruce Momjian wrote: > On Tue, Jul 5, 2022 at 08:02:33PM -0400, Tom Lane wrote: >> "Precondition" is an overly fancy word that makes things less clear >> not more so. Does it mean that setting wal_level = minimal will fail >> if you don't do these other things,

Re: EINTR in ftruncate()

Thomas Munro writes: > On Fri, Jul 15, 2022 at 9:34 AM Tom Lane wrote: >> (Someday we oughta go ahead and make our Windows signal API look more >> like POSIX, as I suggested back in 2015. I'm still not taking >> point on that, though.) > For the sigprocmask() part, here's a patch that passes

Re: Doc about how to set max_wal_senders when setting minimal wal_level

Sorry for the late reply. On Wed, 06 Jul 2022 at 08:02, Tom Lane wrote: > Japin Li writes: >> [ v4-wal-level-documentation.patch ] > > Hm, I don't care for the wording here: > > +A precondition for using minimal WAL is to disable WAL archiving and > +streaming replication by

Re: Allowing REINDEX to have an optional name

On 2022-Jul-15, Alvaro Herrera wrote: > Not sure what to make of this. Maybe the fix in 054325c5eeb3 is not > right, but I don't understand why it doesn't fail in the macOS machines > in the buildfarm. Ah, one theory is that the libpq_pipeline program is getting linked to an installed version

Re: remove reset_shared()

On Fri, 15 Jul 2022 at 16:41, Maxim Orlov wrote: > Hi! > > In general I'm for this patch. Some time ago I was working on a patch > related to shared memory and noticed > no reason to have reset_shared() function. > Hi, hackers! I see the proposed patch as uncontroversial and good enough to be

Re: remove reset_shared()

Hi! In general I'm for this patch. Some time ago I was working on a patch related to shared memory and noticed no reason to have reset_shared() function. -- Best regards, Maxim Orlov.

Re: Add 64-bit XIDs into PostgreSQL 15

On Fri, 15 Jul 2022 at 16:17, Justin Pryzby wrote: > On Fri, Jul 15, 2022 at 03:23:29PM +0400, Pavel Borisov wrote: > > On Fri, 15 Jul 2022 at 15:20, Pavel Borisov > wrote: > > > Hi, hackers! > > > v42 stopped applying, so we rebased it to v43. Attached is a GitHub > link, > > > but I see Cfbot

Re: Add 64-bit XIDs into PostgreSQL 15

On Fri, Jul 15, 2022 at 03:23:29PM +0400, Pavel Borisov wrote: > On Fri, 15 Jul 2022 at 15:20, Pavel Borisov wrote: > > Hi, hackers! > > v42 stopped applying, so we rebased it to v43. Attached is a GitHub link, > > but I see Cfbot hasn't become green. Apparently, it hasn't seen changes in > >

Re: standby recovery fails (tablespace related) (tentative patch and discussion)

On 2022-Jul-15, Alvaro Herrera wrote: > However, looking closer I noticed that on Windows we use our own > readdir() implementation, which AFAICT includes everything to handle > reparse points as symlinks correctly in get_dirent_type. Which means > that do_pg_start_backup is wasting its time

Re: Allowing REINDEX to have an optional name

On 2022-Jul-15, Alvaro Herrera wrote: > > Yeh, repeated failures on MacOS Catalina with HEAD. > > Can you share the contents of src/test/modules/libpq_pipeline/tmp_check? > Since these failures are not visible in the buildfarm (where we do have > 11.0 as well as some 10.X versions of macOS),

Re: Allowing REINDEX to have an optional name

On 2022-Jul-15, Simon Riggs wrote: > > Test Summary Report > > --- > > t/001_libpq_pipeline.pl (Wstat: 512 Tests: 20 Failed: 2) > > Failed tests: 9-10 > > Non-zero exit status: 2 > > Files=1, Tests=20, 4 wallclock secs ( 0.02 usr 0.00 sys + 0.66 cusr > > 0.64 csys = 1.32

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Pavel, Justin, >> Is there any reason to continue with two separate threads and CF entries ? >> The original reason was to have a smaller patch for considerate late in v15. > I see the main goal of this split is to make discussion of this (easier) > thread separate to the discussion of a whole

Re: Allowing REINDEX to have an optional name

On Mon, 4 Jul 2022 at 08:00, Michael Paquier wrote: > > On Sun, Jul 03, 2022 at 05:41:31PM -0400, Tom Lane wrote: > > This is marked as Ready for Committer, but that seems unduly > > optimistic. > > Please note that patch authors should not switch a patch as RfC by > themselves. This is

Re: Add 64-bit XIDs into PostgreSQL 15

On Fri, 15 Jul 2022 at 15:20, Pavel Borisov wrote: > Hi, hackers! > v42 stopped applying, so we rebased it to v43. Attached is a GitHub link, > but I see Cfbot hasn't become green. Apparently, it hasn't seen changes in > GitHub link relative to v42 attached as a patch. > Github link is as

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, hackers! v42 stopped applying, so we rebased it to v43. Attached is a GitHub link, but I see Cfbot hasn't become green. Apparently, it hasn't seen changes in GitHub link relative to v42 attached as a patch. -- Best regards, Pavel Borisov

Re: Allowing REINDEX to have an optional name

On Fri, 15 Jul 2022 at 12:15, Simon Riggs wrote: > > On Fri, 15 Jul 2022 at 09:12, Alvaro Herrera wrote: > > > > On 2022-Jul-15, Simon Riggs wrote: > > > > > On Fri, 15 Jul 2022 at 04:44, Michael Paquier wrote: > > > > > > This patch has been marked as waiting for a review, however the CF bot >

Re: Allowing REINDEX to have an optional name

On Fri, 15 Jul 2022 at 09:12, Alvaro Herrera wrote: > > On 2022-Jul-15, Simon Riggs wrote: > > > On Fri, 15 Jul 2022 at 04:44, Michael Paquier wrote: > > > > This patch has been marked as waiting for a review, however the CF bot > > > is completely red: > > > > Yes, it is failing, but so is

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

This is not a review, but I think the isolation tests should be expanded. At least, include the case of serializable transactions being involved. Thanks! I will expand the tests for the next commitfest. -- With best regards, Dmitry Koval Postgres Professional: http://postgrespro.com

Re: standby recovery fails (tablespace related) (tentative patch and discussion)

On 2022-Jul-15, Kyotaro Horiguchi wrote: > 0002: > +is_path_tslink(const char *path) > > What the "ts" of tslink stands for? If it stands for tablespace, the > function is not specific for table spaces. We already have > > + errmsg("could not stat file

RE: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger

Dear Hou-san, > Thanks for having a look. It was a bit difficult to add a test for this. > Because we currently don't have a user function which can return these > collected ObjectAddresses for ALTER TABLE. And It seems we don't have tests > for > already collected ObjectAddresses as well :( >

Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths

On Mon, 14 Mar 2022 at 18:14, Andres Freund wrote: > > A random thought I had while thinking about the size limits: We could use the > low bits of the length and xl_prev to store XLR_SPECIAL_REL_UPDATE | > XLR_CHECK_CONSISTENCY and give rmgrs the full 8 bit of xl_info. Which would > allow us to

Re: MERGE and parsing with prepared statements

On Thu, 14 Jul 2022, 18:26 Justin Pryzby, wrote: > > We've used INSERT ON CONFLICT for a few years (with partitions as the target). > That's also combined with prepared statements, for bulk loading. > > I was looking to see if we should use MERGE (probably not, but looking > anyway). > And came

Re: Problem about postponing gathering partial paths for topmost scan/join rel

On Fri, Jul 15, 2022 at 4:03 PM Richard Guo wrote: > > On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska wrote: > >> I'd prefer a test that demonstrates that the Gather node at the top of the >> "subproblem plan" is useful purely from the *cost* perspective, rather >> than >> due to executor

Re: Add last_vacuum_index_scans in pg_stat_all_tables

On 2022-07-09 03:18, Peter Geoghegan wrote: On Fri, Jul 8, 2022 at 10:47 AM Alvaro Herrera wrote: Saving some sort of history would be much more useful, but of course a lot more work. Thank you for the comments! Yes, having some sort of history would be ideal in this case. However, I am not

Re: [Commitfest 2022-07] Begins Now

Hi Jacob Abort Global temporary table https://commitfest.postgresql.org/36/2349/# Please move the Global Temporary table to check next month, that is at 202208. I need more time to process the existing issue. Thanks Wenjing > 2022年7月9日 07:42，Jacob

  1   2   >