odd behaviour with serial, non null and partitioned table

Hi Alvaro, Problem 1 #create table tpart (a serial primary key, src varchar) partition by range(a); CREATE TABLE #create table t_p4 (a int primary key, src varchar); CREATE TABLE #\d tpart Partitioned table "public.tpart" Column | Type| Collation

Re: remaining sql/json patches

On 17.10.2023 07:02, Amit Langote wrote: One thing jian he missed during the debugging is that ExecEvalJsonExprCoersion() receives the EMPTY ARRAY value via *op->resvalue/resnull, set by ExecEvalJsonExprBehavior(), because that's the ON EMPTY behavior specified in the constraint. The bug was

Re: Synchronizing slots from primary to standby

FYI - the latest patch failed to apply. [postgres@CentOS7-x64 oss_postgres_misc]$ git apply ../patches_misc/v24-0001-Allow-logical-walsenders-to-wait-for-the-physica.patch error: patch failed: src/include/utils/guc_hooks.h:160 error: src/include/utils/guc_hooks.h: patch does not apply == Kind

Re: remaining sql/json patches

Hi Anton, On Tue, Oct 17, 2023 at 4:11 PM Anton A. Melnikov wrote: > On 17.10.2023 07:02, Amit Langote wrote: > > > One thing jian he missed during the debugging is that > > ExecEvalJsonExprCoersion() receives the EMPTY ARRAY value via > > *op->resvalue/resnull, set by ExecEvalJsonExprBehavior(),

serial and partitioned table

Hi All, #create table tpart (a serial primary key, src varchar) partition by range(a); CREATE TABLE #create table t_p4 (a int primary key, src varchar); CREATE TABLE To appease the gods of surprises I need to add a NOT NULL constraint. See [1]. #alter table t_p4 alter column a set not null; ALTER T

Re: Making aggregate deserialization (and WAL receive) functions slightly faster

On Mon, 16 Oct 2023 at 05:56, Tom Lane wrote: > * in initStringInfoFromString, str->maxlen must be set to len+1 not len > > * comment in exec_bind_message doesn't look like pgindent will like it > > * same in record_recv, plus it has a misspelling "Initalize" > > * in stringinfo.c, inclusion of pg

Re: pg_stat_statements and "IN" conditions

> On Fri, Oct 13, 2023 at 03:35:19PM +0200, Dmitry Dolgov wrote: > > On Fri, Oct 13, 2023 at 05:07:00PM +0900, Michael Paquier wrote: > > Now, it doesn't mean that this approach with the "powers" will never > > happen, but based on the set of opinions I am gathering on this thread > > I would sugge

Re: Asymmetric partition-wise JOIN

On 16/10/2023 23:21, Ashutosh Bapat wrote: On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov Whenever I visited this idea, I hit one issue prominently - how would we differentiate different scans of the non-partitioned relation. Normally we do that using different Relids but in this case we wouldn

Re: pgBufferUsage.blk_{read|write}_time are zero although there are pgBufferUsage.local_blks_{read|written}

On Mon, Oct 16, 2023 at 01:07:07PM +0300, Nazir Bilal Yavuz wrote: > Yes, that could be a better solution. Also, having more detailed stats > for shared and local buffers is helpful. I updated patches in line > with that: > > 0001: Counts extends same way as a write. It can change existing query

Re: Invalidate the subscription worker in cases where a user loses their superuser status

On Fri, Oct 13, 2023 at 11:08 AM Amit Kapila wrote: > > On Fri, Oct 13, 2023 at 10:04 AM vignesh C wrote: > > > > On Thu, 12 Oct 2023 at 11:10, Amit Kapila wrote: > > > > > > On Sun, Oct 8, 2023 at 8:22 AM vignesh C wrote: > > > > > > > > > > --- a/src/include/catalog/pg_subscription.h > > > ++

Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound

Hi, > > LGTM, except for one small detail: I noticed that you misspelled > > "translations" in the commit message. > > Oops. Fixed locally. v11-0001 and v11-0002 LGTM too. IMO "to assign a XID" sounds better than "to generate a XID". -- Best regards, Aleksander Alekseev

Re: PL/pgSQL: Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]

On 2023/10/17 12:15, Pavel Stehule wrote: út 17. 10. 2023 v 3:30 odesílatel Quan Zongliang > napsal: On 2023/10/16 20:05, Pavel Stehule wrote: > > > po 16. 10. 2023 v 13:56 odesílatel Daniel Gustafsson mailto:dan...@yesql.se> > <

Re: Asymmetric partition-wise JOIN

On Tue, Oct 17, 2023 at 2:05 PM Andrei Lepikhov wrote: > > On 16/10/2023 23:21, Ashutosh Bapat wrote: > > On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov > > Whenever I visited this idea, I hit one issue prominently - how would > > we differentiate different scans of the non-partitioned relation.

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 03:23, Peter Geoghegan wrote: > My main objection to the new policy is that it's not quite clear what > process I should go through in order to be 100% confident that koel > won't start whining (short of waiting around for koel to whine). I > know how to run pgindent, of cou

Re: wal recycling problem

Thanks for your feedback > How would you know which part of WAL is needed for any specific replication slot? change are captured for each published table and written twice, once in the current wal and once in the slot-specific wal > How would you handle multiple replications for the same table add

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 04:57, Michael Paquier wrote: > I see an extra reason with not doing that: this increases the > difficulty when it comes to send and maintain patches to the lists and > newcomers would need to learn more tooling. I don't think that we > should make that more complicated for

Re: remaining sql/json patches

On Mon, Oct 16, 2023 at 5:21 PM Nikita Malakhov wrote: > > Hi! > > With the latest set of patches we encountered failure with the following > query: > > postgres@postgres=# SELECT JSON_QUERY(jsonpath '"aaa"', '$' RETURNING text); > server closed the connection unexpectedly > This probably

RE: [PoC] pg_upgrade: allow to upgrade publisher node

Dear Amit, Thanks for reviewing! PSA new version. > > Yeah, I think introducing additional complexity unless it is really > required sounds a bit scary to me as well. BTW, please find attached > some cosmetic changes. Basically LGTM, but below part was conflicted with Bharath's comment [1]. ``

RE: [PoC] pg_upgrade: allow to upgrade publisher node

Dear Vignesh, Thank you for reviewing! New version can be available in [1]. > 1) Should this: > +# Copyright (c) 2023, PostgreSQL Global Development Group > + > +# Tests for upgrading replication slots > + > be: > "Tests for upgrading logical replication slots" Fixed. > 2) This statement is no

Re: Is this a problem in GenericXLogFinish()?

On Mon, Oct 16, 2023 at 7:31 PM Jeff Davis wrote: > Another option might be to just change the hash indexing code to follow > the correct protocol, locking and calling MarkBufferDirty() in those 3 > call sites. Marking the buffer dirty is easy, but making sure that it's > locked might require some

Re: run pgindent on a regular basis / scripted manner

On Sun, Oct 15, 2023 at 8:52 PM Peter Geoghegan wrote: > On Sat, Aug 12, 2023 at 5:53 PM Peter Geoghegan wrote: > > Maybe I'm wrong -- maybe the new policy is practicable. It might even > > turn out to be worth the bother. Time will tell. > > (Two months pass.) > > There were two independent fixu

Re: Fix output of zero privileges in psql

On Mon, 2023-10-16 at 19:05 -0700, David G. Johnston wrote: > Reading both threads I'm not seeing any specific rejection of the > solution that we simply represent empty privileges as "(none)". > > I see an apparent consensus that if we do continue to represent it > as NULL that the printout shoul

Re: odd behaviour with serial, non null and partitioned table

Hello, On 2023-Oct-17, Ashutosh Bapat wrote: > Problem 1 > > #create table tpart (a serial primary key, src varchar) partition by range(a); > CREATE TABLE > #create table t_p4 (a int primary key, src varchar); > CREATE TABLE > But tparts NOT NULL constraint is recorded in pg_constraint

Re: False "pg_serial": apparent wraparound” in logs

> So, I've spent more time on that and applied the simplification today, > doing as you have suggested to use the head page rather than the tail > page when the tail XID is ahead of the head XID, but without disabling > the whole. I've simplified a bit the code and the comments, though, > while on

Re: pgBufferUsage.blk_{read|write}_time are zero although there are pgBufferUsage.local_blks_{read|written}

Hi, Thanks for the review! On Tue, 17 Oct 2023 at 11:40, Michael Paquier wrote: > > On Mon, Oct 16, 2023 at 01:07:07PM +0300, Nazir Bilal Yavuz wrote: > > Yes, that could be a better solution. Also, having more detailed stats > > for shared and local buffers is helpful. I updated patches in line

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 6:34 AM Jelte Fennema wrote: > I think *it is* dead easy to comply. If you run the following commands > before committing/after rebasing, then koel should always be happy: > > src/tools/pgindent/pgindent src # works always but a bit slow > src/tools/pgindent/pgindent $(git

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 8:45 AM Robert Haas wrote: > > This policy isn't working. > > +1. I think this is more annoying than the status quo ante. Although ... I do think it's spared me some rebasing pain, and that does have some real value. I wonder if we could think of other alternatives. For ex

Re: run pgindent on a regular basis / scripted manner

Robert Haas writes: > On Tue, Oct 17, 2023 at 8:45 AM Robert Haas wrote: >> +1. I think this is more annoying than the status quo ante. > Although ... I do think it's spared me some rebasing pain, and that > does have some real value. I wonder if we could think of other > alternatives. An alter

Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound

On Tue, Oct 17, 2023 at 4:57 AM Aleksander Alekseev wrote: > v11-0001 and v11-0002 LGTM too. Cool. Seems we are all in agreement, so committed these. Thanks! -- Robert Haas EDB: http://www.enterprisedb.com

Re: Invalidate the subscription worker in cases where a user loses their superuser status

On Tue, 17 Oct 2023 at 14:17, Amit Kapila wrote: > > On Fri, Oct 13, 2023 at 11:08 AM Amit Kapila wrote: > > > > On Fri, Oct 13, 2023 at 10:04 AM vignesh C wrote: > > > > > > On Thu, 12 Oct 2023 at 11:10, Amit Kapila wrote: > > > > > > > > On Sun, Oct 8, 2023 at 8:22 AM vignesh C wrote: > > >

Force the old transactions logs cleanup even if checkpoint is skipped

Hi, hackers! I've stumbled into an interesting problem. Currently, if Postgres has nothing to write, it would skip the checkpoint creation defined by the checkpoint timeout setting. However, we might face a temporary archiving problem (for example, some network issues) that might lead to a pi

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 7:23 AM Tom Lane wrote: > Robert Haas writes: > > On Tue, Oct 17, 2023 at 8:45 AM Robert Haas wrote: > >> +1. I think this is more annoying than the status quo ante. > > > Although ... I do think it's spared me some rebasing pain, and that > > does have some real value. I

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 16:23, Tom Lane wrote: > > Or we could have a server-side hook that will refuse > > the misindented commit, with some kind of override for emergency > > situations. > > Even though I'm in the camp that would like the tree correctly > indented at all times, I remain very much

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 10:23 AM Tom Lane wrote: > An alternative I was thinking about after reading your earlier email > was going back to the status quo ante, but doing the manual tree-wide > reindents significantly more often than once a year. Adding one at > the conclusion of each commitfest

Re: Pre-proposal: unicode normalized text

Jeff Davis wrote: > I believe the patch has utility as-is, but I've been brainstorming a > few more ideas that could build on it: > > * Add a per-database option to enforce only storing assigned unicode > code points. There's a problem in the fact that the set of assigned code points is

Re: Pre-proposal: unicode normalized text

On Tue, Oct 17, 2023 at 11:07 AM Daniel Verite wrote: > There's a problem in the fact that the set of assigned code points is > expanding with every Unicode release, which happens about every year. > > If we had this option in Postgres 11 released in 2018 it would use > Unicode 11, and in 2023 thi

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 8:01 AM Robert Haas wrote: > In fact, that particular experience is one of the worst things about > being a committer. It actively discourages me, at least, from trying > to get other people's patches committed. This particular problem is > minor, but the overall experience

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 16:04, Robert Haas wrote: > What I really dislike about the current situation is that > it's doubling down on the idea that committers have to be perfect and > get everything right every time. Turns out, that's hard to do. If not, > why do people keep screwing things up? Som

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 11:16 AM Peter Geoghegan wrote: > Yep. Enforcing perfect indentation on koel necessitates rechecking > indentation after each and every last-minute fixup affecting C code -- > the interactions makes it quite a bit harder to get everything right > on the first push. For exam

Re: Add support for AT LOCAL

Michael Paquier writes: > On Tue, Oct 17, 2023 at 01:40:18AM -0400, Tom Lane wrote: >> makes the failure go away. Unfortunately, I've not yet found another >> way to make it go away :-(. My upthread idea of using a local variable >> instead of result->time is no help, and some other random code

Re: Synchronizing slots from primary to standby

Hi, On 10/13/23 10:35 AM, shveta malik wrote: On Thu, Oct 12, 2023 at 9:18 AM shveta malik wrote: PFA v24 patch set which has below changes: 1) 'enable_failover' displayed in pg_replication_slots. 2) Support for 'enable_failover' in pg_create_logical_replication_slot(). It is an optional a

Re: Pre-proposal: unicode normalized text

On Tue, 17 Oct 2023 at 11:15, Robert Haas wrote: > Are code points assigned from a gapless sequence? That is, is the > implementation of codepoint_is_assigned(char) just 'codepoint < > SOME_VALUE' and SOME_VALUE increases over time? > Not even close. Code points are organized in blocks, e.g. fo

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 11:23 AM Jelte Fennema wrote: > To clarify, I did not intend to imply people that commit unindented > code are lazy. It's expected that humans forget to run pgindent before > committing from time to time (I do too). That's why I proposed a > server side git hook to reject b

Re: Pre-proposal: unicode normalized text

On Tue, Oct 17, 2023 at 11:38 AM Isaac Morland wrote: > On Tue, 17 Oct 2023 at 11:15, Robert Haas wrote: >> Are code points assigned from a gapless sequence? That is, is the >> implementation of codepoint_is_assigned(char) just 'codepoint < >> SOME_VALUE' and SOME_VALUE increases over time? > > N

Re: stopgap fix for signal handling during restore_command

Committed and back-patched. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 8:24 AM Robert Haas wrote: > I also just discovered that my pre-commit hook doesn't work if I pull > commits into master by cherry-picking. I had thought that I could have > my hook just check my commits to master and not all of my local dev > branches where I really don't

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 17:47, Peter Geoghegan wrote: > Once you figure all that out, you're still obligated to hand-polish > typedefs.list to be consistent with whatever Bruce's machine's copy of > objdump does (or is it Tom's?). You need to sort the entries so they > kinda look like they originat

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 9:03 AM Jelte Fennema wrote: > To make koel pass you don't need to worry about hand-polishing > typedefs.list. koel uses the typedefs.list that's committed into the > repo, just like when you run pgindent yourself. If you forget to > update the typedefs.list with new types,

Re: run pgindent on a regular basis / scripted manner

Peter Geoghegan writes: > That's beside the point. The point is that I'm obligated to keep > typedef.list up to date in general, a task that is made significantly > harder by random objdump implementation details. And I probably need > to do this not just once per commit, but several times, since

Re: run pgindent on a regular basis / scripted manner

Robert Haas writes: > One potential problem with a server-side hook is that if you back-port > a commit to older branches and then push the commits all together > (which is my workflow) then you might get failure to push on some > branches but not others. I don't know if there's any way to avoid >

Re: Restoring default privileges on objects

On Fri, Oct 6, 2023 at 1:29 PM Laurenz Albe wrote: > On Fri, 2023-10-06 at 22:18 +0200, Laurenz Albe wrote: > > On Fri, 2023-10-06 at 22:16 +0200, Laurenz Albe wrote: > > > Here is a patch that does away with the special handling of NULL values > > > in psql backslash commands. > > > > Erm, I for

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 12:17 PM Tom Lane wrote: > Hmm, I've not found it that hard to manage the typedefs list. > If I run pgindent and it adds weird spacing around uses of a new > typedef name, I go "oh, I better add that to the list" and do so. > End of problem. There's not a requirement that

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 12:18 PM Tom Lane wrote: > Robert Haas writes: > > One potential problem with a server-side hook is that if you back-port > > a commit to older branches and then push the commits all together > > (which is my workflow) then you might get failure to push on some > > branche

Re: Pre-proposal: unicode normalized text

On Tue, 2023-10-17 at 17:07 +0200, Daniel Verite wrote: > There's a problem in the fact that the set of assigned code points is > expanding with every Unicode release, which happens about every year. > > If we had this option in Postgres 11 released in 2018 it would use > Unicode 11, and in 2023 t

Re: Fix output of zero privileges in psql

Laurenz Albe writes: > On Mon, 2023-10-16 at 19:05 -0700, David G. Johnston wrote: >> Reading both threads I'm not seeing any specific rejection of the >> solution that we simply represent empty privileges as "(none)". > Thanks for that summary. I prefer my version (simply display NULLs > as NUL

Re: Is this a problem in GenericXLogFinish()?

On Tue, 2023-10-17 at 08:41 -0400, Robert Haas wrote: > Sorry, I'm not sure I understand the question. Are you asking whether > dirtying buffers unnecessarily might be slower than not doing that? I meant: are those cleanup operations frequent enough that dirtying those buffers in that case would m

Re: Fix a wrong comment in setrefs.c

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested That looks correct for me The new status of this patch is: Ready for Committ

Re: stopgap fix for signal handling during restore_command

On Tue, Oct 17, 2023 at 10:46:47AM -0500, Nathan Bossart wrote: > Committed and back-patched. ... and it looks like some of the back-branches are failing for Windows. I'm assuming this is because c290e79 was only back-patched to v15. My first instinct is just to back-patch that one all the way to

Re: Add support for AT LOCAL

I wrote: > Yeah, the same thing occurred to me in the shower this morning, and it > does seem to work! We can replace both loops with a %= operator, at > least if we're willing to assume C99 division semantics, which seems > pretty safe in 2023. Whoops, no: for negative starting values we'd need

Re: New WAL record to detect the checkpoint redo location

On Fri, Oct 13, 2023 at 3:29 AM Michael Paquier wrote: > Now looking at 0002, where you should be careful about the code > indentation or koel will complain. Fixed in the attached version. > This makes the new code call LocalSetXLogInsertAllowed() and what we > set for checkPoint.PrevTimeLineID

Re: stopgap fix for signal handling during restore_command

Nathan Bossart writes: > ... and it looks like some of the back-branches are failing for Windows. > I'm assuming this is because c290e79 was only back-patched to v15. My > first instinct is just to back-patch that one all the way to v11, but maybe > there's an alternative involving #ifdef WIN32.

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023, 09:22 Robert Haas wrote: > On Tue, Oct 17, 2023 at 12:18 PM Tom Lane wrote: > > Robert Haas writes: > > Is that actually possible? I had the idea that "git push" is an > > atomic operation, ie 100% or nothing. Is it only atomic per-branch? > > I believe so. Git push do

Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"

On Mon, Oct 16, 2023 at 6:48 PM Thomas Munro wrote: > I pushed the retry-loop-in-frontend-executables patch and the > missing-locking-in-SQL-functions patch yesterday. That leaves the > backup ones, which I've rebased and attached, no change. It sounds > like we need some more healthy debate abo

Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE

On Mon, Oct 16, 2023 at 12:31 PM Michael Christofides wrote: > According to the docs[1]: "In a parallel bitmap heap scan, one process is > chosen as the leader. That process performs a scan of one or more indexes and > builds a bitmap indicating which table blocks need to be visited. These > bl

Re: PL/pgSQL: Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]

Hi > Isn't this code a little ugly? > > > > > I propose syntax xxx.yyy%ELEMENTTYPE and xxx%ELEMENTTYPE > > > > What do you think about it? > No other relational database can be found with such an implementation. > But it seems like a good idea. It can bring more convenience to write > stored proc

Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"

On Tue, Oct 17, 2023 at 10:50 AM Robert Haas wrote: > Life would be a lot easier here if we could get rid of the low-level > backup API and just have pg_basebackup DTWT, but that seems like a > completely non-viable proposal. > Yeah, my contribution to this area [1] is focusing on the API becaus

Re: Improving Physical Backup/Restore within the Low Level API

On Mon, Oct 16, 2023 at 5:21 PM David G. Johnston wrote: > But no, by default, and probably so far as pg_basebackup is concerned, a > server crash during backup results in requiring outside intervention in order > to get the server to restart. Others may differ, but I think such a proposal is d

Re: Track Oldest Initialized WAL Buffer Page

On Mon, Jul 3, 2023 at 6:57 PM Heikki Linnakangas wrote: > Thanks a lot for responding. Sorry for being late. > On 07/02/2023 16:00, Bharath Rupireddy wrote: > > Hi, > > > > While working on [1], I was looking for a quick way to tell if a WAL > > record is present in the WAL buffers array withou

Re: The danger of deleting backup_label

Greetings, * David Steele (da...@pgmasters.net) wrote: > On 10/16/23 15:06, Robert Haas wrote: > > On Mon, Oct 16, 2023 at 1:00 PM David Steele wrote: > > > After some agonizing (we hope) they decide to delete backup_label and, > > > wow, it just works! So now they merrily go on their way with a

Re: Improving Physical Backup/Restore within the Low Level API

On 10/17/23 14:28, Robert Haas wrote: On Mon, Oct 16, 2023 at 5:21 PM David G. Johnston wrote: But no, by default, and probably so far as pg_basebackup is concerned, a server crash during backup results in requiring outside intervention in order to get the server to restart. Others may diff

Re: Improve WALRead() to suck data directly from WAL buffers when possible

On Thu, Oct 12, 2023 at 4:13 AM Andres Freund wrote: > > On 2023-10-03 16:05:32 -0700, Jeff Davis wrote: > > > > Does this patch still look like a good fit for your (or someone else's) > > plans for direct IO here? If so, would committing this soon make it > > easier to make progress on that, or s

Re: Improving Physical Backup/Restore within the Low Level API

On Tue, Oct 17, 2023 at 12:30 PM David Steele wrote: > On 10/17/23 14:28, Robert Haas wrote: > > On Mon, Oct 16, 2023 at 5:21 PM David G. Johnston > > wrote: > >> But no, by default, and probably so far as pg_basebackup is concerned, > a server crash during backup results in requiring outside in

Re: The danger of deleting backup_label

On Tue, Oct 17, 2023 at 3:17 PM Stephen Frost wrote: > I'd also put out there that while people don't do restore testing > nearly as much as they should, they tend to at _least_ try to do it once > after taking their first backup and if that fails then they try to figure > out why and what they're

Re: pg_dump needs SELECT privileges on irrelevant extension table

Jacob Champion writes: > v3 fixes a doc comment I forgot to fill in; there are no other code > changes. To try to further reduce the activation energy, I've also > attached an attempt at a backport to 11. The main difference is the > absence of catalogIdHash, which showed up in 15, so we don't get

Re: The danger of deleting backup_label

On 10/14/23 11:30, David Steele wrote: On 10/12/23 10:19, David Steele wrote: On 10/11/23 18:10, Thomas Munro wrote: As Stephen mentioned[1], we could perhaps also complain if both backup label and control file exist, and then hint that the user should remove the *control file* (not the backup

Re: [PoC/RFC] Multiple passwords, interval expirations

Greetings, * Nathan Bossart (nathandboss...@gmail.com) wrote: > On Wed, Oct 04, 2023 at 10:41:15PM -0700, Gurjeet Singh wrote: > > The patches posted in this thread so far attempt to add the ability to > > allow the user to have an arbitrary number of passwords. I believe > > that allowing arbitra

Re: BRIN minmax multi - incorrect distance for infinite timestamp/date

Hi, Here's a couple cleaned-up patches fixing the various discussed here. I've tried to always add a regression test demonstrating the issue first, and then fix it in the next patch. In particular, this deals with these issues: 1) overflows in distance calculation for large timestamp values (000

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 18:53, Maciek Sakrejda wrote: > Git push does have an --atomic flag to treat the entire push as a single > operation. I decided to play around a bit with server hooks. Attached is a git "update" hook that rejects pushes to the master branch when the new HEAD of master does

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 10:43 PM Jelte Fennema wrote: > > On Tue, 17 Oct 2023 at 18:53, Maciek Sakrejda wrote: > > Git push does have an --atomic flag to treat the entire push as a single > > operation. > > I decided to play around a bit with server hooks. Attached is a git > "update" hook that

Re: run pgindent on a regular basis / scripted manner

Magnus Hagander writes: > If it doesn't know how to rebuild it, aren't we going to be stuck in a > catch-22 if we need to change it in certain ways? Since an old version > of pg_bsd_indent would reject the patch that might include updating > it. (And when it does, one should expect the push to tak

Re: pg_dump needs SELECT privileges on irrelevant extension table

I wrote: > Why are we marking extension member objects as being subject to SECLABEL > or POLICY dumping? As the comment notes, that isn't really sensible > unless what we are dumping is a delta from the extension's initial > assignments. But we have no infrastructure for that, and none seems > li

Re: stopgap fix for signal handling during restore_command

On Tue, Oct 17, 2023 at 12:47:29PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> ... and it looks like some of the back-branches are failing for Windows. >> I'm assuming this is because c290e79 was only back-patched to v15. My >> first instinct is just to back-patch that one all the way to v

Re: Add support for AT LOCAL

Hmm, I guess I must have missed some important flag or environment variable when trying to reproduce it, sorry. Given that IBM describes xlc as "legacy" (replaced by xlclang, but still supported for some unspecified period of time for the benefit of people who need C++ ABI compatibility with old c

Re: Add support for AT LOCAL

Thomas Munro writes: > Given that IBM describes xlc as "legacy" (replaced by xlclang, but > still supported for some unspecified period of time for the benefit of > people who need C++ ABI compatibility with old code), I wonder how > long we plan to support it... Should we be testing against xlc

Re: Add support for AT LOCAL

On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote: > Thomas Munro writes: > > > Given that IBM describes xlc as "legacy" (replaced by xlclang, but > > still supported for some unspecified period of time for the benefit of > > people who need C++ ABI compatibility with old code), I wonder how > > lo

Re: Add support for AT LOCAL

Thomas Munro writes: > On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote: >> Should we be testing against xlclang instead? > I hesitated to suggest it because it's not my animal/time we're > talking about but it seems to make more sense. It appears to be IBM's > answer to the nothing-builds-with-

Re: [PoC/RFC] Multiple passwords, interval expirations

On Tue, 2023-10-17 at 16:20 -0400, Stephen Frost wrote: > Agreed that it's a bad idea to design to support 2 and only 2. I don't disagree, but it's difficult to come up with syntax that: (a) supports N passwords (b) makes the ordinary cases simple and documentable (c) helps users avoid mistake

Re: Add support for AT LOCAL

On Tue, Oct 17, 2023 at 12:45:28PM -0400, Tom Lane wrote: > Whoops, no: for negative starting values we'd need truncate-towards- > minus-infinity division whereas C99 specifies truncate-towards-zero. > However, the attached does pass for me on cfarm111 as well as my > usual dev machine. I guess th

Re: New WAL record to detect the checkpoint redo location

On Tue, Oct 17, 2023 at 12:45:52PM -0400, Robert Haas wrote: > On Fri, Oct 13, 2023 at 3:29 AM Michael Paquier wrote: >> I've mentioned as well a test in pg_walinspect after one of the >> checkpoints generated there, but what you do here is enough for the >> online case. > > I don't quite underst

Re: [PoC] pg_upgrade: allow to upgrade publisher node

Here are some review comments for v51-0001 == src/bin/pg_upgrade/check.c 0. +check_old_cluster_for_valid_slots(bool live_check) +{ + char output_path[MAXPGPATH]; + FILE*script = NULL; + + prep_status("Checking for valid logical replication slots"); + + snprintf(output_path, sizeof(output_

Re: The danger of deleting backup_label

At Tue, 17 Oct 2023 16:16:42 -0400, David Steele wrote in > Given that the above can't be back patched, I'm thinking we don't need > backup_label at all going forward. We just write the values we need > for recovery into pg_control and return *that* from pg_backup_stop() > and tell the user to st

Re: remaining sql/json patches

Hi. based on v22. I added some tests again json_value for the sake of coverager test. A previous email thread mentioned needing to check *empty in ExecEvalJsonExpr. since JSON_VALUE_OP, JSON_QUERY_OP, JSON_EXISTS_OP all need to have *empty cases, So I refactored a little bit. might be helpful. Ma

A trouble about meson on Windows

Hello. I've been unable to build PostgreSQL using Meson on Windows. As I'm unsure of the cause, I'm providing this as a report. In brief, the ninja command fails with the following error message on my Windows environment. >ninja -v ninja: error: 'src/backend/postgres_lib.a.p/meson_pch-c.obj', ne

Re: [PoC/RFC] Multiple passwords, interval expirations

Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > On Tue, 2023-10-17 at 16:20 -0400, Stephen Frost wrote: > > Agreed that it's a bad idea to design to support 2 and only 2. > > I don't disagree, but it's difficult to come up with syntax that: > > (a) supports N passwords > (b) makes the ord

Remove wal_level settings for subscribers in tap tests

Dear hackers, While discussing [1], I found that in tap tests, wal_level was set to logical for subscribers too. The setting is not needed for subscriber side, and it may cause misunderstanding for newcomers. Therefore, I wanted to propose the patch which removes unnecessary "allows_streaming =>

Re: Add support for AT LOCAL

Thomas Munro writes: > On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote: >> Should we be testing against xlclang instead? > I hesitated to suggest it because it's not my animal/time we're > talking about but it seems to make more sense. It appears to be IBM's > answer to the nothing-builds-with-

Re: [PoC] pg_upgrade: allow to upgrade publisher node

On Wed, Oct 18, 2023 at 7:31 AM Peter Smith wrote: > > == > src/bin/pg_upgrade/check.c > > 0. > +check_old_cluster_for_valid_slots(bool live_check) > +{ > + char output_path[MAXPGPATH]; > + FILE*script = NULL; > + > + prep_status("Checking for valid logical replication slots"); > + > + snp

Re: Some performance degradation in REL_16 vs REL_15

I wrote a script and test on branch REL_[10-16]_STABLE, and do see performance drop in REL_13_STABLE, which is about 1~2%. scale round 10 11 12 13 14 15 16 1 1 7922.2 8018.3 8102.8 7838.3 7829.2 7870.0 7846.1 2 7922.4 7923.5 8090

Re: pg_logical_emit_message() misses a XLogFlush()

On Tue, Oct 17, 2023 at 11:57:33AM +0530, Amit Kapila wrote: > LGTM. Thanks, I've applied that, then. -- Michael signature.asc Description: PGP signature

Re: Some performance degradation in REL_16 vs REL_15

Hi, On 2023-10-16 11:04:25 +0300, Anton A. Melnikov wrote: > On 13.10.2023 05:05, Andres Freund wrote: > > Could you provide a bit more details about how you ran the benchmark? The > > reason I am asking is that ~330 TPS is pretty slow for -c20. Even on > > spinning > > rust and using the defau

  1   2   >