Multiple FPI_FOR_HINT for the same block during killing btree index items

Hi all, During investigating the issue our customer had, I realized that _bt_killitems() can record the same FPI pages multiple times simultaneously. This can happen when several concurrent index scans are processing pages that contain killable tuples. Because killing index items could be

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 9, 2020 at 12:09 AM Justin Pryzby wrote: > > On Thu, Apr 09, 2020 at 12:06:04AM +0530, Mahendra Singh Thalor wrote: > > On Wed, 8 Apr 2020 at 22:11, Justin Pryzby wrote: > > > > > > > Thanks Justin for the patch. > > > > Patch looks fine to me and it is fixing the issue. After

Fast DSM segments

Hello PostgreSQL 14 hackers, FreeBSD is much faster than Linux (and probably Windows) at parallel hash joins on the same hardware, primarily because its DSM segments run in huge pages out of the box. There are various ways to convince recent-ish Linux to put our DSMs on huge pages (see below for

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

Etsuro Fujita writes: > Yeah, partition_bounds_merge() is currently called only from > try_partitionwise_join(), which guarantees that the strategies are the > same. The assertion cost would be cheap, but not zero, so I still > think it would be better to remove the assertion from >

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 9, 2020 at 7:07 AM Michael Paquier wrote: > > On Wed, Apr 08, 2020 at 01:38:54PM -0500, Justin Pryzby wrote: > > I think the behavior is correct, but the error message could be improved, > > like: > > |ERROR: cannot specify FULL with PARALLEL jobs > > or similar. > > Perhaps "cannot

Re: A problem about partitionwise join

Richard Guo writes: > On Thu, Apr 9, 2020 at 1:07 AM Tom Lane wrote: >> I have hopes of being able to incorporate outer >> joins into the EC logic in a less squishy way in the future, by making >> the representation of Vars distinguish explicitly between >> value-before-outer-join and

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

Hi, On Thu, Apr 9, 2020 at 12:06 AM Kuntal Ghosh wrote: > Both of your patches fix the problem. I don't have much exposure in > this area to comment on whether we should keep/remove the assertion > from the code. But, here is my opinion: > > The code structure looks like following: >

Re: A problem about partitionwise join

On Thu, Apr 9, 2020 at 1:07 AM Tom Lane wrote: > Richard Guo writes: > > On Sun, Apr 5, 2020 at 4:38 AM Tom Lane wrote: > >> There is already something in equivclass.c that would almost do what > >> we want here: exprs_known_equal() would tell us whether the partkeys > >> can be found in the

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/04/08 21:32, legrand legrand wrote: Fujii Masao-4 wrote On 2020/04/03 16:26 [...] "Note that planning and execution statistics are updated only at their respective end phase, and only for successful operations. For example the execution counters of a long running query will only be

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/04/08 18:31, Julien Rouhaud wrote: On Wed, Apr 08, 2020 at 05:37:27PM +0900, Fujii Masao wrote: On 2020/04/03 16:26, Julien Rouhaud wrote: On Thu, Apr 02, 2020 at 01:04:28PM -0700, legrand legrand wrote: Fujii Masao-4 wrote On 2020/04/01 18:19, Fujii Masao wrote: Finally I

Re: [PATCH] Support built control file in PGXS VPATH builds

On Mon, 30 Mar 2020 at 11:50, Craig Ringer wrote: > > > On Mon, 9 Mar 2020, 17:27 Peter Eisentraut, < > peter.eisentr...@2ndquadrant.com> wrote: > >> On 2020-02-07 04:14, Craig Ringer wrote: >> > The attached patch fixes this by having PGXS resolve >> > $(EXTENSION).control along the VPATH. >>

Re: Report error position in partition bound check

On Wed, Apr 08, 2020 at 08:17:55PM -0700, Alexandra Wang wrote: > On Wed, Apr 8, 2020 at 6:11 PM Michael Paquier wrote: > > Please note that you forgot to update the regression test output. > > Yep thanks! Please see my previous email for the updated patch. Thanks, I saw the update. It looks

Re: adding partitioned tables to publications

On Wed, Apr 8, 2020 at 11:07 PM Amit Langote wrote: > On Wed, Apr 8, 2020 at 9:21 PM Peter Eisentraut > wrote: > > On 2020-04-08 13:16, Amit Langote wrote: > > > prion seems to have failed: > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion=2020-04-08%2009%3A53%3A13 > > > > This

Re: Report error position in partition bound check

On Wed, Apr 8, 2020 at 6:11 PM Michael Paquier wrote: > Please note that you forgot to update the regression test output. Yep thanks! Please see my previous email for the updated patch.

Re: Commitfest 2020-03 Now in Progress

On 2020-Apr-08, David Steele wrote: > The 2020-03 Commitfest is officially closed. > > Final stats are (for entire CF, not just from March 1 this time): Thanks for managing! -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: Commitfest 2020-03 Now in Progress

On Wed, Apr 8, 2020 at 6:45 PM David Fetter wrote: > Thanks so much for your hard work managing this one! +1 -- Peter Geoghegan

Re: Commitfest 2020-03 Now in Progress

On Wed, Apr 08, 2020 at 12:36:37PM -0400, David Steele wrote: > On 4/1/20 10:09 AM, David Steele wrote: > > On 3/17/20 8:10 AM, David Steele wrote: > > > On 3/1/20 4:10 PM, David Steele wrote: > > > > The last Commitfest for v13 is now in progress! > > > > > > > > Current stats for the Commitfest

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Wed, Apr 08, 2020 at 01:38:54PM -0500, Justin Pryzby wrote: > I think the behavior is correct, but the error message could be improved, > like: > |ERROR: cannot specify FULL with PARALLEL jobs > or similar. Perhaps "cannot use FULL and PARALLEL options together"? I think that this patch

Re: Commitfest 2020-03 Now in Progress

On Wed, Apr 08, 2020 at 12:39:53PM -0400, Tom Lane wrote: > David Steele writes: >> The 2020-03 Commitfest is officially closed. >> Good job everyone! > > Thanks for running it! I know it's a tedious responsibility. Nice, David. Thanks a lot! -- Michael signature.asc Description: PGP

Re: Improving connection scalability: GetSnapshotData()

On Wed, Apr 08, 2020 at 03:17:41PM -0700, Andres Freund wrote: > On 2020-04-08 09:26:42 -0400, Jonathan S. Katz wrote: >> Lastly, with the ongoing world events, perhaps time that could have been >> dedicated to this and other patches likely affected their completion. I >> know most things in my

Re: Thoughts on "killed tuples" index hint bits support on standby

On Wed, Apr 8, 2020 at 5:23 AM Michail Nikolaev wrote: > Yes, it is a brilliant idea to use uniqueness to avoid bloating the index. I > am > not able to understand all the code now, but I’ll check the patch in more > detail later. The design is probably simpler than you imagine. The algorithm

Re: Report error position in partition bound check

On Wed, Apr 08, 2020 at 05:15:57PM -0700, Alexandra Wang wrote: > I have attached a patch to pass in a ParseState to > check_new_partition_bound() to enable the reporting of the error > position. Below is what the error message looks like before and after > applying the patch. > > Another option

Re: Report error position in partition bound check

Forgot to run make installcheck. Here's the new version of the patch that updated the test answer file. From 9071918648412383e41976a01106257bd6a2539e Mon Sep 17 00:00:00 2001 From: Alexandra Wang Date: Wed, 8 Apr 2020 16:07:28 -0700 Subject: [PATCH v2] Report error position in partition bound

Re: Improving connection scalability: GetSnapshotData()

On Wed, Apr 8, 2020 at 03:25:34PM -0700, Andres Freund wrote: > Hi, > > On 2020-04-08 18:06:23 -0400, Bruce Momjian wrote: > > If we don't commit this, where does this leave us with the > > old_snapshot_threshold feature? We remove it in back branches and have > > no working version in PG 13?

Report error position in partition bound check

Hi, I'm playing with partitioned tables and found a minor thing with the error reporting of bounds checking when create partitions. In function check_new_partition_bound(), there are three places where we call ereport() with a parser_errposition(pstate, spec->location) argument. However, that

Perl modules for testing/viewing/corrupting/repairing your heap files

Hackers, Recently, as part of testing something else, I had need of a tool to create surgically precise corruption within heap pages. I wanted to make the corruption from within TAP tests, so I wrote the tool as a set of perl modules. The modules allow you to "tie" a perl array to a heap file,

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-04-08 18:06:23 -0400, Bruce Momjian wrote: > If we don't commit this, where does this leave us with the > old_snapshot_threshold feature? We remove it in back branches and have > no working version in PG 13? That seems kind of bad. I don't think this patch changes the situation for

Re: Parallel copy

On Wed, 8 Apr 2020 at 22:30, Robert Haas wrote: > - If we're unable to supply data to the COPY process as fast as the > workers could load it, then speed will be limited at that point. We > know reading the file from disk is pretty fast compared to what a > single process can do. I'm not sure

Re: explain HashAggregate to report bucket and memory stats

On Wed, 2020-04-08 at 16:00 -0500, Justin Pryzby wrote: > 90% of the initial goal of this patch was handled by instrumentation > added by > "hash spill to disk" (1f39bce02), but this *also* adds: > > - separate accounting for tuples vs hashtable; > - number of hash buckets; > - handles other

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-04-08 09:44:16 -0400, Robert Haas wrote: > Moreover, shakedown time will be minimal because we're so late in the > release cycle My impression increasingly is that there's very little actual shakedown before beta :(. As e.g. evidenced by the fact that 2PC did basically not work for

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-04-08 09:26:42 -0400, Jonathan S. Katz wrote: > On 4/8/20 8:59 AM, Alexander Korotkov wrote: > > On Wed, Apr 8, 2020 at 3:43 PM Andres Freund wrote: > >> Realistically it still 2-3 hours of proof-reading. > >> > >> This makes me sad :( > > > > Can we ask RMT to extend feature freeze

Re: Improving connection scalability: GetSnapshotData()

On Wed, Apr 8, 2020 at 09:44:16AM -0400, Robert Haas wrote: > I don't know what the right thing to do is. I agree with everyone who > says this is a very important problem, and I have the highest respect > for Andres's technical ability. On the other hand, I have been around > here long enough to

Re: WIP: WAL prefetch (another approach)

On Thu, Apr 9, 2020 at 12:27 AM David Steele wrote: > On 4/8/20 8:12 AM, Thomas Munro wrote: > > Judging by the comments made in this thread and > > elsewhere, I think the feature is in demand so I hope there is a way > > we could get it into 13 in the next couple of days, but I totally > >

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-04-08 09:24:13 -0400, Robert Haas wrote: > On Tue, Apr 7, 2020 at 4:27 PM Andres Freund wrote: > > The main reason is that we want to be able to cheaply check the current > > state of the variables (mostly when checking a backend's own state). We > > can't access the "dense" ones

Re: explain HashAggregate to report bucket and memory stats

On Fri, Mar 20, 2020 at 03:44:42AM -0500, Justin Pryzby wrote: > On Fri, Mar 13, 2020 at 10:57:43AM -0700, Andres Freund wrote: > > On 2020-03-13 10:53:17 -0700, Jeff Davis wrote: > > > On Fri, 2020-03-13 at 10:27 -0700, Andres Freund wrote: > > > > On 2020-03-13 10:15:46 -0700, Jeff Davis wrote:

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

Anna Akenteva writes: > I'd like to hear others' opinions on the syntax as well. Pardon me for coming very late to the party, but it seems like there are other questions that ought to be answered before we worry about any of this. Why is this getting grafted onto BEGIN/START TRANSACTION in the

Re: backup manifests and contemporaneous buildfarm failures

Andrew Dunstan writes: > On 4/8/20 3:41 PM, Robert Haas wrote: >> I don't understand what the local $ENV{MSYS2_ARG_CONV_EXCL} = >> $source_ts_prefix does, > You don't want to know > See for the > gory details. I don't want to

Re: backup manifests and contemporaneous buildfarm failures

On 4/8/20 3:41 PM, Robert Haas wrote: > On Wed, Apr 8, 2020 at 1:59 PM Tom Lane wrote: >> I guess we could commit it and find out. I'm all for the simpler >> coding if it works. > I don't understand what the local $ENV{MSYS2_ARG_CONV_EXCL} = > $source_ts_prefix does, You don't want to know

Re: where should I stick that backup?

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Apr 8, 2020 at 2:06 PM Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > > > On Wed, Apr 8, 2020 at 1:05 PM Stephen Frost wrote: > > > > What if %f.bz2 already exists? > > > > > > That cannot occur in the

Re: backup manifests and contemporaneous buildfarm failures

On Wed, Apr 8, 2020 at 1:59 PM Tom Lane wrote: > I guess we could commit it and find out. I'm all for the simpler > coding if it works. I don't understand what the local $ENV{MSYS2_ARG_CONV_EXCL} = $source_ts_prefix does, but the remove/unlink condition was suggested by Amit Kapila on the basis

Re: where should I stick that backup?

On Wed, Apr 8, 2020 at 2:06 PM Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: > > On Wed, Apr 8, 2020 at 1:05 PM Stephen Frost wrote: > > > What if %f.bz2 already exists? > > > > That cannot occur in the scenario I described. > > Of course it can. Not really. The steps I

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

On 2020-04-08 04:09, Kyotaro Horiguchi wrote: How about something like the follows. BEGIN AFTER ColId Sconst BEGIN FOLOWING ColId Sconst UNTIL ; LIMIT BY ; WITHIN Iconst; regards. I like your suggested keywords! I think that "AFTER" + "WITHIN" sound the most natural. We could completely

Re: Parallel copy

On Tue, Apr 7, 2020 at 9:38 AM Ants Aasma wrote: > I think the element based approach and requirement that all tuples fit > into the queue makes things unnecessarily complex. The approach I > detailed earlier allows for tuples to be bigger than the buffer. In > that case a worker will claim the

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 09, 2020 at 12:06:04AM +0530, Mahendra Singh Thalor wrote: > On Wed, 8 Apr 2020 at 22:11, Justin Pryzby wrote: > > > > On Wed, Apr 08, 2020 at 11:57:08AM -0400, Robert Haas wrote: > > > On Wed, Apr 8, 2020 at 10:25 AM Mahendra Singh Thalor > > > wrote: > > > > I think, Tushar point

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Wed, 8 Apr 2020 at 22:11, Justin Pryzby wrote: > > On Wed, Apr 08, 2020 at 11:57:08AM -0400, Robert Haas wrote: > > On Wed, Apr 8, 2020 at 10:25 AM Mahendra Singh Thalor > > wrote: > > > I think, Tushar point is that either we should allow both > > > vacuum(parallel 0, full 1) and

Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

Alvaro Herrera writes: > On 2020-Apr-08, Tom Lane wrote: >> I think that #1 would soon lead to needing all the same infrastructure >> as we have for inherited columns and constraints, ie triggers would need >> equivalents of attislocal and attinhcount. I don't really want to go >> there, so I'd

Re: where should I stick that backup?

Greeitngs, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Apr 8, 2020 at 1:05 PM Stephen Frost wrote: > > What if %f.bz2 already exists? > > That cannot occur in the scenario I described. Of course it can. > > How about if %f has a space in it? > > For a tar-format backup I don't

Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

On 2020-Apr-08, Tom Lane wrote: > Alvaro Herrera writes: > > Hmm. Let's agree to what behavior we want, and then we implement that. > > It seems to me there are two choices: > > > 1. on detach, keep the trigger but make it independent of the trigger on > > parent. (This requires that the

Re: backup manifests and contemporaneous buildfarm failures

Andrew Dunstan writes: > OK, tricky, but here's what I did to get this working on fairywren. > First, on Msys2 there is a problem with name mangling. We've had to fix > this before by telling it to ignore certain argument prefixes. > Second, once that was fixed rmdir was failing on the

Re: More efficient RI checks - take 2

On Wed, Apr 8, 2020 at 1:06 PM Pavel Stehule wrote: > > > st 8. 4. 2020 v 18:36 odesílatel Antonin Houska napsal: > >> After having reviewed [1] more than a year ago (the problem I found was >> that >> the transient table is not available for deferred constraints), I've >> tried to >> implement

Re: backup manifests and contemporaneous buildfarm failures

On 4/7/20 9:42 AM, Andrew Dunstan wrote: > On Tue, Apr 7, 2020 at 12:37 AM Tom Lane wrote: >> Robert Haas writes: >>> Taking stock of the situation this morning, most of the buildfarm is >>> now green. There are three failures, on eelpout (6 hours ago), >>> fairywren (17 hours ago), and hyrax

Re: backup manifests

On Wed, Apr 8, 2020 at 1:15 AM Fujii Masao wrote: > When there is a backup_manifest in the database cluster, it's included in > the backup even when --no-manifest is specified. ISTM that this is problematic > because the backup_manifest is obviously not valid for the backup. > So, isn't it better

Re: where should I stick that backup?

On Wed, Apr 8, 2020 at 1:05 PM Stephen Frost wrote: > What if %f.bz2 already exists? That cannot occur in the scenario I described. > How about if %f has a space in it? For a tar-format backup I don't think that can happen, because the file names will be base.tar and ${tablespace_oid}.tar. For

Re: A problem about partitionwise join

Richard Guo writes: > On Sun, Apr 5, 2020 at 4:38 AM Tom Lane wrote: >> There is already something in equivclass.c that would almost do what >> we want here: exprs_known_equal() would tell us whether the partkeys >> can be found in the same eclass, without having to generate data >> structures

Re: More efficient RI checks - take 2

st 8. 4. 2020 v 18:36 odesílatel Antonin Houska napsal: > After having reviewed [1] more than a year ago (the problem I found was > that > the transient table is not available for deferred constraints), I've tried > to > implement the same in an alternative way. The RI triggers still work as row

Re: where should I stick that backup?

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Apr 6, 2020 at 2:23 PM Stephen Frost wrote: > > So, instead of talking about 'bzip2 > %f.bz2', and then writing into our > > documentation that that's how this feature can be used, what about > > proposing something that would

doc review for v13

I reviewed docs for v13, like: git log --cherry-pick origin/master...origin/REL_12_STABLE -p doc I did something similar for v12 [0]. I've included portions of that here which still seem lacking 12 months later (but I'm not intending to continue defending each individual patch hunk). I

Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

Alvaro Herrera writes: > Hmm. Let's agree to what behavior we want, and then we implement that. > It seems to me there are two choices: > 1. on detach, keep the trigger but make it independent of the trigger on > parent. (This requires that the trigger is made dependent on the > trigger on

Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

On Wed, Apr 08, 2020 at 12:02:39PM -0400, Alvaro Herrera wrote: > On 2020-Apr-08, Justin Pryzby wrote: > > > This seems to be a bug in master, v12, and (probably) v11, where "FOR EACH > > FOR" > > was first allowed on partition tables (86f575948). > > > > I thought this would work like

Re: Conflict handling for COPY FROM

On Fri, Mar 27, 2020 at 3:27 PM Tom Lane wrote: > Surafel Temesgen writes: > > [ conflict-handling-copy-from-v16.patch ] > > I took a quick look at this patch, since it was marked "ready for > committer", but I don't see how it can possibly be considered committable. > [...] > > Looking at

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Wed, Apr 08, 2020 at 11:57:08AM -0400, Robert Haas wrote: > On Wed, Apr 8, 2020 at 10:25 AM Mahendra Singh Thalor > wrote: > > I think, Tushar point is that either we should allow both > > vacuum(parallel 0, full 1) and vacuum(parallel 1, full 0) or in the > > both cases, we should through

Re: Commitfest 2020-03 Now in Progress

David Steele writes: > The 2020-03 Commitfest is officially closed. > Final stats are (for entire CF, not just from March 1 this time): > Committed: 90. > Moved to next CF: 115. > Withdrawn: 8. > Rejected: 1. > Returned with Feedback: 23. > Total: 237. > Good job everyone! Thanks for running

More efficient RI checks - take 2

After having reviewed [1] more than a year ago (the problem I found was that the transient table is not available for deferred constraints), I've tried to implement the same in an alternative way. The RI triggers still work as row level triggers, but if multiple events of the same kind appear in

Re: Commitfest 2020-03 Now in Progress

On 4/1/20 10:09 AM, David Steele wrote: On 3/17/20 8:10 AM, David Steele wrote: On 3/1/20 4:10 PM, David Steele wrote: The last Commitfest for v13 is now in progress! Current stats for the Commitfest are: Needs review: 192 Waiting on Author: 19 Ready for Committer: 4 Total: 215 Halfway

Re: warning in partioning code

Hi Erik, On Thu, Apr 9, 2020 at 1:07 AM Erik Rijkers wrote: > Compiling master on debian stretch, gcc 9.3.0 complains: > > partbounds.c: In function ‘partition_bounds_merge’: > partbounds.c:1024:21: warning: unused variable ‘inner_binfo’ > [-Wunused-variable] > 1024 | PartitionBoundInfo

Re: Let people set host(no)ssl settings from initdb

On Mon, Apr 06, 2020 at 10:12:16PM +, Cary Huang wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:

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

On Wed, Apr 08, 2020 at 09:54:42AM -0400, James Coleman wrote: On Wed, Apr 8, 2020 at 9:43 AM Tomas Vondra wrote: On Wed, Apr 08, 2020 at 12:51:05PM +0200, Tomas Vondra wrote: >On Tue, Apr 07, 2020 at 11:54:23PM -0400, Tom Lane wrote: >>hyrax is not too happy with this test: >>

warning in partioning code

Hi, Compiling master on debian stretch, gcc 9.3.0 complains: partbounds.c: In function ‘partition_bounds_merge’: partbounds.c:1024:21: warning: unused variable ‘inner_binfo’ [-Wunused-variable] 1024 | PartitionBoundInfo inner_binfo = inner_rel->boundinfo; |

Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

On 2020-Apr-08, Justin Pryzby wrote: > This seems to be a bug in master, v12, and (probably) v11, where "FOR EACH > FOR" > was first allowed on partition tables (86f575948). > > I thought this would work like partitioned indexes (8b08f7d48), where > detaching > a partition makes its index

Re: [PATCH] Incremental sort

On Wed, Apr 08, 2020 at 11:42:12AM -0400, James Coleman wrote: On Wed, Apr 8, 2020 at 11:29 AM David Steele wrote: On 4/8/20 11:13 AM, James Coleman wrote: >> >> James, can you verify it that's still true? I marked this entry as committed in the 2020-03 CF but it's not clear to me if that's

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

On Wed, Apr 08, 2020 at 11:13:26AM -0400, James Coleman wrote: On Wed, Apr 8, 2020 at 11:02 AM Tomas Vondra wrote: On Wed, Apr 08, 2020 at 04:08:39PM +0200, Tomas Vondra wrote: >On Wed, Apr 08, 2020 at 09:54:42AM -0400, James Coleman wrote: >>On Wed, Apr 8, 2020 at 9:43 AM Tomas Vondra >>

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Wed, Apr 8, 2020 at 10:25 AM Mahendra Singh Thalor wrote: > I think, Tushar point is that either we should allow both > vacuum(parallel 0, full 1) and vacuum(parallel 1, full 0) or in the > both cases, we should through error. Oh, yeah, good point. Somebody must not've been careful enough

Re: Function to track shmem reinit time

On 2/24/20 10:57 PM, Robert Haas wrote: On Sat, Feb 22, 2020 at 10:31 PM Tom Lane wrote: I'm still going to object to it, on the grounds that (1) it's exposing an implementation detail that clients should not be concerned with, and that we might change in future. The name isn't even well

Re: [PATCH] Incremental sort

On Wed, Apr 8, 2020 at 11:29 AM David Steele wrote: > > On 4/8/20 11:13 AM, James Coleman wrote: > >> > >> James, can you verify it that's still true? > > I marked this entry as committed in the 2020-03 CF but it's not clear to > me if that's entirely true. I'll leave it up to you (all) to move

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

James Coleman writes: > Should we change `analyze` to `analyze t` to avoid unnecessarily > re-analyzing all other tables in the regression db? Yes, a global analyze here is a remarkably horrid idea. regards, tom lane

Re: [PATCH] Incremental sort

On 4/8/20 11:13 AM, James Coleman wrote: James, can you verify it that's still true? I marked this entry as committed in the 2020-03 CF but it's not clear to me if that's entirely true. I'll leave it up to you (all) to move it to the 2020-07 CF if there is remaining work (other than making

DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

This seems to be a bug in master, v12, and (probably) v11, where "FOR EACH FOR" was first allowed on partition tables (86f575948). I thought this would work like partitioned indexes (8b08f7d48), where detaching a partition makes its index non-inherited, and attaching a partition marks a

Re: Conflict handling for COPY FROM

On Fri, Mar 27, 2020 at 3:27 PM Tom Lane > wrote: I took a quick look at this patch, since it was marked "ready for committer", but I don't see how it can possibly be considered committable. Based on Tom's review I've marked this patch Returned with

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

On Wed, Apr 8, 2020 at 11:02 AM Tomas Vondra wrote: > > On Wed, Apr 08, 2020 at 04:08:39PM +0200, Tomas Vondra wrote: > >On Wed, Apr 08, 2020 at 09:54:42AM -0400, James Coleman wrote: > >>On Wed, Apr 8, 2020 at 9:43 AM Tomas Vondra > >> wrote: > >>> > >>>On Wed, Apr 08, 2020 at 12:51:05PM +0200,

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

On Wed, Apr 08, 2020 at 04:08:39PM +0200, Tomas Vondra wrote: On Wed, Apr 08, 2020 at 09:54:42AM -0400, James Coleman wrote: On Wed, Apr 8, 2020 at 9:43 AM Tomas Vondra wrote: On Wed, Apr 08, 2020 at 12:51:05PM +0200, Tomas Vondra wrote: On Tue, Apr 07, 2020 at 11:54:23PM -0400, Tom Lane

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

Hello Ashutosh, Fujita, On Wed, Apr 8, 2020 at 3:49 PM Ashutosh Bapat wrote: > On Wed, 8 Apr 2020 at 15:42, Etsuro Fujita wrote: >> On Wed, Apr 8, 2020 at 4:30 PM Kuntal Ghosh >> wrote: >> > I'm getting the following warning during compilation. >> > >> > partbounds.c: In function

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Tue, Apr 7, 2020 at 8:40 AM Tatsuro Yamada wrote: > > Hi Julien, > > On 2020/04/02 22:25, Julien Rouhaud wrote: > > New conflict, rebased v9 attached. > > I tested the patch on the head (c7654f6a3) and > the result was fine. See below: > > $ make installcheck-world > = >

Re: Verify true root on replicas with amcheck

On 1/16/20 7:40 PM, Peter Geoghegan wrote: On Thu, Jan 9, 2020 at 12:55 AM godjan • wrote: I heard that amcheck has an invariant about locking no more than 1 page at a moment for avoiding deadlocks. Is there possible a deadlock situation? This is a conservative principle that I came up

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Wed, 8 Apr 2020 at 17:59, Robert Haas wrote: > > On Wed, Apr 8, 2020 at 8:22 AM tushar wrote: > > I just came across this scenario where - vaccum o/p with (full 1, > > parallel 0) option not working > > > > --working > > > > postgres=# vacuum (parallel 1, full 0 ) foo; > > VACUUM > >

Re: Online checksums patch - once again

On 4/1/20 11:30 AM, David Steele wrote: On 1/18/20 6:18 PM, Daniel Gustafsson wrote: Attached is a v16 rebased on top of current master which addresses the above commented points, and which I am basing the concurrency work on. This patch no longer applies cleanly:

Re: adding partitioned tables to publications

On Wed, Apr 8, 2020 at 11:07 PM Amit Langote wrote: > On Wed, Apr 8, 2020 at 9:21 PM Peter Eisentraut > wrote: > > I think this is because the END { } section in PostgresNode.pm shuts > > down all running instances in immediate mode, which doesn't save > > coverage properly. > > Thanks for that

Re: PG compilation error with Visual Studio 2015/2017/2019

On Wed, Apr 8, 2020 at 9:03 AM davinder singh wrote: > On Tue, Apr 7, 2020 at 8:30 PM Juan José Santamaría Flecha < > juanjo.santama...@gmail.com> wrote: > >> >> * The logic on "defined(_MSC_VER) && (_MSC_VER >= 1900)" is defined as >> "_WIN32_WINNT >= 0x0600" on other parts of the code. I would

Re: adding partitioned tables to publications

On Wed, Apr 8, 2020 at 9:21 PM Peter Eisentraut wrote: > On 2020-04-08 13:16, Amit Langote wrote: > > On Wed, Apr 8, 2020 at 6:26 PM Peter Eisentraut > > wrote: > >> All committed. > >> > >> Thank you and everyone very much for working on this. I'm very happy > >> that these two features from

Re: Resume vacuum and autovacuum from interruption and cancellation

On 2/28/20 8:56 AM, Masahiko Sawada wrote: According to those results, it's thought that the more we resume vacuum from the tail of the table, the efficiency is good. Since the table is being updated uniformly even during autovacuum it was more efficient to restart autovacuum from last position

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

On Wed, Apr 8, 2020 at 9:43 AM Tomas Vondra wrote: > > On Wed, Apr 08, 2020 at 12:51:05PM +0200, Tomas Vondra wrote: > >On Tue, Apr 07, 2020 at 11:54:23PM -0400, Tom Lane wrote: > >>hyrax is not too happy with this test: > >> >

Re: WIP/PoC for parallel backup

On Tue, Apr 7, 2020 at 9:44 PM Asif Rehman wrote: > Hi, > > Thanks, Kashif and Rajkumar. I have fixed the reported issues. > > I have added the shared state as previously described. The new grammar > changes > are as follows: > > START_BACKUP [LABEL ''] [FAST] [MAX_RATE %d] > - This will

Re: Improving connection scalability: GetSnapshotData()

On Wed, Apr 8, 2020 at 9:27 AM Jonathan S. Katz wrote: > One of the features of RMT responsibilities[1] is to be "hands off" as > much as possible, so perhaps a reverse ask: how would people feel about > this patch going into PG13, knowing that the commit would come after the > feature freeze

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

On Wed, Apr 08, 2020 at 12:51:05PM +0200, Tomas Vondra wrote: On Tue, Apr 07, 2020 at 11:54:23PM -0400, Tom Lane wrote: hyrax is not too happy with this test: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hyrax=2020-04-07%2004%3A55%3A15 It's not too clear to me why

Re: NOT IN subquery optimization

On 3/26/20 4:58 PM, Li, Zheng wrote: >BTW, so far as I can see, the only reason you're bothering with the whole thing is to compare the size of the subquery output with work_mem, because that's all that subplan_is_hashable does. I wonder whether that consideration is even

Re: Improving connection scalability: GetSnapshotData()

On 4/8/20 8:59 AM, Alexander Korotkov wrote: > On Wed, Apr 8, 2020 at 3:43 PM Andres Freund wrote: >> Realistically it still 2-3 hours of proof-reading. >> >> This makes me sad :( > > Can we ask RMT to extend feature freeze for this particular patchset? > I think it's reasonable assuming extreme

Re: Allow auto_explain to log plans before queries are executed

On 3/5/20 8:46 AM, Julien Rouhaud wrote: On Thu, Feb 27, 2020 at 7:31 AM Julien Rouhaud wrote: On Thu, Feb 27, 2020 at 7:12 AM Pavel Stehule wrote: čt 27. 2. 2020 v 7:01 odesílatel Yugo NAGATA napsal: I think "query debugger" feature you proposed is out of scope of auto_explain module.

Re: Improving connection scalability: GetSnapshotData()

On Tue, Apr 7, 2020 at 4:27 PM Andres Freund wrote: > The main reason is that we want to be able to cheaply check the current > state of the variables (mostly when checking a backend's own state). We > can't access the "dense" ones without holding a lock, but we e.g. don't > want to make

Re: Improving connection scalability: GetSnapshotData()

On Wed, Apr 8, 2020 at 3:43 PM Andres Freund wrote: > Realistically it still 2-3 hours of proof-reading. > > This makes me sad :( Can we ask RMT to extend feature freeze for this particular patchset? I think it's reasonable assuming extreme importance of this patchset. -- Alexander Korotkov

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

On 3/28/20 5:27 AM, Fabien COELHO wrote: Hello Tom, Thanks for your feedback, I'd be rather unclear about what the actual feedback is, though. I'd interpret it as "pg does not care much about code coverage". Most clients are in the red on coverage.postgresql.org. I'd like pgbench at least

Re: [patch]socket_timeout in interfaces/libpq

On 3/24/20 10:58 AM, David Steele wrote: On 11/29/19 12:22 AM, nagaura.ryo...@fujitsu.com wrote: > I couldn't understand what you meant. Do you say that we shouldn't change pqWait() behavior? Or should I modify my patch to use pqDropConnection()? This patch no longer applies:

  1   2   >