Re: default partition and concurrent attach partition

Hi Alvaro, On Tue, Sep 8, 2020 at 8:44 AM Alvaro Herrera wrote: > On 2020-Sep-07, Alvaro Herrera wrote: > > > Ah, it looks like we can get away with initializing the RRI to 0, and > > then explicitly handle that case in ExecPartitionCheckEmitError, as in > > the attached (which means reindenting,

Re: [POC] Fast COPY FROM command for the table with foreign partitions

Hi Andrey, On Mon, Sep 7, 2020 at 7:31 PM Andrey V. Lepikhov wrote: > On 9/7/20 12:26 PM, Michael Paquier wrote: > > While on it, the CF bot is telling that the documentation of the patch > > fails to compile. This needs to be fixed. > > -- > > Michael > > > v.7 (in attachment) fixes this proble

Re: Remove page-read callback from XLogReaderState.

Thank you for the comment and sorry for late reply. At Fri, 17 Jul 2020 14:14:44 +0900, Takashi Menjo wrote in > Hi, > > I applied your v15 patchset to master > ed2c7f65bd9f15f8f7cd21ad61602f983b1e72e9. Here are three feedback points > for you: > > = 1. Build error when WAL_DEBUG is defined

回复: Is it possible to set end-of-data marker for COPY statement.

Thanks for all your feedbacks!

Re: shared-memory based stats collector

At Thu, 3 Sep 2020 13:16:59 -0400, Stephen Frost wrote in > Greetings, > > * Kyotaro Horiguchi (horikyota@gmail.com) wrote: > > At Mon, 01 Jun 2020 18:00:01 +0900 (JST), Kyotaro Horiguchi > > wrote in > > > Rebased on the current HEAD. 36ac359d36 conflicts with this. Tranche > > > > Hmm.

Re: Fix for configure error in 9.5/9.6 on macOS 11.0 Big Sur

On 2020-09-05 17:27, Tom Lane wrote: Jesse Zhang writes: Notice that -Werror=implicit-function-declaration up there? I spent a few minutes digging in Apple's published fork of LLVM, they've been forcing this error flag for quite a while, but this particular warning-turned-error is guarded by a

Re: Boundary value check in lazy_tid_reaped()

On Tue, 1 Sep 2020 at 04:44, Thomas Munro wrote: > > On Tue, Sep 1, 2020 at 7:21 AM Thomas Munro wrote: > > On Sun, Aug 30, 2020 at 11:08 PM Masahiko Sawada > > wrote: > > > So my proposal is to add boundary value check in lazy_tid_reaped() > > > before executing bsearch(3). This will help when

Re: Internal key management system

On Fri, Jul 31, 2020 at 04:06:38PM +0900, Masahiko Sawada wrote: > Since the previous patch sets conflicts with the current HEAD, I've > attached the rebased patch set. Patch 0002 fails to apply, so a rebase is needed. -- Michael signature.asc Description: PGP signature

Re: INSERT ON CONFLICT and RETURNING

I have performed comparison of different ways of implementing UPSERT in Postgres. May be it will be interesting not only for me, so I share my results: So first of all initialization step:   create table jsonb_schemas(id serial, schema bytea primary key);   create unique index on jsonb_schemas(

Re: Improving connection scalability: GetSnapshotData()

On 07.09.2020 23:45, Andres Freund wrote: Hi, On Mon, Sep 7, 2020, at 07:20, Konstantin Knizhnik wrote: And which pgbench database scale factor you have used? 200 Another thing you could try is to run 2-4 pgench instances in different databases. I tried to reinitialize database with scal

Re: [POC] Fast COPY FROM command for the table with foreign partitions

Hi, I've started doing a review of v7 yesterday. On 2020-09-08 10:34, Amit Langote wrote: On Mon, Sep 7, 2020 at 7:31 PM Andrey V. Lepikhov wrote: > v.7 (in attachment) fixes this problem. I also accepted Amit's suggestion to rename all fdwapi routines such as ForeignCopyIn to *ForeignCopy.

Re: INSERT ON CONFLICT and RETURNING

út 8. 9. 2020 v 11:06 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > I have performed comparison of different ways of implementing UPSERT in > Postgres. > May be it will be interesting not only for me, so I share my results: > > So first of all initialization step: > > cre

Re: Evaluate expression at planning time for two more cases

Hi Tom On Tue, Sep 8, 2020 at 4:46 AM Tom Lane wrote: > Surafel Temesgen writes: > > [ null_check_on_pkey_optimization_v1.patch ] > > I took a very brief look at this. > > > I don’t add NOT NULL constraint optimization to the patch because cached > > plan is not invalidation in case of a change

Re: [POC] Fast COPY FROM command for the table with foreign partitions

On 9/8/20 12:34 PM, Amit Langote wrote: Hi Andrey, On Mon, Sep 7, 2020 at 7:31 PM Andrey V. Lepikhov wrote: On 9/7/20 12:26 PM, Michael Paquier wrote: While on it, the CF bot is telling that the documentation of the patch fails to compile. This needs to be fixed. -- Michael v.7 (in attachm

Re: Inconsistency in determining the timestamp of the db statfile.

On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila wrote: > We use the timestamp of the global statfile if we are not able to > determine it for a particular database either because the entry for > that database doesn't exist or there is an error while reading the > specific database entry. This was not

Re: INSERT ON CONFLICT and RETURNING

On 08.09.2020 12:34, Pavel Stehule wrote: út 8. 9. 2020 v 11:06 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: I have performed comparison of different ways of implementing UPSERT in Postgres. May be it will be interesting not only for me, so I share

Re: Global snapshots

On 2020-09-08 05:49, Fujii Masao wrote: On 2020/09/05 3:31, Alexey Kondratov wrote: Attached is a patch, which implements a plain 2PC in the postgres_fdw and adds a GUC 'postgres_fdw.use_twophase'. Also it solves these errors handling issues above and tries to add proper comments everywhere.

Re: INSERT ON CONFLICT and RETURNING

út 8. 9. 2020 v 12:34 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 08.09.2020 12:34, Pavel Stehule wrote: > > > > út 8. 9. 2020 v 11:06 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > >> I have performed comparison of different ways of implem

Re: Division in dynahash.c due to HASH_FFACTOR

Hi Thomas, Tomas :), Alvaro, hackers, >> > After removing HASH_FFACTOR PostgreSQL still compiles... Would >> > removing it break some external API/extensions ? >> >> FWIW, HASH_FFACTOR has *never* been used in Postgres core code. [..] >> I think if we know that there's a 4% performance increase b

RE: extension patch of CREATE OR REPLACE TRIGGER

Hi, Peter-San I've fixed all except one point. > My only remaining comments are for trivial stuff: Not trivial but important. > COMMENT trigger.c (tab alignment) > > @@ -184,6 +185,13 @@ CreateTrigger(CreateTrigStmt *stmt, const char > *queryString, > char*oldtablename = NULL; > char

Re: Global snapshots

On 2020/09/08 19:36, Alexey Kondratov wrote: On 2020-09-08 05:49, Fujii Masao wrote: On 2020/09/05 3:31, Alexey Kondratov wrote: Attached is a patch, which implements a plain 2PC in the postgres_fdw and adds a GUC 'postgres_fdw.use_twophase'. Also it solves these errors handling issues ab

Re: Parallel worker hangs while handling errors.

On Thu, Sep 3, 2020 at 5:29 PM Tom Lane wrote: > Concretely, something about like this (I just did the bgwriter, but > we'd want the same in all the background processes). I tried to > respond to Robert's complaint about the inaccurate comment just above > sigsetjmp, too. > > This passes check-wo

Re: Evaluate expression at planning time for two more cases

On Tue, 8 Sep 2020 at 07:16, Tom Lane wrote: > > > I'm not sure what I think about Ashutosh's ideas about doing this > somewhere else than eval_const_expressions. I do not buy the argument > that it's interesting to do this separately for each child partition. > Child partitions that have attnot

Re: Ideas about a better API for postgres_fdw remote estimates

On Fri, 4 Sep 2020 at 20:27, Tomas Vondra wrote > > > 4) I wonder if we actually want/need to simply output pg_statistic data > verbatim like this. Is postgres_fdw actually going to benefit from it? I > kinda doubt that, and my assumption was that we'd return only a small > subset of the data, ne

Case for Improved Costing for Index Only Scans?

While running a simple SELECT statement on a table where I expected indexonly scan to be preferred over sequential scan, the planner kept on selecting the sequential scan. Looking at the EXPLAIN output, it seemed obvious that the cost of indexonly was exceeding that of sequential scan. So the plann

Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks

On Mon, Sep 7, 2020 at 8:50 PM Tom Lane wrote: > > I think there is agreement that we're not going to change > cancel_before_shmem_exit's restriction to only allow LIFO popping. > So we should improve its comment to explain why. The other thing > that seems legitimately on-the-table for this CF e

Re: Inconsistency in determining the timestamp of the db statfile.

On 2020/09/08 19:28, Magnus Hagander wrote: On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila mailto:amit.kapil...@gmail.com>> wrote: We use the timestamp of the global statfile if we are not able to determine it for a particular database either because the entry for that database does

Re: Transactions involving multiple postgres foreign servers, take 2

On Mon, Sep 7, 2020 at 2:29 PM Fujii Masao wrote: > > #2 > Originally when there was the FDW access in the transaction, > PREPARE TRANSACTION on that transaction failed with an error. The patch > allows PREPARE TRANSACTION and COMMIT/ROLLBACK PREPARED > even when FDW access occurs in the transacti

Re: Inconsistency in determining the timestamp of the db statfile.

On Tue, Sep 8, 2020 at 3:11 PM Fujii Masao wrote: > > > On 2020/09/08 19:28, Magnus Hagander wrote: > > > > > > On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila > wrote: > > > > We use the timestamp of the global statfile if we are not able to > > determine it f

Re: Resetting spilled txn statistics in pg_stat_replication

On Tue, Sep 8, 2020 at 7:53 AM Masahiko Sawada wrote: > > On Mon, 7 Sep 2020 at 15:24, Amit Kapila wrote: > > > > This patch needs a rebase. I don't see this patch in the CF app. I > > hope you are still interested in working on this. > > Thank you for reviewing this patch! > > I'm still going to

Re: PATCH: Attempt to make dbsize a bit more consistent

On Thu, Aug 27, 2020 at 9:39 AM wrote: > > Hi all, > > this minor patch is attempting to force the use of the tableam api in dbsize > where ever it is required. > > Apparently something similar was introduced for toast relations only. > Intuitively it seems that the distinction between a table a

Re: Auto-vectorization speeds up multiplication of large-precision numerics

Amit Khandekar writes: > Thanks. I must admit it did not occur to me that I could have very > well installed clang on my linux machine and tried compiling this > file, or tested with some older gcc versions. I think I was using gcc > 8. Do you know what was the gcc compiler version that gave these

Re: [POC] Fast COPY FROM command for the table with foreign partitions

Hi Alexey, On Tue, Sep 8, 2020 at 6:29 PM Alexey Kondratov wrote: > On 2020-09-08 10:34, Amit Langote wrote: > > Any thoughts on the taking out the refactoring changes out of the main > > patch as I suggested? > > > > +1 for splitting the patch. It was rather difficult for me to > distinguish cha

Re: [PATCH] Automatic HASH and LIST partition creation

> The patch lacks documentation, because I expect some details may change > during discussion. Other than that, the feature is ready for review. > Hi, hackers! >From what I've read I see there is much interest in automatic partitions creation. (Overall discussion on the topic is partitioned into t

Re: Disk-based hash aggregate's cost model

On Mon, Sep 07, 2020 at 01:55:28PM -0700, Jeff Davis wrote: On Sun, 2020-09-06 at 23:21 +0200, Tomas Vondra wrote: I've tested the costing changes on the simplified TPC-H query, on two different machines, and it seems like a clear improvement. Thank you. Committed. So yeah, the patched costi

Re: default partition and concurrent attach partition

Hello Amit, On 2020-Sep-08, Amit Langote wrote: > On Tue, Sep 8, 2020 at 8:44 AM Alvaro Herrera > wrote: > > On 2020-Sep-07, Alvaro Herrera wrote: > > > > > Ah, it looks like we can get away with initializing the RRI to 0, and > > > then explicitly handle that case in ExecPartitionCheckEmitErro

Re: Logical Replication - detail message with names of missing columns

Thanks for the comments, v2 patch is attached. > > On Tue, Sep 8, 2020 at 6:50 AM Kyotaro Horiguchi > wrote: > > > > +1 for objective. However, that can be done simpler way that doesn't > > need additional loops by using bitmapset to hold missing remote > > attribute numbers. This also make the v

Re: Logical Replication - detail message with names of missing columns

On 2020-Sep-08, Bharath Rupireddy wrote: > + /* Find the remote attributes that are missing in the local relation. */ > + for (i = 0; i < remoterel->natts; i++) > + { > + if (!bms_is_member(i, localattnums)) > + { > + if (missingatts->len ==

Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ...

On Mon, 2020-09-07 at 11:42 -0300, Alvaro Herrera wrote: > > This patch would provide a more convenient way to do that. > > Again, I am not sure if that justifies the effort. > > I have to admit I've seen cases where it'd be useful to have included > columns in primary keys. > > TBH I think if we

Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ...

On 2020-Sep-08, Laurenz Albe wrote: > We should at least have > > ALTER TABLE ... ADD PRIMARY KEY (id) INCLUDE (val); > > or something before we consider this patch. Agreed. Now the trick in this new command is to let the user change the included columns afterwards, which remains useful (sin

Re: proposal - reference to plpgsql_check from plpgsql doc

po 17. 8. 2020 v 11:03 odesílatel Pavel Stehule napsal: > > > po 17. 8. 2020 v 10:37 odesílatel Magnus Hagander > napsal: > >> >> >> On Mon, Aug 17, 2020 at 8:47 AM Pavel Stehule >> wrote: >> >>> Hi >>> >>> plpgsql_check extension is almost complete now. This extension is >>> available on all e

Re: Use for name of unnamed portal's memory context

On 2020-09-05 17:10, Tom Lane wrote: Julien Rouhaud writes: +1 too, and obviously patch looks good. The adjacent comment needs updating. committed with that change -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Serv

Re: [POC] Fast COPY FROM command for the table with foreign partitions

On 2020-09-08 17:00, Amit Langote wrote: Hi Alexey, On Tue, Sep 8, 2020 at 6:29 PM Alexey Kondratov wrote: On 2020-09-08 10:34, Amit Langote wrote: > Any thoughts on the taking out the refactoring changes out of the main > patch as I suggested? > +1 for splitting the patch. It was rather diff

Re: Optimising compactify_tuples()

On Tue, 8 Sep 2020 at 12:08, Thomas Munro wrote: > > One thought is that if we're going to copy everything out and back in > again, we might want to consider doing it in a > memory-prefetcher-friendly order. Would it be a good idea to > rearrange the tuples to match line pointer order, so that th

Re: Optimising compactify_tuples()

On Mon, 7 Sep 2020 at 19:47, David Rowley wrote: > I wondered if we could get around that just by having another buffer > somewhere and memcpy the tuples into that first then copy the tuples > out that buffer back into the page. No need to worry about the order > we do that in as there's no chance

Re: Global snapshots

On 2020-09-08 14:48, Fujii Masao wrote: On 2020/09/08 19:36, Alexey Kondratov wrote: On 2020-09-08 05:49, Fujii Masao wrote: On 2020/09/05 3:31, Alexey Kondratov wrote: Attached is a patch, which implements a plain 2PC in the postgres_fdw and adds a GUC 'postgres_fdw.use_twophase'. Also it

Re: Logical Replication - detail message with names of missing columns

Thanks for the comments. Attaching the v3 patch. On Tue, Sep 8, 2020 at 8:19 PM Alvaro Herrera wrote: > > This looks a bit fiddly. Would it be less cumbersome to use > quote_identifier here instead? > Changed. quote_identifier() adds quotes wherever necessary. > > Please do use errmsg_plural -

Re: Nicer error when connecting to standby with hot_standby=off

On Tue, Aug 18, 2020 at 12:25 PM Fujii Masao wrote: > Thanks for updating the patch! But it failed to be applied to the master > branch > cleanly because of the recent commit 0038f94387. So could you update the patch > again? Updated patch attached. James v3-0001-Improve-standby-connection-de

Re: [DOC] Document concurrent index builds waiting on each other

On Fri, Jul 31, 2020 at 2:51 PM James Coleman wrote: > > On Thu, Jul 16, 2020 at 7:34 PM David Johnston > wrote: > > > > The following review has been posted through the commitfest application: > > make installcheck-world: not tested > > Implements feature: not tested > > Spec compliant:

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Sat, 2020-09-05 at 12:03 -0700, Peter Geoghegan wrote: > We should totally disable the preallocation stuff for external sorts > in any case. External sorts are naturally characterized by relatively > large, distinct batching of reads and writes -- preallocation cannot > help. Patch attached to

Re: PROC_IN_ANALYZE stillborn 13 years ago

On Sat, Aug 29, 2020 at 8:06 PM Tom Lane wrote: > > Alvaro Herrera writes: > > I pushed despite the objection because it seemed that downstream > > discussion was largely favorable to the change, and there's a different > > proposal to solve the bloat problem for analyze; and also: > > Note that

Re: Optimising compactify_tuples()

On Wed, Sep 9, 2020 at 3:47 AM David Rowley wrote: > On Tue, 8 Sep 2020 at 12:08, Thomas Munro wrote: > > One thought is that if we're going to copy everything out and back in > > again, we might want to consider doing it in a > > memory-prefetcher-friendly order. Would it be a good idea to > >

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-09-08 16:44:17 +1200, Thomas Munro wrote: > On Tue, Sep 8, 2020 at 4:11 PM Andres Freund wrote: > > At first I was very confused as to why none of the existing tests have > > found this significant issue. But after thinking about it for a minute > > that's because they all use psql, a

Re: Rare deadlock failure in create_am test

On 2020-09-04 12:41:23 -0400, Tom Lane wrote: > Alvaro Herrera writes: > > On 2020-Sep-03, Tom Lane wrote: > >> I'm inclined to think that the best fix is to put > >> > >> begin; > >> lock table [fast_emp4000]; > >> ... > >> commit; > >> > >> around the DROP CASCADE. > > > Yeah, sounds good. >

Re: [Patch] ALTER SYSTEM READ ONLY

Hi, On 2020-08-28 15:53:29 -0400, Robert Haas wrote: > On Wed, Aug 19, 2020 at 6:28 AM Amul Sul wrote: > > Attached is a rebased on top of the latest master head (# 3e98c0bafb2). > > Does anyone, especially anyone named Andres Freund, have comments on > 0001? That work is somewhat independent of

Re: Yet another fast GiST build

> > > Thanks! Did you measure the quality of the built index somehow? The > > ordering shouldn't make any difference to the build speed, but it > > affects the shape of the resulting index and the speed of queries > > against it. Again I've tried random select tests near axes and haven't noticed

Re: Autovac cancellation is broken in v14

Hi, On 2020-08-27 14:35:06 -0700, Andres Freund wrote: > On 2020-08-27 16:20:30 -0400, Jeff Janes wrote: > > On Thu, Aug 27, 2020 at 3:10 PM Jeff Janes wrote: > > > > > If I create a large table with "CREATE TABLE ... AS SELECT ... from > > > generate_series(1,3e7)" with no explicit transactions

VACUUM (INTERRUPTIBLE)?

Hi, Jeff Janes in [1] found that I ([2]) broke autovacuum cancellations. It obviously would be good to add a test for this, but it seems hard to have that be reliable given how long it can take for autovacuum actually get around to vacuum a specific table. That made me wonder if it'd be worthwhil

Re: More aggressive vacuuming of temporary tables

Hi, On 2020-08-28 11:46:49 -0400, Tom Lane wrote: > It strikes me that when we are vacuuming a temporary table (which > necessarily will be one of our own session), we don't really need > to care what the global xmin horizon is. If we're not inside a > user transaction block, then there are no tu

Re: Yet another fast GiST build

On 08/09/2020 21:33, Pavel Borisov wrote: > Thanks! Did you measure the quality of the built index somehow? The > ordering shouldn't make any difference to the build speed, but it > affects the shape of the resulting index and the speed of queries > against it. Again I've tri

Re: Missing "Up" navigation link between parts and doc root?

On Sun, Sep 6, 2020 at 04:59:11PM +0200, Peter Eisentraut wrote: > On 2020-08-25 21:48, Bruce Momjian wrote: > > On Sat, Jul 4, 2020 at 08:47:53AM +0200, Fabien COELHO wrote: > > > > > > Hello Peter, > > > > > > > The original stylesheets explicitly go out of their way to do it that > > > > way

Re: INSERT ON CONFLICT and RETURNING

út 8. 9. 2020 v 12:34 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 08.09.2020 12:34, Pavel Stehule wrote: > > > > út 8. 9. 2020 v 11:06 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > >> I have performed comparison of different ways of implem

Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

Hi, On 2020-07-29 22:26:04 -0500, David Pirotte wrote: > FWIW, we have been using pg_logical_emit_message to send application-level > events alongside our change-data-capture for about two years, and we would > move this part of our stack to pgoutput if message support was available. Yea, it's re

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-06-07 11:24:50 +0300, Michail Nikolaev wrote: > Hello, hackers. > Andres, nice work! > > Sorry for the off-top. > > Some of my work [1] related to the support of index hint bits on > standby is highly interfering with this patch. > Is it safe to consider it committed and start rebasi

Re: More aggressive vacuuming of temporary tables

Andres Freund writes: > But now I do wonder why we need to know whether the command is top level > or not? Why isn't the correct thing to instead look at what the current > backend's xmin is? Seems like you could just replace > *oldestXmin = XidFromFullTransactionId(ReadNextFullTransactionId()

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On Wed, Aug 19, 2020 at 3:16 AM Heikki Linnakangas wrote: > > On 01/05/2020 05:20, James Coleman wrote: > > On Tue, Apr 28, 2020 at 8:25 AM Tomas Vondra > > wrote: > > ... > >> Any particular reasons to pick dynahash over simplehash? ISTM we're > >> using simplehash elsewhere in the executor (gro

Re: PATCH: Attempt to make dbsize a bit more consistent

I found the function "table_relation_size" is only used by buffer manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and "RELKIND_MATVIEW", i.e.         case RELKIND_RELATION:         case RELKIND_TOASTVALUE:         case RELKIND_MATVIEW:             {                 /*                  *

Re: Boundary value check in lazy_tid_reaped()

On Tue, Sep 8, 2020 at 1:23 AM Masahiko Sawada wrote: > > > I wonder if you would also see a speed-up with a bsearch() replacement > > > that is inlineable, so it can inline the comparator (instead of > > > calling it through a function pointer). I wonder if something more > > > like (lblk << 32

Re: Collation versioning

Re: Julien Rouhaud > Here's the rationale for this new flag, extracted from the patch's commit > message: > > Add a new amnostablecollorder flag in IndexAmRoutine. > > This flag indicates if the access method does not rely on a stable collation > ordering for deterministic collation, i.e. would n

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

On Sat, Jul 18, 2020 at 03:15:32PM -0500, Justin Pryzby wrote: > Still waiting for feedback from a committer. This patch has been waiting for input from a committer on the approach I've taken with the patches since March 10, so I'm planning to set to "Ready" - at least ready for senior review. --

Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks

Bharath Rupireddy writes: > Attaching a patch with both the comments modification and changing > DEBUG3 to ERROR. make check and make world-check passes on this patch. I pushed this after simplifying the ereport down to an elog. I see no reason to consider this a user-facing error, so there's no

Re: Collation versioning

On Tue, Sep 08, 2020 at 09:33:26PM +0200, Christoph Berg wrote: > Re: Julien Rouhaud > > Here's the rationale for this new flag, extracted from the patch's commit > > message: > > > > Add a new amnostablecollorder flag in IndexAmRoutine. > > > > This flag indicates if the access method does not r

Re: default partition and concurrent attach partition

Hi, Andres added to CC because of TTS interface: apparently calling slot_getallattrs() on a virtual slot raises error that "getsomeattrs is not required to be called on a virtual tuple table slot". I'm thinking that this exposes implementation details that should not be necessary for a caller to

Re: VACUUM (INTERRUPTIBLE)?

On Tue, Sep 8, 2020 at 8:49 PM Andres Freund wrote: > Hi, > > Jeff Janes in [1] found that I ([2]) broke autovacuum cancellations. It > obviously would be good to add a test for this, but it seems hard to > have that be reliable given how long it can take for autovacuum actually > get around to v

Re: VACUUM (INTERRUPTIBLE)?

On 2020-Sep-08, Andres Freund wrote: > That made me wonder if it'd be worthwhile to add an option that'd make > user invoked VACUUM be interruptible by conflicting lock requests, just > like autovacuum is. Yeah, I recall a request for this in the past, too. > So how about adding an INTERRUPTIBLE

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On 08/09/2020 22:25, James Coleman wrote: On Wed, Aug 19, 2020 at 3:16 AM Heikki Linnakangas wrote: You could also apply the optimization for non-Const expressions, as long as they're stable (i.e. !contain_volatile_functions(expr)). Is that true? Don't we also have to worry about whether or

Re: Ideas about a better API for postgres_fdw remote estimates

On Tue, Sep 08, 2020 at 05:55:09PM +0530, Ashutosh Bapat wrote: On Fri, 4 Sep 2020 at 20:27, Tomas Vondra wrote 4) I wonder if we actually want/need to simply output pg_statistic data verbatim like this. Is postgres_fdw actually going to benefit from it? I kinda doubt that, and my assumption

Re: VACUUM (INTERRUPTIBLE)?

Hi, On 2020-09-08 17:36:00 -0300, Alvaro Herrera wrote: > On 2020-Sep-08, Andres Freund wrote: > > > That made me wonder if it'd be worthwhile to add an option that'd make > > user invoked VACUUM be interruptible by conflicting lock requests, just > > like autovacuum is. > > Yeah, I recall a req

SIGQUIT handling, redux

This is to pull together a couple of recent threads that are seemingly unrelated to $SUBJECT. Over in the long thread at [1] we've agreed to try to make the backend code actually do what assorted comments claim it does, namely allow SIGQUIT to be accepted at any point after a given process has est

Re: More aggressive vacuuming of temporary tables

Hi, On 2020-09-08 15:24:54 -0400, Tom Lane wrote: > Andres Freund writes: > > But now I do wonder why we need to know whether the command is top level > > or not? Why isn't the correct thing to instead look at what the current > > backend's xmin is? Seems like you could just replace > > *olde

Re: default partition and concurrent attach partition

On 2020-Sep-08, Alvaro Herrera wrote: > Andres added to CC because of TTS interface: apparently calling > slot_getallattrs() on a virtual slot raises error that "getsomeattrs is > not required to be called on a virtual tuple table slot". I'm thinking > that this exposes implementation details tha

Re: More aggressive vacuuming of temporary tables

Andres Freund writes: > On 2020-09-08 15:24:54 -0400, Tom Lane wrote: >> Andres Freund writes: >>> But now I do wonder why we need to know whether the command is top level >>> or not? Why isn't the correct thing to instead look at what the current >>> backend's xmin is? Seems like you could just

Re: VACUUM (INTERRUPTIBLE)?

Andres Freund writes: > So it doesn't seem that useful to not make manual analyze interruptible? I find the main attraction of this idea is that instead of saying "autovacuum/autoanalyze have these magic behaviors", we can say "autovacuum/autoanalyze use option FOO". So whatever behavior autoana

Re: default partition and concurrent attach partition

On 2020-Sep-08, Amit Langote wrote: > Yeah, we need to make sure that ExecPartitionCheck gets a slot whose > TupleDesc matches the partition's. Actually we do have such dedicated > slots for partitions around (for both sub-partitioned and leaf > partitions), so we can simply use them instead of c

Re: VACUUM (INTERRUPTIBLE)?

Hi, On 2020-09-08 22:30:40 +0200, Magnus Hagander wrote: > One thing I've been wanting many times but never properly got around to > investigating how much work it would be to make happen, was to be able to > trigger an autovacuum manually (yeah, strange choice of terms). That is, > instead of the

Re: WIP: WAL prefetch (another approach)

On Sat, Sep 05, 2020 at 12:05:52PM +1200, Thomas Munro wrote: On Wed, Sep 2, 2020 at 2:18 AM Tomas Vondra wrote: On Wed, Sep 02, 2020 at 02:05:10AM +1200, Thomas Munro wrote: >On Wed, Sep 2, 2020 at 1:14 AM Tomas Vondra > wrote: >> from the archive > >Ahh, so perhaps that's the key. Maybe. For

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Thu, Sep 03, 2020 at 09:43:51PM -0500, Justin Pryzby wrote: > And rebased on Michael's commit removing ReindexStmt->concurrent. Rebased on a6642b3ae: Add support for partitioned tables and indexes in REINDEX So now this includes the new functionality and test for reindexing a partitioned table

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On 2020-Sep-08, Justin Pryzby wrote: > From 992e0121925c74d5c5a4e5b132cddb3d6b31da86 Mon Sep 17 00:00:00 2001 > From: Justin Pryzby > Date: Fri, 27 Mar 2020 17:50:46 -0500 > Subject: [PATCH v27 1/5] Change REINDEX/CLUSTER to accept an option list.. > > ..like EXPLAIN (..), VACUUM (..), and ANALY

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Tue, Sep 08, 2020 at 09:02:38PM -0300, Alvaro Herrera wrote: > On 2020-Sep-08, Justin Pryzby wrote: > > > From 992e0121925c74d5c5a4e5b132cddb3d6b31da86 Mon Sep 17 00:00:00 2001 > > From: Justin Pryzby > > Date: Fri, 27 Mar 2020 17:50:46 -0500 > > Subject: [PATCH v27 1/5] Change REINDEX/CLUSTER

Re: Implementing Incremental View Maintenance

Hi Thomas, Thank you for your comment! On Sat, 5 Sep 2020 17:56:18 +1200 Thomas Munro wrote: > + /* > +* Wait for concurrent transactions which update this materialized view at > +* READ COMMITED. This is needed to see changes committed in other > +* transactions. No wait and raise

Re: default partition and concurrent attach partition

On Wed, Sep 9, 2020 at 7:41 AM Alvaro Herrera wrote: > On 2020-Sep-08, Amit Langote wrote: > > > Yeah, we need to make sure that ExecPartitionCheck gets a slot whose > > TupleDesc matches the partition's. Actually we do have such dedicated > > slots for partitions around (for both sub-partitioned

Re: file_fdw vs relative paths

Hi On 2020/09/07 2:31, Magnus Hagander wrote: On Mon, Aug 31, 2020 at 5:03 PM Bruce Momjian mailto:br...@momjian.us>> wrote: On Mon, Aug 31, 2020 at 01:16:05PM +0200, Magnus Hagander wrote: >     Bruce, I've applied and backpatched your docs patch for this. > > Gah, and of co

Re: Implementing Incremental View Maintenance

On Wed, Sep 9, 2020 at 12:29 PM Yugo NAGATA wrote: > I also thought it might be resolved using tuple locks and EvalPlanQual > instead of table level lock, but there is still a unavoidable case. For > example, suppose that tuple dR is inserted into R in T1, and dS is inserted > into S in T2. Also,

Re: VACUUM (INTERRUPTIBLE)?

Hi, On 2020-09-08 18:37:05 -0400, Tom Lane wrote: > Andres Freund writes: > > So it doesn't seem that useful to not make manual analyze interruptible? > > I find the main attraction of this idea is that instead of saying > "autovacuum/autoanalyze have these magic behaviors", we can say > "autova

Re: Inconsistency in determining the timestamp of the db statfile.

On Tue, Sep 8, 2020 at 7:03 PM Magnus Hagander wrote: > > On Tue, Sep 8, 2020 at 3:11 PM Fujii Masao > wrote: >> >> >> >> On 2020/09/08 19:28, Magnus Hagander wrote: >> > >> > >> > On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila > > > wrote: >> > >> > We use the ti

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Sep 7, 2020 at 12:57 PM Dilip Kumar wrote: > > On Mon, Sep 7, 2020 at 12:00 PM Amit Kapila wrote: >> >> On Sat, Sep 5, 2020 at 8:55 PM Dilip Kumar wrote: >> > >> > >> > I have reviewed the changes and looks fine to me. >> > >> >> Thanks, I have pushed the last patch. Let's wait for a day

Re: Two fsync related performance issues?

On Thu, Sep 3, 2020 at 11:30 AM Thomas Munro wrote: > On Wed, May 27, 2020 at 12:31 AM Craig Ringer wrote: > > On Tue, 12 May 2020, 08:42 Paul Guo, wrote: > >> 1. StartupXLOG() does fsync on the whole data directory early in the crash > >> recovery. I'm wondering if we could skip some directori

Re: v13: CLUSTER segv with wal_level=minimal and parallel index creation

On Mon, Sep 07, 2020 at 07:47:09PM -0700, Noah Misch wrote: > On Tue, Sep 08, 2020 at 10:43:32AM +0900, Kyotaro Horiguchi wrote: > > At Tue, 08 Sep 2020 09:13:53 +0900 (JST), Kyotaro Horiguchi > > wrote in > > > At Mon, 7 Sep 2020 02:32:55 -0700, Noah Misch wrote > > > in > > > > As a PoC, th

Re: VACUUM (INTERRUPTIBLE)?

Hi, On 2020-09-08 19:30:40 -0700, Andres Freund wrote: > It was fairly straight forward to implement the basics of > INTERRUPTIBLE. However it seems like it might not actually address my > main concern, i.e. making this reliably testable with isolation > tester. At least not the way I envisioned i

Re: Ideas about a better API for postgres_fdw remote estimates

On Wed, 9 Sep 2020 at 02:35, Tomas Vondra wrote > > I think that was the topic of *this* thread as started by Tom, but I now > realize Andrey steered it in the direction to allow re-using remote > stats. Which seems useful too, but it confused me a bit. > I didn't realize that the nearby thread

  1   2   >