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 t

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 o

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 environmen

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 smarte

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 closer

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 processin

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: 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 try

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: [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: 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 dat

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 ex

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 WRA

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: 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 local

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 a/src/pl/plp

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 P

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 r

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. > A

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 my

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: 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: 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 byt

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 te

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: 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, sinc

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: 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 inf

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 some

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 > rm32044_

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 done

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: 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: > >>> >

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: 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 ev

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: 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 to

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 be

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 relea

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 R

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 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 backup,

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 scan

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 checks

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 to

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 pg_start_backup()

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 expand

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 de

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 rest

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 mistake-proof

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 wi

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: 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 crash.si

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 of

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. Than

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 r

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 notice

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 for

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 futu

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 it

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: 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 parallel-quer

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 these

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 da

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 curious

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 ca

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, t

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 b

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 r

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 n

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 patc

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 exte

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 person

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 2023/

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: 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 prob

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 addres

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 mu

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 in

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: 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 cont

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 application/octet

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: 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 shou

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*var

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 = (D

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: 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 > PERL5LIB=/ho

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: [PoC] pg_upgrade: allow to upgrade publisher node

On Mon, 16 Oct 2023 at 14:44, Amit Kapila wrote: > > 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_resetwa

Re: interval_ops shall stop using btequalimage (deduplication)

> I've also caught btree posting lists where one TID refers to a '1d' heap > tuple, while another TID refers to a '24h' heap tuple. amcheck complains. Index-only scans can return the '1d' bits where the actual tuple had the '24h' bits. Have a build without the patch. I can't reproduce amcheck com

Re: Add support for AT LOCAL

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 > alterations didn't change th

Re: pg_logical_emit_message() misses a XLogFlush()

On Mon, Oct 16, 2023 at 12:47 PM Michael Paquier wrote: > > 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

Re: Schema variables - new implementation for Postgres 15

Hi When I thought about global temporary tables, I got one maybe interesting idea. The one significant problem of global temporary tables is place for storing info about size or column statistics. I think so these data can be stored simply in session variables. Any global temporary table can get