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

On Mon, Oct 16, 2023 at 04:58:31PM +0900, Michael Paquier wrote: > On Sat, Oct 14, 2023 at 07:29:54PM +, Imseih (AWS), Sami wrote: >> After looking at this a bit more, I don't think the previous rev is correct. >> We should not fall through to the " The SLRU is no longer needed." Which >> also

Re: Add support for AT LOCAL

Noah Misch writes: > On Mon, Oct 16, 2023 at 01:54:23AM -0400, Tom Lane wrote: >> Ugh. So if the failure is robust enough to persist across >> several major xlc versions, why couldn't Thomas reproduce it? > Beats me. hornet wipes its starting environment down to OBJECT_MODE=32_64 >

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

ú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 > > napsal: > > > > > On 16 Oct 2023, at 12:15, Quan Zongliang >

Re: remaining sql/json patches

On Mon, Oct 16, 2023 at 10:44 PM Anton A. Melnikov wrote: > On 16.10.2023 15:49, jian he wrote: > > add the following code after ExecEvalJsonExprCoercion if > > (!InputFunctionCallSafe(...) works, but seems like a hack. > > > > if (!val_string) > > { > > *op->resnull = true; > > *op->resvalue =

Re: UniqueKey v2

jian he writes: Hi jian, > hi. > After `git am`, I still cannot build. > > ../../Desktop/pg_sources/main/postgres/src/backend/optimizer/path/uniquekey.c:125:45: > error: variable ‘var’ set but not used > [-Werror=unused-but-set-variable] > 125 | Var

Re: broken master regress tests

On Tue, 2023-10-10 at 17:54 -0700, Andres Freund wrote: > Yea. I wonder if the better fix would have been to copy > setenv("LC_MESSAGES", "C", 1); > to the initdb template creation. That afaict also fixes the issue, > with a > smaller blast radius? Sounds good to me. Is there anything else we

Re: run pgindent on a regular basis / scripted manner

On Mon, Oct 16, 2023 at 08:45:00PM -0400, Tom Lane wrote: > 2. We could raise awareness of this issue by adding indent verification > to CI testing. I hesitate to suggest that, though, for a couple of > reasons: >2a. It seems fairly expensive, though I might be misjudging. >2b. It's often

Re: Patch: Improve Boolean Predicate JSON Path Docs

On Oct 16, 2023, at 18:07, Erik Wienhold wrote: >> Okay, added, let’s just put all our cards on the table. :-) > > I'll have a look but the attached v3 is not a patch but some applefile. Weird, should be no different from previous attachments. I believe Apple Mail always uses

Re: CREATE DATABASE with filesystem cloning

On Sat, Oct 7, 2023, at 1:51 AM, Thomas Munro wrote: > I tested on bleeding edge FreeBSD/ZFS, where you need to set sysctl > vfs.zfs.bclone_enabled=1 to enable the optimisation, as it's still a > very new feature that is still being rolled out. The system call > succeeds either way, but that

Re: Add support for AT LOCAL

Michael Paquier writes: > On Mon, Oct 16, 2023 at 09:54:41AM -0400, Tom Lane wrote: >> I'm mighty tempted though to (a) add coverage for timetz_izone >> to HEAD, and (b) backpatch the new tests, sans the AT LOCAL case, >> to the back branches (maybe not v11). > I see that you've already done (a)

Re: Fix output of zero privileges in psql

On Mon, Oct 16, 2023 at 6:19 PM Laurenz Albe wrote: > On Mon, 2023-10-16 at 23:51 +0200, Erik Wienhold wrote: > > What's the process for the CommitFest now since we settled on your > > patch? This is my first time being involved in this, so still learning. > > I'see that you've withdrawn your

Re: run pgindent on a regular basis / scripted manner

On Mon, Oct 16, 2023 at 6:32 PM Tom Lane wrote: > But it's *not* a hard rule --- we explicitly rejected mechanisms > that would make it so (such as a precommit hook). I view "koel > is unhappy" as something that you ought to clean up, but if you > don't get to it for a day or three there's not

Re: Move bki file pre-processing from initdb to bootstrap

> The version comparison has been moved from initdb to bootstrap. This > created some compatibility problems with windows tests. For now I kept > the version check to not have \n added, which worked fine and serves > the purpose. However hoping to have something better in v3 in addition > to

Re: run pgindent on a regular basis / scripted manner

Peter Geoghegan writes: > 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 course, and haven't had any

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

On 2023/10/16 20:05, Pavel Stehule wrote: po 16. 10. 2023 v 13:56 odesílatel Daniel Gustafsson > napsal: > On 16 Oct 2023, at 12:15, Quan Zongliang mailto:quanzongli...@yeah.net>> wrote: > Implement TODO item: > PL/pgSQL > Incomplete item Allow

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

Error messages still seem ambiguous. do not support multi-dimensional arrays in PL/pgSQL Isn't that better? do not support multi-dimensional %TYPE arrays in PL/pgSQL On 2023/10/17 09:19, Quan Zongliang wrote: Attached new patch   More explicit error messages based on type. On

Re: run pgindent on a regular basis / scripted manner

On Mon, Oct 16, 2023 at 5:45 PM Tom Lane wrote: > Two thoughts about that: > > 1. We should not commit indent fixups on behalf of somebody else's > misindented commit. Peer pressure on committers who aren't being > careful about this is the only way to improve matters; so complain > to the

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

Attached new patch More explicit error messages based on type. On 2023/10/16 18:15, Quan Zongliang wrote: Implement TODO item: PL/pgSQL Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[] As a first step, deal only with [], such as xxx.yyy%TYPE[] xxx%TYPE[] It can be

Re: Fix output of zero privileges in psql

On Mon, 2023-10-16 at 23:51 +0200, Erik Wienhold wrote: > What's the process for the CommitFest now since we settled on your > patch?  This is my first time being involved in this, so still learning. > I'see that you've withdrawn your initial patch [1] but this thread is > still attached to my

Re: run pgindent on a regular basis / scripted manner

Peter Geoghegan writes: > There were two independent fixup commits to address complaints from > koel just today (from two different committers). Plus there was a > third issue (involving a third committer) this past Wednesday. > This policy isn't working. Two thoughts about that: 1. We should

Allow ALTER SYSTEM SET on unrecognized custom GUCs

Currently we have this odd behavior (for a superuser): regression=# ALTER SYSTEM SET foo.bar TO 'baz'; ERROR: unrecognized configuration parameter "foo.bar" regression=# SET foo.bar TO 'baz'; SET regression=# ALTER SYSTEM SET foo.bar TO 'baz'; ALTER SYSTEM That is, you can't ALTER SYSTEM SET a

Re: The danger of deleting backup_label

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 corrupted cluster. They also remember for the next time that deleting

Re: The danger of deleting backup_label

On Mon, Oct 16, 2023 at 12:25:59PM -0400, Robert Haas wrote: > On Mon, Oct 16, 2023 at 11:45 AM David Steele wrote: > > If you start from the last checkpoint (which is what will generally be > > stored in pg_control) then the effect is pretty similar. > > If the backup didn't span a checkpoint,

Re: Is this a problem in GenericXLogFinish()?

On Wed, 2023-10-11 at 14:53 +0300, Heikki Linnakangas wrote: > > The comment suggests that you don't need to hold an exclusive lock > when > you call this, but there's an assertion that you do. Reworded. > Is it a new requirement that you must hold an exclusive lock on the > buffer when you

Re: Add support for AT LOCAL

On Mon, Oct 16, 2023 at 09:54:41AM -0400, Tom Lane wrote: > I'm mighty tempted though to (a) add coverage for timetz_izone > to HEAD, and (b) backpatch the new tests, sans the AT LOCAL case, > to the back branches (maybe not v11). I see that you've already done (a) with 2f04720307. I'd be

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

On Mon, Oct 16, 2023 at 05:48:43PM +0200, Laurenz Albe wrote: > I don't have strong feelings either way. If you have backup_label > but no signal file, starting PostgreSQL may succeed (if the WAL > with the checkpoint happens to be in pg_wal) or it may fail with > an error message. There is no

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

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 about that backup label idea that would mean we don't need

Re: Postgres Architecture

Timothy Nelson writes: > Great! I'm not surprised it's been around a long time -- I didn't think I > could be the only one to think of it. > Thanks for the heads-up on Postgres-XL -- I'd missed that one somehow. FWIW, we also have some in-core history with passing plans around, for

Re: Patch: Improve Boolean Predicate JSON Path Docs

On 2023-10-16 21:59 +0200, David E. Wheeler write: > On Oct 15, 2023, at 23:03, Erik Wienhold wrote: > > > Your call but I'm not against including it in this patch because it > > already touches the modes section. > > Okay, added, let’s just put all our cards on the table. :-) I'll have a look

Re: Fix output of zero privileges in psql

On 2023-10-16 17:56 +0200, Laurenz Albe write: > David, how do you feel about this? I am wondering whether to set this patch > "ready for committer" or not. > > There is Tom wondering upthread whether changing psql's behavior like that > is too much of a compatibility break or not, but I guess

Re: Postgres Architecture

Great! I'm not surprised it's been around a long time -- I didn't think I could be the only one to think of it. Thanks for the heads-up on Postgres-XL -- I'd missed that one somehow. I'm going to include the words "architecture" and "replication" so that people searching the archives in the

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

On Mon, Oct 16, 2023 at 12:36 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Mon, Oct 16, 2023 at 12:09 PM Laurenz Albe > wrote: > >> I think it won't meet with favor if there are cases that require manual >> intervention >> for starting the server. That was the main argument

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

On Mon, Oct 16, 2023 at 3:46 PM Peter Geoghegan wrote: > On Mon, Oct 16, 2023 at 11:06 AM Robert Haas wrote: > > I propose to commit these changes only to master. I have included a > > fairly long paragraph about that in the commit message for 0002. > > LGTM, except for one small detail: I

Re: Patch: Improve Boolean Predicate JSON Path Docs

On Oct 15, 2023, at 23:03, Erik Wienhold wrote: > Your call but I'm not against including it in this patch because it > already touches the modes section. Okay, added, let’s just put all our cards on the table. :-) >> Agreed. Would be good if we could teach these functions and operators >> to

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

On Mon, Oct 16, 2023 at 11:06 AM Robert Haas wrote: > I propose to commit these changes only to master. I have included a > fairly long paragraph about that in the commit message for 0002. LGTM, except for one small detail: I noticed that you misspelled "translations" in the commit message.

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

On Mon, Oct 16, 2023 at 12:09 PM Laurenz Albe wrote: > I think it won't meet with favor if there are cases that require manual > intervention > for starting the server. That was the main argument for getting rid of > the exclusive > backup API, which had a similar problem. > In the rare case

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

On Mon, 2023-10-16 at 11:18 -0700, David G. Johnston wrote: > > I see a couple of problems and/or things that need clarification with that > > idea: > > > > - Two backups can run concurrently.  How do you reconcile that with the "in > > backup" > >   flag and crash.signal? > > - I guess

Re: The danger of deleting backup_label

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 corrupted > cluster. They also remember for the next time that deleting backup_label > is definitely a good

Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression

On Fri, Oct 6, 2023 at 9:14 AM Peter Eisentraut wrote: > > Should we treat it the same fashion as ALTER COLUMN ... TYPE which > > rewrites the column values? Of course that rewrites the whole table, > > but logically they are comparable. > > I don't know. What are the semantics of that command

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

On Mon, Oct 16, 2023 at 10:26 AM Laurenz Albe wrote: > On Mon, 2023-10-16 at 09:26 -0700, David G. Johnston wrote: > > This email is a first pass at a user-visible design for how our backup > and restore > > process, as enabled by the Low Level API, can be modified to make it > more

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

On Fri, Oct 13, 2023 at 5:03 AM Aleksander Alekseev wrote: > > Thanks for working on this. I will be relieved once this is finally > > taken care of. > > +1, and many thanks for your attention to the patchset and all the details! Cool. I committed that and back-patched to v14, and here's the

Re: Rename backup_label to recovery_control

On Mon, 2023-10-16 at 12:12 -0400, Robert Haas wrote: > On Mon, Oct 16, 2023 at 12:06 PM Michael Banck wrote: > > Not sure what to do about this, but as people/companies start moving to > > 15, I am afraid we will get people complaining about this. I think > > having exclusive mode still be the

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

On Mon, 2023-10-16 at 09:26 -0700, David G. Johnston wrote: > This email is a first pass at a user-visible design for how our backup and > restore > process, as enabled by the Low Level API, can be modified to make it more > mistake-proof. > In short, it requires pg_start_backup to further

Re: Rename backup_label to recovery_control

On 10/16/23 12:12, Robert Haas wrote: On Mon, Oct 16, 2023 at 12:06 PM Michael Banck wrote: Not sure what to do about this, but as people/companies start moving to 15, I am afraid we will get people complaining about this. I think having exclusive mode still be the default for

Re: Rename backup_label to recovery_control

On 10/16/23 12:06, Michael Banck wrote: On Mon, Oct 16, 2023 at 11:15:53AM -0400, David Steele wrote: On 10/16/23 10:19, Robert Haas wrote: We got rid of exclusive backup mode. We replaced pg_start_backup with pg_backup_start. I do think this was an improvement. For example it allows us

Re: The danger of deleting backup_label

On 10/16/23 12:25, Robert Haas wrote: On Mon, Oct 16, 2023 at 11:45 AM David Steele wrote: Hmmm, the reason to back patch this is that it would fix [1], which sure looks like a problem to me even if it is not a "bug". We can certainly require backup software to retry pg_control until the

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

> EXPLAIN ANALYZE for parallel Bitmap Heap Scans currently only reports > the number of heap blocks processed by the leader. It's missing the > per-worker stats. Hi David, According to the docs[1]: "In a parallel bitmap heap scan, one process is chosen as the leader. That process performs a

Improving Physical Backup/Restore within the Low Level API

Hi! This email is a first pass at a user-visible design for how our backup and restore process, as enabled by the Low Level API, can be modified to make it more mistake-proof. In short, it requires pg_start_backup to further expand upon what it means for the system to be in the midst of a

Re: The danger of deleting backup_label

On Mon, Oct 16, 2023 at 11:45 AM David Steele wrote: > Hmmm, the reason to back patch this is that it would fix [1], which sure > looks like a problem to me even if it is not a "bug". We can certainly > require backup software to retry pg_control until the checksum is valid > but that seems like

Re: Asymmetric partition-wise JOIN

On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov wrote: > > > > > Great! I'm looking forward to the revised patch > Before preparing a new patch, it would be better to find the common > ground in the next issue: > So far, this optimization stays aside, proposing an alternative path for > a join

Re: Rename backup_label to recovery_control

On Mon, Oct 16, 2023 at 12:06 PM Michael Banck wrote: > Not sure what to do about this, but as people/companies start moving to > 15, I am afraid we will get people complaining about this. I think > having exclusive mode still be the default for pg_start_backup() (albeit > deprecated) in one

Re: Rename backup_label to recovery_control

On Mon, Oct 16, 2023 at 11:15:53AM -0400, David Steele wrote: > On 10/16/23 10:19, Robert Haas wrote: > > We got rid of exclusive backup mode. We replaced pg_start_backup > > with pg_backup_start. > > I do think this was an improvement. For example it allows us to do > [1], which I believe is a

Re: Fix output of zero privileges in psql

On Sat, 2023-10-14 at 02:45 +0200, Erik Wienhold wrote: > On 2023-10-09 09:54 +0200, Laurenz Albe write: > > > > I tinkered a bit with your documentation.  For example, the suggestion to > > "\pset null" seemed to be in an inappropriate place.  Tell me what you > > think. > > +1  You're right

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

On Mon, 2023-10-16 at 14:54 +0900, Michael Paquier wrote: > Thanks for the review.  Yes, I am wondering if other people would > chime in here.  It doesn't feel like this has gathered enough > opinions. I don't have strong feelings either way. If you have backup_label but no signal file, starting

Re: The danger of deleting backup_label

On 10/16/23 10:55, Robert Haas wrote: On Sat, Oct 14, 2023 at 11:33 AM David Steele wrote: All of this is fixable in HEAD, but seems incredibly dangerous to back patch. Even so, I have attached the patch in case somebody sees an opportunity that I do not. I really do not think we should be

event trigger sgml touch-up

Some small (grammatical) changes in event-trigger.sgml (also one delete of 'community-we' (which I think is just confusing for the not-postgresql-community reader). Erik--- doc/src/sgml/event-trigger.sgml.orig 2023-10-16 17:16:00.017452340 +0200 +++ doc/src/sgml/event-trigger.sgml 2023-10-16

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

On Mon, Oct 16, 2023 at 7:33 PM Tomas Vondra wrote: > > On 10/16/23 11:25, Ashutosh Bapat wrote: > > Thanks Tomas for bringing this discussion to hackers. > > > > > > On Fri, Oct 13, 2023 at 8:58 PM Dean Rasheed > > wrote: > >> > >> On Fri, 13 Oct 2023 at 13:17, Tomas Vondra > >> wrote: > >>>

Re: Rename backup_label to recovery_control

On 10/16/23 10:19, Robert Haas wrote: On Sat, Oct 14, 2023 at 2:22 PM David Steele wrote: I was recently discussing the complexities of dealing with pg_control and backup_label with some hackers at PGConf NYC, when David Christensen commented that backup_label was not a very good name since it

Re: Postgres Architecture

On Mon, Oct 16, 2023 at 6:42 AM Timothy Nelson wrote: > I'm expecting that people will pick the idea apart, and wanted to know > what people think of it. > Thanks for the proposal. This is actually a model that's been around for a very long time. And, in fact, variations of it (e.g. parsing

Re: Server crash on RHEL 9/s390x platform against PG16

On Sun, Oct 8, 2023 at 10:55 PM Suraj Kharage < suraj.khar...@enterprisedb.com> wrote: > It looks like an issue with JIT. If I disable the JIT then the above query > runs successfully. > > postgres=# set jit to off; > > SET > > postgres=# SELECT * FROM rm32044_t1 LEFT JOIN rm32044_t2 ON >

Re: The danger of deleting backup_label

On Sat, Oct 14, 2023 at 11:33 AM David Steele wrote: > All of this is fixable in HEAD, but seems incredibly dangerous to back > patch. Even so, I have attached the patch in case somebody sees an > opportunity that I do not. I really do not think we should be even thinking about back-patching

Re: Rename backup_label to recovery_control

On Sat, Oct 14, 2023 at 2:22 PM David Steele wrote: > I was recently discussing the complexities of dealing with pg_control > and backup_label with some hackers at PGConf NYC, when David Christensen > commented that backup_label was not a very good name since it gives the > impression of being

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

On 10/16/23 11:25, Ashutosh Bapat wrote: > Thanks Tomas for bringing this discussion to hackers. > > > On Fri, Oct 13, 2023 at 8:58 PM Dean Rasheed wrote: >> >> On Fri, 13 Oct 2023 at 13:17, Tomas Vondra >> wrote: >>> >>> I do plan to backpatch this, yes. I don't think there are many people

Re: Add support for AT LOCAL

Michael Paquier writes: > Perhaps that's a stupid question.. But a server running under this > environment fails the two following queries even for older branches, > right? > select timezone('UTC', '23:59:59.99-07'::timetz); > select timezone('UTC', '23:59:00-07'::timetz); One would expect,

Re: list of acknowledgments for PG16

On 2023-Aug-27, Peter Eisentraut wrote: > On 22.08.23 15:48, Vik Fearing wrote: > > I think these might be the same person: > > > >     Zhihong Yu > >     Zihong Yu > > > > I did not spot any others. > > Fixed. Hm, I noticed we also list Ted Yu, but that's the same person as Zhihong Yu.

Re: remaining sql/json patches

Hello! On 16.10.2023 15:49, jian he wrote: add the following code after ExecEvalJsonExprCoercion if (!InputFunctionCallSafe(...) works, but seems like a hack. if (!val_string) { *op->resnull = true; *op->resvalue = (Datum) 0; } It seems the constraint should work here: After CREATE TABLE

Re: Rename backup_label to recovery_control

On 10/16/23 00:26, Kyotaro Horiguchi wrote: At Mon, 16 Oct 2023 13:16:42 +0900 (JST), Kyotaro Horiguchi wrote in Just an idea in a slightly different direction, but I'm wondering if we can simply merge the content of backup_label into control file. The file is 8192 bytes long, yet only 256

Re: remaining sql/json patches

On Mon, Oct 16, 2023 at 5:47 PM Amit Langote wrote: > > > We're currently looking into this case. > > Thanks for the report. I think I've figured out the problem -- > ExecEvalJsonExprCoercion() mishandles the EMPTY ARRAY ON EMPTY case. > > I'm reading the other 2 patches... > > -- > Thanks, Amit

Re: Pro et contra of preserving pg_proc oids during pg_upgrade

Hi, Thank you very much, I'll check it out. It looks like the getObjectIdentity() used in pg_identify_object() could do. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

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

po 16. 10. 2023 v 13:56 odesílatel Daniel Gustafsson napsal: > > On 16 Oct 2023, at 12:15, Quan Zongliang wrote: > > > Implement TODO item: > > PL/pgSQL > > Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[] > > Cool! While I haven't looked at the patch yet, I've wanted this

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

> On 16 Oct 2023, at 12:15, Quan Zongliang wrote: > Implement TODO item: > PL/pgSQL > Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[] Cool! While I haven't looked at the patch yet, I've wanted this myself many times in the past when working with large plpgsql codebases. >

Re: Pro et contra of preserving pg_proc oids during pg_upgrade

On 2023-Oct-13, Nikita Malakhov wrote: > Textual representation requires a long text field because it could > contain schema, arguments, it is difficult and not effective to be > saved as part of the data, and must be parsed to retrieve function > oid. It is worse than that: the regproc textual

Postgres Architecture

Hi all! I'm a DevOps Manager/Engineer by trade (though the place I work is not, unfortunately, using Postgres). I've been thinking quite a bit about what our ideal architecture at work will look like and what scaling looks like, both for work and for home projects (where I *am* looking at using

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

Implement TODO item: PL/pgSQL Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[] As a first step, deal only with [], such as xxx.yyy%TYPE[] xxx%TYPE[] It can be extended to support multi-dimensional and complex syntax in the future. -- Quan Zongliangdiff --git

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

Hi, On Tue, 10 Oct 2023 at 03:54, Michael Paquier wrote: > > In ~14, as far as I can see blk_write_time is only incremented for > shared buffers. FWIW, I agree that we should improve these stats for > local buffers but I am not on board with a solution where we'd use the > same counter for

Re: remaining sql/json patches

Hi, Sorry, forgot to mention above - patches from our patch set should be applied onto SQL/JSON part 3 - v22-0003-SQL-JSON-query-functions.patch, thus they are numbered as v23-0003-1 and -2. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

Hi, On Mon, Oct 16, 2023 at 5:34 PM Nikita Malakhov wrote: > > Hi, > > Also FYI - the following case results in segmentation fault: > > postgres@postgres=# CREATE TABLE test_jsonb_constraints ( > js text, > i int, > x jsonb DEFAULT JSON_QUERY(jsonb '[1,2]', '$[*]' WITH

Re: RFC: Logging plan of the running query

On Thu, Oct 12, 2023 at 6:51 PM torikoshia wrote: > > On 2023-10-11 16:22, Ashutosh Bapat wrote: > > > > Considering the similarity with auto_explain I wondered whether this > > function should be part of auto_explain contrib module itself? If we > > do that users will need to load auto_explain

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

Thanks Tomas for bringing this discussion to hackers. On Fri, Oct 13, 2023 at 8:58 PM Dean Rasheed wrote: > > On Fri, 13 Oct 2023 at 13:17, Tomas Vondra > wrote: > > > > I do plan to backpatch this, yes. I don't think there are many people > > affected by this (few people are using infinite

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

On Sat, Oct 14, 2023 at 10:45 AM Hayato Kuroda (Fujitsu) wrote: > > Here is a new patch. > > Previously I wrote: > > Based on above idea, I made new version patch which some functionalities > > were > > exported from pg_resetwal. In this approach, pg_upgrade itself removed WALs > > and > > then

Re: remaining sql/json patches

Hi, Also FYI - the following case results in segmentation fault: postgres@postgres=# CREATE TABLE test_jsonb_constraints ( js text, i int, x jsonb DEFAULT JSON_QUERY(jsonb '[1,2]', '$[*]' WITH WRAPPER) CONSTRAINT test_jsonb_constraint1 CHECK (js IS

Re: LLVM 16 (opaque pointers)

Le vendredi 13 octobre 2023, 22:32:13 CEST Thomas Munro a écrit : > On Wed, Oct 11, 2023 at 10:31 PM Ronan Dunklau wrote: > > Le mercredi 11 octobre 2023, 10:59:50 CEST Thomas Munro a écrit : > > > The back-patch to 12 was a little trickier than anticipated, but after > > > taking a break and

Re: Removing unneeded self joins

On 12/10/2023 18:32, Alexander Korotkov wrote: On Thu, Oct 5, 2023 at 12:17 PM Andrei Lepikhov wrote: On 4/10/2023 14:34, Alexander Korotkov wrote: > Relid replacement machinery is the most contradictory code here. We used > a utilitarian approach and implemented a simplistic variant.

Re: remaining sql/json patches

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 means the server terminated abnormally before or while

Re: Some performance degradation in REL_16 vs REL_15

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 default settings, I get considerably higher results. Oh - I do get results

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

On Sat, Oct 14, 2023 at 07:29:54PM +, Imseih (AWS), Sami wrote: >> Anyway, it looks like you're right, we don't really need the SLRU once >> the tail is ahead of the tail because the SLRU has wrapped around due >> to the effect of transactions aging out, so making the truncation a >> bit

Re: Add support for AT LOCAL

On Sun, Oct 15, 2023 at 11:05:10PM -0700, Noah Misch wrote: > On Mon, Oct 16, 2023 at 01:54:23AM -0400, Tom Lane wrote: >> Ugh. So if the failure is robust enough to persist across >> several major xlc versions, why couldn't Thomas reproduce it? > > Beats me. hornet wipes its starting

Re: pg_logical_emit_message() misses a XLogFlush()

On Fri, Oct 13, 2023 at 03:20:30PM +0530, Amit Kapila wrote: > I would prefer to associate the new parameter 'flush' with > non-transactional messages as per the proposed patch. Check. > Is there a reason to make the functions strict now when they were not earlier? These two are already STRICT

Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag

On Sun, Oct 15, 2023 at 10:47:22PM -0400, Tom Lane wrote: > I agree that that probably is the root cause, and we should fix it > by bumping up max_worker_processes in this test. Thanks. I've fixed this one now. Let's see if mamba is OK after that. > If there's actually a defensible reason for

Re: Can concurrent create index concurrently block each other?

On 15/10/2023 10:59 pm, Tom Lane wrote: Konstantin Knizhnik writes: One our customer complains that he spawned two `create index concurrently` for two different tables and both stuck in"waiting for old snapshots". I wonder if two CIC can really block each other in `WaitForOlderSnapshots`?

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed It looks good to me. I have reviewed the code and tested

Re: Add support for AT LOCAL

On Mon, Oct 16, 2023 at 01:54:23AM -0400, Tom Lane wrote: > Noah Misch writes: > > On Sun, Oct 15, 2023 at 09:58:04PM -0700, Noah Misch wrote: > >> Works for me. I've started a test run with the xlc version change. > > > It failed similarly: > > > + 23:59:00-07|