Re: pgbench - allow to create partitioned tables

On Fri, Sep 27, 2019 at 7:05 PM Alvaro Herrera wrote: > > On 2019-Sep-27, Amit Kapila wrote: > > > The other thing is that the query used in patch to fetch partition > > information seems correct to me, but maybe there is a better way to > > get that information. > > I hadn't looked at that, but

Re: Consider low startup cost in add_partial_path

On Fri, Sep 27, 2019 at 2:24 PM James Coleman wrote: > Over in the incremental sort patch discussion we found [1] a case > where a higher cost plan ends up being chosen because a low startup > cost partial path is ignored in favor of a lower total cost partial > path and a limit is a applied on

Re: max_parallel_workers question

On Fri, Sep 27, 2019 at 8:07 PM Jeff Davis wrote: > The current docs for max_parallel_workers start out: > > "Sets the maximum number of workers that the system can support for > parallel operations..." > > In my interpretation, "the system" means the entire cluster, but the >

contrib/bloom Valgrind error

My Valgrind test script reports the following error, triggered from within contrib/bloom's regression test suite on master as of right now: "" 2019-09-27 20:53:50.910 PDT 9740 DEBUG: building index "bloomidx" on table "tst" serially 2019-09-27 20:53:51.049 PDT 9740 DEBUG:

Re: ECPG installcheck tests fail if PGDATABASE is set

On Fri, Sep 27, 2019 at 3:03 PM Tom Lane wrote: > > Please do. > > After looking closer at the code in pg_regress.c, I'm wondering a bit > about PGSERVICE. A setting for that might certainly bring in a value > for the database name, but I don't think we can just summarily unset it. > I don't

Re: Change atoi to strtol in same place

Alvaro Herrera wrote: > ... can we have a new patch? Not only because there seems to have > been some discussion points that have gone unaddressed (?) Yes, I'll work on it over the weekend. > but also because Appveyor complains really badly about this one. >

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Fri, Sep 27, 2019 at 9:43 AM Anastasia Lubennikova wrote: > Attached is v19. Cool. > * By default deduplication is on for non-unique indexes and off for > unique ones. I think that it makes sense to enable deduplication by default -- even with unique indexes. It looks like deduplication can

max_parallel_workers question

The current docs for max_parallel_workers start out: "Sets the maximum number of workers that the system can support for parallel operations..." In my interpretation, "the system" means the entire cluster, but the max_parallel_workers setting is PGC_USERSET. That's a bit confusing, because two

Re: ECPG installcheck tests fail if PGDATABASE is set

Peter Geoghegan writes: > On Fri, Sep 27, 2019 at 2:39 PM Tom Lane wrote: >> I think I just forgot about this thread. Shall we change it in HEAD >> and see what happens? Maybe backpatch, but not till after 12.0 is out. > Please do. After looking closer at the code in pg_regress.c, I'm

Re: ECPG installcheck tests fail if PGDATABASE is set

On 2019-09-27 14:43:00 -0700, Peter Geoghegan wrote: > On Fri, Sep 27, 2019 at 2:39 PM Tom Lane wrote: > > I think I just forgot about this thread. Shall we change it in HEAD > > and see what happens? Maybe backpatch, but not till after 12.0 is out. > > Please do. +1

Re: Batch insert in CTAS/MatView code

Hi, On 2019-09-09 18:31:54 +0800, Paul Guo wrote: > diff --git a/src/backend/access/heap/heapam.c > b/src/backend/access/heap/heapam.c > index e9544822bf..8a844b3b5f 100644 > --- a/src/backend/access/heap/heapam.c > +++ b/src/backend/access/heap/heapam.c > @@ -2106,7 +2106,6 @@

Re: Batch insert in CTAS/MatView code

Hi, On 2019-09-26 10:43:27 -0300, Alvaro Herrera wrote: > On 2019-Sep-25, Asim R P wrote: > > > I reviewed your patch today. It looks good overall. My concern is that > > the ExecFetchSlotHeapTuple call does not seem appropriate. In a generic > > place such as createas.c, we should be using

Re: ECPG installcheck tests fail if PGDATABASE is set

On Fri, Sep 27, 2019 at 2:39 PM Tom Lane wrote: > I think I just forgot about this thread. Shall we change it in HEAD > and see what happens? Maybe backpatch, but not till after 12.0 is out. Please do. -- Peter Geoghegan

Re: ECPG installcheck tests fail if PGDATABASE is set

Peter Geoghegan writes: > On Sun, Mar 18, 2018 at 5:28 PM Tom Lane wrote: >> Don't think I like ecpg's tests behaving differently in this respect >> than the rest of them do; that seems like a recipe for unrecognized >> security issues. >> >> If nobody can think of a positive reason for

Re: ECPG installcheck tests fail if PGDATABASE is set

On Sun, Mar 18, 2018 at 5:28 PM Tom Lane wrote: > Don't think I like ecpg's tests behaving differently in this respect > than the rest of them do; that seems like a recipe for unrecognized > security issues. > > If nobody can think of a positive reason for pg_regress not to > unset PGDATABASE

Re: [HACKERS] "may be unused" warnings for gcc

Hi, On 2017-02-22 09:26:10 -0500, Peter Eisentraut wrote: > On 2/21/17 22:17, Andres Freund wrote: > > I've not run comparisons this year, but late last year I was seeing > 5% > > < 10% benefits - that seems plenty enough to care. > > You mean the 5-minute benchmarks on my laptop are not

Re: recovery starting when backup_label exists, but not recovery.signal

Hi Peter, On 9/27/19 3:35 PM, Peter Eisentraut wrote: > On 2019-09-27 10:34, Fujii Masao wrote: >>> Also, are you sure this is a new behavior? >> In v11 or before, if backup_label exists but not recovery.conf, >> the startup process doesn't enter an archive recovery mode. It starts >> crash

Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown)

On 2019-Sep-27, Paul Guo wrote: > I'm using --no-ensure-shutdown in the new version unless there are better > suggestions. That sounds sufficiently good. I pushed this patch, after fixing a few smallish problems, such as an assertion failure because of the terminating \n in the error message

Re: recovery starting when backup_label exists, but not recovery.signal

On 2019-09-27 10:34, Fujii Masao wrote: >> Also, are you sure this is a new behavior? > In v11 or before, if backup_label exists but not recovery.conf, > the startup process doesn't enter an archive recovery mode. It starts > crash recovery in that case. So the bahavior is somewhat different >

Re: Attempt to consolidate reading of XLOG page

Alvaro Herrera writes: > On 2019-Sep-27, Antonin Houska wrote: >>> You placed the errinfo in XLogRead's stack rather than its callers' ... >>> I don't think that works, because as soon as XLogRead returns that >>> memory is no longer guaranteed to exist. >> I was aware of this problem, therefore

Re: Hooks for session start and end, take two

Michael Paquier-2 wrote > On Thu, Sep 26, 2019 at 09:57:57AM -0700, legrand legrand wrote: >> Does that mean that all processes seen in pg_stat_activity like >> - autovacuum launcher >> - logical replication launcher >> - background writer >> - checkpointer >> - walwriter >> ... >> - Parallel

Re: Improving on MAX_CONVERSION_GROWTH

Robert Haas writes: > On Fri, Sep 27, 2019 at 11:40 AM Andres Freund wrote: >> Note that one of the additional reasons for the 1GB limit is that it >> protects against int overflows. I'm somewhat unconvinced that that's a >> sensible approach, but ... > It's not crazy. People using 'int' rather

Re: Attempt to consolidate reading of XLOG page

On 2019-Sep-27, Antonin Houska wrote: > > You placed the errinfo in XLogRead's stack rather than its callers' ... > > I don't think that works, because as soon as XLogRead returns that > > memory is no longer guaranteed to exist. > > I was aware of this problem, therefore I defined the field as

Re: Hooks for session start and end, take two

On Fri, Sep 27, 2019 at 12:54 AM Michael Paquier wrote: > > On Thu, Sep 26, 2019 at 09:57:57AM -0700, legrand legrand wrote: > > Does that mean that all processes seen in pg_stat_activity like > > - autovacuum launcher > > - logical replication launcher > > - background writer > > - checkpointer

Skip recovery/standby signal files in pg_basebackup

Hackers, Restoring these files could cause surprising behaviors so it seems best to let the restore process create them when needed. Patch is attached. -- -David da...@pgmasters.net From 1b3d95607afeb4f1fa98c3ea006f310ab68252f7 Mon Sep 17 00:00:00 2001 From: David Steele Date: Fri, 27 Sep

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Mon, Sep 16, 2019 at 6:32 AM Tomas Vondra wrote: > > On Sun, Sep 15, 2019 at 09:33:33PM -0400, James Coleman wrote: > >On Sat, Jul 20, 2019 at 11:25 AM Tomas Vondra > > wrote: > >> >> ... > >> >> > >> >> I think this may be a thinko, as this plan demonstrates - but I'm not > >> >> sure about

v12 relnotes: alter system tables

https://www.postgresql.org/docs/12/release-12.html |Allow modifications of system catalogs' options using ALTER TABLE (Peter Eisentraut) |Modifications of catalogs' reloptions and autovacuum settings are now supported. I wonder if that should say: "... WHEN ALLOW_SYSTEM_TABLE_MODS IS ENABLED."

Consider low startup cost in add_partial_path

Over in the incremental sort patch discussion we found [1] a case where a higher cost plan ends up being chosen because a low startup cost partial path is ignored in favor of a lower total cost partial path and a limit is a applied on top of that which would normal favor the lower startup cost

Re: A problem presentaion about ECPG, DECLARE STATEMENT

On Mon, Sep 16, 2019 at 01:12:17PM +0200, Peter Eisentraut wrote: > Moreover, I've been wondering about the behavior detail given in the > table at > . > In scenario 3, the declare statement says con1 but the subsequent >

Re: recovery starting when backup_label exists, but not recovery.signal

On 9/27/19 4:34 AM, Fujii Masao wrote: > On Fri, Sep 27, 2019 at 3:36 AM David Steele wrote: >> >> On 9/24/19 1:25 AM, Fujii Masao wrote: >>> >>> When backup_label exists, the startup process enters archive recovery mode >>> even if recovery.signal file doesn't exist. In this case, the startup

Re: recovery starting when backup_label exists, but not recovery.signal

On 9/27/19 4:41 AM, Fujii Masao wrote: > On Fri, Sep 27, 2019 at 4:07 PM Masahiko Sawada wrote: >> >> On Fri, Sep 27, 2019 at 3:36 AM David Steele wrote: >>> >>> On 9/24/19 1:25 AM, Fujii Masao wrote: When backup_label exists, the startup process enters archive recovery mode even

Re: Attempt to consolidate reading of XLOG page

Alvaro Herrera wrote: > On 2019-Sep-26, Antonin Houska wrote: > You placed the errinfo in XLogRead's stack rather than its callers' ... > I don't think that works, because as soon as XLogRead returns that > memory is no longer guaranteed to exist. I was aware of this problem, therefore I

Re: pg_upgrade issues

On Mon, Sep 9, 2019 at 10:58:02AM -0400, Dave Cramer wrote: > pgjdbc has a bug report which is as follows: > > The database has a table that has a description and a constraint. > The constraint also has a description. > > somehow the constraint and the table end up with the same OID's after >

Document recovery_target_action behavior?

Hackers, In versions < PG12 recovery_target_action has a behavior that appears to be a bug, or is at least undocumented. If hot_standby = off and recovery_target_action is not specified then the cluster will promote when the target is found rather than shutting down as the documentation seems to

Re: Minimal logical decoding on standbys

On Fri, Sep 27, 2019 at 12:41 PM Amit Khandekar wrote: > Preferably I want wait_for_xmins() to get rid of the $node parameter, > because we can deduce it using slot name. But that requires having > get_node_from_slotname(). Your suggestion was to remove > get_node_from_slotname() and add back the

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Mon, Sep 9, 2019 at 5:55 PM Tomas Vondra wrote: > The "patched" column means all developer GUCs disabled, so it's expected > to produce the same plan as master (and it is). And then there's one > column for each developer GUC. If the column is just TRUE it means the > GUC does not affect any

Re: patch: psql - enforce constant width of last column

On Tue, Sep 17, 2019 at 05:15:42PM +0200, Pavel Stehule wrote: > > > út 17. 9. 2019 v 17:06 odesílatel Ahsan Hadi napsal: > > Hi Pavel, > > I have been trying to reproduce the case of badly displaying last columns > of a query result-set. I played around with the legal values for

Re: Standby accepts recovery_target_timeline setting?

On 9/27/19 11:58 AM, Fujii Masao wrote: > On Sat, Sep 28, 2019 at 12:14 AM David Steele wrote: >> >> I think, at the very least, the fact that targeted recovery proceeds in >> the absence of recovery.signal represents a bug. > > Yes, recovery target settings are used even when neither

Re: log bind parameter values on error

Hello Alvaro, I didn't like abusing testlibpq3.c for your new stuff, so I moved it off to a new file testlibpq5.c. I cleaned up a few other cosmetics things about this -- v10 attached. Thanks for doing this. I eventually noticed that this patch fails to initialize each param's textValue to

Re: Minimal logical decoding on standbys

On Fri, 27 Sep 2019 at 01:57, Robert Haas wrote: > > On Thu, Sep 26, 2019 at 5:14 AM Amit Khandekar wrote: > > Actually in some of the conflict-recovery testcases, I am still using > > wait_for_xmins() so that we could test the xmin values back after we > > drop the slots. So xmin-related

Re: Removing unneeded self joins

Some more bug fixes in this patch. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c index b0dcd02..dc8cb9c 100644 --- a/src/backend/nodes/outfuncs.c +++

Re: Append with naive multiplexing of FDWs

On Wed, Sep 4, 2019 at 06:18:31PM +1200, Thomas Munro wrote: > Hello, > > A few years back[1] I experimented with a simple readiness API that > would allow Append to start emitting tuples from whichever Foreign > Scan has data available, when working with FDW-based sharding. I used > that

Re: WIP/PoC for parallel backup

Hi Robert, Thanks for the feedback. Please see the comments below: On Tue, Sep 24, 2019 at 10:53 PM Robert Haas wrote: > On Wed, Aug 21, 2019 at 9:53 AM Asif Rehman > wrote: > > - BASE_BACKUP [PARALLEL] - returns a list of files in PGDATA > > If the parallel option is there, then it will only

Re: Instability of partition_prune regression test results

Amit Langote writes: > On Fri, Sep 27, 2019 at 7:25 AM Tom Lane wrote: >> I experimented with adjusting explain_parallel_append() to filter >> more fields, but soon realized that we'd have to filter out basically >> everything that makes it useful to run EXPLAIN ANALYZE at all. >> Therefore, I

Re: Standby accepts recovery_target_timeline setting?

On Sat, Sep 28, 2019 at 12:14 AM David Steele wrote: > > Hi Peter, > > On 9/27/19 10:36 AM, Peter Eisentraut wrote: > > On 2019-09-26 23:02, David Steele wrote: > >> On 9/26/19 4:48 PM, Peter Eisentraut wrote: > >> > >>> I don't know if recovery_target_timeline is actually useful to change in >

Re: Improving on MAX_CONVERSION_GROWTH

On Fri, Sep 27, 2019 at 11:40 AM Andres Freund wrote: > Note that one of the additional reasons for the 1GB limit is that it > protects against int overflows. I'm somewhat unconvinced that that's a > sensible approach, but ... It's not crazy. People using 'int' rather casually just as they use

Re: fix "Success" error messages

On Tue, Sep 3, 2019 at 08:38:22AM +0200, Peter Eisentraut wrote: > On 2019-08-27 08:27, Michael Paquier wrote: > > Thanks for the new patch, and you are right that pg_checksums has been > > slacking here. There is the same issue with pg_verify_checksums in > > 11. Not sure that's worth a

Re: errbacktrace

On 2019-Sep-13, Alvaro Herrera wrote: > On 2019-Aug-20, Peter Eisentraut wrote: > > > The memory management of that seems too complicated. The "extra" > > mechanism of the check/assign hooks only supports one level of malloc. > > Using a List seems impossible. I don't know if you can safely do

Re: Improving on MAX_CONVERSION_GROWTH

Hi, On 2019-09-27 10:53:48 -0400, Robert Haas wrote: > A lot of that is because they hit the 1GB allocation limit, and I > wonder whether we shouldn't be trying harder to avoid imposing that > limit in multiple places. > It's reasonable - and necessary - to impose > a limit on the size of an

Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown)

On 2019-Sep-27, Alexey Kondratov wrote: > 1) Maybe I've missed it somewhere in the thread above, but currently > pg_rewind allows to run itself with -R and --source-pgdata. In that case -R > option is just swallowed and neither standby.signal, nor > postgresql.auto.conf is written, which is

Re: Standby accepts recovery_target_timeline setting?

Hi Peter, On 9/27/19 10:36 AM, Peter Eisentraut wrote: > On 2019-09-26 23:02, David Steele wrote: >> On 9/26/19 4:48 PM, Peter Eisentraut wrote: >> >>> I don't know if recovery_target_timeline is actually useful to change in >>> standby mode. > > OK, I have committed your original documentation

Re: Improving on MAX_CONVERSION_GROWTH

On Tue, Sep 24, 2019 at 5:15 PM Tom Lane wrote: > In any case, it seems likely that we could end up with a > multiplier of 1, 2, or 3 rather than 4 in just about every > case of practical interest. That sure seems like a win > when converting long strings. +1. From what I've seen, I'd say this

Re: Standby accepts recovery_target_timeline setting?

On 2019-09-26 23:02, David Steele wrote: > On 9/26/19 4:48 PM, Peter Eisentraut wrote: >> On 2019-09-25 22:21, David Steele wrote: >>> While testing against PG12 I noticed the documentation states that >>> recovery targets are not valid when standby.signal is present. >>> >>> But surely the

Re: abort-time portal cleanup

On Tue, Sep 24, 2019 at 4:45 PM Andres Freund wrote: > Hm. Doing that cleanup requires digging through all the portals etc. I'd > rather rely on less state being correct than more during FATAL > processing. I agree with the principle, but the advantage of removing the hash table entries is that

Re: Support for jsonpath .datetime() method

On 25.09.2019 22:55, Alexander Korotkov wrote: On Mon, Sep 23, 2019 at 10:05 PM Alexander Korotkov wrote: I've reordered the patchset. I moved the most debatable patch, which introduces and RR and changes parsing of YYY, YY and Y to the end. I think we have enough of time in this

Re: PostgreSQL12 and older versions of OpenSSL

On Fri, Sep 27, 2019 at 03:50:57PM +0200, Peter Eisentraut wrote: > On 2019-09-27 03:51, Michael Paquier wrote: >> Your patch does not issue a ereport(LOG/FATAL) in the event of a >> failure with SSL_CTX_set_max_proto_version(), which is something done >> when ssl_protocol_version_to_openssl()'s

Re: PostgreSQL12 and older versions of OpenSSL

On 2019-09-27 03:51, Michael Paquier wrote: > I have tested compilation of REL_12_STABLE with the top of OpenSSL > 0.9.8, 1.0.0, 1.0.1, 1.0.2, 1.1.0 and 1.1.1. Our SSL tests also pass > in all the setups I have tested. great > Your patch does not issue a ereport(LOG/FATAL) in the event of a >

Re: Cleanup code related to OpenSSL <= 0.9.6 in fe/be-secure-openssl.c

On 2019-09-27 05:23, Michael Paquier wrote: > While reviewing the area, I have bumped into the following bit in > fe-secure-openssl.c and be-secure-openssl.c: > -/* OpenSSL 0.96 does not support X509_V_FLAG_CRL_CHECK */ > -#ifdef X509_V_FLAG_CRL_CHECK > [... stuff ...] > > I think that

Re: Shared Memory: How to use SYSV rather than MMAP ?

Hi Tony, On 2019-Sep-27, REIX, Tony wrote: > Hello Thomas, Alvaro, > > Sorry for the late answer, I missed your message of September 10. (I'm > working on several different projects in parallel.) > Let me talk with Sylvie ASAP and see when I will be able to test it, probably > next week,

Re: pgbench - allow to create partitioned tables

On 2019-Sep-27, Amit Kapila wrote: > Thanks, Alvaro, both seem like good suggestions to me. However, there > are a few more things where your feedback can help: > a. With new options, we will partition pgbench_accounts and the > reason is that because that is the largest table. Do we need to

Re: Attempt to consolidate reading of XLOG page

On 2019-Sep-26, Antonin Houska wrote: > One comment on the remaining part of the series: > > Before this refactoring, the walsender.c:XLogRead() function contained these > lines > >/* > * After reading into the buffer, check that what we read was valid. > We do > * this

Re: pg_wal/RECOVERYHISTORY file remains after archive recovery

On Fri, Sep 27, 2019 at 8:41 PM Fujii Masao wrote: > > On Fri, Sep 27, 2019 at 7:16 PM Michael Paquier wrote: > > > > On Fri, Sep 27, 2019 at 05:58:21PM +0900, Fujii Masao wrote: > > > So you think that it's better to remove them just after > > > writeTimeLineHistory()? > > > Per the following

Re: pg_upgrade fails with non-standard ACL

On Fri, Sep 27, 2019 at 04:22:15PM +0900, Michael Paquier wrote: > On Thu, Sep 26, 2019 at 04:19:38PM -0400, Bruce Momjian wrote: > > On Thu, Sep 26, 2019 at 05:16:19PM -0300, Alvaro Herrera wrote: > >> On 2019-Sep-26, Bruce Momjian wrote: > >>> Well, right now, pg_upgrade --check succeeds, but

Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown)

On 27.09.2019 6:27, Paul Guo wrote: Secondarily, I see no reason to test connstr_source rather than just "conn" in the other patch; doing it the other way is more natural, since it's that thing that's tested as an argument. pg_rewind.c: Please put the new #include line

Re: Built-in connection pooler

New version of builtin connection pooler fixing handling messages of extended protocol. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/contrib/spi/refint.c b/contrib/spi/refint.c index adf0490..5c2095f 100644 ---

Re: pglz performance

On 2019-09-04 14:45, Andrey Borodin wrote: >> On 2019-09-04 11:22, Andrey Borodin wrote: What about the two patches? Which one is better? >>> On our observations pglz_decompress_hacked.patch is best for most of tested >>> platforms. >>> Difference is that pglz_decompress_hacked8.patch will

Re: pg_wal/RECOVERYHISTORY file remains after archive recovery

On Fri, Sep 27, 2019 at 7:16 PM Michael Paquier wrote: > > On Fri, Sep 27, 2019 at 05:58:21PM +0900, Fujii Masao wrote: > > So you think that it's better to remove them just after > > writeTimeLineHistory()? > > Per the following Sawada-san's comment, I was thinking that idea is > > basically >

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

On Fri, Sep 27, 2019 at 02:33:32PM +0530, Amit Kapila wrote: On Tue, Jan 9, 2018 at 7:55 AM Peter Eisentraut wrote: On 1/3/18 14:53, Tomas Vondra wrote: >> I don't see the need to tie this setting to maintenance_work_mem. >> maintenance_work_mem is often set to very large values, which could

Re: pg_wal/RECOVERYHISTORY file remains after archive recovery

On Fri, Sep 27, 2019 at 05:58:21PM +0900, Fujii Masao wrote: > So you think that it's better to remove them just after > writeTimeLineHistory()? > Per the following Sawada-san's comment, I was thinking that idea is basically > not good. And, RemoveNonParentXlogFiles() also removes garbage files

Re: let's kill AtSubStart_Notify

Correction - On Fri, Sep 27, 2019 at 3:11 PM Jeevan Ladhe wrote: > I ran your testcase and on my VM I get numbers like 3593.801 ms > without patch and 3593.801 with the patch, average of 5 runs each. > The runs were quite consistent. > 3593.801 ms without patch and 3213.809 with the patch,

Re: let's kill AtSubStart_Notify

> > I did not read the patch but run the same case what you have given and > I can see the similar improvement with the patch. > With the patch 8832.988, without the patch 10252.701ms (median of three > reading) > Possibly you had debug symbols enabled? With debug symbols enabled I also get about

Re: let's kill AtSubStart_Notify

Hi Robert, Generally, a subsystem can avoid needing a callback at subtransaction > start (or transaction start) by detecting new levels of > subtransactions at time of use. Yes I agree with this argument. > A typical practice is to maintain a > stack which has entries only for those

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

On Thu, Sep 26, 2019 at 11:37 PM Tomas Vondra wrote: > > On Wed, Sep 25, 2019 at 06:55:01PM +0530, Amit Kapila wrote: > >On Tue, Sep 3, 2019 at 4:30 AM Alvaro Herrera > >wrote: > >> > >> In the interest of moving things forward, how far are we from making > >> 0001 committable? If I understand

Re: Zedstore - compressed in-core columnar storage

Hi Ashutosh, Sorry I indeed missed your question, thanks for the reminder! On Wed, Sep 25, 2019 at 4:10 AM Ashutosh Sharma wrote: > > Further, the UPDATE operation on zedstore table is very slow. I think > > that's because in case of zedstore table we have to update all the > > btree data

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

On Tue, Jan 9, 2018 at 7:55 AM Peter Eisentraut wrote: > > On 1/3/18 14:53, Tomas Vondra wrote: > >> I don't see the need to tie this setting to maintenance_work_mem. > >> maintenance_work_mem is often set to very large values, which could > >> then have undesirable side effects on this use. > >

Re: pg_wal/RECOVERYHISTORY file remains after archive recovery

On Fri, Sep 27, 2019 at 5:09 PM Michael Paquier wrote: > > On Fri, Sep 27, 2019 at 01:51:25PM +0900, Masahiko Sawada wrote: > > On Thu, Sep 26, 2019 at 6:23 PM Fujii Masao wrote: > >> What about moving the logic that removes RECO VERYXLOG and > >> RECOVERYHISTORY from exitArchiveRecovery() and

Re: recovery starting when backup_label exists, but not recovery.signal

On Fri, Sep 27, 2019 at 4:07 PM Masahiko Sawada wrote: > > On Fri, Sep 27, 2019 at 3:36 AM David Steele wrote: > > > > On 9/24/19 1:25 AM, Fujii Masao wrote: > > > > > > When backup_label exists, the startup process enters archive recovery mode > > > even if recovery.signal file doesn't exist.

Re: recovery starting when backup_label exists, but not recovery.signal

On Fri, Sep 27, 2019 at 3:36 AM David Steele wrote: > > On 9/24/19 1:25 AM, Fujii Masao wrote: > > > > When backup_label exists, the startup process enters archive recovery mode > > even if recovery.signal file doesn't exist. In this case, the startup > > process > > tries to retrieve WAL files

Re: [PATCH] psql: add tab completion for \df slash command suffixes

On Wed, Sep 04, 2019 at 03:19:57PM +0900, Ian Barwick wrote: > Ah, good catch, I will update and resubmit. Ping. Ian, could you update and resubmit please? -- Michael signature.asc Description: PGP signature

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

On Thu, Aug 01, 2019 at 09:39:53PM +1200, Thomas Munro wrote: > Looks like some good actionable feedback. I've moved this patch to > September, and set it to "Waiting on Author". The patch is in this state for two months now, so I have switched it to "returned with feedback". The latest patch

Re: Implementing Incremental View Maintenance

On Tue, 17 Sep 2019 12:03:20 -0600 Paul Draper wrote: > Have you had any thoughts for more than two joined tables? > > Either there needs to be an quadratic number of joins, or intermediate join > results need to be stored and reused. I don't think that we need to store intermediate join

Re: pg_wal/RECOVERYHISTORY file remains after archive recovery

On Fri, Sep 27, 2019 at 01:51:25PM +0900, Masahiko Sawada wrote: > On Thu, Sep 26, 2019 at 6:23 PM Fujii Masao wrote: >> What about moving the logic that removes RECO VERYXLOG and >> RECOVERYHISTORY from exitArchiveRecovery() and performing it >> just before/after RemoveNonParentXlogFiles()?

Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )

Hello, I add further information. This issue also has a problem about *overflow checking*. The original code is as follows. src/backend/utils/adt/timestamp.c:3222 - if (result_double > PG_INT64_MAX || result_double < PG_INT64_MIN) ereport(ERROR,

RE: Shared Memory: How to use SYSV rather than MMAP ?

Hello Thomas, Alvaro, Sorry for the late answer, I missed your message of September 10. (I'm working on several different projects in parallel.) Let me talk with Sylvie ASAP and see when I will be able to test it, probably next week, Tuesday. Is that OK for you? Regards, Tony

Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hi, On 2019-09-25 22:11:51 -0700, Soumyadeep Chakraborty wrote: > Thank you very much for reviewing my patch! > > On Wed, Sep 25, 2019 at 1:02 PM Andres Freund wrote: > > IOW, wherever ExecComputeSlotInfo() is called, we should only actually > > push the expression step, when

Re: pg_upgrade fails with non-standard ACL

On Thu, Sep 26, 2019 at 04:19:38PM -0400, Bruce Momjian wrote: > On Thu, Sep 26, 2019 at 05:16:19PM -0300, Alvaro Herrera wrote: >> On 2019-Sep-26, Bruce Momjian wrote: >>> Well, right now, pg_upgrade --check succeeds, but the upgrade fails. I >>> am proposing, at a minimum, that pg_upgrade

Re: Unstable select_parallel regression output in 12rc1

Re: Tom Lane 2019-09-26 <12685.1569510...@sss.pgh.pa.us> > We haven't seen it in quite some time in HEAD, though I fear that's > just due to bad luck or change of timing of unrelated tests. The v13 package builds that are running every 6h here haven't seen a problem yet either, so the probability

Re: Refactoring of connection with password prompt loop for frontends

On Thu, Sep 26, 2019 at 10:06:27AM -0300, Alvaro Herrera wrote: > Hmm, you have an XXX comment that appears to need addressing; and I'd > add an explanation about the looping behavior to the comment atop the > new function. > > I see that vacuumlo and scripts/common retain their "have_password" >

Re: recovery starting when backup_label exists, but not recovery.signal

On Fri, Sep 27, 2019 at 3:36 AM David Steele wrote: > > On 9/24/19 1:25 AM, Fujii Masao wrote: > > > > When backup_label exists, the startup process enters archive recovery mode > > even if recovery.signal file doesn't exist. In this case, the startup > > process > > tries to retrieve WAL files

Re: Batch insert in CTAS/MatView code

On Thu, Sep 26, 2019 at 7:13 PM Alvaro Herrera wrote: > > On 2019-Sep-25, Asim R P wrote: > > > I reviewed your patch today. It looks good overall. My concern is that > > the ExecFetchSlotHeapTuple call does not seem appropriate. In a generic > > place such as createas.c, we should be using

Re: PATCH: standby crashed when replay block which truncated in standby but failed to truncate in master node

On Thu, Sep 26, 2019 at 01:13:56AM +0900, Fujii Masao wrote: > On Tue, Sep 24, 2019 at 10:41 AM Michael Paquier wrote: >> This also points out that there are other things to worry about than >> interruptions, as for example DropRelFileNodeLocalBuffers() could lead >> to an ERROR, and this happens