Re: Allow non-superuser to cancel superuser tasks.

2024-06-20 Thread Andrey M. Borodin
> On 21 Jun 2024, at 09:01, Michael Paquier wrote: > > On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote: >> I’ve tried to dig into the test. >> The problem is CV is allocated in >> >> inj_state = GetNamedDSMSegment("injection_points”, >> >> which seems to be destroyed in >>

Re: Allow non-superuser to cancel superuser tasks.

2024-06-20 Thread Michael Paquier
On Fri, Jun 14, 2024 at 03:12:50PM -0500, Nathan Bossart wrote: > On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote: > > This patch looks good to me. > > Thanks for looking. While double-checking the whole, where I don't have much to say about 0001, I have fixed a few issues with

Re: Allow non-superuser to cancel superuser tasks.

2024-06-20 Thread Michael Paquier
On Fri, Jun 21, 2024 at 10:31:30AM +0500, Andrey M. Borodin wrote: > Thanks for the pointer, I’ll try this approach! Thanks. FWIW, I've put my mind into it, and fixed the thing a few minutes ago: https://www.postgresql.org/message-id/ZnURUaujl39wSoEW%40paquier.xyz -- Michael signature.asc Descr

Re: ON ERROR in json_query and the like

2024-06-20 Thread David G. Johnston
On Thursday, June 20, 2024, Markus Winand wrote: > > > > On 21.06.2024, at 06:46, David G. Johnston > wrote: > >> > > > > > 2 also has the benefit of being standard conforming while 1 does not. > > Why do you think so? Do you have any references or is this just based on > previous statements in

Re: jsonapi type fixups

2024-06-20 Thread Peter Eisentraut
On 20.06.24 14:05, Andrew Dunstan wrote: On 2024-06-18 Tu 7:48 AM, Peter Eisentraut wrote: I have this patch series that fixes up the types of the new incremental JSON API a bit.  Specifically, it uses "const" throughout so that the top-level entry points such as pg_parse_json_incremental() ca

Re: 001_rep_changes.pl fails due to publisher stuck on shutdown

2024-06-20 Thread Amit Kapila
On Wed, Jun 19, 2024 at 10:44 AM Hayato Kuroda (Fujitsu) wrote: > > Dear Horiguchi-san, > > Thanks for sharing the patch! I agree this approach (ensure WAL records are > flushed) > Is more proper than others. > > I have an unclear point. According to the comment atop GetInsertRecPtr(), it > just

Re: Remove distprep

2024-06-20 Thread Peter Eisentraut
On 20.06.24 16:34, Noah Misch wrote: On Thu, Jun 20, 2024 at 09:29:45AM +0200, Peter Eisentraut wrote: On 16.06.24 21:34, Noah Misch wrote: On Thu, Oct 05, 2023 at 05:46:46PM +0200, Peter Eisentraut wrote: --- a/src/backend/Makefile +++ b/src/backend/Makefile $(top_builddir)/src/include/

Re: DOCS: Generated table columns are skipped by logical replication

2024-06-20 Thread Amit Kapila
On Thu, Jun 20, 2024 at 6:36 AM Peter Smith wrote: > > Hi Amit. > > I modified the patch text slightly according to Peter E's suggestion [1]. > > I also tested the above examples against all older PostgreSQL versions > 12,13,14,15,16,17. The logical replication behaviour of skipping > generated co

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

2024-06-20 Thread Michael Paquier
On Mon, Jun 17, 2024 at 07:00:51PM +0200, Michail Nikolaev wrote: > The simplest possible fix is to use ShareLock > instead ShareUpdateExclusiveLock in the index_concurrently_swap > > oldClassRel = relation_open(oldIndexId, ShareLock); > newClassRel = relation_open(newIndex

<    1   2