Re: Parallel INSERT (INTO ... SELECT ...)

On Wed, Sep 30, 2020 at 7:38 AM Greg Nancarrow wrote: > > > > > > > I think you still need to work on the costing part, basically if we > > > are parallelizing whole insert then plan is like below > > > > > > -> Gather > > > -> Parallel Insert > > > -> Parallel Seq Scan > > > > > > That

Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro)

On Tue, Sep 29, 2020 at 09:29:18AM -0400, Tom Lane wrote: > Hm, it doesn't seem like "OBJS_PGCOMMON" conveys much. I think > OBJS_FRONTEND ought to be the set of files built for frontend > application use (i.e., libpgcommon.a), so we need a new name > for what will go into libpgcommon_shlib.a.

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

Hi Amit, > I don't have a patch for this idea but you can refer [1] > (v25-0002-Issue-individual-invalidations-with-wal_level-lo) to see > what I was trying to say about registering the invalidations in the > form of ReorderBufferChange. We have something along the lines of what > I described

Some comment problem in nodeAgg.c

Hi When looking into the code about hash disk, I found some comment in nodeAgg.c may have not been updated. 1. Since function lookup_hash_entry() has been deleted, there are still some comment talk about lookup_hash_entry(). * and is packed/unpacked in lookup_hash_entry() /

Re: DROP relation IF EXISTS Docs and Tests - Bug Fix

st 30. 9. 2020 v 4:01 odesílatel David G. Johnston < david.g.johns...@gmail.com> napsal: > On Tue, Sep 15, 2020 at 3:48 PM Alexander Korotkov > wrote: > >> Hi! >> >> I've skimmed through the thread and checked the patchset. Everything >> looks good, except one paragraph, which doesn't look

Re: Optimize memory allocation code

On Sep 29, 2020, at 9:30 PM, Alvaro Herrera mailto:alvhe...@2ndquadrant.com>> wrote: On 2020-Sep-26, Li Japin wrote: Thanks! How big is this overhead? Is there any way I can test it？ You could also have a look at the assembly code that your compiler generates -- particularly examine how it

Re: NOTIFY docs fixup - emit and deliver consistency

On Tue, Sep 29, 2020 at 7:58 PM Tom Lane wrote: > Maybe we could use terminology along the lines of "added to the > queue" and "removed from the queue"? > Quickly looking it over with this in mind there are a few spots that can be cleaned up and linked together by explicitly talking about a

Re: problem with RETURNING and update row movement

On Thu, Sep 24, 2020 at 2:26 PM Amit Langote wrote: > On Thu, Sep 24, 2020 at 1:54 PM Michael Paquier wrote: > > On Thu, Sep 24, 2020 at 04:25:24AM +0900, Etsuro Fujita wrote: > > > Sorry, my thought was vague. To store xmin/xmax/cmin/cmax into a > > > given slot, we need to extend the

RE: Disable WAL logging to speed up data loading

Hello, Ashutosh > Can they use a database with all unlogged tables? Unfortunately, no. They want to switch a cluster condition to "without WAL logging" only when they execute night bulk loading for their data warehouse. In other words, they would like to keep their other usual operations with

Re: Use PG_FINALLY to simplify code

Kyotaro Horiguchi writes: > At Tue, 29 Sep 2020 01:03:13 +, "Hou, Zhijie" > wrote in >> Since PG_FINALLY can be used now, I think we can use PG_FINALLY to simplify >> code here. > The patch removes PG_RETHROW(), which is crucial in the code > path. No, that's not a problem, because

Re: NOTIFY docs fixup - emit and deliver consistency

"David G. Johnston" writes: > Over in [1] Greg got confused by some wording in our NOTIFY documentation. > The attached patch uses "emits" and "delivered" more consistently (in > lieu of "processed" in the complained of location). Meh --- I do not think "emitted" is much of an improvement over

pg_proc.dat "proargmodes is not a 1-D char array"

Hi all Random tip for future searchers. If you've modified pg_proc.dat and initdb fails with "proargmodes is not a 1-D char array" - it could well actually be that the length of proargmodes does not match the length of proallargtypes given the test ARR_DIMS(arr)[0] !=

Document JSON primitive quoting and letter-case rules

In Bug# 11636 [1] ChandraKumar complained that we documented fairly explicitly how to write json boolean true and false but not json null. While repeating the entire RFC in our docs isn't desirable its seems worth considering making the comments on the existing table consistently cover quoting

Re: Use PG_FINALLY to simplify code

At Tue, 29 Sep 2020 01:03:13 +, "Hou, Zhijie" wrote in > In (/src/pl/plpgsql/src/pl_exec.c), I found some code like the following: > > PG_CATCH(); > { > if (expr->plan && !expr->plan->saved) > expr->plan = NULL; > PG_RE_THROW();

RE: Disable WAL logging to speed up data loading

Hi, Amul > > We'd like to propose a feature to disable WAL to speed up data loading. > > This > was inspired by a feature added in the latest MySQL. I wish you won't fear > this feature... > > > > TWIMW, pg_bulkload contrib module[1], also does the same for the faster data > loading. Both

RE: BLOB / CLOB support in PostgreSQL

From: Vladimir Sitnikov > Just in case, I'm PgJDBC committer. Thank you very much for your great efforts for the wonderful PgJDBC. I saw you active. # I'd be happy if you send emails in text format so that the reply looks nice. Your email seems to be in HTML. > and apparently, Andrew is

NOTIFY docs fixup - emit and deliver consistency

Hackers, Over in [1] Greg got confused by some wording in our NOTIFY documentation. The attached patch uses "emits" and "delivered" more consistently (in lieu of "processed" in the complained of location). [1] https://www.postgresql.org/message-id/6EDB6A52-17F1-4DA9-B5B8-3BFFD5A576C8%40loblaw.ca

Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress

On Tue, 29 Sep 2020 at 22:09, Alvaro Herrera wrote: > On 2018-Jun-01, Craig Ringer wrote: > > > On 28 May 2018 at 15:06, Craig Ringer wrote: > > > > > Per topic, the Pg makefiles install pg_regress (for use by extensions) > and > > > htey install the isolationtester, but they don't install > >

Re: Parallel INSERT (INTO ... SELECT ...)

> > > > I think you still need to work on the costing part, basically if we > > are parallelizing whole insert then plan is like below > > > > -> Gather > > -> Parallel Insert > > -> Parallel Seq Scan > > > > That means the tuple we are selecting via scan are not sent back to > > the

Re: DROP relation IF EXISTS Docs and Tests - Bug Fix

On Tue, Sep 15, 2020 at 3:48 PM Alexander Korotkov wrote: > Hi! > > I've skimmed through the thread and checked the patchset. Everything > looks good, except one paragraph, which doesn't look completely clear. > > + > + This emulates the functionality provided by > +but sets the created

Re: Parallel Full Hash Join

On Mon, Sep 21, 2020 at 8:34 PM Thomas Munro wrote: > On Tue, Sep 22, 2020 at 8:49 AM Melanie Plageman > wrote: > > On Wed, Sep 11, 2019 at 11:23 PM Thomas Munro > wrote: > > I took it for a very quick spin and saw simple cases working nicely, > but TPC-DS queries 51 and 97 (which contain full

Re: Why does PostgresNode.pm set such a low value of max_wal_senders?

Alvaro Herrera writes: > On 2020-Sep-29, Tom Lane wrote: >> So I wonder why PostgresNode.pm is doing >> print $conf "max_wal_senders = 5\n"; >> Considering that our default these days is 10 senders, and that a >> walsender slot doesn't really cost much, this seems unduly cheapskate. >> I propose

Re: Why does PostgresNode.pm set such a low value of max_wal_senders?

On 2020-Sep-29, Tom Lane wrote: > So I wonder why PostgresNode.pm is doing > > print $conf "max_wal_senders = 5\n"; > > Considering that our default these days is 10 senders, and that a > walsender slot doesn't really cost much, this seems unduly cheapskate. > I propose raising

Why does PostgresNode.pm set such a low value of max_wal_senders?

I noticed this recent buildfarm failure: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sidewinder=2020-09-29%2018%3A45%3A17 which boils down to error running SQL: 'psql::1: ERROR: could not connect to the publisher: FATAL: number of requested standby connections exceeds

Re: BLOB / CLOB support in PostgreSQL

Andrew>It needs to contain a substantial implementation plan Here's an implementation plan, again, quoted from the very same mail: Vladimir>Of course both variations above fail to support streaming Vladimir> (as in "need to process all the contents in order to get the last character"), so it

Re: Planner making bad choice in alternative subplan decision

On Wed, 30 Sep 2020 at 04:42, Tom Lane wrote: > > David Rowley writes: > > On Tue, 29 Sep 2020 at 12:08, Tom Lane wrote: > >> The idea I'd had was to adjust make_subplan and cost_subplan to estimate > >> EXIST cases on the basis of either 50% retrieval (same as ANY/ALL) or > >> maybe full

Re: Yet another fast GiST build

On 29/09/2020 21:04, Andrey M. Borodin wrote: 28 сент. 2020 г., в 13:12, Heikki Linnakangas написал(а): I did some testing with your patch. It seems that the rightlinks are still not always set. I didn't try to debug why. Yes, there is a bug. Now it seems to me so obvious, yet it took some

Re: Dumping/restoring fails on inherited generated column

Daniel Gustafsson writes: > On 29 Sep 2020, at 18:37, Tom Lane wrote: >> This does not cause child2.f1's attislocal property to become >> true. Maybe it should have, but it's probably too late for >> that; at least, pg_dump couldn't assume it's true in older >> servers. > Do you recall the

Re: BLOB / CLOB support in PostgreSQL

On 9/29/20 3:48 PM, Vladimir Sitnikov wrote: > Andrew>You and I clearly have a different idea from what constitutes a > concrete > Andrew>proposal. This is hardly the ghost of a proposal. > > Can you please clarify what is a proposal from your point of view? > Is it documented? > > I think I

Re: Dumping/restoring fails on inherited generated column

> On 29 Sep 2020, at 18:37, Tom Lane wrote: > > [ Pulling Daniel into this older thread seems like the cleanest way to > unify the two threads ] > > Masahiko Sawada writes: >> If we have ALTER TABLE ONLY / DROP EXPRESSION update the attlocal >> column of children to true to fix the issue you

Re: BLOB / CLOB support in PostgreSQL

Andrew>You and I clearly have a different idea from what constitutes a concrete Andrew>proposal. This is hardly the ghost of a proposal. Can you please clarify what is a proposal from your point of view? Is it documented? I think I have read the relevant TODO items:

Re: BLOB / CLOB support in PostgreSQL

On 9/29/20 2:39 PM, Dave Cramer wrote: > > > On Tue, 29 Sep 2020 at 14:33, Andrew Dunstan > > wrote: > > > On 9/29/20 10:26 AM, Peter Eisentraut wrote: > > On 2020-09-28 15:46, Vladimir Sitnikov wrote: > >> The concerns to avoid "Clob maps to

Re: BLOB / CLOB support in PostgreSQL

On Tue, 29 Sep 2020 at 14:33, Andrew Dunstan wrote: > > On 9/29/20 10:26 AM, Peter Eisentraut wrote: > > On 2020-09-28 15:46, Vladimir Sitnikov wrote: > >> The concerns to avoid "Clob maps to text" could be: > >> a) Once the behavior is implemented, it is hard to change. That is > >>

Re: BLOB / CLOB support in PostgreSQL

On 9/29/20 10:26 AM, Peter Eisentraut wrote: > On 2020-09-28 15:46, Vladimir Sitnikov wrote: >> The concerns to avoid "Clob maps to text" could be: >> a) Once the behavior is implemented, it is hard to change. That is >> applications would rely on it (and it becomes a defacto standard), >> and

Re: BUG #16419: wrong parsing BC year in to_date() function

I wrote: > I think this is nuts. The current behavior is obviously broken; > we should just treat it as a bug and fix it, including back-patching. > I do not think there is a compatibility problem of any significance. > Who out there is going to have an application that is relying on the >

Re: Yet another fast GiST build

> 28 сент. 2020 г., в 13:12, Heikki Linnakangas написал(а): > > On 21/09/2020 17:19, Andrey M. Borodin wrote: >>> 21 сент. 2020 г., в 18:29, Andrey M. Borodin >>> написал(а): >>> >>> It was a conscious decision with incorrect motivation. I was thinking that >>> it will help to reduce

Re: BUG #16419: wrong parsing BC year in to_date() function

Peter Eisentraut writes: > Adding support for negative years in make_timestamp seems pretty > straightforward; see attached patch. In hopes of moving things along, I pushed that, along with documentation additions. I couldn't quite convince myself that it was a bug fix though, so no

Re: BUG #16419: wrong parsing BC year in to_date() function

Bruce Momjian writes: > On Fri, Sep 4, 2020 at 12:45:36PM -0700, David G. Johnston wrote: >>> Because we already have the to_date/make_date inconsistency, and the -1 >>> to -2 BC mapping is confusing, and doesn't match Oracle, I think the >>> clean solution is to change PG 14 to treat -1 as 1

Re: Dumping/restoring fails on inherited generated column

I wrote: > The situation is different for GENERATED columns, since we disallow > a child having a different GENERATED property than the parent. BTW, that alleged prohibition is pretty damn leaky: d3=# create table pp1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED); CREATE TABLE d3=# create

some pointless HeapTupleHeaderIndicatesMovedPartitions calls

Hello Pavan Deolasee recently noted that a few of the HeapTupleHeaderIndicatesMovedPartitions calls added by commit 5db6df0c0117 are useless, since they are done after comparing t_self with t_ctid. That's because t_self can never be set to the magical values that indicate that the tuple moved

Re: calling procedures is slow and consumes extra much memory against calling function

út 29. 9. 2020 v 17:20 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I agree with these conclusions. I'll try to look if I can do #2 patch > > better for pg14. Probably it can fix more issues related to CALL > statement, > > and I agree so this should not be backapatched. > > I've

Re: Dumping/restoring fails on inherited generated column

[ Pulling Daniel into this older thread seems like the cleanest way to unify the two threads ] Masahiko Sawada writes: > If we have ALTER TABLE ONLY / DROP EXPRESSION update the attlocal > column of children to true to fix the issue you raised, my proposed > patch is not necessary. OTOH if we

Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away

On 2020/09/30 0:50, Bharath Rupireddy wrote: Thanks for the comments. On Tue, Sep 29, 2020 at 7:30 PM Fujii Masao wrote: +1 to add debug3 message there. But this message doesn't seem to match with what the error actually happened. What about something like "could not start remote

Re: New statistics for tuning WAL buffer size

On 2020/09/29 11:51, Masahiro Ikeda wrote: On 2020-09-29 11:43, Amit Kapila wrote: On Tue, Sep 29, 2020 at 7:39 AM Masahiro Ikeda wrote: On 2020-09-28 12:43, Amit Kapila wrote: > On Mon, Sep 28, 2020 at 8:24 AM Kyotaro Horiguchi > wrote: >> >> At Mon, 28 Sep 2020 08:11:23 +0530, Amit

Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away

Thanks for the comments. On Tue, Sep 29, 2020 at 7:30 PM Fujii Masao wrote: > > +1 to add debug3 message there. But this message doesn't seem to > match with what the error actually happened. What about something like > "could not start remote transaction on connection %p", instead? > Looks

Re: Planner making bad choice in alternative subplan decision

David Rowley writes: > On Tue, 29 Sep 2020 at 12:08, Tom Lane wrote: >> The idea I'd had was to adjust make_subplan and cost_subplan to estimate >> EXIST cases on the basis of either 50% retrieval (same as ANY/ALL) or >> maybe full retrieval if you want to be pessimistic. I've not had time >>

Re: calling procedures is slow and consumes extra much memory against calling function

Pavel Stehule writes: > I agree with these conclusions. I'll try to look if I can do #2 patch > better for pg14. Probably it can fix more issues related to CALL statement, > and I agree so this should not be backapatched. I've pushed this and marked the CF entry committed. Please start a new

Re: Parallel INSERT (INTO ... SELECT ...)

On Tue, Sep 29, 2020 at 8:27 PM Dilip Kumar wrote: > > On Mon, Sep 28, 2020 at 8:45 AM Greg Nancarrow wrote: > > > > On Sat, Sep 26, 2020 at 3:30 PM Bharath Rupireddy > > wrote: > > > > > I further checked on full txn id and command id. Yes, these are > > > getting passed to workers via

Re: Parallel INSERT (INTO ... SELECT ...)

On Mon, Sep 28, 2020 at 8:45 AM Greg Nancarrow wrote: > > On Sat, Sep 26, 2020 at 3:30 PM Bharath Rupireddy > wrote: > > > I further checked on full txn id and command id. Yes, these are > > getting passed to workers via InitializeParallelDSM() -> > > SerializeTransactionState(). I tried to

Re: Parallel copy

On Tue, Sep 29, 2020 at 6:30 PM Amit Kapila wrote: > > On Mon, Sep 28, 2020 at 12:19 PM Amit Kapila wrote: > > > > Few additional comments: > > == > > Some more comments: > Thanks Amit for the comments, I will work on the comments and provide a patch in the next few days.

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

On Mon, Sep 28, 2020 at 1:13 PM Ajin Cherian wrote: > > On Wed, Sep 23, 2020 at 2:39 PM Amit Kapila wrote: > > > No problem. I think you can handle the other comments and then we can > > come back to this and you might want to share the exact details of the > > test (may be a narrow down version

Re: BLOB / CLOB support in PostgreSQL

On 2020-09-28 15:46, Vladimir Sitnikov wrote: The concerns to avoid "Clob maps to text" could be: a) Once the behavior is implemented, it is hard to change. That is applications would rely on it (and it becomes a defacto standard), and it would be hard to move to the proper "text with

Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress

On 2018-Jun-01, Craig Ringer wrote: > On 28 May 2018 at 15:06, Craig Ringer wrote: > > > Per topic, the Pg makefiles install pg_regress (for use by extensions) and > > htey install the isolationtester, but they don't install > > pg_isolation_regress. > > > > We should install it too. I

Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away

On 2020/09/25 21:19, Bharath Rupireddy wrote: On Fri, Sep 25, 2020 at 3:21 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote: > > I think that we can simplify the code by merging the connection-retry > code into them, like the attached very WIP patch (based on yours) does. > +1.

Re: Optimize memory allocation code

On 2020-Sep-26, Li Japin wrote: > Thanks! How big is this overhead? Is there any way I can test it？ You could also have a look at the assembly code that your compiler generates -- particularly examine how it changes. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL

Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro)

Michael Paquier writes: > On Mon, Sep 28, 2020 at 12:49:29PM -0400, Tom Lane wrote: >> Since prairiedog is not likely to be around forever, I propose that >> we ought to enforce this going forward by arranging for common/logging.c >> to not get built into the libpgcommon_shlib library variant. >

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

On Tue, Sep 29, 2020 at 5:08 PM Ajin Cherian wrote: > > On Wed, Sep 23, 2020 at 2:39 PM Amit Kapila wrote: > > > If the transaction is prepared which you can ensure via > > ReorderBufferTxnIsPrepared() (considering you have a proper check in > > that function), it should not require skipping the

Re: Parallel copy

On Mon, Sep 28, 2020 at 12:19 PM Amit Kapila wrote: > > Few additional comments: > == Some more comments: v5-0002-Framework-for-leader-worker-in-parallel-copy === 1. These values + * help in handover of multiple records with

Re: Disable WAL logging to speed up data loading

Can they use a database with all unlogged tables? On Tue, Sep 29, 2020 at 1:58 PM tsunakawa.ta...@fujitsu.com wrote: > > Hello, > > > We'd like to propose a feature to disable WAL to speed up data loading. This > was inspired by a feature added in the latest MySQL. I wish you won't fear >

Re: Corner-case bug in pg_rewind

On 11/09/2020 09:42, Ian Barwick wrote: Take the following cluster with: - node1 (initial primary) - node2 (standby) - node3 (standby) Following activity takes place (greatly simplified from a real-world situation): 1. node1 is shut down. 2. node3 is promoted 3. node2 is attached to

Re: Skip ExecCheckRTPerms in CTAS with no data

On Mon, Sep 28, 2020 at 7:48 PM Tom Lane wrote: > > Bharath Rupireddy writes: > > In case of CTAS with no data, we actually do not insert the tuples > > into the created table, so we can skip checking for the insert > > permissions. Anyways, the insert permissions will be checked when the > >

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

On Wed, Sep 23, 2020 at 2:39 PM Amit Kapila wrote: > If the transaction is prepared which you can ensure via > ReorderBufferTxnIsPrepared() (considering you have a proper check in > that function), it should not require skipping the transaction in > Abort. One way it could happen is if you clean

Re: BLOB / CLOB support in PostgreSQL

On Mon, 28 Sep 2020 at 20:08, Andy Fan wrote: > > > On Tue, Sep 29, 2020 at 5:22 AM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > >> >100% compatible with the MySQL >> >> It is hardly a justification for a feature or for a change request. >> >> Vladimir >> > I would have to agree.

Re: OpenSSL 3.0.0 compatibility

> On 22 Sep 2020, at 14:01, Daniel Gustafsson wrote: > >> On 22 Sep 2020, at 11:37, Peter Eisentraut >> wrote: >> >> On 2020-09-18 16:11, Daniel Gustafsson wrote: >>> Since we support ciphers that are now deprecated, we have no other choice >>> than >>> to load the legacy provider. >> >>

Re: Improved Cost Calculation for IndexOnlyScan

On 29/09/2020 11:49, Hamid Akhtar wrote: So, not actually random replacement here, rather a change with baserel->allvisfrac taken into consideration (as given below): index_random_page_cost = Min(spc_seq_page_cost + spc_random_page_cost * (1.0 - baserel->allvisfrac),

Re: Parallel copy

Hi Vignesh and Bharath, Seems like the Parallel Copy patch is regarding RI_TRIGGER_PK as parallel-unsafe. Can you explain why this is? Regards, Greg Nancarrow Fujitsu Australia

Re: Add session statistics to pg_stat_database

On Thu, 2020-09-24 at 14:38 -0700, Soumyadeep Chakraborty wrote: > Thanks for submitting this! Please find my feedback below. Thanks for the thorough review. Before I update the patch, I have a few comments and questions. > * Are we trying to capture ONLY client initiated disconnects in >

Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers

On 2020-09-26 07:32, Amit Kapila wrote: This is exactly my feeling too. But how about changing documentation a bit as proposed above [1] to make it precise. [1] - https://www.postgresql.org/message-id/CAA4eK1LQWXS_4RwLo%2BWT7jusGnBkUvXO73xQOCsydWLYBpLBEg%40mail.gmail.com Yes, making the

Re: Disable WAL logging to speed up data loading

On Tue, Sep 29, 2020 at 1:58 PM tsunakawa.ta...@fujitsu.com wrote: > > Hello, > > > We'd like to propose a feature to disable WAL to speed up data loading. This > was inspired by a feature added in the latest MySQL. I wish you won't fear > this feature... > TWIMW, pg_bulkload contrib

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On Wed, 23 Sep 2020 at 08:42, David Rowley wrote: > > On Tue, 22 Sep 2020 at 19:08, David Rowley wrote: > > I ran another scale=5 TPCH benchmark on v4 against f859c2ffa using gcc > > 9.3. I'm unable to see any gains with this, however, the results were > > pretty noisy. I only ran pgbench for 60

Re: Fix inconsistency in jsonpath .datetime()

On Fri, Sep 25, 2020 at 2:02 AM Alexander Korotkov wrote: > Other opinions? Given no other opinions yet, I've pushed the both patches. -- Regards, Alexander Korotkov

Re: Improved Cost Calculation for IndexOnlyScan

On Tue, Sep 29, 2020 at 1:08 PM Heikki Linnakangas wrote: > On 29/09/2020 10:06, Hamid Akhtar wrote: > > In one of my earlier emails [1], I mentioned that there seems to be a > > problem with how the cost for index only scans is being calculated. > > [1] > > >

Disable WAL logging to speed up data loading

Hello, We'd like to propose a feature to disable WAL to speed up data loading. This was inspired by a feature added in the latest MySQL. I wish you won't fear this feature... BACKGROUND This branches off from [1] as mentioned therein. Briefly

Re: Assertion failure with barriers in parallel hash join

On Tue, Sep 29, 2020 at 7:11 PM Michael Paquier wrote: > #2 0x009027d2 in ExceptionalCondition > (conditionName=conditionName@entry=0xa80846 "!barrier->static_party", > #4 0x00682ebf in ExecParallelHashJoinNewBatch Thanks. Ohhh. I think I see how that condition was reached

Re: Improved Cost Calculation for IndexOnlyScan

On 29/09/2020 10:06, Hamid Akhtar wrote: In one of my earlier emails [1], I mentioned that there seems to be a problem with how the cost for index only scans is being calculated. [1] https://www.postgresql.org/message-id/CANugjhsnh0OBMOYc7qKcC%2BZsVvAXCeF7QiidLuFvg6zmHy1C7A%40mail.gmail.com

Re: Support for NSS as a libpq TLS backend

> On 29 Sep 2020, at 07:59, Michael Paquier wrote: > > On Thu, Sep 17, 2020 at 11:41:28AM +0200, Daniel Gustafsson wrote: >> Attached is a v10 rebased to apply on top of HEAD. > > I am afraid that this needs a new rebase. The patch is failing to > apply, per the CF bot. :/ It's failing on

Re: Buggy handling of redundant options in COPY

út 29. 9. 2020 v 9:24 odesílatel Michael Paquier napsal: > Hi all, > > While diving into the CF, I have noticed the following message from > Remy (in CC): > > https://www.postgresql.org/message-id/0b55bd07-83e4-439f-aacc-fa2d7cf50...@lenstra.fr > > The following two cases should fail the same

Re: history file on replica and double switchover

On 2020/09/26 5:34, David Zhang wrote: The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed "make

Buggy handling of redundant options in COPY

Hi all, While diving into the CF, I have noticed the following message from Remy (in CC): https://www.postgresql.org/message-id/0b55bd07-83e4-439f-aacc-fa2d7cf50...@lenstra.fr The following two cases should fail the same way, but the second does not because we check directly the flag value

Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64

On 10/09/2020 09:37, Zidenberg, Tsahi wrote: On 08/09/2020, 1:01, "Tom Lane" wrote: > I wonder what version of gcc you intend this for. AFAICS, older > gcc versions lack this flag at all, while newer ones have it on > by default. (previously sent private reply, sorry) The

Improved Cost Calculation for IndexOnlyScan

In one of my earlier emails [1], I mentioned that there seems to be a problem with how the cost for index only scans is being calculated. [1] https://www.postgresql.org/message-id/CANugjhsnh0OBMOYc7qKcC%2BZsVvAXCeF7QiidLuFvg6zmHy1C7A%40mail.gmail.com My concern is that there seems to be a bigger

Re: Concurrency issue in pg_rewind

On 18/09/2020 10:17, Alexander Kukushkin wrote: At the same time, pg_rewind due to such "fatal" error leaves PGDATA in an inconsistent state with empty pg_control file, this is totally bad and easily fixable. We want the specific file to be absent and it is already absent, why should it be a

Re: Transactions involving multiple postgres foreign servers, take 2

On Tue, 29 Sep 2020 at 15:03, Masahiko Sawada wrote: > > On Tue, 29 Sep 2020 at 11:37, tsunakawa.ta...@fujitsu.com > wrote: > > > > From: Masahiko Sawada > > > No. Please imagine a case where a user executes PREPARE TRANSACTION on > > > the transaction that modified data on foreign servers. The

Re: Add header support to text format and matching feature

On Thu, Aug 27, 2020 at 04:53:11PM +0200, Rémi Lapeyre wrote: > I have two remarks with the state of the current patches: > - DefGetCopyHeader() duplicates a lot of code from defGetBoolean(), > should we refactor this so that they can share more of their > internals? In the current implementation

Re: Support for OUT parameters in procedures

po 28. 9. 2020 v 18:43 odesílatel Andrew Dunstan < andrew.duns...@2ndquadrant.com> napsal: > > On 8/27/20 4:34 AM, Peter Eisentraut wrote: > > Procedures currently don't allow OUT parameters. The reason for this > > is that at the time procedures were added (PG11), some of the details > > of how

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

On Tue, Sep 29, 2020 at 11:29:45AM +0530, Bharath Rupireddy wrote: > Unfortunately, we have not arrived at a final solution yet, please > ignore this patch. I will post a new patch, once the solution is > finalized. I will move it to the next commit fest if okay. If you are planning to get that

Assertion failure with barriers in parallel hash join

Hi all, prion, that uses -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE, has just failed with an interesting failure: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion=2020-09-29%2005%3A24%3A11 The assertion failure happens in a parallel worker when attempting to attach a barrier:

Re: Transactions involving multiple postgres foreign servers, take 2

On Tue, 29 Sep 2020 at 11:37, tsunakawa.ta...@fujitsu.com wrote: > > From: Masahiko Sawada > > No. Please imagine a case where a user executes PREPARE TRANSACTION on > > the transaction that modified data on foreign servers. The backend > > process prepares both the local transaction and foreign

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

On Tue, Sep 29, 2020 at 11:21 AM Michael Paquier wrote: > > On Mon, Aug 03, 2020 at 04:41:58PM +0530, Bharath Rupireddy wrote: > > IMHO, we are not fully solving the problem with > > idle_in_session_timeout on remote backends though we are addressing > > the main problem partly by letting the

Re: Support for NSS as a libpq TLS backend

On Thu, Sep 17, 2020 at 11:41:28AM +0200, Daniel Gustafsson wrote: > Attached is a v10 rebased to apply on top of HEAD. I am afraid that this needs a new rebase. The patch is failing to apply, per the CF bot. :/ -- Michael signature.asc Description: PGP signature