RE: Terminate the idle sessions

Dear Li, David, > Additionally, using postgres_fdw within the server doesn't cause issues, > its using postgres_fdw and the remote server having this setting set to zero > that causes a problem. I didn't know the fact that postgres_fdw can use within the server... Thanks. I read

Re: pgbench: option delaying queries till connections establishment?

I think the issue really is that, independent of PG lock contention, it'll take a while to establish all connections, and that starting to benchmark with only some connections established will create pretty pointless numbers. Yes. This is why I think that if we have some way to synchronize

Re: Deleting older versions in unique indexes to avoid page splits

On Sun, Nov 15, 2020 at 2:29 PM Victor Yegorov wrote: > TPS > --- > query | Master TPS | Patched TPS | diff > ++-+--- > UPDATE + SELECT | 2413 |2473 | +2.5% > 3 SELECT in txn | 19737 | 19545 | -0.9% > 15min SELECT

Re: list of extended statistics on psql

Hi Tomas, Thanks for your comments and also revising patches. On 2020/11/16 3:22, Tomas Vondra wrote: It's better to always post the whole patch series, so that cfbot can test it properly. Sending just 0003 separately kind breaks that. I now understand how "cfbot" works so that I'll take

Re: enable_incremental_sort changes query behavior

Hmm, I missed that other thread. That indeed seems like a bug in the same area already tweaked by ebb7ae839d033d0f2 for similar cases. The attached patch fixes this simply by adding is_parallel_safe to get_useful_pathkeys_for_relation - that does fix the reproducer, but I'm not entirely sure

Re: Add statistics to pg_stat_wal view for wal related parameter tuning

>> Thanks for your comments. >> >> You're understanding is almost the same as mine. >> It describes when not only backends but also other backgrounds initialize a >> new wal page, >> wal buffer's space is already used and there is no space. >> >>> 'Total number of times WAL data written to the

Re: Terminate the idle sessions

On Nov 17, 2020, at 10:53 AM, David G. Johnston mailto:david.g.johns...@gmail.com>> wrote: On Monday, November 16, 2020, Li Japin mailto:japi...@hotmail.com>> wrote: Consider setting this for specific users instead of as a server default. Client connections managed by connection poolers,

Re: Tab complete for CREATE OR REPLACE TRIGGER statement

Michael Paquier writes: > I don't think that this is a requirement for this thread, though. Agreed, I'm not trying to block this patch. Just wishing there were a better way. regards, tom lane

Re: Tab complete for CREATE OR REPLACE TRIGGER statement

On Mon, Nov 16, 2020 at 09:14:51PM -0500, Tom Lane wrote: > It's kind of depressing how repetitive the patch is. There's > probably not much to be done about that in the short run, but > it seems to point up the need to start thinking about how to > refactor tab-complete.c more thoroughly.

Re: Terminate the idle sessions

On Monday, November 16, 2020, Li Japin wrote: > > > Consider setting this for specific users instead of as a server default. > Client connections managed by connection poolers, or initiated indirectly > like those by a remote postgres_fdw using server, should probably be > excluded from this

Re: Add statistics to pg_stat_wal view for wal related parameter tuning

On 2020/11/16 18:24, Masahiro Ikeda wrote: On 2020-11-13 12:32, lchch1...@sina.cn wrote: Now, pg_stat_wal supports reset all informantion in WalStats using pg_stat_reset_shared('wal') function. Isn't it enough? Yes it ok, sorry I miss this infomation. OK. 3. I do not think it's a

RE: Disable WAL logging to speed up data loading

# It'd be helpful if you could send mails in text format, not HTML. From: David G. Johnston > For this case the fundamental feature that would seem to be required is an > ability for a transaction commit to return only after the system has ensured > that all of the new pages added to the

Re: Add statistics to pg_stat_wal view for wal related parameter tuning

On 2020/11/16 16:35, Masahiro Ikeda wrote: On 2020-11-12 14:58, Fujii Masao wrote: On 2020/11/06 10:25, Masahiro Ikeda wrote: On 2020-10-30 11:50, Fujii Masao wrote: On 2020/10/29 17:03, Masahiro Ikeda wrote: Hi, Thanks for your comments and advice. I updated the patch. On 2020-10-21

Re: Terminate the idle sessions

-- Best regards Japin Li On Nov 17, 2020, at 7:59 AM, David G. Johnston mailto:david.g.johns...@gmail.com>> wrote: On Mon, Nov 16, 2020 at 5:41 AM Li Japin mailto:japi...@hotmail.com>> wrote: Thanks for your review! Attached. Reading the doc changes: I'd rather not name postgres_fdw

Re: Tab complete for CREATE OR REPLACE TRIGGER statement

Michael Paquier writes: > On Mon, Nov 16, 2020 at 08:12:05AM +, Shinoda, Noriyoshi (PN Japan FSI) > wrote: >> Yesterday, OR REPLACE clause was provided to the CREATE TRIGGER >> statement, so I wrote a patch for tab completion for the psql >> command. > Thanks, the logic looks fine. I'll

Re: Tab complete for CREATE OR REPLACE TRIGGER statement

On Mon, Nov 16, 2020 at 08:12:05AM +, Shinoda, Noriyoshi (PN Japan FSI) wrote: > Yesterday, OR REPLACE clause was provided to the CREATE TRIGGER > statement, so I wrote a patch for tab completion for the psql > command. Thanks, the logic looks fine. I'll apply if there are no objections.

RE: Disable WAL logging to speed up data loading

From: Robert Haas > I'm also concerned about the way that this proposed feature interacts with > incremental backup capabilities that already exist in tools like pgBackRest, > EDB's BART, pg_probackup, and future things we might want to introduce into > core, along the lines of what I have

Re: Skip ExecCheckRTPerms in CTAS with no data

On Mon, Nov 16, 2020 at 04:01:33PM +0100, Peter Eisentraut wrote: > While this patch was nice enough to update the documentation about the > requirement of the INSERT privilege, this is maybe more confusing now: How > could a new table not have INSERT privilege? Yes, you can do that with >

Re: Add Information during standby recovery conflicts

On Mon, Nov 16, 2020 at 4:55 PM Drouvot, Bertrand wrote: > > Hi, > > On 11/16/20 6:44 AM, Masahiko Sawada wrote: > > Thank you for updating the patch. > > > > Here are review comments. > > > > + if (report_waiting && (!logged_recovery_conflict || > > new_status == NULL)) > > +

RE: Cache relation sizes?

On Tuesday, November 17, 2020 9:40 AM, Tsunkawa-san wrote: > From: Thomas Munro > > On Mon, Nov 16, 2020 at 11:01 PM Konstantin Knizhnik > > wrote: > > > I will look at your implementation more precisely latter. > > > > Thanks! Warning: I thought about making a thing like this for a > > while,

Re: Crash in virtual file descriptor FDDEBUG code

Greg Nancarrow writes: > While investigating a possible file-descriptor issue, I enabled the > FDDEBUG code in src/backend/storage/file/fd.c, only to find that it > resulted in a crash as soon as it was invoked. Yeah, I can imagine that code doesn't get tested often. > I've attached a small

RE: Cache relation sizes?

From: Thomas Munro > On Mon, Nov 16, 2020 at 11:01 PM Konstantin Knizhnik > wrote: > > I will look at your implementation more precisely latter. > > Thanks! Warning: I thought about making a thing like this for a > while, but the patch itself is only a one-day prototype, so I am sure > you

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On Mon, Nov 16, 2020 at 09:23:41PM -0300, Alvaro Herrera wrote: > I've been wondering if it would be sane/safe to do the WaitForFoo stuff > outside of any transaction. This needs to remain within a transaction as CIC holds a session lock on the parent table, which would not be cleaned up without

Re: remove spurious CREATE INDEX CONCURRENTLY wait

I am really unsure about the REINDEX CONCURRENTLY part of this, for two reasons: 1. It is not as good when reindexing multiple indexes, because we can only apply the flag if *all* indexes are "safe". Any unsafe index means we step down from it for the whole thing. This is probably not worth

Crash in virtual file descriptor FDDEBUG code

Hi Hackers, While investigating a possible file-descriptor issue, I enabled the FDDEBUG code in src/backend/storage/file/fd.c, only to find that it resulted in a crash as soon as it was invoked. It turns out the crash was in some logging code that was being passed a NULL fileName. I've attached a

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On 2020-Nov-09, Tom Lane wrote: > Michael Paquier writes: > >> + LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); > >> + MyProc->vacuumFlags |= PROC_IN_SAFE_IC; > >> + ProcGlobal->vacuumFlags[MyProc->pgxactoff] = > >> MyProc->vacuumFlags; > >> +

Re: Terminate the idle sessions

On Mon, Nov 16, 2020 at 5:41 AM Li Japin wrote: > Thanks for your review! Attached. > Reading the doc changes: I'd rather not name postgres_fdw explicitly, or at least not solely, as a reason for setting this to zero. Additionally, using postgres_fdw within the server doesn't cause issues,

Re: [PATCH] Covering SPGiST index

Pavel Borisov writes: > [ v10-0001-Covering-SP-GiST-index-support-for-INCLUDE-colum.patch ] I've started to review this, and I've got to say that I really disagree with this choice: + * If there are INCLUDE columns, they are stored after a key value, each + * starting from its own typalign

Re: PATCH: Batch/pipelining support for libpq

On Fri, Nov 13, 2020 at 5:38 PM Alvaro Herrera wrote: > Here's a v25. > > I made a few more changes to the docs per David's suggestions; I also > reordered the sections quite a bit. It's now like this: > * Batch Mode >* Using Batch Mode > * Issuing Queries > * Processing Results

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On Tue, Nov 17, 2020 at 5:52 AM Simon Riggs wrote: > > The docs are misleading for this feature, since they say: > "This option disables all page-skipping behavior, and is > intended to be used only when the contents of the visibility map are > suspect, which should happen only if there is a

Re: Cache relation sizes?

On Mon, Nov 16, 2020 at 11:01 PM Konstantin Knizhnik wrote: > I will look at your implementation more precisely latter. Thanks! Warning: I thought about making a thing like this for a while, but the patch itself is only a one-day prototype, so I am sure you can find many bugs... Hmm, I guess

Re: enable_incremental_sort changes query behavior

I've pushed the 0001 part, i.e. the main fix. Not sure about the other parts (comments and moving the code back to postgres_fdw) yet. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services Hi, Tomas! I'm still

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On Mon, Nov 16, 2020 at 1:52 PM Simon Riggs wrote: > The docs are misleading for this feature, since they say: > "This option disables all page-skipping behavior, and is > intended to be used only when the contents of the visibility map are > suspect, which should happen only if there is a

Re: pgbench: option delaying queries till connections establishment?

Hi, On 2020-11-17 00:09:34 +0300, Marina Polyakova wrote: > Sorry I'm not familiar with the internal architecture of snapshots, locks > etc. in postgres, but I wanted to ask - what exact kind of patch for fair > lwlocks do you want to offer to the community? I applied the 6-th version of > the

Re: pgbench: option delaying queries till connections establishment?

Hi, On 2020-11-14 20:07:38 +0300, Alexander Korotkov wrote: > Hmm... Let's see the big picture. You've recently committed a > patchset, which greatly improved the performance of GetSnapshotData(). > And you're making further improvements in this direction. But you're > getting trouble in

Re: pgbench: option delaying queries till connections establishment?

Hello! On 2020-11-14 20:07, Alexander Korotkov wrote: Hmm... Let's see the big picture. You've recently committed a patchset, which greatly improved the performance of GetSnapshotData(). And you're making further improvements in this direction. But you're getting trouble in measuring the

Re: [PATCH] remove deprecated v8.2 containment operators

On Fri, Nov 13, 2020 at 10:03:43AM -0500, Stephen Frost wrote: > * Magnus Hagander (mag...@hagander.net) wrote: > > On Thu, Nov 12, 2020 at 11:28 PM Tom Lane wrote: > > > > The changes to the contrib modules appear to be incomplete in some ways. > > > > In cube, hstore, and seg, there are no

VACUUM (DISABLE_PAGE_SKIPPING on)

The docs are misleading for this feature, since they say: "This option disables all page-skipping behavior, and is intended to be used only when the contents of the visibility map are suspect, which should happen only if there is a hardware or software issue causing database corruption." The docs

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On 2020-Nov-16, Dmitry Dolgov wrote: > The same with reindex without locks: > > nsecs : count distribution >512 -> 1023 : 0|| > 1024 -> 2047 : 111345 || >

Re: Support for NSS as a libpq TLS backend

On Nov 13, 2020, at 4:14 AM, Daniel Gustafsson wrote: >> On 12 Nov 2020, at 23:12, Jacob Champion wrote: >> >> I'm not completely sure why this is exposed so easily with an OpenSSL >> server -- I'm guessing the implementation slices up its packets >> differently on the wire, causing a read

Re: Tracking cluster upgrade and configuration history

> On Nov 15, 2020, at 11:23 PM, Ian Lawrence Barwick wrote: > > 2020年11月16日(月) 15:48 Bharath Rupireddy > : >> >> On Thu, Nov 12, 2020 at 4:01 AM Mark Dilger >> wrote: >>> >>> While supporting customers, it would frequently be useful to have more >>> information about the history of a

Re: Tracking cluster upgrade and configuration history

> On Nov 15, 2020, at 10:47 PM, Bharath Rupireddy > wrote: > > On Thu, Nov 12, 2020 at 4:01 AM Mark Dilger > wrote: >> >> While supporting customers, it would frequently be useful to have more >> information about the history of a cluster. For example, which prior >> versions were ever

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On Tue, 10 Nov 2020 at 03:02, Tom Lane wrote: > > Alvaro Herrera writes: > > Yeah ... it would be much better if we can make it use atomics instead. > > I was thinking more like "do we need any locking at all". > > Assuming that a proc's vacuumFlags can be set by only the process itself, >

Re: remove spurious CREATE INDEX CONCURRENTLY wait

> On Fri, Nov 13, 2020 at 09:25:40AM +0900, Michael Paquier wrote: > On Thu, Nov 12, 2020 at 04:36:32PM +0100, Dmitry Dolgov wrote: > > Interesting enough, similar discussion happened about vaccumFlags before > > with the same conclusion that theoretically it's fine to update without > > holding

Re: planner support functions: handle GROUP BY estimates ?

On 1/15/20 12:44 AM, Tom Lane wrote: > Tomas Vondra writes: >> On Tue, Jan 14, 2020 at 05:37:53PM -0500, Tom Lane wrote: >>> I wonder just how messy it would be to add a column to pg_statistic_ext >>> whose type is the composite type "pg_statistic", and drop the required >>> data into that.

Re: Zedstore - compressed in-core columnar storage

On Mon, Nov 16, 2020 at 10:07 AM Tomas Vondra wrote: > > > On 11/16/20 1:59 PM, Merlin Moncure wrote: > > On Thu, Nov 12, 2020 at 4:40 PM Tomas Vondra > > wrote: > >>masterzedstore/pglzzedstore/lz4 > >> - > >>copy

Re: Heads-up: macOS Big Sur upgrade breaks EDB PostgreSQL installations

On Mon, Nov 16, 2020 at 4:45 PM Pavel Borisov wrote: > I suppose there are many ways to have PG on OSX i.e. package managers > (Homebrew, Macports), App installers etc and so many places anyone can find > his data directory reside in. Generally I prefer data directory to be > somewhere inside

Re: [PATCH] Add features to pg_stat_statements

On 2020/11/16 12:22, Seino Yuki wrote: Thanks for updating the patch! +    pgss_info->dealloc = 0; +    SpinLockInit(_info->mutex); +    Assert(pgss_info->dealloc == 0); Why is this assertion check necessary? It seems not necessary. +    { +    Assert(found == found_info);

Re: Heads-up: macOS Big Sur upgrade breaks EDB PostgreSQL installations

I suppose there are many ways to have PG on OSX i.e. package managers (Homebrew, Macports), App installers etc and so many places anyone can find his data directory reside in. Generally I prefer data directory to be somewhere inside the user home dir as OSX will take care of possible backups and

Re: doc CREATE INDEX

On Mon, Nov 16, 2020 at 11:04:57AM -0300, Álvaro Herrera wrote: > On 2020-Nov-16, Erik Rijkers wrote: > > > This one seems to have fallen by the wayside. > > So it did. > > Pushed to all three branches, thanks. I have applied with to PG 9.5-11, which also had the odd wording. -- Bruce

Re: [PATCH] remove deprecated v8.2 containment operators

On 2020-11-13 16:57, Tom Lane wrote: Peter Eisentraut writes: On 2020-11-12 23:28, Tom Lane wrote: I'm on board with pulling these now --- 8.2 to v14 is plenty of deprecation notice. However, the patch seems incomplete in that the code support for these is still there -- look for

Re: Heads-up: macOS Big Sur upgrade breaks EDB PostgreSQL installations

On Mon, Nov 16, 2020 at 3:55 PM Jonathan S. Katz wrote: > On 11/16/20 4:27 AM, Dave Page wrote: > > Hi, > > > > This is more of a head-ups than anything else, as I suspect this may > > come up in various forums. > > > > The PostgreSQL installers for macOS (from EDB, possibly others too) > >

Re: Zedstore - compressed in-core columnar storage

On 11/16/20 1:59 PM, Merlin Moncure wrote: > On Thu, Nov 12, 2020 at 4:40 PM Tomas Vondra > wrote: >>masterzedstore/pglzzedstore/lz4 >> - >>copy 1855680922131 >>dump 751

Re: Cache relation sizes?

On 16.11.2020 10:11, Thomas Munro wrote: On Tue, Aug 4, 2020 at 2:21 PM Thomas Munro wrote: On Tue, Aug 4, 2020 at 3:54 AM Konstantin Knizhnik wrote: This shared relation cache can easily store relation size as well. In addition it will solve a lot of other problems: - noticeable overhead

Re: Heads-up: macOS Big Sur upgrade breaks EDB PostgreSQL installations

On 11/16/20 4:27 AM, Dave Page wrote: > Hi, > > This is more of a head-ups than anything else, as I suspect this may > come up in various forums. > > The PostgreSQL installers for macOS (from EDB, possibly others too) > create the data directory in /Library/PostgreSQL//data. This > has been the

Re: Multi Inserts in CREATE TABLE AS - revived patch

On Mon, Nov 16, 2020 at 8:02 PM Paul Guo wrote: > > > On Nov 13, 2020, at 7:21 PM, Bharath Rupireddy > > wrote: > > > > On Tue, Nov 10, 2020 at 3:47 PM Paul Guo wrote: > >> > >> Thanks for doing this. There might be another solution - use raw insert > >> interfaces (i.e. raw_heap_insert()). >

Re: PoC/WIP: Extended statistics on expressions

On 11/16/20 2:49 PM, Tomas Vondra wrote: > Hi, > > ... > > 4) apply the statistics > >This is the hard part, really, and the exact state of the support >depends on type of statistics. > >For ndistinct coefficients, it generally works. I'm sure there may be >bugs in

Re: Add important info about ANALYZE after create Functional Index

On Mon, Nov 16, 2020 at 11:59:03AM -0300, Álvaro Herrera wrote: > On 2020-Nov-12, Bruce Momjian wrote: > > > For new expression indexes, it is necessary to run > linkend="sql-analyze">ANALYZE or wait for > > the autovacuum daemon to analyze > > - the table to generate statistics

Re: default result formats setting

On 11/9/20 5:10 AM, Peter Eisentraut wrote: > On 2020-11-05 22:03, Peter Eisentraut wrote: >>> Independently of that, how would you implement "says otherwise" here, >>> ie do a single-query override of the session's prevailing setting? >>> Maybe the right thing for that is to define -1 all the

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

Magnus Hagander writes: > I agree with those -- either we remove the ability to choose random source > independently of the SSL library (and then only use the windows crypto > provider or /dev/urandom as platform-specific choices when *no* SSL library > is used), and in that case we should not

Re: Skip ExecCheckRTPerms in CTAS with no data

On 2020-11-16 04:04, Michael Paquier wrote: On Fri, Nov 13, 2020 at 12:58:52PM +0530, Bharath Rupireddy wrote: It's not required to set bistate to null as we have allocated myState with palloc0 in CreateIntoRelDestReceiver, it will anyways be null. if (!into->skipData)

Re: Add important info about ANALYZE after create Functional Index

On 2020-Nov-16, Justin Pryzby wrote: > I see Alvaro already patched the first issue at bcbd77133. > > The problematic language was recently introduced, and I'd reported at: > https://www.postgresql.org/message-id/20201112211143.GL30691%40telsasoft.com > And Erik at: >

Re: Add important info about ANALYZE after create Functional Index

On 2020-Nov-12, Bruce Momjian wrote: > For new expression indexes, it is necessary to run linkend="sql-analyze">ANALYZE or wait for > the autovacuum daemon to analyze > - the table to generate statistics about new expression indexes. > + the table to generate statistics for these

Re: Multi Inserts in CREATE TABLE AS - revived patch

> On Nov 13, 2020, at 7:21 PM, Bharath Rupireddy > wrote: > > On Tue, Nov 10, 2020 at 3:47 PM Paul Guo wrote: >> >> Thanks for doing this. There might be another solution - use raw insert >> interfaces (i.e. raw_heap_insert()). >> Attached is the test (not formal) patch that verifies this

Re: cutting down the TODO list thread

On Wed, Nov 11, 2020 at 4:45 PM John Naylor wrote: > Here is the next section on data types, proposed to be moved to the "not > worth doing" page. As before, if there are any objections, do speak up. > I'll make the move in a few days. > Hearing no objection, these have been moved over. --

Re: doc CREATE INDEX

On 2020-Nov-16, Erik Rijkers wrote: > This one seems to have fallen by the wayside. So it did. Pushed to all three branches, thanks.

Re: Add important info about ANALYZE after create Functional Index

On Thu, Nov 12, 2020 at 06:01:02PM -0500, Bruce Momjian wrote: > On Thu, Nov 12, 2020 at 03:11:43PM -0600, Justin Pryzby wrote: > > I guess it should say "The system regularly ..." > > > > Also, the last sentence begins "For new expression indexes" and ends with > > "about new expression

Re: Zedstore - compressed in-core columnar storage

On Thu, Nov 12, 2020 at 4:40 PM Tomas Vondra wrote: >masterzedstore/pglzzedstore/lz4 > - >copy 1855680922131 >dump 751 905 811 > > And the size of the lineitem

Re: More time spending with "delete pending"

On Sun, Nov 15, 2020 at 4:00 PM Alexander Lakhin wrote: > As I've found out, readdir() replacement for Windows in fact gets all > the needed information (correct file size, attributes...) in > WIN32_FIND_DATA, but it just leaves it inside and returns only fields of > the dirent structure. So

Re: ECPG: proposal for new DECLARE STATEMENT

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Recently I have been doing some work on ecpg. So I review

Re: Terminate the idle sessions

Hi Kuroda, On Nov 16, 2020, at 1:22 PM, kuroda.hay...@fujitsu.com wrote: @@ -30,6 +30,7 @@ typedef enum TimeoutId STANDBY_DEADLOCK_TIMEOUT, STANDBY_TIMEOUT, STANDBY_LOCK_TIMEOUT, + IDLE_SESSION_TIMEOUT, IDLE_IN_TRANSACTION_SESSION_TIMEOUT, /* First

doc CREATE INDEX

This one seems to have fallen by the wayside. Erik --- doc/src/sgml/ref/create_index.sgml.orig 2020-11-16 13:04:29.923760413 +0100 +++ doc/src/sgml/ref/create_index.sgml 2020-11-16 13:04:54.260093095 +0100 @@ -746,7 +746,7 @@ - The regularly system collects statistics on all of a

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hi! On Mon, Nov 16, 2020 at 1:09 PM wrote: > I've changed the BEGIN WAIT FOR LSN statement to core functions > pg_waitlsn, pg_waitlsn_infinite and pg_waitlsn_no_wait. > Currently the functions work inside repeatable read transactions, but > waitlsn creates a snapshot if called first in a

Re: Evaluate expression at planning time for two more cases

Thank you for working on this! I got slightly into this patch. I can be wrong, but my opinion is that planner/optimizer-related changes are not without dangers generally. So anyway, they should be justified by performance increase, or the previous behavior should be considered totally wrong.

Re: Get memory contexts of an arbitrary backend process

On 2020-10-28 15:32, torikoshia wrote: On 2020-10-23 13:46, Kyotaro Horiguchi wrote: I think we might need to step-back to basic design of this feature since this patch seems to have unhandled corner cases that are difficult to find. I've written out the basic design below and attached

Re: Online verification of checksums

On Mon, Nov 16, 2020 at 1:23 AM Michael Paquier wrote: > On Sun, Nov 15, 2020 at 04:37:36PM +0100, Magnus Hagander wrote: > > On Tue, Nov 10, 2020 at 5:44 AM Michael Paquier > wrote: > >> On Thu, Nov 05, 2020 at 10:57:16AM +0900, Michael Paquier wrote: > >>> I was referring to the patch I sent

Re: Split copy.c

On 16/11/2020 04:28, Justin Pryzby wrote: On Tue, Nov 03, 2020 at 03:15:27PM +1300, David Rowley wrote: On Tue, 3 Nov 2020 at 07:35, Andres Freund wrote: On 2020-11-02 19:43:38 +0200, Heikki Linnakangas wrote: On 02/11/2020 19:23, Andres Freund wrote: On 2020-11-02 11:03:29 +0200, Heikki

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hello, I've changed the BEGIN WAIT FOR LSN statement to core functions pg_waitlsn, pg_waitlsn_infinite and pg_waitlsn_no_wait. Currently the functions work inside repeatable read transactions, but waitlsn creates a snapshot if called first in a transaction block, which can possibly lead the

Re: Cache relation sizes?

On 16.11.2020 10:11, Thomas Munro wrote: On Tue, Aug 4, 2020 at 2:21 PM Thomas Munro wrote: On Tue, Aug 4, 2020 at 3:54 AM Konstantin Knizhnik wrote: This shared relation cache can easily store relation size as well. In addition it will solve a lot of other problems: - noticeable overhead

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

On Mon, Nov 16, 2020 at 4:25 PM Ajin Cherian wrote: > > Updated with a new test case > (contrib/test_decoding/t/002_twophase-streaming.pl) that tests > concurrent aborts during streaming prepare. Had to make a few changes > to the test_decoding stream_start callbacks to handle >

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

On Mon, Nov 16, 2020 at 10:19 AM Daniel Gustafsson wrote: > > On 16 Nov 2020, at 01:20, Michael Paquier wrote: > > > > On Sun, Nov 15, 2020 at 12:16:56PM -0500, Tom Lane wrote: > >> The obvious problem with this is that if !USE_OPENSSL, we will not have > >> pulled in openssl's headers. > > > >

Re: Delay of standby shutdown

On 2020/11/13 2:58, Soumyadeep Chakraborty wrote: Thanks! Marking this as ready for committer. Pushed. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION

Heads-up: macOS Big Sur upgrade breaks EDB PostgreSQL installations

Hi, This is more of a head-ups than anything else, as I suspect this may come up in various forums. The PostgreSQL installers for macOS (from EDB, possibly others too) create the data directory in /Library/PostgreSQL//data. This has been the case since the first release, 10+ years ago. It looks

Re: Add statistics to pg_stat_wal view for wal related parameter tuning

On 2020-11-13 12:32, lchch1...@sina.cn wrote: Now, pg_stat_wal supports reset all informantion in WalStats using pg_stat_reset_shared('wal') function. Isn't it enough? Yes it ok, sorry I miss this infomation. OK. 3. I do not think it's a correct describe in document for 'wal_buffers_full'.

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

> On 16 Nov 2020, at 01:20, Michael Paquier wrote: > > On Sun, Nov 15, 2020 at 12:16:56PM -0500, Tom Lane wrote: >> The obvious problem with this is that if !USE_OPENSSL, we will not have >> pulled in openssl's headers. > > FWIW, I argued upthread against including this part because it is >

Tab complete for CREATE OR REPLACE TRIGGER statement

Hi, Hackers. Yesterday, OR REPLACE clause was provided to the CREATE TRIGGER statement, so I wrote a patch for tab completion for the psql command. TRIGGER adds tab completion to the CREATE OR REPLACE statement, and the CREATE TRIGGER and CREATE OR REPLACE TRIGGER statements are completed in

Re: [PATCH] remove pg_archivecleanup and pg_standby

On Tue, Nov 03, 2020 at 05:28:46PM +0200, Heikki Linnakangas wrote: > Removing pg_standby has been proposed a couple of times in the past. See > https://www.postgresql.org/message-id/20170913064824.rqflkadxwpboa...@alap3.anarazel.de > for the latest attempt. > > Masao-san, back in 2014 you