Re: Improving spin-lock implementation on ARM.

Alexander Korotkov writes: > On Fri, Nov 27, 2020 at 1:55 AM Tom Lane wrote: >> ... and, after retrieving my jaw from the floor, I present the >> attached. Apple's chips evidently like this style of spinlock a LOT >> better. The difference is so remarkable that I wonder if I made a >> mistake

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

On Fri, Nov 27, 2020 at 12:26 PM Fujii Masao wrote: > > > > > When I read the patch again, I found that, with the patch, the shutdown > > > > of worker_spi causes to report the following FATAL message. > > > > > > > > FATAL: terminating connection due to administrator command > > > > >

Re: Multi Inserts in CREATE TABLE AS - revived patch

On Fri, Nov 27, 2020 at 12:22 PM Luc Vlaming wrote: > > > > > I wonder, how can the do_multi_insert() API decide on when to flush, I > > mean, based on the number of pages to flush? Do we need to pass the > > maximum number of pages the buffered tuples can occupy and track the > > pages currently

Re: Parallel Inserts in CREATE TABLE AS

On 25-11-2020 03:40, Bharath Rupireddy wrote: On Tue, Nov 24, 2020 at 4:43 PM Hou, Zhijie wrote: I'm very interested in this feature, and I'm looking at the patch, here are some comments. Thanks for the review. How about the following style:

Re: Improving spin-lock implementation on ARM.

On Fri, Nov 27, 2020 at 2:20 AM Tom Lane wrote: > Alexander Korotkov writes: > > On Thu, Nov 26, 2020 at 1:32 PM Heikki Linnakangas wrote: > >> Is there some official ARM documentation, like a programmer's reference > >> manual or something like that, that would show a reference > >>

Re: Improving spin-lock implementation on ARM.

On Fri, Nov 27, 2020 at 1:55 AM Tom Lane wrote: > > Krunal Bauskar writes: > > On Thu, 26 Nov 2020 at 10:50, Tom Lane wrote: > >> Also, exactly what hardware/software platform were these curves > >> obtained on? > > > Hardware: ARM Kunpeng 920 BareMetal Server 2.6 GHz. 64 cores (56 cores for >

RE: Disable WAL logging to speed up data loading

From: Masahiko Sawada > While testing the patch on some workload, I realized that > XLOG_FPI_FOR_HINT record could still be emitted even when wal_level = > none. IIUC that WAL record is not necessary during wal_level = none > since the server cannot be the primary server and the server crash >

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

On 2020/11/27 12:13, Bharath Rupireddy wrote: On Wed, Nov 25, 2020 at 8:08 PM Bharath Rupireddy mailto:bharath.rupireddyforpostg...@gmail.com>> wrote: > > > When I read the patch again, I found that, with the patch, the shutdown > > of worker_spi causes to report the following FATAL

Re: Parallel plans and "union all" subquery

On 27-11-2020 04:14, Greg Nancarrow wrote: On Thu, Nov 26, 2020 at 6:11 PM Luc Vlaming wrote: If interesting I can make a draft of what this would look like if this makes it easier to discuss? Sure, that would help clarify it. Okay. I will try to build an example but this will take a few

Re: Parallel Inserts in CREATE TABLE AS

On Fri, Nov 27, 2020 at 11:57 AM Hou, Zhijie wrote: > > > Thanks a lot for the use case. Yes with the current patch table will lose > > data related to the subplan. On analyzing further, I think we can not allow > > parallel inserts in the cases when the Gather node has some projections > > to

Re: Multi Inserts in CREATE TABLE AS - revived patch

On 26-11-2020 14:45, Bharath Rupireddy wrote: On Thu, Nov 26, 2020 at 5:34 PM Luc Vlaming wrote: On 26-11-2020 12:36, Bharath Rupireddy wrote: Few things: IIUC Andres mentioned similar kinds of APIs earlier in [1]. [1] -

Re: Disable WAL logging to speed up data loading

At Fri, 27 Nov 2020 15:07:34 +0900, Masahiko Sawada wrote in > On Tue, Nov 24, 2020 at 11:19 AM osumi.takami...@fujitsu.com > wrote: > > > > Hi > > > > On Monday, Nov 23, 2020 12:17 PM Tsunakawa, Takayuki > > wrote: > > > PREPARE TRANSACTION is the same as COMMIT in that it persists > > >

RE: Parallel Inserts in CREATE TABLE AS

Hi, > > I took a deep look at the projection logic. > > In most cases, you are right that Gather node does not need projection. > > > > In some rare cases, such as Subplan (or initplan I guess). > > The projection will happen in Gather node. > > > > The example: > > > > Create table test(i int);

Re: Disable WAL logging to speed up data loading

On Tue, Nov 24, 2020 at 11:19 AM osumi.takami...@fujitsu.com wrote: > > Hi > > On Monday, Nov 23, 2020 12:17 PM Tsunakawa, Takayuki > wrote: > > PREPARE TRANSACTION is the same as COMMIT in that it persists > > transaction updates. A crash during wal_level = none loses both of them. > > So, I

Re: [Patch] Optimize dropping of relation buffers using dlist

At Fri, 27 Nov 2020 02:19:57 +, "k.jami...@fujitsu.com" wrote in > > From: Kyotaro Horiguchi > > Hello, Kirk. Thank you for the new version. > > Hi, Horiguchi-san. Thank you for your very helpful feedback. > I'm updating the patches addressing those. > > > + if

RE: POC: postgres_fdw insert batching

From: Craig Ringer > But in the libpq pipelining patch I demonstrated a 300 times (3000%) > performance improvement on a test workload... Wow, impressive number. I've just seen it in the beginning of the libpq pipelining thread (oh, already four years ago..!) Could you share the workload

Re: Add Information during standby recovery conflicts

On Thu, Nov 26, 2020 at 12:49 AM Drouvot, Bertrand wrote: > > Hi, > > On 11/25/20 2:20 PM, Masahiko Sawada wrote: > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you can confirm the sender and know > > the content is safe. >

Re: POC: postgres_fdw insert batching

On Fri, Nov 27, 2020 at 10:47 AM tsunakawa.ta...@fujitsu.com < tsunakawa.ta...@fujitsu.com> wrote: Covering this one first: I expect postgresExecForeignBatchInsert() would be able to use the libpq > batching API, because it receives an array of tuples and can generate and > issue INSERT

Re: Parallel plans and "union all" subquery

On Thu, Nov 26, 2020 at 6:11 PM Luc Vlaming wrote: > > If interesting I can make a draft of what this would look like if this > makes it easier to discuss? > Sure, that would help clarify it. I did debug this a bit, but it seems my gut feeling was wrong, even though it knows a type coercion is

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

On Wed, Nov 25, 2020 at 8:08 PM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > > > When I read the patch again, I found that, with the patch, the shutdown > > of worker_spi causes to report the following FATAL message. > > > > FATAL: terminating connection due to

Re: Allow some recovery parameters to be changed with reload

At Fri, 27 Nov 2020 09:48:25 +0900, Fujii Masao wrote in > > > On 2020/11/27 9:30, Kyotaro Horiguchi wrote: > > At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao > > wrote in > >> > >> > >> On 2020/11/12 4:38, Sergei Kornilov wrote: > >>> Hello > >>> > Anyway, for now I think that your

RE: POC: postgres_fdw insert batching

From: Tomas Vondra > Not sure how is this related to app developers? I think the idea was > that the libpq features might be useful between the two PostgreSQL > instances. I.e. the postgres_fdw would use the libpq batching to send > chunks of data to the other side. > Well, my point was that we

Re: Hybrid Hash/Nested Loop joins and caching results from subplans

On Fri, Nov 27, 2020 at 8:10 AM David Rowley wrote: > Thanks for having another look at this. > > > On Sun, Nov 22, 2020 at 9:21 PM Andy Fan > wrote: > > add 2 more comments. > > > > 1. I'd suggest adding Assert(false); in RC_END_OF_SCAN case to make the > error clearer. > > > > case

Re: Add table access method as an option to pgbench

Thanks Fabien for the comments. On 2020-11-25 11:29 p.m., Fabien COELHO wrote: Hello David, The previous patch was based on branch "REL_13_STABLE". Now, the attached new patch v2 is based on master branch. I followed the new code structure using appendPQExpBuffer to append the new clause

Re: Add table access method as an option to pgbench

Thanks a lot again for the review and comments. On 2020-11-25 9:36 p.m., Michael Paquier wrote: On Wed, Nov 25, 2020 at 12:13:55PM -0800, David Zhang wrote: The previous patch was based on branch "REL_13_STABLE". Now, the attached new patch v2 is based on master branch. I followed the new code

RE: [Patch] Optimize dropping of relation buffers using dlist

> From: Kyotaro Horiguchi > Hello, Kirk. Thank you for the new version. Hi, Horiguchi-san. Thank you for your very helpful feedback. I'm updating the patches addressing those. > + if (!smgrexists(rels[i], j)) > + continue; > + > +

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Wed, Nov 25, 2020 at 12:13 AM Alexey Kondratov wrote: > > 1) Return 'true' if there were open connections and we successfully > closed them. > 2) Return 'false' in the no-op case, i.e. there were no open > connections. > 3) Rise an error if something went wrong. And non-existing server case >

Re: POC: postgres_fdw insert batching

On Fri, Nov 27, 2020 at 3:34 AM Tomas Vondra wrote: > Not sure how is this related to app developers? I think the idea was > that the libpq features might be useful between the two PostgreSQL > instances. I.e. the postgres_fdw would use the libpq batching to send > chunks of data to the other

Re: Allow some recovery parameters to be changed with reload

On 2020/11/27 9:30, Kyotaro Horiguchi wrote: At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao wrote in On 2020/11/12 4:38, Sergei Kornilov wrote: Hello Anyway, for now I think that your first patch would be enough, i.e., just change the context of restore_command to PGC_SIGHUP. Glad

Re: Allow some recovery parameters to be changed with reload

At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao wrote in > > > On 2020/11/12 4:38, Sergei Kornilov wrote: > > Hello > > > >> Anyway, for now I think that your first patch would be enough, i.e., > >> just change the context of restore_command to PGC_SIGHUP. > > Glad to hear. Attached a

Re: Rename of triggers for partitioned tables

I'm sorry for the spam. Here a patch with updated comments, I missed one before. Regards Arne From: Arne Roland Sent: Friday, November 27, 2020 1:05:02 AM To: Pg Hackers Subject: Re: Rename of triggers for partitioned tables I'm too unhappy with the

Re: Hybrid Hash/Nested Loop joins and caching results from subplans

Thanks for having another look at this. > On Sun, Nov 22, 2020 at 9:21 PM Andy Fan wrote: > add 2 more comments. > > 1. I'd suggest adding Assert(false); in RC_END_OF_SCAN case to make the > error clearer. > > case RC_END_OF_SCAN: > /* > * We've already returned NULL for this scan, but just in

Re: Rename of triggers for partitioned tables

I'm too unhappy with the interface change, so please view attached patch instead. Regards Arne From: Arne Roland Sent: Friday, November 27, 2020 12:28:31 AM To: Pg Hackers Subject: Rename of triggers for partitioned tables Hello, I got too annoyed at

Re: [PoC] Non-volatile WAL buffer

On 11/26/20 10:19 PM, Tomas Vondra wrote: > > > On 11/26/20 9:59 PM, Heikki Linnakangas wrote: >> On 26/11/2020 21:27, Tomas Vondra wrote: >>> Hi, >>> >>> Here's the "simple patch" that I'm currently experimenting with. It >>> essentially replaces open/close/write/fsync with pmem calls >>>

Rename of triggers for partitioned tables

Hello, I got too annoyed at building queries for gexec all the time. So wrote a patch to fix the issue that the rename of partitioned trigger doesn't affect children. In case there isn't a dependent trigger with the same name on the child the function errors out. If the user touched the

Re: Improving spin-lock implementation on ARM.

Alexander Korotkov writes: > On Thu, Nov 26, 2020 at 1:32 PM Heikki Linnakangas wrote: >> Is there some official ARM documentation, like a programmer's reference >> manual or something like that, that would show a reference >> implementation of a spinlock on ARM? It would be good to refer to an

Re: pgbench and timestamps (bounced)

CFM reminder. Hi, this entry is "Waiting on Author" and the thread was inactive for a while. I see this discussion still has some open questions. Are you going to continue working on it, or should I mark it as "returned with feedback" until a better time? IMHO the proposed fix is

Re: Improving spin-lock implementation on ARM.

Krunal Bauskar writes: > On Thu, 26 Nov 2020 at 10:50, Tom Lane wrote: >> Also, exactly what hardware/software platform were these curves >> obtained on? > Hardware: ARM Kunpeng 920 BareMetal Server 2.6 GHz. 64 cores (56 cores for > server and 8 for client) [2 numa nodes] > Storage: 3.2 TB NVMe

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On 2020-Nov-26, Alvaro Herrera wrote: > So let's discuss the next step in this series: what to do about REINDEX > CONCURRENTLY. > [...] ... as in the attached. diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c index ca24620fd0..9c1c0aad3e 100644 ---

Re: [PoC] Non-volatile WAL buffer

On 11/26/20 9:59 PM, Heikki Linnakangas wrote: > On 26/11/2020 21:27, Tomas Vondra wrote: >> Hi, >> >> Here's the "simple patch" that I'm currently experimenting with. It >> essentially replaces open/close/write/fsync with pmem calls >> (map/unmap/memcpy/persist variants), and it's by no means

Re: [PoC] Non-volatile WAL buffer

Hi, Here's the "simple patch" that I'm currently experimenting with. It essentially replaces open/close/write/fsync with pmem calls (map/unmap/memcpy/persist variants), and it's by no means committable. But it works well enough for experiments / measurements, etc. The numbers (5-minute pgbench

Re: [PoC] Non-volatile WAL buffer

On 26/11/2020 21:27, Tomas Vondra wrote: Hi, Here's the "simple patch" that I'm currently experimenting with. It essentially replaces open/close/write/fsync with pmem calls (map/unmap/memcpy/persist variants), and it's by no means committable. But it works well enough for experiments /

Re: remove spurious CREATE INDEX CONCURRENTLY wait

So let's discuss the next step in this series: what to do about REINDEX CONCURRENTLY. I started with Dmitry's patch (an updated version of which I already posted in [1]). However, Dmitry missed (and I hadn't noticed) that some of the per-index loops are starting transactions also, and that we

Re: POC: postgres_fdw insert batching

On 11/26/20 2:48 AM, tsunakawa.ta...@fujitsu.com wrote: > From: Tomas Vondra >> Well, good that we all agree this is a useful feature to have (in >> general). The question is whether postgres_fdw should be doing >> batching on it's onw (per this thread) or rely on some other >> feature

Re: [PATCH] Covering SPGiST index

> > > The way that seems acceptable to me is to add (optional) nulls mask into > > the end of existing style SpGistLeafTuple header and use indextuple > > routines to attach attributes after it. In this case, we can reduce the > > amount of code at the cost of adding one extra MAXALIGN size to the

Re: [patch] CLUSTER blocks scanned progress reporting

On 2020/11/27 1:45, Matthias van de Meent wrote: On Thu, 26 Nov 2020 at 00:55, Fujii Masao wrote: +* A heap scan need not return tuples for the last page it has +* scanned. To ensure that heap_blks_scanned is equivalent to +

Re: configure and DocBook XML

=?utf-8?Q?Paul_F=C3=B6rster?= writes: > On 26. Nov, 2020, at 17:21, Tom Lane wrote: >> There's a nearby thread in which I was suggesting that we should just >> not bother with this configure test [1]. >> [1] >>

Re: [patch] CLUSTER blocks scanned progress reporting

On Thu, 26 Nov 2020 at 00:55, Fujii Masao wrote: > > +* A heap scan need not return tuples for the > last page it has > +* scanned. To ensure that heap_blks_scanned > is equivalent to > +*

Re: autovac issue with large number of tables

On 2020/11/26 10:41, Kasahara Tatsuhito wrote: On Wed, Nov 25, 2020 at 8:46 PM Masahiko Sawada wrote: On Wed, Nov 25, 2020 at 4:18 PM Kasahara Tatsuhito wrote: Hi, On Wed, Nov 25, 2020 at 2:17 PM Masahiko Sawada wrote: On Fri, Sep 4, 2020 at 7:50 PM Kasahara Tatsuhito wrote: Hi,

Re: configure and DocBook XML

Hi Tom, > On 26. Nov, 2020, at 17:21, Tom Lane wrote: > > On machines where I don't have the stylesheets installed, it always > takes several seconds (2 or 3, I think, though I've not put a stopwatch > on it). 15 to 20 sec does seem like a lot, so it makes me wonder if > Paul's network

Re: Improper use about DatumGetInt32

On 2020-11-26 14:27, Alvaro Herrera wrote: On 2020-Nov-26, Peter Eisentraut wrote: The point of the patch is to have the range check somewhere. If you just cast it, then you won't notice out of range arguments. Note that other contrib modules that take block numbers work the same way. I'm

Re: configure and DocBook XML

Alvaro Herrera writes: > On 2020-Nov-26, Paul Förster wrote: >> On 26. Nov, 2020, at 14:47, Alvaro Herrera wrote: >>> My guess is that it's related to trying to obtain stylesheets from >>> remote Internet locations that are missing locally. >> I don't know DocBook at all, so I can't say. But it

Re: proposal: possibility to read dumped table's name from file

Dean Rasheed writes: > Actually, that raises a different possible benefit of passing options > in an options file -- if the user wants to pass in a table name > pattern, it can be a nuisance if the shell's argument processing does > additional unwanted things like globbing and environment

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On 2020-Nov-25, Alvaro Herrera wrote: > On 2020-Nov-23, Andres Freund wrote: > > > On 2020-11-23 12:30:05 -0300, Alvaro Herrera wrote: > > > > In other words, my conclusion is that there definitely is a bug here and > > > I am going to restore the use of exclusive lock for setting the > > >

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

On 2020/11/27 0:15, Bharath Rupireddy wrote: On Thu, Nov 26, 2020 at 7:37 PM Fujii Masao wrote: What do you mean by normal shutdown of bgworker? Is it that bgworker has exited successfully with exit code 0 or for some reason with exit code other than 0? Or is it when the postmaster is

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

On Thu, Nov 26, 2020 at 7:37 PM Fujii Masao wrote: > > > What do you mean by normal shutdown of bgworker? Is it that bgworker has > > exited successfully with exit code 0 or for some reason with exit code > > other than 0? Or is it when the postmaster is shutdown normally? > > > > IIUC, when a

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

This patch has stopped moving for a while, any suggestion about how to move on is appreciated. -- Best Regards Andy Fan

Re: configure and DocBook XML

Hi Alvaro, > On 26. Nov, 2020, at 15:19, Alvaro Herrera wrote: > > One way to know for sure would be to run it under strace, and see where > it takes a large number of seconds. Maybe something like > strace -f -etrace=%network -T -tt -o/tmp/configure.trace ./configure ok, I'll try this.

Re: configure and DocBook XML

On 2020-Nov-26, Paul Förster wrote: > Hi Alvaro, > > > On 26. Nov, 2020, at 14:47, Alvaro Herrera wrote: > > > > My guess is that it's related to trying to obtain stylesheets from > > remote Internet locations that are missing locally. > > I don't know DocBook at all, so I can't say. But it

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

On 2020/11/25 23:38, Bharath Rupireddy wrote: On Wed, Nov 25, 2020 at 3:29 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote: > > On 2020/11/20 19:33, Bharath Rupireddy wrote: > > On Wed, Nov 18, 2020 at 5:52 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>

Re: configure and DocBook XML

Hi Alvaro, > On 26. Nov, 2020, at 14:47, Alvaro Herrera wrote: > > My guess is that it's related to trying to obtain stylesheets from > remote Internet locations that are missing locally. I don't know DocBook at all, so I can't say. But it takes about the same time, whether I run configure on

Re: configure and DocBook XML

On 2020-Nov-26, Paul Förster wrote: > Hi, > > I always compile PostgreSQL from source and never install a pre-compiled > package. When I run configure, the last check, which is for DocBook XML > always takes very long compared to all others. It's about 15 to 20 secs or > so. I noticed that

Re: Multi Inserts in CREATE TABLE AS - revived patch

On Thu, Nov 26, 2020 at 5:34 PM Luc Vlaming wrote: > > On 26-11-2020 12:36, Bharath Rupireddy wrote: > > Few things: > > > > IIUC Andres mentioned similar kinds of APIs earlier in [1]. > > > > [1] - > > https://www.postgresql.org/message-id/20200924024128.kyk3r5g7dnu3fxxx%40alap3.anarazel.de > >

Re: Allow some recovery parameters to be changed with reload

On 2020/11/12 4:38, Sergei Kornilov wrote: Hello Anyway, for now I think that your first patch would be enough, i.e., just change the context of restore_command to PGC_SIGHUP. Glad to hear. Attached a rebased version of the original proposal. Thanks for rebasing the patch! This

Re: Improper use about DatumGetInt32

On 2020-Nov-26, Peter Eisentraut wrote: > The point of the patch is to have the range check somewhere. If you just > cast it, then you won't notice out of range arguments. Note that other > contrib modules that take block numbers work the same way. I'm not saying not to do that; just saying we

Re: libpq compression

Hi, > On Nov 24, 2020, at 11:35 PM, Robert Haas wrote: > > So the time to talk about the > general approach here is now, before anything gets committed, before > the project has committed itself to any particular design. If we > decide in that discussion that certain things can be left for the

Re: cleanup temporary files after crash

On Thu, 26 Nov 2020 at 05:48, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > > I also think that the GUC is not needed here. This 'feature' was > internal from the very beginning, so users shouldn't care about > preserving old behavior. Without the GUC the patch is very simple, >

Re: Improper use about DatumGetInt32

On 2020-11-25 20:04, Alvaro Herrera wrote: On 2020-Nov-25, Peter Eisentraut wrote: bt_page_stats(PG_FUNCTION_ARGS) { text *relname = PG_GETARG_TEXT_PP(0); - uint32 blkno = PG_GETARG_UINT32(1); + int64 blkno = PG_GETARG_INT64(1); As a matter of

Re: Improving spin-lock implementation on ARM.

On Thu, 26 Nov 2020 at 16:02, Heikki Linnakangas wrote: > On 26/11/2020 06:30, Krunal Bauskar wrote: > > Improving spin-lock implementation on ARM. > > > > > > * Spin-Lock is known to have a significant effect on performance > >

Re: [PATCH] Add features to pg_stat_statements

On 2020/11/25 17:07, Fujii Masao wrote: On 2020/11/25 15:40, Seino Yuki wrote: 2020-11-25 13:13 に Fujii Masao さんは書きました: On 2020/11/25 12:02, Seino Yuki wrote: 2020-11-17 01:46 に Fujii Masao さんは書きました: On 2020/11/16 12:22, Seino Yuki wrote: Thanks for updating the patch! +   

Re: Multi Inserts in CREATE TABLE AS - revived patch

On 26-11-2020 12:36, Bharath Rupireddy wrote: Few things: IIUC Andres mentioned similar kinds of APIs earlier in [1]. [1] - https://www.postgresql.org/message-id/20200924024128.kyk3r5g7dnu3fxxx%40alap3.anarazel.de

Re: proposal: possibility to read dumped table's name from file

On Thu, 26 Nov 2020 at 06:43, Pavel Stehule wrote: > > st 25. 11. 2020 v 21:00 odesílatel Tom Lane napsal: >> >> (One thing to consider is >> how painful will it be for people to quote table names containing >> funny characters, for instance. On the command line, we largely >> depend on the

Re: [HACKERS] logical decoding of two-phase transactions

On Thu, Nov 26, 2020 at 4:24 PM Ajin Cherian wrote: > > On Wed, Nov 25, 2020 at 11:54 PM Amit Kapila wrote: > > > One problem with this patch is: What if we have assembled a consistent > > snapshot after prepare and before commit prepared. In that case, it > > will currently just send commit

Re: Multi Inserts in CREATE TABLE AS - revived patch

Few things: IIUC Andres mentioned similar kinds of APIs earlier in [1]. [1] - https://www.postgresql.org/message-id/20200924024128.kyk3r5g7dnu3fxxx%40alap3.anarazel.de I would like to add some more info to one of the API: typedef struct MultiInsertStateData { MemoryContext

Re: Improving spin-lock implementation on ARM.

On Thu, Nov 26, 2020 at 1:32 PM Heikki Linnakangas wrote: > On 26/11/2020 06:30, Krunal Bauskar wrote: > > Improving spin-lock implementation on ARM. > > > > > > * Spin-Lock is known to have a significant effect on performance > >

Re: Multi Inserts in CREATE TABLE AS - revived patch

On Thu, Nov 26, 2020 at 12:25 PM Luc Vlaming wrote: > > What I'm wondering about is the reason for wanting a cap on data volume. > When doing some local (highly concurrent) ingest speed tests a few weeks > ago it seemed to mostly matter how many pages were being written and the > resulting

Re: [HACKERS] logical decoding of two-phase transactions

On Wed, Nov 25, 2020 at 11:54 PM Amit Kapila wrote: > One problem with this patch is: What if we have assembled a consistent > snapshot after prepare and before commit prepared. In that case, it > will currently just send commit prepared record which would be a bad > idea. It should decode the

Re: [Proposal] Global temporary tables

On Thu, Nov 26, 2020 at 11:16 AM Julien Rouhaud wrote: > > On Thu, Nov 26, 2020 at 4:05 PM 曾文旌 wrote: > > > > I found that the new Patch mail failed to register to Commitfest > > https://commitfest.postgresql.org/28/2349/# > > I don't know what's wrong and how to check it? > > Could you help me

Re: Improving spin-lock implementation on ARM.

On 26/11/2020 06:30, Krunal Bauskar wrote: Improving spin-lock implementation on ARM. * Spin-Lock is known to have a significant effect on performance   with increasing scalability. * Existing Spin-Lock implementation for ARM is

Re: [Proposal] Global temporary tables

On Thu, Nov 26, 2020 at 4:05 PM 曾文旌 wrote: > > I found that the new Patch mail failed to register to Commitfest > https://commitfest.postgresql.org/28/2349/# > I don't know what's wrong and how to check it? > Could you help me figure it out? Apparently the attachment in

Re: fixing old_snapshot_threshold's time->xid mapping

On 06.10.2020 08:32, Thomas Munro wrote: On Fri, Sep 25, 2020 at 2:00 PM Michael Paquier wrote: On Thu, Sep 24, 2020 at 03:46:14PM -0400, Robert Haas wrote: Thomas, with respect to your part of this patch set, I wonder if we can make the functions that you're using to write tests safe enough

Re: Parallel Inserts in CREATE TABLE AS

On Thu, Nov 26, 2020 at 12:15 PM Hou, Zhijie wrote: > > I took a deep look at the projection logic. > In most cases, you are right that Gather node does not need projection. > > In some rare cases, such as Subplan (or initplan I guess). > The projection will happen in Gather node. > > The

configure and DocBook XML

Hi, I always compile PostgreSQL from source and never install a pre-compiled package. When I run configure, the last check, which is for DocBook XML always takes very long compared to all others. It's about 15 to 20 secs or so. I noticed that with many configure scripts, not only the one of

Re: ResourceOwner refactoring

At Thu, 19 Nov 2020 17:27:18 +0800, Julien Rouhaud wrote in > On Thu, Nov 19, 2020 at 10:16 AM Michael Paquier wrote: > > > > On Wed, Nov 18, 2020 at 10:50:08AM +0200, Heikki Linnakangas wrote: > > > If RESOWNER_ARRAY_STATS is increased to 16, all the lookups fit in the > > > array. But I

Re: cleanup temporary files after crash

On 01.11.2020 04:25, Michael Paquier wrote: On Sat, Oct 31, 2020 at 09:01:15PM -0300, Euler Taveira wrote: I thought about not providing a GUC at all or provide it in the developer section. I've never heard someone saying that they use those temporary files to investigate an issue. Regarding a

Re: POC: Cleaning up orphaned files using undo logs

Amit Kapila wrote: > On Wed, Nov 25, 2020 at 8:00 PM Antonin Houska wrote: > > I meant that AbortOutOfAnyTransaction should PANIC itself if it sees that > > there is unapplied undo, so nothing changes for its callers. Do I still miss > > something? > > > > Adding PANIC in some generic

Re: POC: Cleaning up orphaned files using undo logs

Amit Kapila wrote: > On Wed, Nov 25, 2020 at 7:47 PM Antonin Houska wrote: > > > > Antonin Houska wrote: > > > > > Amit Kapila wrote: > > > > > > I think we also need to maintain oldestXidHavingUndo for CLOG > > > > truncation and > > > > transaction-wraparound. We can't allow CLOG

Re: Online verification of checksums

On Thu, Nov 26, 2020 at 8:42 AM Michael Paquier wrote: > > On Tue, Nov 24, 2020 at 12:38:30PM -0500, David Steele wrote: > > We are not just looking at one LSN value. Here are the steps we are > > proposing (I'll skip checks for zero pages here): > > > > 1) Test the page checksum. If it passes

Re: OpenSSL 3.0.0 compatibility

On Tue, Sep 29, 2020 at 12:25:05PM +0200, Daniel Gustafsson wrote: > The attached adds config loading to pgcrypto for < 1.1.0 and a doc notice for > enabling the legacy provider in 3.0.0. This will require an alternative > output > file for non-legacy configs, but that should wait until 3.0.0 is

Re: Enumize logical replication message actions

On Thu, Nov 26, 2020 at 10:15 AM Amit Kapila wrote: > On Wed, Nov 25, 2020 at 2:52 PM Amit Kapila > wrote: > > > > On Wed, Nov 25, 2020 at 2:26 PM Peter Smith > wrote: > > > > > > Hi Hackers. > > > > > > Last month there was a commit [1] for replacing logical replication > > > message type

Re: [Proposal] Global temporary tables

I found that the new Patch mail failed to register to Commitfest https://commitfest.postgresql.org/28/2349/# I don't know what's wrong and how to check it? Could you help me figure it out? > 2020年11月25日 14:19，Pavel Stehule 写道： > > > > po 23.