Re: Add --{no-,}bypassrls flags to createuser

On 2022-04-14 18:57, Daniel Gustafsson wrote: On 14 Apr 2022, at 09:42, Shinya Kato wrote: To add the ROLE clause, the originally existing --role option (corresponding to the IN ROLE clause) is changed to the --in-role option. Would this not be good from a backward compatibility

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 10:12:05PM -0700, Andres Freund wrote: > On 2022-04-14 19:45:15 -0700, Noah Misch wrote: > > I suspect the failure is somehow impossible in "check". Yesterday, I > > cranked > > up the number of locales, so there are now a lot more installcheck. Before > > that, each

Re: Intermittent buildfarm failures on wrasse

Andres Freund writes: > On 2022-04-14 23:56:15 -0400, Tom Lane wrote: >> Well, damn. I changed my script that way and it failed on the tenth >> iteration (versus a couple hundred successful iterations the other >> way). > Just to make sure: This is also on wrasse? Right, gcc211 with a

Re: Intermittent buildfarm failures on wrasse

Hi, On 2022-04-14 19:45:15 -0700, Noah Misch wrote: > I suspect the failure is somehow impossible in "check". Yesterday, I cranked > up the number of locales, so there are now a lot more installcheck. Before > that, each farm run had one "check" and two "installcheck". Those days saw > ten

Re: Intermittent buildfarm failures on wrasse

Hi, On 2022-04-14 23:56:15 -0400, Tom Lane wrote: > I wrote: > > One thing I'm eyeing now is that it looks like Noah is re-initdb'ing > > each time, whereas I'd just stopped and started the postmaster of > > an existing installation. That does not seem like it could matter > > but ... > > Well,

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 11:56:15PM -0400, Tom Lane wrote: > Anyway, I'm too tired to do more tonight, but now that I can reproduce it > I will stick some debugging logic in tomorrow. I no longer think we > should clutter the git repo with any more short-term hacks. Sounds good. I've turned off

Re: Intermittent buildfarm failures on wrasse

Hi, On 2022-04-14 22:40:51 -0400, Tom Lane wrote: > Peter Geoghegan writes: > > Suppose that the bug was actually in 06f5295af6, "Add single-item > > cache when looking at topmost XID of a subtrans XID". Doesn't that fit > > your timeline just as well? > > I'd dismissed that on the grounds that

Re: Intermittent buildfarm failures on wrasse

I wrote: > One thing I'm eyeing now is that it looks like Noah is re-initdb'ing > each time, whereas I'd just stopped and started the postmaster of > an existing installation. That does not seem like it could matter > but ... Well, damn. I changed my script that way and it failed on the tenth

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 11:06:04PM -0400, Tom Lane wrote: > Noah Misch writes: > > But 24s after that email, it did reproduce the problem. > > Ain't that always the way. Quite so. > > Same symptoms as the > > last buildfarm runs, including visfrac=0. I'm attaching my script. (It has > >

Re: Intermittent buildfarm failures on wrasse

Peter Geoghegan writes: > Well, Noah is running wrasse with 'fsync = off'. And did so in the > script as well. As am I. I duplicated wrasse's config to the extent of cat >>$PGDATA/postgresql.conf <

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 7:54 PM Tom Lane wrote: > This is far from the first time that I've failed to reproduce a buildfarm > result manually, even on the very machine hosting the animal. I would > like to identify the cause(s) of that. One obvious theory is that the > environment under a cron

Re: Intermittent buildfarm failures on wrasse

Noah Misch writes: > But 24s after that email, it did reproduce the problem. Ain't that always the way. > Same symptoms as the > last buildfarm runs, including visfrac=0. I'm attaching my script. (It has > various references to my home directory, so it's not self-contained.) That's

Re: Intermittent buildfarm failures on wrasse

Noah Misch writes: > Like Tom, I'm failing to reproduce this outside the buildfarm client. This is far from the first time that I've failed to reproduce a buildfarm result manually, even on the very machine hosting the animal. I would like to identify the cause(s) of that. One obvious theory

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 07:45:15PM -0700, Noah Misch wrote: > On Thu, Apr 14, 2022 at 06:52:49PM -0700, Andres Freund wrote: > > On 2022-04-14 21:32:27 -0400, Tom Lane wrote: > > > Peter Geoghegan writes: > > > > Are you aware of Andres' commit 02fea8fd? That work prevented exactly > > > > the

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 06:52:49PM -0700, Andres Freund wrote: > On 2022-04-14 21:32:27 -0400, Tom Lane wrote: > > Peter Geoghegan writes: > > > Are you aware of Andres' commit 02fea8fd? That work prevented exactly > > > the same set of symptoms (the same index-only scan create_index > > >

Re: Intermittent buildfarm failures on wrasse

Peter Geoghegan writes: > Suppose that the bug was actually in 06f5295af6, "Add single-item > cache when looking at topmost XID of a subtrans XID". Doesn't that fit > your timeline just as well? I'd dismissed that on the grounds that there are no subtrans XIDs involved in tenk1's contents.

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 7:20 PM Tom Lane wrote: > Oh! You mean that maybe the OldestXmin horizon was fine, but something > decided not to update hint bits (and therefore also not the all-visible > bit) anyway? Worth investigating I guess. Yes. That is starting to seem like a plausible

Re: Intermittent buildfarm failures on wrasse

Peter Geoghegan writes: > That was the intent, but that in itself doesn't mean that it isn't > something to do with setting hint bits (not the OldestXmin horizon > being held back). Oh! You mean that maybe the OldestXmin horizon was fine, but something decided not to update hint bits (and

Re: Support logical replication of DDLs

> > But then this could be true for DML as well right? Like after > > replicating the function to the subscriber if we are sending the DML > > done by function then what's the problem in DDL. I mean if there is > > no design issue in implementing this then I don't think there is much > > point

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 6:53 PM Tom Lane wrote: > That band-aid only addressed the situation of someone having turned > off synchronous_commit in the first place; which is not the case > on wrasse or most/all other buildfarm animals. Whatever we're > dealing with here is something independent of

Re: Intermittent buildfarm failures on wrasse

Peter Geoghegan writes: > Anyway, I suppose it's possible that problems reappeared here due to > some other patch. Something else could have broken Andres' earlier > band aid solution (which was to set synchronous_commit=on in > test_setup). That band-aid only addressed the situation of someone

Re: Intermittent buildfarm failures on wrasse

Hi, On 2022-04-14 21:32:27 -0400, Tom Lane wrote: > Peter Geoghegan writes: > > Are you aware of Andres' commit 02fea8fd? That work prevented exactly > > the same set of symptoms (the same index-only scan create_index > > regressions), > > Hm. I'm starting to get the feeling that the real

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 6:32 PM Tom Lane wrote: > Hm. I'm starting to get the feeling that the real problem here is > we've "optimized" the system to the point where repeatable results > from VACUUM are impossible :-( I don't think that there is any fundamental reason why VACUUM cannot have

Re: Intermittent buildfarm failures on wrasse

Peter Geoghegan writes: > Are you aware of Andres' commit 02fea8fd? That work prevented exactly > the same set of symptoms (the same index-only scan create_index > regressions), Hm. I'm starting to get the feeling that the real problem here is we've "optimized" the system to the point where

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Hi, On 2022-04-14 15:05:50 -0400, Tom Lane wrote: > Andres' complaint is that that snapshot might get invalidated when you > weren't expecting it, but I'm not really convinced that we have all > that many bugs of that ilk. Wouldn't CLOBBER_CACHE_ALWAYS testing > find them? Don't see why it

Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]

At Thu, 14 Apr 2022 11:13:01 -0400, Robert Haas wrote in > On Tue, Apr 12, 2022 at 6:55 AM Kyotaro Horiguchi > wrote: > > (My mailer has been fixed.) > > Cool. > > > So, I created the patches for back-patching from 10 to 14. (With > > fixed a silly bug of the v1-pg14 that

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 3:28 PM Peter Geoghegan wrote: > A bunch of autovacuums that ran between "2022-04-14 22:49:16.274" and > "2022-04-14 22:49:19.088" all have the same "removable cutoff". Are you aware of Andres' commit 02fea8fd? That work prevented exactly the same set of symptoms (the

Re: shared-memory based stats collector - v70

Hi, On 2022-04-13 17:55:18 -0700, Andres Freund wrote: > On 2022-04-13 16:56:45 -0700, David G. Johnston wrote: > > On Wed, Apr 13, 2022 at 4:34 PM David G. Johnston < > > david.g.johns...@gmail.com> wrote: > > Sorry, apparently this "2000-01-01" behavior only manifests after crash > > recovery

Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations

On Thu, Apr 14, 2022 at 4:19 PM Jim Nasby wrote: > > - percentage of non-yet-removable vs removable tuples > > This'd give you an idea how bad your long-running-transaction problem is. VACUUM fundamentally works by removing those tuples that are considered dead according to an XID-based cutoff

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 3:23 PM Tom Lane wrote: > If we captured equivalent output from the manual VACUUM in test_setup, > maybe something could be learned. However, it seems virtually certain > to me that the problematic xmin is in some background process > (eg autovac launcher) and thus

Re: Intermittent buildfarm failures on wrasse

Peter Geoghegan writes: > Have you looked at the autovacuum log output in more detail? I don't think there's anything to be learned there. The first autovacuum in wrasse's log happens long after things went south: 2022-04-14 22:49:15.177 CEST [9427:1] LOG: automatic vacuum of table

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 2:33 PM Tom Lane wrote: > Meanwhile, wrasse did fail with my relallvisible check in place [1], > and what that shows is that relallvisible is *zero* to start with > and remains so throughout the CREATE INDEX sequence. That pretty > definitively proves that it's not a

Re: Intermittent buildfarm failures on wrasse

I wroteL > Andres Freund writes: >> Thanks! Can you repro the problem manually on wrasse, perhaps even >> outside the buildfarm script? > I'm working on that right now, actually... So far, reproducing it manually has been a miserable failure: I've run about 180 cycles of the core regression

Re: Support logical replication of DDLs

> You should forbid it. Unless you can decompose the command into multiple SQL > commands to make it a safe operation for logical replication. > > Let's say you want to add a column with a volatile default. > > ALTER TABLE foo ADD COLUMN bar double precision DEFAULT random(); > > If you replicate

Re: [Proposal] vacuumdb --schema only

Le 11/04/2022 à 20:37, Nathan Bossart a écrit : > On Fri, Apr 08, 2022 at 05:16:06PM +0200, Gilles Darold wrote: >> Attached v7 of the patch that should pass cfbot. > Thanks for the new patch! Unfortunately, it looks like some recent changes > have broken it again. > >> +enum trivalue

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Robert Haas writes: > On Thu, Apr 14, 2022 at 3:05 PM Tom Lane wrote: >> If you don't register it, then you need to also make sure that it's >> destroyed whenever that older snapshot is. > Well, if that's true, then I agree that it's a good argument against > that approach. But I guess I'm

Re: Skipping schema changes in publication

On Thu, Apr 14, 2022, at 10:47 AM, Peter Eisentraut wrote: > On 12.04.22 08:23, vignesh C wrote: > > I have also included the implementation for skipping a few tables from > > all tables publication, the 0002 patch has the implementation for the > > same. > > This feature is helpful for use cases

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

On Thu, Apr 14, 2022 at 3:05 PM Tom Lane wrote: > If you don't register it, then you need to also make sure that it's > destroyed whenever that older snapshot is. Which I think would require > either a lot of useless/inefficient CatalogSnapshot destructions, or > infrastructure that's more or

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Robert Haas writes: > On Thu, Apr 14, 2022 at 1:36 PM Tom Lane wrote: >> Not really following? ISTM the point of ffaa44cb5 was that if we don't >> include the CatalogSnapshot in our advertised xmin, then the length >> of time we can safely use it is *zero*. > No, I don't think so. I'm

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Andres Freund writes: > On 2022-04-14 12:16:45 -0400, Robert Haas wrote: >> I got curious and looked at the underlying problem here and I am >> wondering whether HaveRegisteredOrActiveSnapshot() is just buggy. It >> seems to me that the code is always going to return true if there are >> any

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

On Thu, Apr 14, 2022 at 1:36 PM Tom Lane wrote: > Robert Haas writes: > > I am wondering whether ffaa44cb559db332baeee7d25dedd74a61974203 bet on > > the wrong horse. When I invented CatalogSnapshot, I intended for it to > > be an ephemeral snapshot that we'd keep for as long as we could safely >

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Hi, On 2022-04-14 13:36:51 -0400, Tom Lane wrote: > What if the reason we need a snapshot is to detoast some toasted item > we read from a catalog with the CatalogSnapshot? There might not be > any other valid snapshot, so I don't think I buy your argument here. We definitely do have places

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Robert Haas writes: > I am wondering whether ffaa44cb559db332baeee7d25dedd74a61974203 bet on > the wrong horse. When I invented CatalogSnapshot, I intended for it to > be an ephemeral snapshot that we'd keep for as long as we could safely > do so and then discard it as soon as there's any hint of

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

On Thu, Apr 14, 2022 at 12:54 PM Andres Freund wrote: > Part of that is because right now the assertion is placed "too deep" - > it should be much higher up, so it's reached even if there's not > actually a toast datum. But there's of other bugs preventing that :(. A > lot of bugs have been

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 10:07 AM Peter Geoghegan wrote: > It looks like you're changing the elevel convention for these "extra" > messages with this patch. That might be fine, but don't forget about > similar ereports() in vacuumparallel.c. I think that the elevel should > probably remain uniform

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 9:48 AM Andres Freund wrote: > I think it might be worth leaving in, but let's debate that separately? > I'm thinking of something like the attached. The current convention for the "extra" ereport()s that VACUUM VERBOSE outputs at INFO elevel is to use DEBUG2 elevel in

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Hi, On 2022-04-14 09:54:25 -0700, Andres Freund wrote: > On 2022-04-14 12:16:45 -0400, Robert Haas wrote: > > I got curious and looked at the underlying problem here and I am > > wondering whether HaveRegisteredOrActiveSnapshot() is just buggy. It > > seems to me that the code is always going to

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Hi, On 2022-04-14 12:16:45 -0400, Robert Haas wrote: > I got curious and looked at the underlying problem here and I am > wondering whether HaveRegisteredOrActiveSnapshot() is just buggy. It > seems to me that the code is always going to return true if there are > any active snapshots, and the

Re: fix cost subqueryscan wrong parallel cost

On Tue, Apr 12, 2022 at 2:57 AM bu...@sohu.com wrote: > The cost_subqueryscan function does not judge whether it is parallel. I don't see any reason why it would need to do that. A subquery scan isn't parallel aware. > regress > -- Incremental sort vs. set operations with varno 0 > set

Re: Intermittent buildfarm failures on wrasse

Hi, On 2022-04-14 12:26:20 -0400, Tom Lane wrote: > Andres Freund writes: > > Thanks! Can you repro the problem manually on wrasse, perhaps even > > outside the buildfarm script? Ah, cool. > I'm working on that right now, actually... > > > I wonder if we should make VACUUM log the VERBOSE

Re: pg_get_publication_tables() output duplicate relid

On 2022-Apr-11, houzj.f...@fujitsu.com wrote: > I have confirmed that the bug of ATTACH PARTITION has been fixed due to recent > commit 7f481b8. Currently, we always invalidate the RelationSyncCache when > attaching a partition, so the pubactions of the newly attached partition will > be rebuilt

Re: make MaxBackends available in _PG_init

Robert Haas writes: > On Thu, Apr 14, 2022 at 12:22 PM Nathan Bossart > wrote: >>> I'd be in favor of a hard break. >> Yeah, this is a good point. If we're okay with breaking existing >> extensions like this, I will work on a patch. > I tend to think it's a good idea. I've come around to

Re: make MaxBackends available in _PG_init

On Thu, Apr 14, 2022 at 12:22 PM Nathan Bossart wrote: > > I'd be in favor of a hard break. There are already multiple extensions that > > relies on non final value of GUCs to size their shmem request. And as an > > extension author it can be hard to realize that, as those extensions work > >

Re: BufferAlloc: don't take two simultaneous locks

On Thu, Apr 14, 2022 at 11:27 AM Tom Lane wrote: > If it's not atomic, then you have to worry about what happens if you > fail partway through, or somebody else changes relevant state while > you aren't holding the lock. Maybe all those cases can be dealt with, > but it will be significantly

Re: Intermittent buildfarm failures on wrasse

Andres Freund writes: > Thanks! Can you repro the problem manually on wrasse, perhaps even > outside the buildfarm script? I'm working on that right now, actually... > I wonder if we should make VACUUM log the VERBOSE output at DEBUG1 > unconditionally. This is like the third bug where we

Re: Intermittent buildfarm failures on wrasse

On Thu, Apr 14, 2022 at 9:18 AM Andres Freund wrote: > I wonder if we should make VACUUM log the VERBOSE output at DEBUG1 > unconditionally. This is like the third bug where we needed that > information, and it's practically impossible to include in regression > output. Then we'd know what the

Re: make MaxBackends available in _PG_init

On Thu, Apr 14, 2022 at 01:50:24PM +0800, Julien Rouhaud wrote: > On Wed, Apr 13, 2022 at 11:30:40AM -0700, Nathan Bossart wrote: >> If we do move forward with the shmem request hook, do we want to disallow >> shmem requests anywhere else, or should we just leave it up to extension >> authors to

Re: Intermittent buildfarm failures on wrasse

Hi, On 2022-04-14 12:01:23 -0400, Tom Lane wrote: > Noah Misch writes: > > On Wed, Apr 13, 2022 at 06:51:12PM -0700, Andres Freund wrote: > >> Noah, any chance you could enable log_autovacuum_min_duration=0 on > >> wrasse? > > > Done. Also forced hourly builds. Thanks! Can you repro the

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

On Thu, Apr 14, 2022 at 11:46 AM Tom Lane wrote: > I don't think Andres had any intention of ignoring it indefinitely. > What he is doing is prioritizing it lower than several of the other > open items, an opinion I fully agree with. Well, my point is that, historically, relegating things to the

Re: allow specifying action when standby encounters incompatible parameter settings

Thanks for taking a look! On Thu, Apr 14, 2022 at 11:36:11AM +0900, Kyotaro Horiguchi wrote: > At Wed, 13 Apr 2022 14:35:21 -0700, Nathan Bossart > wrote in >> I initially set out to see if it was possible to automatically adjust these >> parameters on a standby, but that is considerably more

Re: Intermittent buildfarm failures on wrasse

Noah Misch writes: > On Wed, Apr 13, 2022 at 06:51:12PM -0700, Andres Freund wrote: >> Noah, any chance you could enable log_autovacuum_min_duration=0 on >> wrasse? > Done. Also forced hourly builds. Thanks! We now have two failing runs with the additional info [1][2], and in both, it's clear

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Robert Haas writes: > On Thu, Apr 14, 2022 at 10:42 AM Tom Lane wrote: >> I think you're trying to shoot the messenger. As Andres says, >> 277692220 just exposes that there is some pre-existing bug here. >> It's probably related to 84f5c2908, so I was planning to take a >> look at it at some

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Hi, On 2022-04-14 11:33:45 -0400, Robert Haas wrote: > On Thu, Apr 14, 2022 at 10:42 AM Tom Lane wrote: > > Robert Haas writes: > > > On Wed, Apr 13, 2022 at 8:38 PM Andres Freund wrote: > > >> FWIW, that'd just mean it's an old bug that wasn't easily noticeable > > >> before, not that it's

[GSOC-22] Proposal Review

Hello, Herewith attach my GSOC22 Proposal and request for reviews and comments Looking forward to constructive feedback Regards, Arjun

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

On Thu, Apr 14, 2022 at 10:42 AM Tom Lane wrote: > Robert Haas writes: > > On Wed, Apr 13, 2022 at 8:38 PM Andres Freund wrote: > >> FWIW, that'd just mean it's an old bug that wasn't easily noticeable > >> before, not that it's the fault of 277692220. > > > I think you're still on the hook to

Re: BufferAlloc: don't take two simultaneous locks

Robert Haas writes: > On Thu, Apr 14, 2022 at 10:04 AM Tom Lane wrote: >> FWIW, I have extremely strong doubts about whether this patch >> is safe at all. This particular problem seems resolvable though. > Can you be any more specific? > This existing comment is surely in the running for

Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]

On Tue, Apr 12, 2022 at 6:55 AM Kyotaro Horiguchi wrote: > (My mailer has been fixed.) Cool. > So, I created the patches for back-patching from 10 to 14. (With > fixed a silly bug of the v1-pg14 that HaveVirtualXIDsDelayingChkpt and > HaveVirtualXIDsDelayingChkptEnd are inverted..) I am very

Re: BufferAlloc: don't take two simultaneous locks

On Thu, Apr 14, 2022 at 10:04 AM Tom Lane wrote: > I agree that "just hope it doesn't overflow" is unacceptable. > But couldn't you bound the number of extra entries as MaxBackends? Yeah, possibly ... as long as it can't happen that an operation still counts against the limit after it's failed

Re: Error logging messages

> On 14 Apr 2022, at 16:32, Peter Eisentraut > wrote: > > On 13.04.22 13:51, Daniel Gustafsson wrote: >> 0002: Capitalizes pg_log_error_detail and conversely starts pg_log_error >> with a >> lowercase letter without punctuation. > > I'm having some doubts about some of these changes,

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Robert Haas writes: > On Wed, Apr 13, 2022 at 8:38 PM Andres Freund wrote: >> FWIW, that'd just mean it's an old bug that wasn't easily noticeable >> before, not that it's the fault of 277692220. > I think you're still on the hook to do something about it for this > release. I think you're

Re: Error logging messages

On 13.04.22 13:51, Daniel Gustafsson wrote: 0002: Capitalizes pg_log_error_detail and conversely starts pg_log_error with a lowercase letter without punctuation. I'm having some doubts about some of these changes, especially for interactive features in psql, where the messages are often use a

Re: Support logical replication of DDLs

On Thu, Apr 14, 2022, at 6:26 AM, Dilip Kumar wrote: > I agree. But here the bigger question is what is the correct behavior > in case of the Alter Table? I mean for example in the publisher the > table gets rewritten due to the Access Method change then what should > be the behavior of the

Re: BufferAlloc: don't take two simultaneous locks

Robert Haas writes: > With the existing system, there is a hard cap on the number of hash > table entries that we can ever need: one per buffer, plus one per > partition to cover the "extra" entries that are needed while changing > buffer tags. With the patch, the number of concurrent buffer tag

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

On Wed, Apr 13, 2022 at 8:38 PM Andres Freund wrote: > On 2022-04-13 15:28:19 -0500, Justin Pryzby wrote: > > On Wed, Mar 30, 2022 at 05:58:24PM +0900, Kyotaro Horiguchi wrote: > > > I'm not still confident on this, but it should be better than the v1. > > > > +Andres as this seems to be related

Re: Skipping schema changes in publication

On 12.04.22 08:23, vignesh C wrote: I have also included the implementation for skipping a few tables from all tables publication, the 0002 patch has the implementation for the same. This feature is helpful for use cases where the user wants to subscribe to all the changes except for the changes

Re: BufferAlloc: don't take two simultaneous locks

On Wed, Apr 6, 2022 at 9:17 AM Yura Sokolov wrote: > I skipped v10 since I used it internally for variant > "insert entry with dummy index then search victim". Hi, I think there's a big problem with this patch: --- a/src/backend/storage/buffer/freelist.c +++

Re: GSOC'2022: New and improved website for pgjdbc (JDBC) (2022)

Ok, I will do that. On Thu, 14 Apr, 2022, 6:33 pm Robert Haas, wrote: > On Thu, Apr 14, 2022 at 5:18 AM S.R Keshav wrote: > > Hello, this is keshav. And I have changed my proposal for this project. > > Kindly accept it. > > Hi, > > When you post updates, please reply to the email you sent

Re: GSOC'2022: New and improved website for pgjdbc (JDBC) (2022)

On Thu, Apr 14, 2022 at 5:18 AM S.R Keshav wrote: > Hello, this is keshav. And I have changed my proposal for this project. > Kindly accept it. Hi, When you post updates, please reply to the email you sent previously, instead of sending a new one. That way, your messages will all be grouped

Re: Allow parallel plan for referential integrity checks?

On 3/19/22 01:57, Imseih (AWS), Sami wrote: I looked at your patch and it's a good idea to make foreign key validation use parallel query on large relations. It would be valuable to add logging to ensure that the ActiveSnapshot and TransactionSnapshot is the same for the leader and the

Re: Logical replication timeout problem

On Wed, Apr 13, 2022, at 7:45 AM, Amit Kapila wrote: > On Mon, Apr 11, 2022 at 12:09 PM wangw.f...@fujitsu.com > wrote: > > > > So I skip tracking lag during a transaction just like the current HEAD. > > Attach the new patch. > > > > Thanks, please find the updated patch where I have slightly

Re: Logical replication timeout problem

On Wed, Apr 13, 2022 at 7:45 PM Amit Kapila wrote: > > On Mon, Apr 11, 2022 at 12:09 PM wangw.f...@fujitsu.com > wrote: > > > > So I skip tracking lag during a transaction just like the current HEAD. > > Attach the new patch. > > > > Thanks, please find the updated patch where I have slightly

GSoC: New and improved website for pgjdbc (JDBC) (2022)

Hi Dave, My name is Alena, I am a 4th year Software Engineering student. I'd like to rebuild and improve the website for pgjdbc. I have experience in frontend (Vanilla JS and React) and backend (Express.js) web development and understanding on how Jekyll works. Before writing a proposal I

Re: Add --{no-,}bypassrls flags to createuser

> On 14 Apr 2022, at 09:42, Shinya Kato wrote: > To add the ROLE clause, the originally existing --role option (corresponding > to the IN ROLE clause) is changed to the --in-role option. Would this not be > good from a backward compatibility standpoint? - printf(_(" -g, --role=ROLE

RE: Skipping schema changes in publication

On Tue, Apr 12, 2022 at 2:23 PM vignesh C wrote: > The patch does not apply on top of HEAD because of the recent commit, > attached patch is rebased on top of HEAD. Thanks for your patches. Here are some comments for v1-0001: 1. I found the patch add the following two new functions in gram.y:

Re: Support logical replication of DDLs

On Fri, Apr 8, 2022 at 4:30 PM Amit Kapila wrote: > > On Tue, Mar 29, 2022 at 9:47 AM Dilip Kumar wrote: > > > > > > The idea is to force skipping any direct data population (which can > > > potentially cause data inconsistency on the subscriber) > > > in CREATE AS and SELECT INTO command on the

Re: A qsort template

On Thu, Apr 14, 2022 at 1:46 PM David Rowley wrote: > > On Wed, 13 Apr 2022 at 23:19, John Naylor > wrote: > > More broadly than the regression, Thomas' is very often the fastest of > > all, at the cost of more binary size. David's is occasionally slower > > than v15 or v15 with revert, but

RE: Skipping schema changes in publication

On Tue, Apr 12, 2022 2:23 PM vignesh C wrote: > > The patch does not apply on top of HEAD because of the recent commit, > attached patch is rebased on top of HEAD. > Thanks for your patch. Here are some comments for 0001 patch. 1. doc/src/sgml/catalogs.sgml @@ -6438,6 +6438,15 @@

Re: Handle infinite recursion in logical replication setup

Here are my review comments for v8-0001. == 1. Commit message CREATE SUBSCRIPTION sub1 CONNECTION 'dbname =postgres port=' PUBLICATION pub1 with (local_only = true); The spaces in the CONNECTION string are a bit strange. ~~~ 2. src/backend/catalog/pg_subscription. @@ -71,6 +71,7 @@

Re: Error logging messages

> On 14 Apr 2022, at 09:10, Michael Paquier wrote: > > On Wed, Apr 13, 2022 at 01:51:16PM +0200, Daniel Gustafsson wrote: >> 0001: Makes sure that database and file names are printed quoted. This patch >> has hunks in contrib and backend as well. >> >> 0002: Capitalizes pg_log_error_detail and

Re: Add --{no-,}bypassrls flags to createuser

On 2022-04-13 17:35, Kyotaro Horiguchi wrote: At Wed, 13 Apr 2022 16:10:01 +0900, Michael Paquier wrote in On Wed, Apr 13, 2022 at 03:46:25PM +0900, Kyotaro Horiguchi wrote: > It is sensible to rig createuser command with full capability of > CREATE ROLE is reasonable. > > Only --replication

Re: Error logging messages

On Wed, Apr 13, 2022 at 01:51:16PM +0200, Daniel Gustafsson wrote: > 0001: Makes sure that database and file names are printed quoted. This patch > has hunks in contrib and backend as well. > > 0002: Capitalizes pg_log_error_detail and conversely starts pg_log_error with > a > lowercase letter

Use outerPlanState macro instead of referring to leffttree

In the executor code, we mix use outerPlanState macro and referring to leffttree. Commit 40f42d2a tried to keep the code consistent by replacing referring to lefftree with outerPlanState macro, but there are still some outliers. This patch tries to clean them up. Thanks Richard

Re: A qsort template

On Wed, 13 Apr 2022 at 23:19, John Naylor wrote: > More broadly than the regression, Thomas' is very often the fastest of > all, at the cost of more binary size. David's is occasionally slower > than v15 or v15 with revert, but much of that is a slight difference > and some is probably noise.

Re: Improving the "Routine Vacuuming" docs

On Thu, Apr 14, 2022 at 5:03 AM David G. Johnston wrote: > I would be on board with having the language of the entire section written > with the assumption that autovacuum is enabled, with a single statement > upfront that this is the case. Most of the content remains as-is but we > remove a

Re: Assert in pageinspect with NULL pages

On Wed, Mar 16, 2022 at 05:43:48PM +0900, Michael Paquier wrote: > So, I have looked at this second part of the thread, and concluded > that we should not fail for empty pages. First, we fetch pages from > the buffer pool in normal mode, where empty pages are valid. There is > also a second