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: [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: 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: 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: 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

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

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

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: 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: 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: [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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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

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: [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

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: 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: 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

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 (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

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: [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: >>

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: 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: 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: 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: 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: 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: 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: 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: 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

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: [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: 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: 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: 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: 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: 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: 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 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: [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: 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

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

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?

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: 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: 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: 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: 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: 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: 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 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: 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()

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

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()

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: 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: 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: 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: 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: 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: 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

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: [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: 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

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 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: 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: 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: 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: [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: 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: [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: >

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: Transactions involving multiple postgres foreign servers, take 2

On Fri, 27 Mar 2020 at 22:06, Muhammad Usama wrote: > > Hi Sawada San, > > I have been further reviewing and testing the transaction involving multiple > server patches. > Overall the patches are working as expected bar a few important exceptions. > So as discussed over the call I have fixed the

Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Wed, 8 Apr 2020 at 14:44, Amit Kapila wrote: > > On Tue, Apr 7, 2020 at 5:17 PM Masahiko Sawada > wrote: > > > > On Tue, 7 Apr 2020 at 18:29, Masahiko Sawada > > wrote: > > > > > > On Tue, 7 Apr 2020 at 17:42, Amit Kapila wrote: > > > > > > > > On Tue, Apr 7, 2020 at 1:30 PM Masahiko Sawada

Re: 2pc leaks fds

On Tue, Apr 07, 2020 at 05:12:49PM -0700, Andres Freund wrote: > I pushed a fix. While it might not be the best medium/long term fix, it > unbreaks 2PC. Perhaps we should add an open item to track whether we > want to fix this differently? Sounds fine to me. I have updated the open item that we

Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Wed, Apr 8, 2020 at 11:53 AM Masahiko Sawada wrote: > > On Wed, 8 Apr 2020 at 14:44, Amit Kapila wrote: > > > > > > Thanks for the investigation. I don't see we can do anything special > > about this. In an ideal world, this should be done once and not for > > each worker but I guess it

Re: 2pc leaks fds

Antonin Houska wrote: > Andres Freund wrote: > > But I'm not sure it's quite the right idea. I'm not sure I fully > > understand the design of 0dc8ead46, but it looks to me like it's > > intended to allow users of the interface to have different ways of > > opening files. If we just close() the

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

Hi, On Wed, Apr 8, 2020 at 7:07 AM Etsuro Fujita wrote: > > Pushed after modifying some comments further, based on the suggestions > of Ashutosh. I'm getting the following warning during compilation. partbounds.c: In function ‘partition_bounds_merge’: partbounds.c:1024:21: warning: unused

Re: recovery_target_action=pause with confusing hint

>> we should notice it in document I think. >There is the following explation about the relationship the recovery >pause and the promotion, in the document. You may want to add more >descriptions into the docs? >-- >If a promotion is triggered while recovery is

Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Wed, 8 Apr 2020 at 16:04, Amit Kapila wrote: > > On Wed, Apr 8, 2020 at 11:53 AM Masahiko Sawada > wrote: > > > > On Wed, 8 Apr 2020 at 14:44, Amit Kapila wrote: > > > > > > > > > Thanks for the investigation. I don't see we can do anything special > > > about this. In an ideal world, this

Re: [Proposal] Global temporary tables

> 2020年4月7日 下午6:22，Prabhat Sahu 写道： > > Thanks for review. > This parameter should support all types of writing of the bool type like > parameter autovacuum_enabled. > So I fixed in global_temporary_table_v24-pg13.patch. > > Thank you Wenjing for the new patch with the fix and the "VACUUM

Re: Planning counters in pg_stat_statements (using pgss_store)

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 pushed the

Re: Use compiler intrinsics for bit ops in hash

On Wed, 8 Apr 2020 at 15:06, John Naylor wrote: > Looks good to me, marked RFC. Thanks a lot for reviewing those changes. I've now pushed all 3 of the patches. David

  1   2   >