Re: jit and explain nontext

On 2020-11-20 17:16, Justin Pryzby wrote: It matters if it was planned with jit but executed without jit. postgres=# DEALLOCATE p; SET jit=on; SET jit_above_cost=0; prepare p as select from generate_series(1,9); explain(format yaml) execute p; SET jit=off; explain(format yaml) execute p;

Re: [doc] improve tableoid description

On 2020-10-19 14:28, Ian Lawrence Barwick wrote: On further reflection, I think trying to explain all that is going to end up as a mini-tutorial which is beyond the scope of the explanation of a column, so the existing reference to pg_class should be enough. Revised patch attached just

Re: Removal of currtid()/currtid2() and some table AM cleanup

On Fri, Nov 20, 2020 at 09:50:08PM -0500, Tom Lane wrote: > Michael Paquier writes: >> What about cutting the cake in two and just remove >> currtid() then? > > +1. That'd still let us get rid of setLastTid() which is > the ugliest part of the thing, IMO. Indeed, this could go. There is a

Re: Removal of currtid()/currtid2() and some table AM cleanup

Michael Paquier writes: > What about cutting the cake in two and just remove > currtid() then? +1. That'd still let us get rid of setLastTid() which is the ugliest part of the thing, IMO. regards, tom lane

Fix generate_useful_gather_paths for parallel unsafe pathkeys

Over on the -bugs list we had a report [1] of a seg fault with incremental sort. The short of the investigation there was that a subplan wasn't being serialized since it wasn't parallel safe, and that attempting to initialize that subplan resulted in the seg fault. Tom pushed a change to raise an

Re: Online verification of checksums

On Fri, Nov 20, 2020 at 11:08:27AM -0500, Stephen Frost wrote: > David Steele (da...@pgmasters.net) wrote: >> Our current plan for pgBackRest: >> >> 1) Remove the LSN check as you have done in your patch and when rechecking >> see if the page has become valid *or* the LSN is ascending. >> 2)

Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2

On Fri, Nov 20, 2020 at 11:17:44PM +0100, Daniel Gustafsson wrote: > On 20 Nov 2020, at 01:33, Michael Paquier wrote: >> knowing that we still need to deal with the OOM failure handling >> and pass down the error to the callers playing with SHA2, it feels >> like the most consistent API to me for

Re: Removal of currtid()/currtid2() and some table AM cleanup

On Fri, Nov 20, 2020 at 11:53:11AM -0500, Tom Lane wrote: > Yeah, if pgODBC were not using it at all then I think it'd be fine > to get rid of, but if it still contains calls then we cannot. > The suggestion upthread that those calls might be unreachable > is interesting, but it seems unproven.

Re: Different results between PostgreSQL and Oracle for "for update" statement

On Fri, Nov 20, 2020 at 3:04 PM Andreas Karlsson wrote: > I am sadly not familiar enough with Oracle or have access to any Oracle > license so I cannot comment on how Oracle have implemented their behvior > or what tradeoffs they have made. I bet that Oracle does a statement-level rollback for

Re: Different results between PostgreSQL and Oracle for "for update" statement

On 11/20/20 3:25 PM, Andy Fan wrote:> On Fri, Nov 20, 2020 at 9:37 PM Andreas Karlsson > wrote: On 11/20/20 9:57 AM, Andy Fan wrote: > Thank you for your attention. Your suggestion would fix the issue.  However > The difference will cause some risks

Re: xid wraparound danger due to INDEX_CLEANUP false

On Fri, Nov 20, 2020 at 2:17 PM Robert Haas wrote: > > Does that make sense? > > I *think* so. For me the point is that the index never has a right to > insist on being vacuumed, but it can offer an opinion on how helpful > it would be. Right, that might be the single most important point. It's

Re: Strange behavior with polygon and NaN

Further to this ... I realized after looking at things some more that one of line_closept_point's issues is really a bug in line_construct: it fails to draw a horizontal line through a point with x = Inf, though surely that's not particularly ill-defined. The reason is that somebody thought they

Why does create_gather_merge_plan need make_sort?

While looking at another issue I noticed that create_gather_merge_plan calls make_sort if the subplan isn't sufficiently sorted. In all of the cases I've seen where a gather merge path (not plan) is created the input path is expected to be properly sorted, so I was wondering if anyone happened to

Re: [HACKERS] Custom compression methods

On Wed, Nov 11, 2020 at 9:39 AM Dilip Kumar wrote: > There were a few problems in this rebased version, basically, the > compression options were not passed while compressing values from the > brin_form_tuple, so I have fixed this. Since the authorship history of this patch is complicated, it

Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2

> On 20 Nov 2020, at 01:33, Michael Paquier wrote: >> This seems like a complication which brings little benefit since the only >> real >> errorcase is OOM in creating the context? The built-in crypto support is >> designed to never fail, and reading the OpenSSL code the only failure cases >>

Re: xid wraparound danger due to INDEX_CLEANUP false

On Fri, Nov 20, 2020 at 4:21 PM Peter Geoghegan wrote: > Actually, now I think that BRIN shouldn't be special to vacuumlazy.c > in any way. It doesn't make sense as part of this future world in > which index vacuuming can be skipped for individual indexes (which is > what I talked to Sawada-san

Re: Additional Chapter for Tutorial - arch-dev.sgml

On 2020-11-15 19:45, Jürgen Purtz wrote: (smallish) Changes to arch-dev.sgml Erik --- ./doc/src/sgml/arch-dev.sgml.orig 2020-11-20 19:14:21.576775798 +0100 +++ ./doc/src/sgml/arch-dev.sgml 2020-11-20 21:43:10.435370787 +0100 @@ -7,7 +7,7 @@ Author This chapter originated as

Re: enable_incremental_sort changes query behavior

Thanks much for the detailed followup; this is super helpful. On Fri, Nov 20, 2020 at 2:57 PM Robert Haas wrote: > > On Fri, Nov 20, 2020 at 1:51 PM James Coleman wrote: > > > This isn't a counterexample, because there's no join tree here -- or, > > > well, there is, but it's trivial, because

Re: xid wraparound danger due to INDEX_CLEANUP false

On Fri, Nov 20, 2020 at 12:04 PM Robert Haas wrote: > That's an interesting idea. We should think about the needs of brin > indexes when designing something better than the current system. They > have the interesting property that the heap deciding to change LP_DEAD > to LP_UNUSED doesn't break

Default role -> Predefined role

Greetings, Attached is a patch to move from 'default role' terminology to 'predefined role' in the documentation. In the code, I figured it made more sense to avoid saying either one and instead opted for just 'ROLE_NAME_OF_ROLE' as the #define, which we were very close to (one removing the

Re: Refactor pg_rewind code and make it work against a standby

On 20/11/2020 19:14, Andres Freund wrote: Hi, On 2020-11-20 16:19:03 +0200, Heikki Linnakangas wrote: Pushed a fix similar to your patch, but I put the wait_for_catchup() before running pg_rewind. The point of inserting the 'in A, after C was promoted' row is that it's present in B when

Re: Strange behavior with polygon and NaN

I spent some more time looking at this patch. Some experimentation shows that the changes around bounding box calculation (ie float8_min_nan() and its call sites) seem to be completely pointless: removing them doesn't change any of the regression results. Nor does using float8_min_nan() in the

Re: xid wraparound danger due to INDEX_CLEANUP false

On Fri, Nov 20, 2020 at 2:37 PM Peter Geoghegan wrote: > Right. Maybe we don't ask the index AMs for discrete yes/no answers. > Maybe we can ask them for a continuous answer, such as a value between > 0.0 and 1.0 that represents the urgency/bloat, or something like that. > And so the final yes/no

Re: enable_incremental_sort changes query behavior

On Fri, Nov 20, 2020 at 1:51 PM James Coleman wrote: > > This isn't a counterexample, because there's no join tree here -- or, > > well, there is, but it's trivial, because there's only one relation > > involved. You can't have a non-Var expression computed before you > > finish all the joins,

Re: xid wraparound danger due to INDEX_CLEANUP false

On Fri, Nov 20, 2020 at 3:17 AM Masahiko Sawada wrote: > I had missed your bottom-up index deletion patch but it's a promising > improvement. With that patch, the number of dead tuples in individual > indexes may differ. So it's important that we make index vacuuming a > per-index thing. Right,

Re: enable_incremental_sort changes query behavior

On Fri, Nov 20, 2020 at 12:06 PM Robert Haas wrote: > > On Wed, Oct 7, 2020 at 6:22 PM Tomas Vondra > wrote: > > I'm still not entirely sure I understand what's happening, or what the > > exact rule is. Consider this query: > > > >explain (verbose) select distinct i, t, md5(t) from ref_0; >

Re: [Proposal] Global temporary tables

Hi pá 11. 9. 2020 v 17:00 odesílatel 曾文旌 napsal: > I have written the README for the GTT, which contains the GTT requirements > and design. > I found that compared to my first email a year ago, many GTT Limitations > are now gone. > Now, I'm adding comments to some of the necessary functions. >

Re: Probable documentation errors or improvements

Thank you for preparing the patches, and Heikki Linnakangas for pushing those!Yaroslav, could you prepare a patch for your remaining suggestions ?I suggest to include just the handful of items which are most important (mostwrong/ambiguous/confusing).Let me write this again: I'm not a native

Re: [Patch] ALTER SYSTEM READ ONLY

On Fri, 20 Nov 2020 at 9:53 PM, Robert Haas wrote: > On Thu, Oct 8, 2020 at 6:23 AM Amul Sul wrote: > > On a quick look at the latest 0001 patch, the following hunk to reset > leftover > > flags seems to be unnecessary: > > > > + /* > > + * If some barrier types were not successfully absorbed,

[patch] CLUSTER blocks scanned progress reporting

Hi, The pg_stat_progress_cluster view can report incorrect heap_blks_scanned values when synchronize_seqscans is enabled, because it allows the sequential heap scan to not start at block 0. This can result in wraparounds in the heap_blks_scanned column when the table scan wraps around, and

Re: abstract Unix-domain sockets

On Friday, November 20, 2020, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2020-11-18 04:35, David G. Johnston wrote: > >> >> >> I agree that there isn't a useful hint for the abstract case as it >> shouldn't happen unless there is indeed another running instance with the >>

Re: Refactor pg_rewind code and make it work against a standby

Hi, On 2020-11-20 16:19:03 +0200, Heikki Linnakangas wrote: > Pushed a fix similar to your patch, but I put the wait_for_catchup() before > running pg_rewind. The point of inserting the 'in A, after C was promoted' > row is that it's present in B when pg_rewind runs. Hm - don't we possibly need

Re: enable_incremental_sort changes query behavior

On Wed, Oct 7, 2020 at 6:22 PM Tomas Vondra wrote: > I'm still not entirely sure I understand what's happening, or what the > exact rule is. Consider this query: > >explain (verbose) select distinct i, t, md5(t) from ref_0; > > which on PG12 (i.e. before incremental sort) is planned like

Re: Removal of currtid()/currtid2() and some table AM cleanup

Peter Eisentraut writes: > On 2020-09-03 12:14, Michael Paquier wrote: >> Opinions are welcome about the arguments of upthread. > It appears that currtid2() is still used, so we ought to keep it. Yeah, if pgODBC were not using it at all then I think it'd be fine to get rid of, but if it still

Re: enable_incremental_sort changes query behavior

On Tue, Nov 17, 2020 at 11:20 AM Tomas Vondra wrote: > > > > On 11/17/20 3:03 PM, James Coleman wrote: > > On Mon, Nov 16, 2020 at 11:23 PM Tomas Vondra > > wrote: > >> > >> Hmm, I missed that other thread. That indeed seems like a bug in the > >> same area already tweaked by ebb7ae839d033d0f2

Re: [PATCH] remove pg_archivecleanup and pg_standby

On 2020-10-29 03:44, Justin Pryzby wrote: diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml index 4e833d79ef..be4292ec33 100644 --- a/doc/src/sgml/contrib.sgml +++ b/doc/src/sgml/contrib.sgml @@ -199,6 +199,5 @@ pages. part of the core PostgreSQL distribution. -

Re: [Patch] ALTER SYSTEM READ ONLY

On Thu, Oct 8, 2020 at 6:23 AM Amul Sul wrote: > On a quick look at the latest 0001 patch, the following hunk to reset leftover > flags seems to be unnecessary: > > + /* > + * If some barrier types were not successfully absorbed, we will have > + * to try again later. > + */ > + if (!success) > +

Re: jit and explain nontext

On Fri, Nov 20, 2020 at 04:56:38PM +0100, Peter Eisentraut wrote: > On 2020-10-17 21:21, Justin Pryzby wrote: > > Added at:https://commitfest.postgresql.org/30/2766/ > > > > diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c > > index 41317f1837..7345971507 100644 > >

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On Fri, Nov 20, 2020 at 11:02 AM Alvaro Herrera wrote: > On 2020-Nov-20, Robert Haas wrote: > > Yeah, I think dirtying the page fewer times is a big win. However, a > > page may have tuples that are not yet all-visible, and we can't freeze > > those just because we are freezing others. > > Of

Re: Online verification of checksums

Greetings, * David Steele (da...@pgmasters.net) wrote: > On 11/20/20 2:28 AM, Michael Paquier wrote: > >On Mon, Nov 16, 2020 at 11:41:51AM +0100, Magnus Hagander wrote: > >>I was referring to the latest patch on the thread. But as I said, I have > >>not read up on all the different issues raised

Re: Disable WAL logging to speed up data loading

Greetings, * osumi.takami...@fujitsu.com (osumi.takami...@fujitsu.com) wrote: > On Friday, Nov 20, 2020 9:33 AM Tsunakawa, Takayuki > wrote: > > From: Kyotaro Horiguchi > > > At Thu, 19 Nov 2020 11:04:17 -0500, Stephen Frost > > > > * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > > > > > I

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On 2020-Nov-20, Robert Haas wrote: > Yeah, I think dirtying the page fewer times is a big win. However, a > page may have tuples that are not yet all-visible, and we can't freeze > those just because we are freezing others. Of course! We should only freeze tuples that are freezable. I thought

Re: xid wraparound danger due to INDEX_CLEANUP false

On Thu, Nov 19, 2020 at 8:58 PM Masahiko Sawada wrote: > For HEAD, there was a discussion that we change lazy vacuum and > bulkdelete and vacuumcleanup APIs so that it calls these APIs even > when INDEX_CLEANUP is specified. That is, when INDEX_CLEANUP false is > specified, it collects dead tuple

Re: jit and explain nontext

On 2020-10-17 21:21, Justin Pryzby wrote: Added at:https://commitfest.postgresql.org/30/2766/ diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c index 41317f1837..7345971507 100644 --- a/src/backend/commands/explain.c +++ b/src/backend/commands/explain.c @@ -839,7

Re: Should we document IS [NOT] OF?

On Thu, Nov 19, 2020 at 6:43 PM Tom Lane wrote: > After digging a bit more I noticed that we'd discussed removing > IS OF in the 2007 thread, but forebore because there wasn't an easy > replacement. pg_typeof() was added a year later (b8fab2411), so we > could have done this at any point since

Re: Improve handling of parameter differences in physical replication

Hello > I think I like "unpaused" better here, because "resumed" would seem to > imply that recovery can actually continue. Good, I agree. > One thing that has not been added to my patch is the equivalent of > 496ee647ecd2917369ffcf1eaa0b2cdca07c8730, which allows promotion while > recovery is

Re: Prevent printing "next step instructions" in initdb and pg_upgrade

On 2020-11-09 13:05, Magnus Hagander wrote: PFA a rebased version of this patch on top of what has happened since, and changing the pg_upgrade parameter to be --no-scripts. It seems were are still finding out more nuances about pg_upgrade, but looking at initdb for moment, I think the

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On Fri, Nov 20, 2020 at 9:08 AM Alvaro Herrera wrote: > There are two costs associated with this processing. One is dirtying > the page (which means it needs to be written down when evicted), and the > other is to write WAL records for each change. The cost for the latter > is going to be the

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On 2020-Nov-20, Simon Riggs wrote: > On Fri, 20 Nov 2020 at 01:40, Masahiko Sawada wrote: > > Since we use the term aggressive scan in the docs, I personally don't > > feel unnatural about that. But since this option also disables index > > cleanup when not enabled explicitly, I’m concerned a

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

Note on heap_prepare_freeze_tuple()'s fifth parameter, it's not valid to pass OldestXmin; you need a multixact limit there, not an Xid limit. I think the return value of GetOldestMultiXactId is a good choice. AFAICS this means that you'll need to add a new output argument to

Re: pg_dump, ATTACH, and independently restorable child partitions

On Fri, Nov 06, 2020 at 11:18:35PM -0300, Alvaro Herrera wrote: > On 2020-Oct-24, Justin Pryzby wrote: > > > On Fri, Oct 23, 2020 at 12:29:40AM -0500, Justin Pryzby wrote: > > > > Now that I look, it seems like this is calling PQexec(), which sends a > > > single, > > > "simple" libpq message

Re: Issue with server side statement-level rollback

Hi, Le 19/11/2020 à 21:43, Andres Freund a écrit : Hi, On 2020-11-12 11:40:22 +0100, Gilles Darold wrote: The problem we are encountering is when PostgreSQL is compiled in debug mode with --enable-cassert. At line 1327 of src/backend/tcop/pquery.c the following assert fail:     /*      *

Re: Removal of currtid()/currtid2() and some table AM cleanup

On 2020-09-03 12:14, Michael Paquier wrote: On Fri, Jun 26, 2020 at 01:11:55PM +0900, Michael Paquier wrote: From what I can see on this thread, we could just remove currtid() per the arguments of the RETURNING ctid clause supported since PG 8.2, but it would make more sense to me to just

Re: abstract Unix-domain sockets

On 2020-11-18 04:35, David G. Johnston wrote: Given that "port" is a postgresql.conf setting its use here (and elsewhere) should be taken to mean the value of that specific variable. To that end, I find the current description of port to be lacking - it should mention its usage as a qualifier

Re: parsing pg_ident.conf

I noticed somewhat to my surprise as I was prepping the tests for the "match the whole DN" patch that pg_ident.conf is parsed using the same routines used for pg_hba.conf, and as a result the DN almost always needs to be quoted, because they almost all contain a comma e.g. "O=PGDG,OU=Testing".

Re: Online verification of checksums

Hi Michael, On 11/20/20 2:28 AM, Michael Paquier wrote: On Mon, Nov 16, 2020 at 11:41:51AM +0100, Magnus Hagander wrote: I was referring to the latest patch on the thread. But as I said, I have not read up on all the different issues raised in the thread, so take it with a big grain os salt.

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On Fri, 20 Nov 2020 at 14:07, Alvaro Herrera wrote: > > On 2020-Nov-20, Masahiko Sawada wrote: > > > I'm concerned that always freezing all tuples when we're going to make > > the page dirty would affect the existing vacuum workload much. The > > additional cost of freezing multiple tuples would

Re: Add session statistics to pg_stat_database

On Tue, 2020-11-17 at 17:33 +0100, Magnus Hagander wrote: > I've taken a look as well, and here are a few short notes: Much appreciated! > * It talks about "number of connections" but "number of aborted sessions". We > should probably > be consistent about talking either about connections or

Re: [bug+patch] Inserting DEFAULT into generated columns from VALUES RTE

On Sun, 6 Sept 2020 at 22:42, Tom Lane wrote: > > I think you'd be better off to make transformInsertStmt(), specifically > its multi-VALUES-rows code path, check for all-DEFAULT columns and adjust > the tlist itself. Doing it there might be a good bit less inefficient > for very long VALUES

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

On 2020-11-03 21:53, David Rowley wrote: On Tue, 3 Nov 2020 at 20:08, Peter Eisentraut wrote: On 2020-09-29 11:26, David Rowley wrote: I've marked this patch back as waiting for review. It would be good if someone could run some tests on some intel hardware and see if they can see any

Re: Different results between PostgreSQL and Oracle for "for update" statement

Hi Andreas: Thanks for your input. On Fri, Nov 20, 2020 at 9:37 PM Andreas Karlsson wrote: > On 11/20/20 9:57 AM, Andy Fan wrote: > > Thank you for your attention. Your suggestion would fix the issue. > However > > The difference will cause some risks when users move their application > > from

Re: Refactor pg_rewind code and make it work against a standby

On 20/11/2020 02:38, Andres Freund wrote: I locally, on a heavily modified branch (AIO support), started to get consistent failures in this test. I *suspect*, but am not sure, that it's the test's fault, not the fault of modifications. As far as I can tell, after the pg_rewind call, there's no

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On 2020-Nov-20, Masahiko Sawada wrote: > I'm concerned that always freezing all tuples when we're going to make > the page dirty would affect the existing vacuum workload much. The > additional cost of freezing multiple tuples would be low but if we > freeze tuples we would also need to write

Re: Different results between PostgreSQL and Oracle for "for update" statement

On 11/20/20 9:57 AM, Andy Fan wrote: Thank you for your attention. Your suggestion would fix the issue.  However The difference will cause some risks when users move their application from Oracle to PostgreSQL. So I'd like to think which behavior is more reasonable. I think PostgreSQL's

Re: parsing pg_ident.conf

On 11/20/20 2:19 AM, Fabien COELHO wrote: > > Hello Andrew, > >> I noticed somewhat to my surprise as I was prepping the tests for the >> "match the whole DN" patch that pg_ident.conf is parsed using the same >> routines used for pg_hba.conf, and as a result the DN almost always >> needs to be

Re: don't allocate HashAgg hash tables when running explain only

On 20/11/2020 08:31, Michael Paquier wrote: On Thu, Nov 19, 2020 at 08:47:51AM +0200, Heikki Linnakangas wrote: Yeah, I believe it's always been like that. Yeah, arguably it should be backpatched. I felt conservative and didn't backpatch, but feel free to do it if you think it should be. +1

Re: Improve handling of parameter differences in physical replication

On 2020-11-19 20:17, Sergei Kornilov wrote: Seems WAIT_EVENT_RECOVERY_PAUSE addition was lost during patch simplification. added ereport(FATAL, (errmsg("recovery aborted because of insufficient parameter settings"),

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

On Fri, Nov 20, 2020 at 3:31 AM Michael Paquier wrote: > > On Thu, Nov 19, 2020 at 09:49:05PM +0100, Magnus Hagander wrote: > > Ugh, that's pretty terrible. > > I have spent some time testing this part this morning, and I can see > that genhtml does not complain with your patch. It looks like in

RE: Disable WAL logging to speed up data loading

Hi This time, I updated my patch to address comments below only. Please have a look at updated one. On Thursday, Nov 19, 2020 4:51 PM Tsunakawa, Takayuki > (1) > #define RelationNeedsWAL(relation) > \ > + (wal_level != WAL_LEVEL_NONE && >

Re: a misbehavior of partition row movement (?)

On Sat, Oct 3, 2020 at 8:26 PM Amit Langote wrote: > On Sat, Oct 3, 2020 at 8:15 PM Tomas Vondra > wrote > > On Sat, Oct 03, 2020 at 11:42:21AM +0900, Amit Langote wrote: > > >On Fri, Oct 2, 2020 at 11:32 PM David G. Johnston > > > wrote: > > >> On Friday, October 2, 2020, Amit Langote > > >>

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On Fri, 20 Nov 2020 at 10:15, Simon Riggs wrote: > > On Fri, 20 Nov 2020 at 01:40, Masahiko Sawada wrote: > > > > On Thu, Nov 19, 2020 at 8:02 PM Simon Riggs wrote: > > > > > > On Wed, 18 Nov 2020 at 17:59, Robert Haas wrote: > > > > > > > > On Wed, Nov 18, 2020 at 12:54 PM Simon Riggs > > >

Re: Asynchronous Append on postgres_fdw nodes.

At Fri, 20 Nov 2020 20:16:42 +0900 (JST), Kyotaro Horiguchi wrote in me> + /* If this was the second part of an async request, we must fetch until NULL. */ me> + if (fsstate->async_aware) me> + { me> + /* call once and raise error if not NULL as

Re: xid wraparound danger due to INDEX_CLEANUP false

On Fri, Nov 20, 2020 at 12:56 PM Peter Geoghegan wrote: > > On Thu, Nov 19, 2020 at 5:58 PM Masahiko Sawada wrote: > > Several months passed from the discussion. We decided not to do > > anything on back branches but IIUC the fundamental issue is not fixed > > yet. The issue pointed out by

Re: Asynchronous Append on postgres_fdw nodes.

Hello. I looked through the nodeAppend.c and postgres_fdw.c part and those are I think the core of this patch. -* figure out which subplan we are currently processing +* try to get a tuple from async subplans +*/ + if

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On Fri, 20 Nov 2020 at 03:54, Masahiko Sawada wrote: > > > So +1 for this idea. > > > > Patch to do this attached, for discussion. > > Thank you for the patch! > > +* > +* Once we decide to dirty the data block we may as well > freeze > +* any

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

On Wed, Nov 18, 2020 at 5:52 PM Fujii Masao wrote: > > > handle_sigterm() and die() are similar except that die() has extra > > handling(below) for exiting immediately when waiting for input/command > > from the client. > > /* > > * If we're in single user mode, we want to quit

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On Fri, 20 Nov 2020 at 01:40, Masahiko Sawada wrote: > > On Thu, Nov 19, 2020 at 8:02 PM Simon Riggs wrote: > > > > On Wed, 18 Nov 2020 at 17:59, Robert Haas wrote: > > > > > > On Wed, Nov 18, 2020 at 12:54 PM Simon Riggs > > > wrote: > > > > Patches attached. > > > > 1.

Re: Skip ExecCheckRTPerms in CTAS with no data

On Fri, Nov 20, 2020 at 11:07 AM Michael Paquier wrote: > > Thanks. Based on what Peter has said, the ACL_INSERT check in > intorel_startup() could just be removed, and the tests of matview.sql > and select_into.sql would need some cleanup. We could keep around > some scenarios with some

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

> On 20 Nov 2020, at 03:31, Michael Paquier wrote > pg_strong_random.c needs a pgindent run, there are two inconsistent > diffs. Looks fine except for those nits. Agreed, this is the least complicated (and most readable) we can make this file, especially if we add more providers. +1. cheers

Re: Skip ExecCheckRTPerms in CTAS with no data

On Fri, Nov 20, 2020 at 12:59 PM Peter Eisentraut wrote: > > On 2020-11-20 06:37, Michael Paquier wrote: > >>> But if you consider materialized views as a variant of normal views, > >>> then the INSERT privilege would be applicable if you pass an INSERT on > >>> the materialized view through to

Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted

Yes, It's my fault. You're right. Pavel Borisov 于2020年11月19日周四 下午11:55写道： > One thing that doesn't matter is that the modify here seems unnecessary, >> right? >> >> > mdunlinkfork(RelFileNodeBackend rnode, ForkNumber forkNum, bool isRedo) >> > { >> > char *path; >> > - int

Re: Different results between PostgreSQL and Oracle for "for update" statement

On Thu, Nov 19, 2020 at 11:49 PM Tom Lane wrote: > Andy Fan writes: > > create table su (a int, b int); > > insert into su values(1, 1); > > > - session 1: > > begin; > > update su set b = 2 where b = 1; > > > - sess 2: > > select * from su where a in (select a from su where b = 1) for update;

Re: Unnecessary delay in streaming replication due to replay lag

On Tue, Sep 15, 2020 at 05:30:22PM +0800, lchch1...@sina.cn wrote: > I read the code and test the patch, it run well on my side, and I have > several issues on the > patch. + RequestXLogStreaming(ThisTimeLineID, +startpoint, +