Re: Using each rel as both outer and inner for JOIN_ANTI

On Sun, Jul 31, 2022 at 12:07 AM Tom Lane wrote: > Richard Guo writes: > > [ v4-0001-Using-each-rel-as-both-outer-and-inner-for-anti-j.patch ] > > I took a quick look through this. The executor changes are indeed > impressively short, but that's largely because you've paid zero > attention to u

Re: Skip partition tuple routing with constant partition key

On Tue, Aug 2, 2022 at 6:58 AM David Rowley wrote: > On Thu, 28 Jul 2022 at 19:37, Amit Langote wrote: > > > > On Thu, Jul 28, 2022 at 11:59 AM David Rowley wrote: > > > > I'd quite like to push this patch early next week, so if anyone else > > > is following along that might have any objections

Generalize ereport_startup_progress infrastructure

Hi, ereport_startup_progress infrastructure added by commit 9ce346e [1] will be super-useful for reporting progress of any long-running server operations, not just the startup process operations. For instance, postmaster can use it for reporting progress of temp file and temp relation file removal

Re: Typo in pg_db_role_setting.h

On Tue, Aug 2, 2022 at 12:13 PM John Naylor wrote: > > On Tue, Aug 2, 2022 at 10:06 AM Richard Guo > wrote: > > > > I'm not sure that we should remove such comments. And a rough search > > shows that there are much more places with this kind of comments, such > > as below: > > > > nbtxlog transa

Re: Strange behavior with polygon and NaN

At Mon, 1 Aug 2022 13:29:09 -0700, Jacob Champion wrote in > As discussed in [1], we're taking this opportunity to return some > patchsets that don't appear to be getting enough reviewer interest. Oh, sorry. I missed that thread. Thank you for kindly noticing that. > This is not a rejection, s

Re: Typo in pg_db_role_setting.h

> On 2 Aug 2022, at 09:37, Richard Guo wrote: > The examples listed upthread all contain such comment in foo.h saying > 'prototypes for functions in foo.c'. For instance, in buffile.h, there is > comment saying > /* > * prototypes for functions in buffile.c > */ > > So if we remove such comm

Re: Typo in pg_db_role_setting.h

On Tue, 02 Aug 2022 at 15:45, Daniel Gustafsson wrote: >> On 2 Aug 2022, at 09:37, Richard Guo wrote: > >> The examples listed upthread all contain such comment in foo.h saying >> 'prototypes for functions in foo.c'. For instance, in buffile.h, there is >> comment saying > >> /* >> * prototyp

Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO

Regards, Zhang Mingli On Aug 2, 2022, 12:30 +0800, Kyotaro Horiguchi , wrote: > An empty List is not NULL but NIL (which values are identical, > though). Thanks for pointing that out. Fix it in new patch. > There are some other option combinations that are rejected > by ProcessCopyOptions. On the

Re: COPY TO (FREEZE)?

At Tue, 2 Aug 2022 14:17:46 +0800, Julien Rouhaud wrote in > Hi, > > On Tue, Aug 02, 2022 at 01:30:46PM +0900, Kyotaro Horiguchi wrote: > > I noticed that COPY TO accepts FREEZE option but it is pointless. > > > > Don't we reject that option as the first-attached does? > > I agree that we shoul

Re: COPY TO (FREEZE)?

Regards, Zhang Mingli On Aug 2, 2022, 12:30 +0800, Kyotaro Horiguchi , wrote: > I noticed that COPY TO accepts FREEZE option but it is pointless. > > Don't we reject that option as the first-attached does? I +1, should be rejected like other invalid options. > > regards. > > -- > Kyotaro Horiguchi

Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns

On Tue, Aug 2, 2022 at 12:00 PM Kyotaro Horiguchi wrote: > > At Mon, 1 Aug 2022 20:01:00 +0530, Amit Kapila > wrote in > > On Mon, Aug 1, 2022 at 7:46 AM Masahiko Sawada > > wrote: > > > > > > On Fri, Jul 29, 2022 at 3:45 PM Amit Kapila > > > wrote: > > > > > > > > > > I've attached updated

RE: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns

On Mon, Aug 1, 2022 10:31 PM Amit Kapila wrote: > > On Mon, Aug 1, 2022 at 7:46 AM Masahiko Sawada > wrote: > > > > On Fri, Jul 29, 2022 at 3:45 PM Amit Kapila > wrote: > > > > > > > I've attached updated patches for all branches. Please review them. > > > > Thanks, the patches look mostly goo

Re: fix typos

Op 02-08-2022 om 07:28 schreef John Naylor: On Tue, Aug 2, 2022 at 1:05 AM Erik Rijkers > wrote: > > Recent typos... The part of the sentence inside parentheses is not clear to me, before or after the patch:     Dropping an extension causes its component objects, a

Re: Column Filtering in Logical Replication

On Mon, Jul 25, 2022 at 1:27 PM Peter Smith wrote: > > On Sat, Dec 11, 2021 at 12:24 AM Alvaro Herrera > wrote: > > > > On 2021-Dec-10, Peter Eisentraut wrote: > > > ... > > > > > There was no documentation, so I wrote a bit (patch 0001). It only > > > touches > > > the CREATE PUBLICATION and

Fix obsoleted comments for function prototypes

While doing the search in [1], I spotted several places where the comments for the function prototypes are obsoleted. For instance, btree_desc() and btree_identify() are now located in nbtdesc.c but the comment in nbtxlog.h is still claiming they are in nbtxlog.c. Fix these places with the attache

RE: Handle infinite recursion in logical replication setup

On Fri, Jul 29, 2022 1:22 PM vignesh C wrote: > > On Fri, Jul 29, 2022 at 8:31 AM Peter Smith > wrote: > > > > Thanks for the comments, the attached v41 patch has the changes for the > same. > Thanks for updating the patch. A comment for 0002 patch. In the example in section 31.11.4 (Generi

Re: POC: GROUP BY optimization

On Fri, Jul 15, 2022 at 09:46:51PM +0200, Tomas Vondra wrote: > I agree this is a mistake in db0d67db2 that makes the test useless. Tomas, please note that this is an open item assigned to you. Are you planning to do something with these regression tests by beta3? -- Michael signature.asc Descr

support for SSE2 intrinsics

Recently there have been several threads where the problem at hand lends itself to using SSE2 SIMD intrinsics. These are convenient because on 64-bit x86 the instructions are always present and so don't need a runtime check. To integrate them into our code base, we will need to take some measures f

Re: Fix obsoleted comments for function prototypes

On Tue, Aug 02, 2022 at 05:06:44PM +0800, Richard Guo wrote: > While doing the search in [1], I spotted several places where the > comments for the function prototypes are obsoleted. For instance, > btree_desc() and btree_identify() are now located in nbtdesc.c but the > comment in nbtxlog.h is sti

Re: [PATCH] Fix pg_upgrade test from v10

On Mon, Aug 01, 2022 at 01:04:39AM +0300, Anton A. Melnikov wrote: > I looked at this thread and tried to apply some changes from it in practice. > And found one strange error and describe it in a comment here: > https://www.postgresql.org/message-id/cc7e961a-d5ad-8c6d-574b-478aacc11cf7%40inbox.ru

Re: Allow file inclusion in pg_hba and pg_ident files

On Sat, Jul 30, 2022 at 04:09:36PM +0800, Julien Rouhaud wrote: > I've been working on all of that and came up with the attached v8. > > - 0001: I modified things as discussed previously to report the real auth file > names rather than the hardcoded "pg_ident.conf" and "pg_hba.conf" in the > v

Re: Slow standby snapshot

On Fri, 29 Jul 2022 at 18:24, Michail Nikolaev wrote: > > A simple patch like this seems to hit the main concern, aiming to keep > > the array from spreading out and impacting snapshot performance for > > SELECTs, yet not doing it so often that the startup process has a > > higher burden of work.

Re: POC: GROUP BY optimization

On Tue, 2 Aug 2022 at 22:21, Michael Paquier wrote: > > On Fri, Jul 15, 2022 at 09:46:51PM +0200, Tomas Vondra wrote: > > I agree this is a mistake in db0d67db2 that makes the test useless. > > Tomas, please note that this is an open item assigned to you. Are you > planning to do something with t

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

On Mon, 1 Aug 2022 at 03:49, Tom Lane wrote: > Are you going to push the other patch (adjusting > select_outer_pathkeys_for_merge) first, so that we can see the residual > plan changes that this patch creates? I'm not entirely comfortable > with the regression test changes as posted. Yes, I push

Re: remove more archiving overhead

On 8/2/22 01:02, Nathan Bossart wrote: On Sat, Jul 30, 2022 at 11:51:56PM -0700, Noah Misch wrote: Inviting the administrator to resolve things is more dangerous than just returning true. I recommend making this text more opinionated and simpler: libraries must return true. Alternately, if som

[PATCH] Add a inline function to eliminate duplicate code

abstract the logic of `scankey change attribute num to index col number` to change_sk_attno_to_index_column_num, which is a static inline function. -- Regards Junwang Zhao 0001-add-a-inline-function-to-eliminate-duplicate-code.patch Description: Binary data

Re: Slow standby snapshot

> On 29 Jul 2022, at 20:08, Simon Riggs wrote: > > A simple patch like this seems to hit the main concern, aiming to keep > the array from spreading out and impacting snapshot performance for > SELECTs, yet not doing it so often that the startup process has a > higher burden of work. The idea

RE: Perform streaming logical transactions by background workers and parallel apply

On Wednesday, July 27, 2022 4:22 PM houzj.f...@fujitsu.com wrote: > > On Tuesday, July 26, 2022 5:34 PM Dilip Kumar > wrote: > > > 3. > > Why are we restricting parallel apply workers only for the streamed > > transactions, because streaming depends upon the size of the logical > > decoding work

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em seg., 1 de ago. de 2022 às 22:19, Peter Smith escreveu: > On Tue, Aug 2, 2022 at 3:09 AM Ranier Vilela wrote: > > > > Em sáb., 16 de jul. de 2022 às 16:54, Ranier Vilela > escreveu: > >> > >> > >> > >> Em sáb, 16 de jul de 2022 2:58 AM, Peter Eisentraut < > peter.eisentr...@enterprisedb.com>

Re: Handle infinite recursion in logical replication setup

On Tue, Jul 26, 2022 at 9:07 AM Amit Kapila wrote: > > On Tue, Jul 26, 2022 at 7:13 AM Jonathan S. Katz wrote: > > > > Thanks for the example. I agree that it is fairly simple to reproduce. > > > > I understand that "copy_data = force" is meant to protect a user from > > hurting themself. I'm not

Re: add test: pg_rowlocks extension

I modified my previous patch by reflecting the feedback. and I wrote most of the queries for the test after looking at the file below. - ref: (https://github.com/postgres/postgres/blob/master/src/test/isolation/specs/tuplelock-conflict.spec) The coverage of the test is approximately 81.5%. If t

Re: Perform streaming logical transactions by background workers and parallel apply

On Tue, Aug 2, 2022 at 5:16 PM houzj.f...@fujitsu.com wrote: > > On Wednesday, July 27, 2022 4:22 PM houzj.f...@fujitsu.com wrote: > > > > On Tuesday, July 26, 2022 5:34 PM Dilip Kumar > > wrote: > > > > > 3. > > > Why are we restricting parallel apply workers only for the streamed > > > transact

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Hi Ranier, I'm pretty late to thread but would like to know about your claim in the thread: `All compilers currently have memset optimized.` I know one case of optimization where variable is not used after the memset. Are the cases for which the optimization is done consistent across all the compi

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

David Rowley writes: > On Mon, 1 Aug 2022 at 03:49, Tom Lane wrote: >> Likewise, it might be >> better to fix DEFAULT_FDW_TUPLE_COST beforehand, to detangle what >> the effects of that are. > I chatted to Andres and Thomas about this last week and their view > made me think it might not be quite

Re: [PATCH] Add a inline function to eliminate duplicate code

Patch is looking good to me. Thanks, Mahendrakar. On Tue, 2 Aug 2022 at 16:57, Junwang Zhao wrote: > abstract the logic of `scankey change attribute num to index col > number` to change_sk_attno_to_index_column_num, which is a static > inline function. > > -- > Regards > Junwang Zhao >

Re: Race between KeepFileRestoredFromArchive() and restartpoint

On 7/31/22 02:17, Noah Misch wrote: On Tue, Jul 26, 2022 at 07:21:29AM -0400, David Steele wrote: On 6/19/21 16:39, Noah Misch wrote: On Tue, Feb 02, 2021 at 07:14:16AM -0800, Noah Misch wrote: Recycling and preallocation are wasteful during archive recovery, because KeepFileRestoredFromArchiv

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em ter., 2 de ago. de 2022 às 10:17, mahendrakar s < mahendrakarfo...@gmail.com> escreveu: > Hi Ranier, > > I'm pretty late to thread but would like to know about your claim in the > thread: > `All compilers currently have memset optimized.` > What did I mean, modern compilers. I know one case of

Re: Race between KeepFileRestoredFromArchive() and restartpoint

On Tue, Aug 02, 2022 at 10:14:22AM -0400, David Steele wrote: > On 7/31/22 02:17, Noah Misch wrote: > >On Tue, Jul 26, 2022 at 07:21:29AM -0400, David Steele wrote: > >>On 6/19/21 16:39, Noah Misch wrote: > >>>On Tue, Feb 02, 2021 at 07:14:16AM -0800, Noah Misch wrote: > Recycling and prealloca

Why is DEFAULT_FDW_TUPLE_COST so insanely low?

Over on [1] I was complaining that I thought DEFAULT_FDW_TUPLE_COST, which is defined as 0.01 was unrealistically low. For comparison, cpu_tuple_cost, something we probably expect to be in a CPU cache is also 0.01. We've defined DEFAULT_PARALLEL_TUPLE_COST to be 0.1, which is 10x cpu_tuple_cost.

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

On Wed, 3 Aug 2022 at 01:19, Tom Lane wrote: > > David Rowley writes: > > I chatted to Andres and Thomas about this last week and their view > > made me think it might not be quite as clear-cut as "just bump it up a > > bunch because it's ridiculously low" that I had in mind. They > > mentioned

Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size

Hi, On 2022-08-02 12:05:55 +0900, Amit Langote wrote: > On Tue, Aug 2, 2022 at 9:39 AM Andres Freund wrote: > > On 2022-07-27 17:01:13 +0900, Amit Langote wrote: > > > Here's an updated version of the patch, with mostly cosmetic changes. > > > In particular, I added comments describing the new ll

Re: Race between KeepFileRestoredFromArchive() and restartpoint

On 8/2/22 10:37, Noah Misch wrote: On Tue, Aug 02, 2022 at 10:14:22AM -0400, David Steele wrote: On 7/31/22 02:17, Noah Misch wrote: On Tue, Jul 26, 2022 at 07:21:29AM -0400, David Steele wrote: On 6/19/21 16:39, Noah Misch wrote: On Tue, Feb 02, 2021 at 07:14:16AM -0800, Noah Misch wrote:

Re: Slow standby snapshot

On Tue, 2 Aug 2022 at 12:32, Andrey Borodin wrote: > KnownAssignedXidsRemoveTree() only compress with probability 1/8, but it is > still O(N*N). Currently it is O(NlogS), not quite as bad as O(N^2). Since each xid in the tree is always stored to the right, it should be possible to make that si

Re: Pluggable toaster

Hi, On 2022-08-02 09:15:12 +0300, Nikita Malakhov wrote: > Attach includes: > v11-0002-toaster-interface.patch - contains TOAST API with default Toaster > left as-is (reference implementation) and Dummy toaster as an example > (will be removed later as a part of refactoring?). > > v11-0003-toaste

Cutting test runtime for src/test/modules/snapshot_too_old

I've complained before that the snapshot_too_old TAP tests seem ridiculously slow --- close to a minute of runtime even on very fast machines. Today I happened to look closer and realized that there's an absolutely trivial way to cut that. The core of the slow runtime is that there's a "pg_sleep(

Re: support for SSE2 intrinsics

On Tue, Aug 02, 2022 at 05:22:52PM +0700, John Naylor wrote: > Given all this, the anti-climax is: it seems we can start with something > like src/include/port/simd.h with: > > #if (defined(__x86_64__) || defined(_M_AMD64)) > #include > #define USE_SSE2 > #endif > > (plus a comment summarizing t

Re: Parse CE and BCE in dates and times

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Add index scan progress to pg_stat_progress_vacuum

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: [PATCH] Add sortsupport for range types and btree_gist

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

> > > Hi, David: I was looking at the final patch and noticed that setno field in agg_presorted_distinctcheck struct is never used. Looks like it was copied from neighboring struct. Can you take a look at the patch ? Thanks > drop-setno-from-agg_presorted_distinctcheck.patch Description: Bin

Re: Cutting test runtime for src/test/modules/snapshot_too_old

On Tue, Aug 2, 2022 at 11:38 AM Tom Lane wrote: > I've complained before that the snapshot_too_old TAP tests seem > ridiculously slow --- close to a minute of runtime even on very fast > machines. Today I happened to look closer and realized that there's > an absolutely trivial way to cut that.

Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Restructure ALTER TABLE notes to clarify table rewrites and verification scans

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Cutting test runtime for src/test/modules/snapshot_too_old

Robert Haas writes: > Yeah, I feel like it was a mistake to allow the list of permutations > to be unspecified. It encourages people to just run them all, which is > almost never a thoughtful decision. Maybe there's something to be said > for running these tests in one successful permutation and o

Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints

On Tue, Mar 29, 2022 at 11:55:05AM -0400, Robert Haas wrote: > On Mon, Mar 28, 2022 at 3:08 PM Robert Haas wrote: > > smgrcreate() as we would for most WAL records or whether it should be > > adopting the new system introduced by > > 49d9cfc68bf4e0d32a948fe72d5a0ef7f464944e. I wrote about this con

Re: pg_auth_members.grantor is bunk

On Mon, Aug 1, 2022 at 10:38 AM Tom Lane wrote: > > I can't see this on cfbot - either I don't know how to use it > > properly, which is quite possible, or the results aren't showing up > > because of the close of the July CommitFest. > > I think the latter --- the cfbot thinks the July CF is no l

Re: Finer grain log timestamps

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: pg15b2: large objects lost on upgrade

"Jonathan S. Katz" writes: > Given this appears to be resolved, I have removed this from "Open > Items". Thanks! Sadly, we're still not out of the woods. I see three buildfarm failures in this test since Robert resolved the "-X" problem [1][2][3]: grassquit reported [19:34:15.249](0.001s) not

Re: Generalize ereport_startup_progress infrastructure

On Tue, Aug 2, 2022 at 3:25 AM Bharath Rupireddy wrote: > ereport_startup_progress infrastructure added by commit 9ce346e [1] > will be super-useful for reporting progress of any long-running server > operations, not just the startup process operations. For instance, > postmaster can use it for re

Re: Add LZ4 compression in pg_dump

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: TAP output format in pg_regress

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Add last commit LSN to pg_last_committed_xact()

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: WaitLatchOrSocket seems to not count to 4 right...

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Avoiding smgrimmedsync() during nbtree index builds

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: speed up a logical replica setup

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: [WIP] Allow pg_upgrade to copy segments of the same relfilenode in parallel

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Speed up transaction completion faster after many relations are accessed in a transaction

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: pg15b2: large objects lost on upgrade

On 8/2/22 1:12 PM, Tom Lane wrote: "Jonathan S. Katz" writes: Given this appears to be resolved, I have removed this from "Open Items". Thanks! Sadly, we're still not out of the woods. I see three buildfarm failures in this test since Robert resolved the "-X" problem [1][2][3]: Not sure wha

Re: pg15b2: large objects lost on upgrade

On Tue, Aug 2, 2022 at 1:12 PM Tom Lane wrote: > Not sure what to make of this, except that maybe the test is telling > us about an actual bug of exactly the kind it's designed to expose. That could be, but what would the bug be exactly? It's hard to think of a more direct way of setting relminmx

Re: pg15b2: large objects lost on upgrade

On 8/2/22 3:23 PM, Robert Haas wrote: On Tue, Aug 2, 2022 at 1:12 PM Tom Lane wrote: Not sure what to make of this, except that maybe the test is telling us about an actual bug of exactly the kind it's designed to expose. That could be, but what would the bug be exactly? It's hard to think of

Re: pg15b2: large objects lost on upgrade

"Jonathan S. Katz" writes: > On 8/2/22 1:12 PM, Tom Lane wrote: >> Sadly, we're still not out of the woods. I see three buildfarm >> failures in this test since Robert resolved the "-X" problem [1][2][3]: > Looking at the test code, is there anything that could have changed the > relfrozenxid o

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

On Tue, Aug 2, 2022 at 11:02 AM Zhihong Yu wrote: > >> Hi, David: > > I was looking at the final patch and noticed that setno field > in agg_presorted_distinctcheck struct is never used. > > Looks like it was copied from neighboring struct. > > Can you take a look at the patch ? > > Thanks > >> >

Re: pg15b2: large objects lost on upgrade

"Jonathan S. Katz" writes: > On 8/2/22 3:23 PM, Robert Haas wrote: >> I'm not quite sure how to rule that theory in or out, though. > Without overcomplicating this, are we able to check to see if autovacuum > ran during the course of the test? Looks like we're all thinking along the same lines.

Re: pg15b2: large objects lost on upgrade

On 8/2/22 3:39 PM, Tom Lane wrote: "Jonathan S. Katz" writes: On 8/2/22 3:23 PM, Robert Haas wrote: I'm not quite sure how to rule that theory in or out, though. Without overcomplicating this, are we able to check to see if autovacuum ran during the course of the test? Looks like we're al

Re: pg15b2: large objects lost on upgrade

"Jonathan S. Katz" writes: > On 8/2/22 3:39 PM, Tom Lane wrote: >>> I am not in favor of disabling autovacuum in the test: ordinary >>> users are not going to do that while pg_upgrade'ing, so it'd make >>> the test less representative of real-world usage, which seems like >>> a bad idea. We could

Re: standby recovery fails (tablespace related) (tentative patch and discussion)

On Sun, Jul 31, 2022 at 3:46 PM Thomas Munro wrote: > On Sun, Jul 31, 2022 at 2:37 AM Tom Lane wrote: > > Alvaro Herrera writes: > > > WFM, pushed that way. > > > > Looks like conchuela is still intermittently unhappy. > > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=

Re: pg15b2: large objects lost on upgrade

On 8/2/22 3:51 PM, Tom Lane wrote: "Jonathan S. Katz" writes: On 8/2/22 3:39 PM, Tom Lane wrote: I am not in favor of disabling autovacuum in the test: ordinary users are not going to do that while pg_upgrade'ing, so it'd make the test less representative of real-world usage, which seems like

Re: oat_post_create expected behavior

> Right, same thing I'm saying. I also think we should discourage > people from doing cowboy CCIs inside their OAT hooks, because that > makes the testability problem even worse. Maybe that means we > need to uniformly move the CREATE hooks to after a system-provided > CCI, but I've not thought h

Re: pg15b2: large objects lost on upgrade

On 8/2/22 4:20 PM, Jonathan S. Katz wrote: On 8/2/22 3:51 PM, Tom Lane wrote: "Jonathan S. Katz" writes: On 8/2/22 3:39 PM, Tom Lane wrote: I am not in favor of disabling autovacuum in the test: ordinary users are not going to do that while pg_upgrade'ing, so it'd make the test less represent

Re: libpq compression (part 2)

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Per-table storage parameters for TableAM/IndexAM extensions

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Parallelize correlated subqueries that execute within each worker

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Push down time-related SQLValue functions to foreign server

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: [PATCH] Allow multiple recursive self-references

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Patch to avoid orphaned dependencies

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: Race between KeepFileRestoredFromArchive() and restartpoint

On Tue, Aug 2, 2022 at 10:01 AM David Steele wrote: > > > That makes sense. Each iteration of the restartpoint recycle loop has a > 1/N > > chance of failing. Recovery adds >N files between restartpoints. > Hence, the > > WAL directory grows without bound. Is that roughly the theory in mind? >

Re: Consider parallel for lateral subqueries with limit

This entry has been waiting on author input for a while (our current threshold is roughly two weeks), so I've marked it Returned with Feedback. Once you think the patchset is ready for review again, you (or any interested party) can resurrect the patch entry by visiting https://commitfest.pos

Re: jsonpath syntax extensions

As discussed in [1], we're taking this opportunity to return some patchsets that don't appear to be getting enough reviewer interest. This is not a rejection, since we don't necessarily think there's anything unacceptable about the entry, but it differs from a standard "Returned with Feedback" in

Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints

On Tue, Aug 2, 2022 at 1:50 PM Justin Pryzby wrote: > Unfortunately, that isn't very consistent, and you have have to run it a bunch > of times... I was eventually able to reproduce this in part by using the interactive psql method you describe. It didn't crash, but it did spit out a bunch of fun

Re: [PATCH] minor reloption regression tests improvement

On 6/30/22 16:16, Jacob Champion wrote: > [CFM hat] Since you feel strongly about the patch, and we're short on > time before the commitfest starts, I have re-registered this. That way > there can be an explicit decision as opposed to a pocket veto by me. [CFM hat] Okay, with another CF come and g

Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints

Robert Haas writes: > WARNING: problem in alloc set PortalContext: req size > alloc size > for chunk 0x7f99508911f0 in block 0x7f9950890800 > WARNING: problem in alloc set PortalContext: bad size 0 for chunk > 0x7f99508911f0 in block 0x7f9950890800 > WARNING: problem in alloc set PortalContext:

Re: Proposal: Support custom authentication methods using hooks

[CFM hat] Okay, either way you look at it, this patchset needs author work before any further review can be done. Peter has given some additional feedback on next steps, Stephen has asked for clarification on the goals of the patchset, etc. I feel pretty confident in marking this Returned with Feed

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

On Wed, 3 Aug 2022 at 07:31, Zhihong Yu wrote: > On Tue, Aug 2, 2022 at 11:02 AM Zhihong Yu wrote: >> I was looking at the final patch and noticed that setno field in >> agg_presorted_distinctcheck struct is never used. > Looks like setoff field is not used either. Thanks for the report. It se

Re: [PATCH] Expose port->authn_id to extensions and triggers

On 6/22/22 06:31, Drouvot, Bertrand wrote: > FWIW, I just created a new thread to expose the port->authn_id through > the SYSTEM_USER sql reserved word. Review for both seems to have dried up a bit. I'm not particularly invested in my code, but I do want to see *a* solution go in. So if it helps

Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints

On Tue, Aug 02, 2022 at 05:46:34PM -0400, Tom Lane wrote: > Robert Haas writes: > > WARNING: problem in alloc set PortalContext: req size > alloc size for > > chunk 0x7f99508911f0 in block 0x7f9950890800 > > This looks like nothing so much as the fallout from something scribbling > past the end

Re: Proposal: Support custom authentication methods using hooks

Hi Jacob, On Tue, Aug 2, 2022 at 2:48 PM Jacob Champion wrote: > [CFM hat] Okay, either way you look at it, this patchset needs author > work before any further review can be done. Peter has given some > additional feedback on next steps, Stephen has asked for clarification > on the goals of the

Re: [PROPOSAL] new diagnostic items for the dynamic sql

>From looking at this patch and its history [1, 2], I think momentum was probably lost during the January CF, where this patch was unregistered (presumably by accident). I've carried it forward, but it needs some help to keep from stalling out. Definitely make sure it's rebased and up to date by t

Re: [PROPOSAL] new diagnostic items for the dynamic sql

On 8/2/22 15:09, Jacob Champion wrote: > I've carried it forward, but it needs some help to keep from stalling > out. Definitely make sure it's rebased and up to date by the time the > next CF starts, to give it the best chance at getting additional review > (if you haven't received any by then).

Re: optimize lookups in snapshot [sub]xip arrays

On Fri, Jul 29, 2022 at 10:38:11PM -0700, Nathan Bossart wrote: > On Sat, Jul 30, 2022 at 12:02:02PM +0700, John Naylor wrote: >> I'll be the first to say it's not committable and needs some thought. Since >> there are several recently proposed patches that take advantage of SSE2, it >> seems time

Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints

On 2022-08-02 17:04:16 -0500, Justin Pryzby wrote: > I got this interesting looking thing. > > ==11628== Invalid write of size 8 > ==11628==at 0x1D12B3A: smgrsetowner (smgr.c:213) > ==11628==by 0x1C7C224: RelationGetSmgr (rel.h:572) > ==11628==by 0x1C7C224: RelationCopyStorageUsingBuff

  1   2   >