Re: Add information to rm_redo_error_callback()

On Tue, 11 Aug 2020 at 00:07, Drouvot, Bertrand wrote: > > Hi, > > On 8/10/20 7:10 AM, 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: Hybrid Hash/Nested Loop joins and caching results from subplans

Hi, On 2020-08-11 17:23:42 +1200, David Rowley wrote: > On Tue, 11 Aug 2020 at 12:21, Andres Freund wrote: > > > > On 2020-07-09 10:25:14 +1200, David Rowley wrote: > > > On Thu, 9 Jul 2020 at 04:53, Andres Freund wrote: > > > > I'm not convinced it's a good idea to introduce a separate

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

On Sun, Aug 09, 2020 at 09:24:43PM -0500, Justin Pryzby wrote: > That part of your patch handles REINDEX and REINDEX(*) differently than mine. > Yours is technically more correct/complete. But, I recall Tom objected a > different patch because of completing to a single char. I think the case is

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

On Tue, 11 Aug 2020 at 12:21, Andres Freund wrote: > > On 2020-07-09 10:25:14 +1200, David Rowley wrote: > > On Thu, 9 Jul 2020 at 04:53, Andres Freund wrote: > > > I'm not convinced it's a good idea to introduce a separate executor node > > > for this. There's a fair bit of overhead in them,

Re: stress test for parallel workers

On Tue, Jul 28, 2020 at 3:27 PM Tom Lane wrote: > Anyway, I guess the interesting question for us is how long it > will take for this fix to propagate into real-world systems. > I don't have much of a clue about the Linux kernel workflow, > anybody want to venture a guess? Me neither. It just

Re: Terminate the idle sessions

Hi, On Aug 11, 2020, at 5:42 AM, Cary Huang mailto:cary.hu...@highgo.ca>> wrote: I applied this patch to the PG13 branch and generally this feature works as described. The new "idle_session_timeout" that controls the idle session disconnection is not in the default postgresql.conf and I think

Can I test Extended Query in core test framework

I want to write some test cases with extended query in core test system. basically it looks like PreparedStatement preparedStatement = conn.prepareStatement("select * from bigtable"); preparedStatement.setFetchSize(4); ResultSet rs = preparedStatement.executeQuery(); while(rs.next()) {

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

On Mon, Aug 10, 2020 at 8:46 PM Tom Lane wrote: > It's certainly arguable that PG_ENSURE_ERROR_CLEANUP is a special > snowflake and needs to use a separate mechanism. What is not real clear > to me is why there are any other callers that must use before_shmem_exit > rather than on_shmem_exit ---

RE: Libpq support to connect to standby server as priority

Hi Greg, I have spent some time reading this discussion thread, and doing a code review of the latest (v17-0001) patch. Below are my review comments; some are trivial, others not so much. GENERAL COMMENT 1 ("any") "any" should be included as valid option for target_server_type. IIUC

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On Mon, Aug 10, 2020 at 8:37 PM Tom Lane wrote: > > Alvaro Herrera writes: > > To recap: currently, any CREATE INDEX CONCURRENTLY will wait for all > > other CICs running concurrently to finish, because they can't be > > distinguished amidst other old snapshots. We can change things by > >

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

Andres Freund writes: > I think there's two different aspects here: Having before_shmem_exit(), > and having cancel_before_shmem_exit(). We could just not have the > latter, and instead use a separate list for PG_ENSURE_ERROR_CLEANUP > internally. With the callback for PG_ENSURE_ERROR_CLEANUP

Re: Add LWLock blocker(s) information

Hi, On 2020-08-10 18:27:17 -0400, Robert Haas wrote: > On Tue, Jun 2, 2020 at 8:25 AM Drouvot, Bertrand wrote: > > the patch adds into the LWLock struct: > > > > last_holding_pid: last pid owner of the lock > > last_mode: last holding mode of the last pid

Re: remove spurious CREATE INDEX CONCURRENTLY wait

Alvaro Herrera writes: > To recap: currently, any CREATE INDEX CONCURRENTLY will wait for all > other CICs running concurrently to finish, because they can't be > distinguished amidst other old snapshots. We can change things by > having CIC set a special flag in PGPROC (like PROC_IN_VACUUM)

Re: walsender waiting_for_ping spuriously set

On 2020-08-06 18:55:58 -0400, Alvaro Herrera wrote: > Ashutosh Bapat noticed that WalSndWaitForWal() is setting > waiting_for_ping_response after sending a keepalive that does *not* > request a reply. The bad consequence is that other callers that do > require a reply end up in not sending a

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

Hi, On 2020-07-09 10:25:14 +1200, David Rowley wrote: > On Thu, 9 Jul 2020 at 04:53, Andres Freund wrote: > > > > On 2020-05-20 23:44:27 +1200, David Rowley wrote: > > > I've attached a patch which implements this. The new node type is > > > called "Result Cache". I'm not particularly wedded

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

Hi, On 2020-08-10 15:50:19 -0400, Robert Haas wrote: > On Mon, Aug 10, 2020 at 3:41 PM Tom Lane wrote: > > > What I do think we should do, after thinking about it more, > > > is discourage the casual use of before_shmem_exit() for things where > > > on_shmem_exit() or on_proc_exit() would be

Re: remove spurious CREATE INDEX CONCURRENTLY wait

+ James Coleman -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

remove spurious CREATE INDEX CONCURRENTLY wait

I previously[1] posted a patch to have multiple CREATE INDEX CONCURRENTLY not wait for the slowest of them. This is an update of that, with minor conflicts fixed and a fresh thread. To recap: currently, any CREATE INDEX CONCURRENTLY will wait for all other CICs running concurrently to finish,

massive FPI_FOR_HINT load after promote

Last week, James reported to us that after promoting a replica, some seqscan was taking a huge amount of time; on investigation he saw that there was a high rate of FPI_FOR_HINT wal messages by the seqscan. Looking closely at the generated traffic, HEAP_XMIN_COMMITTED was being set on some tuples.

Re: Add LWLock blocker(s) information

On Tue, Jun 2, 2020 at 8:25 AM Drouvot, Bertrand wrote: > the patch adds into the LWLock struct: > > last_holding_pid: last pid owner of the lock > last_mode: last holding mode of the last pid owner of the > lock > nholders: number of

Re: Terminate the idle sessions

On Mon, Aug 10, 2020 at 2:43 PM Cary Huang wrote: > There is currently no enforced minimum value for "idle_session_timeout" > (except for value 0 for disabling the feature), so user can put any value > larger than 0 and it could be very small like 500 or even 50 millisecond, > this would make

Re: Terminate the idle sessions

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 I applied this patch to the PG13 branch and generally this

Re: nested queries vs. pg_stat_activity

Hi po 10. 8. 2020 v 22:21 odesílatel Robert Haas napsal: > On Mon, Aug 10, 2020 at 4:09 PM Magnus Hagander > wrote: > > Would it even solve the problem for them? pg_stat_statements collects > aggregate stats and not a view of what's happening right now -- so it'd be > mixing two different

Re: nested queries vs. pg_stat_activity

On Mon, Aug 10, 2020 at 4:09 PM Magnus Hagander wrote: > Would it even solve the problem for them? pg_stat_statements collects > aggregate stats and not a view of what's happening right now -- so it'd be > mixing two different types of values. And it would get worse if the same > thing is

Re: Allow some recovery parameters to be changed with reload

On Sun, Aug 9, 2020 at 1:21 AM Michael Paquier wrote: > Sorry for the late reply. I have been looking at that stuff again, > and restore_command can be called in the context of a WAL sender > process within the page_read callback of logical decoding via > XLogReadDetermineTimeline(), as

Re: nested queries vs. pg_stat_activity

On Mon, Aug 10, 2020 at 9:51 PM Robert Haas wrote: > On Mon, Aug 10, 2020 at 12:51 PM legrand legrand > wrote: > > An other solution is to expose nested queryid, and to join it with > pg_stat_statements. > > Actual development trying to add queryid to pg_stat_activity isn't > helpfull, because

Re: nested queries vs. pg_stat_activity

On Mon, Aug 10, 2020 at 12:51 PM legrand legrand wrote: > An other solution is to expose nested queryid, and to join it with > pg_stat_statements. > Actual development trying to add queryid to pg_stat_activity isn't helpfull, > because it is only exposing top level one. > Extension

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

On Mon, Aug 10, 2020 at 3:41 PM Tom Lane wrote: > Robert Haas writes: > > Perhaps we really have four categories here: > > (1) Temporary handlers for PG_ENSURE_ERROR_CLEANUP(). > > (2) High-level cleanup that needs to run after aborting out of the > > current transaction. > > (3) Per-subsystem

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

Robert Haas writes: > Perhaps we really have four categories here: > (1) Temporary handlers for PG_ENSURE_ERROR_CLEANUP(). > (2) High-level cleanup that needs to run after aborting out of the > current transaction. > (3) Per-subsystem shutdown for shared memory stuff. > (4) Per-subsystem shutdown

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

On Mon, Aug 10, 2020 at 10:44 AM Tom Lane wrote: > I agree that doing nothing seems like a bad idea. My concern about > allowing non-LIFO callback removal is that it seems to me that such > usage patterns have likely got *other* bugs, so we should discourage > that. These callbacks don't exist

Re: pendingOps table is not cleared with fsync=off

Shawn Debnath writes: > Good catch. Question is, are the users aware of the requirement to do a > manual fsync if they flip the fsync GUC off and then on? Should we do > this on their behalf to make a good faith attempt to ensure things are > flushed properly via an assign hook? No. Or at

Re: [BUG] Error in BRIN summarization

On 30.07.2020 16:40, Anastasia Lubennikova wrote: While testing this fix, Alexander Lakhin spotted another problem. After a few runs, it will fail with "ERROR: corrupted BRIN index: inconsistent range map" The problem is caused by a race in page locking in brinGetTupleForHeapBlock [1]:

nested queries vs. pg_stat_activity

Hello, An other solution is to expose nested queryid, and to join it with pg_stat_statements. Actual development trying to add queryid to pg_stat_activity isn't helpfull, because it is only exposing top level one. Extension pg_stat_sql_plans (github) propose a function called

Re: [PATCH] Covering SPGiST index

Same code formatted as a patch. пн, 10 авг. 2020 г. в 17:45, Pavel Borisov : > Also little bit corrected code formatting. > >> Best regards, >> Pavel Borisov >> >> Postgres Professional: http://postgrespro.com >> >> > v3-0001-Covering-SpGist.patch Description:

Re: nested queries vs. pg_stat_activity

On Mon, Aug 10, 2020 at 4:37 PM Robert Haas wrote: > Is there a way that we can show information about nested queries in > pg_stat_activity? It's often inconvenient for users when somebody's > executing a function and it doesn't seem to be finishing as quickly as > anticipated. You can't really

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

Robert Haas writes: > Well, I don't really care whether or not we change this function to > iterate over the callback list or whether we add a warning that you > need to use it in LIFO order, but I think we should do one or the > other, because this same confusion has come up multiple times. I >

nested queries vs. pg_stat_activity

Is there a way that we can show information about nested queries in pg_stat_activity? It's often inconvenient for users when somebody's executing a function and it doesn't seem to be finishing as quickly as anticipated. You can't really tell where in that function things broke down. There are a

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

On Fri, Aug 7, 2020 at 5:20 PM Andres Freund wrote: > In which situations is the removal actually useful *and* safe, with > these constraints? You'd have to have a very narrow set of functions > that are called while the exit hook is present, i.e. basically this > would only be usable for

Re: [PATCH] Covering SPGiST index

Also little bit corrected code formatting. > Best regards, > Pavel Borisov > > Postgres Professional: http://postgrespro.com > spgist-covering-0003.diff Description: Binary data

Re: [PATCH] Add section headings to index types doc

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:tested, passed a) I'm wondering if we should apply one more change to this page. The

Re: problem with RETURNING and update row movement

On Fri, Aug 7, 2020 at 10:45 PM Etsuro Fujita wrote: > On Mon, Aug 3, 2020 at 4:39 PM Amit Langote wrote: > > On Mon, Aug 3, 2020 at 2:54 PM Amit Langote wrote: > > > By the way, you'll need two adjustments to even get this example > > > working, one of which is a reported problem that system

Re: Parallel worker hangs while handling errors.

On Fri, Aug 7, 2020 at 11:30 PM Tom Lane wrote: > > Robert Haas writes: > > On Fri, Aug 7, 2020 at 12:56 PM Tom Lane wrote: > >> That SETMASK call will certainly unblock SIGQUIT, so I don't see what > >> your point is. > > > I can't figure out if you're trolling me here or what. It's true that

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

On Fri, Aug 7, 2020 at 11:09 PM Robert Haas wrote: > > On Fri, Aug 7, 2020 at 1:12 PM Tom Lane wrote: > > That's a meaningless statement for any one caller. So it needs to be more > > like "we expect callers to add and remove temporary before_shmem_exit > > callbacks in strict LIFO order". > >

Re: FETCH FIRST clause PERCENT option

Hi > PERCENT and WITH TIES can play together, per spec. > I also Implement PERCENT WITH TIES option. patch is attached i don't start a new tread because the patches share common code regards Surafel diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c index

Re: Unnecessary delay in streaming replication due to replay lag

> On 10-Aug-2020, at 12:27 PM, Masahiko Sawada > wrote: > > The patch can be applied cleanly to the current HEAD but I got the > error on building the code with this patch: > > xlog.c: In function 'StartupXLOG': > xlog.c:7315:6: error: too few arguments to function 'RequestXLogStreaming' >

Re: public schema default ACL

On Thu, Aug 6, 2020 at 3:34 PM Stephen Frost wrote: > Greetings, > > * Magnus Hagander (mag...@hagander.net) wrote: > > On Mon, Aug 3, 2020 at 5:26 PM Stephen Frost wrote: > > > * Noah Misch (n...@leadboat.com) wrote: > > > > I'd like to reopen this. Reception was mixed, but more in favor than

Re: [PATCH] Covering SPGiST index

> > On a first glance the whole concept of non-multicolumn index with included > attributes seems...well, just difficult to understand. > But I expect for SP-GiST this must be single key with multiple included > attributes, right? > I couldn't find a test that checks impossibility of on 2-column

Re: Unnecessary delay in streaming replication due to replay lag

On Sun, 9 Aug 2020 at 14:54, Asim Praveen wrote: > > I would like to revive this thready by submitting a rebased patch to start > streaming replication without waiting for startup process to finish replaying > all WAL. The start LSN for streaming is determined to be the LSN that points > to

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

On 2020-07-07 01:08, Tom Lane wrote: Alvaro Herrera writes: On 2020-Jul-05, Anna Akenteva wrote: -- Swapping primary key's index for an equivalent index, -- but with INCLUDE-d attributes. CREATE UNIQUE INDEX new_idx ON target_tbl (id) INCLUDE (info); ALTER TABLE target_tbl ALTER CONSTRAINT