Re: Extending amcheck to check toast size and compression

Robert Haas writes: > OK, I've committed this version. Some of the buildfarm is unimpressed with this --- looks like the test output is less stable than you thought. regards, tom lane

Re: Schema variables - new implementation for Postgres 15

Hi st 3. 11. 2021 v 14:05 odesílatel Tomas Vondra < tomas.von...@enterprisedb.com> napsal: > Hi, > > I took a quick look at the latest patch version. In general the patch > looks pretty complete and clean, and for now I have only some basic > comments. The attached patch tweaks some of this,

Re: amcheck's verify_heapam(), and HOT chain verification

> On Nov 5, 2021, at 7:51 PM, Peter Geoghegan wrote: > > I recently pushed a commit which formalized what we expect of HOT > chains during pruning -- see assertions and comments added by commit > 5cd7eb1f, "Add various assertions to heap pruning code". I notice that > verify_heapam() doesn't

amcheck's verify_heapam(), and HOT chain verification

I recently pushed a commit which formalized what we expect of HOT chains during pruning -- see assertions and comments added by commit 5cd7eb1f, "Add various assertions to heap pruning code". I notice that verify_heapam() doesn't really do anything with HOT chains, and I'd say that that's a gap.

Re: Draft release notes for next week's releases

On Fri, Nov 05, 2021 at 08:27:49PM -0400, Tom Lane wrote: > First draft is up at > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=39387228c8b7043d168bada0c64e9f59e83285f5 > As usual, please send any comments/corrections by Sunday. + one more row than requested, so tha it

Re: [PATCH] Don't block HOT update by BRIN index

Hi, I've polished the patch a bit, with the goal to get it committed. I've added the new amhotblocking flag to indexam.sgml (and I'm wondering if there's another place in docs for more details). But then I realized there's an issue in handling the predicate. Consider this example: drop

Re: Commitfest 2021-11 Patch Triage - Part 1

> 1741: Index Skip Scan > = > An often requested feature which has proven hard to reach consensus on an > implementation for. The thread(s) have stalled since May, This statement is not accurate. Peter started a new thread in [1] for this topic last month and then we had a

Re: Commitfest 2021-11 Patch Triage - Part 1

Thanks for taking care of this. > 2433: Erase the distinctClause if the result is unique by definition > > (parts of) The approach taken in this patch has been objected against in favor > of work that Tom has proposed. Actually

Draft release notes for next week's releases

First draft is up at https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=39387228c8b7043d168bada0c64e9f59e83285f5 As usual, please send any comments/corrections by Sunday. regards, tom lane

Re: WIP: expression evaluation improvements

Hi, On 2021-11-05 14:13:38 -0400, Robert Haas wrote: > On Fri, Nov 5, 2021 at 1:20 PM Andres Freund wrote: > > Yes. Optimally we'd do JIT caching across connections as well. One of the > > biggest issues with the costs of JITing is actually parallel query, where > > we'll often recreate the same

Re: jsonb crash

On Tue, Oct 26, 2021 at 07:07:01PM +1300, David Rowley wrote: > Does anyone have any thoughts on the proposed fixes? I don't have any thoughts, but I want to be sure it isn't forgotten. -- Justin

Re: Portability report: ninja

On 2021-11-02 09:27:17 +1300, Thomas Munro wrote: > On Tue, Nov 2, 2021 at 8:25 AM Tom Lane wrote: > > 6. While configure.py thinks it knows what to do on AIX, it fails > > on AIX 7.1 and 7.2: > > > > Traceback (most recent call last): > > File "./configure.py", line 544, in > > if

Commitfest 2021-11 Patch Triage - Part 1

We have amassed quite a lot of patches in the CF app, and while Jaime did a very good job closing patches in the last CF there is still a lot to go through. I've attempted a brief per-patch triage here to see where we are with these. Reading every email in the threads for these patches is a

Re: [PROPOSAL] new diagnostic items for the dynamic sql

Hi Daniel, Thank you for your follow up, and attaching a new patch which addresses Pavel's comments. Let me know If I miss anything here. On Thu, 4 Nov 2021 at 17:40, Daniel Gustafsson wrote: > > On 9 Sep 2021, at 08:23, Dinesh Chemuduru > wrote: > > > Let me try to fix the suggested case(I

Re: WIP: expression evaluation improvements

On Fri, Nov 5, 2021 at 1:20 PM Andres Freund wrote: > Yes. Optimally we'd do JIT caching across connections as well. One of the > biggest issues with the costs of JITing is actually parallel query, where > we'll often recreate the same JIT code again and again. For that you really > can't have

Re: WIP: expression evaluation improvements

Hi, On 2021-11-05 09:48:16 -0700, Andres Freund wrote: > On 2021-11-05 08:34:26 -0400, Robert Haas wrote: > > I'm not sure why that requires all of this relative pointer stuff, > > honestly. Under that problem statement, we don't need everything to be > > one contiguous allocation. We just need

Re: WIP: expression evaluation improvements

Hi, On 2021-11-05 13:09:10 -0400, Robert Haas wrote: > On Fri, Nov 5, 2021 at 12:48 PM Andres Freund wrote: > > I don't see how that works - the same expression can be evaluated multiple > > times at once, recursively. So you can't have things like > > FunctionCallInfoData > > shared. One key

Re: WIP: expression evaluation improvements

On Fri, Nov 5, 2021 at 12:48 PM Andres Freund wrote: > I don't see how that works - the same expression can be evaluated multiple > times at once, recursively. So you can't have things like FunctionCallInfoData > shared. One key point of separating out the mutable data into something that > can

Re: removing global variable ThisTimeLineID

On Fri, Nov 5, 2021 at 9:49 AM Alvaro Herrera wrote: > I looked at these in a very quick skim. I agree that this is a > good step in a good direction. Cool. I have now committed these. I grouped them into just 3 commits rather than having 11 separate commits as I did in my earlier posting, but

Re: [PATCH] Full support for index LP_DEAD hint bits on standby

Hello, Antonin. Thanks for pushing it forward. > I understand that the RR snapshot is used to check the MVCC behaviour, however > this comment seems to indicate that the RR snapshot should also prevent the > standb from setting the hint bits. > # Make sure previous queries not set the hints on

Re: WIP: expression evaluation improvements

Hi, On 2021-11-05 08:34:26 -0400, Robert Haas wrote: > I'm not sure why that requires all of this relative pointer stuff, > honestly. Under that problem statement, we don't need everything to be > one contiguous allocation. We just need it to have the same lifespan > as the JITted code. If you

Re: [PATCH] rename column if exists

On Fri, Nov 5, 2021 at 8:37 AM Robert Haas wrote: > > Making renaming work in the same kind of context is harder. You're > definitely going to have to upgrade the application and the schema in > lock step, unless the application is smart enough to work with the > column having either name.

Re: refactoring basebackup.c

On Tue, Nov 2, 2021 at 10:32 AM Robert Haas wrote: > Meanwhile, I think it's probably OK for me to go ahead and commit > 0001-0003 from my patches at this point, since it seems we have pretty > good evidence that the abstraction basically works, and there doesn't > seem to be any value in holding

Re: [PATCH] rename column if exists

On Fri, Nov 5, 2021 at 8:08 AM Tom Lane wrote: > "David G. Johnston" writes: > > On Friday, November 5, 2021, Tom Lane wrote: > >> I'd be more willing to overlook that if a clear use-case had been > >> given, but AFAICS no concrete case has been offered. > > > The use case is the exact same

Re: [PATCH] rename column if exists

On Fri, Nov 5, 2021 at 10:40 AM Tom Lane wrote: > In this framework, RENAME IF EXISTS is in sort of a weird place. > You'd know that afterwards there is no longer any column with the > source name. But you are not entitled to draw any conclusions > about whether a column exists with the target

Re: should we enable log_checkpoints out of the box?

On 11/5/21 10:50, Alvaro Herrera wrote: On 2021-Nov-05, Michael Banck wrote: Well that, and the fact those distinctions are only done for user- facing events, whereas it seems to me we only distinguish between LOG and PANIC for server-facing events; maybe we need one or more additional levels

Re: should we enable log_checkpoints out of the box?

On Fri, Nov 5, 2021 at 03:29:37PM +0100, Michael Banck wrote: > Am Freitag, dem 05.11.2021 um 11:27 -0300 schrieb Alvaro Herrera: > > On 2021-Nov-03, Jan Wieck wrote: > > > On 11/3/21 09:09, Robert Haas wrote: > > > > > > > For better or for worse, the distinction between ERROR, FATAL, > > > >

Re: [PATCH] rename column if exists

"David G. Johnston" writes: > On Friday, November 5, 2021, Tom Lane wrote: >> I'd be more willing to overlook that if a clear use-case had been >> given, but AFAICS no concrete case has been offered. > The use case is the exact same one for all of these - indempotence, ... except that, as I

Re: should we enable log_checkpoints out of the box?

On Fri, Nov 5, 2021 at 10:50 AM Alvaro Herrera wrote: > I think what we need is an orthogonal classification. "This FATAL here > is routine; that ERROR there denotes a severe problem in the underlying > OS". Additional levels won't help with that. Maybe adding the concept > of "severity" or

Re: [PATCH] rename column if exists

On Friday, November 5, 2021, Tom Lane wrote: > > I'd be more willing to overlook that if a clear use-case had been > given, but AFAICS no concrete case has been offered. > > The use case is the exact same one for all of these - indempotence, especially in the face of being able to run migration

Re: pg14 psql broke \d datname.nspname.relname

> On Nov 5, 2021, at 6:59 AM, Tom Lane wrote: > > Alvaro Herrera writes: >> I think it would appropriate to normalize identifiers that are going to >> be stored in catalogs. As presented, this is a bit ridiculous and I see >> no reason to continue to support it. > > If we had any sort of

Re: should we enable log_checkpoints out of the box?

On 2021-Nov-05, Michael Banck wrote: > Well that, and the fact those distinctions are only done for user- > facing events, whereas it seems to me we only distinguish between LOG > and PANIC for server-facing events; maybe we need one or more > additional levels here in order to make it easier for

Re: Parallel vacuum workers prevent the oldest xmin from advancing

On Fri, 22 Oct 2021 at 07:38, Masahiko Sawada wrote: > > On Wed, Oct 20, 2021 at 9:27 AM Masahiko Sawada wrote: > > > > On Wed, Oct 20, 2021 at 3:07 AM Alvaro Herrera > > wrote: > > > > > > On 2021-Oct-19, Alvaro Herrera wrote: > > > > > > > Thank you for the comment. > > > > > > Hmm, I think

Re: [PATCH] rename column if exists

"David G. Johnston" writes: > On Friday, November 5, 2021, Daniel Gustafsson wrote: >> I know that, I'm just not convinced that it's a feature (in the case at >> hand) > I don’t see how this one should be expected to meet a higher bar than drop > table or other existing commands. I get why in

Re: pg14 psql broke \d datname.nspname.relname

On Fri, Nov 5, 2021 at 9:59 AM Tom Lane wrote: > In any case, that seems quite orthogonal to the question of how to treat > names with too many dots in them. Considering we are three days out from > freezing 14.1, I think it is time to stop the meandering discussion and > fix it. And by "fix",

Re: should we enable log_checkpoints out of the box?

Am Freitag, dem 05.11.2021 um 11:27 -0300 schrieb Alvaro Herrera: > On 2021-Nov-03, Jan Wieck wrote: > > On 11/3/21 09:09, Robert Haas wrote: > > > > > For better or for worse, the distinction between ERROR, FATAL, > > > and > > > PANIC is entirely based on what we do after printing the message,

Re: should we enable log_checkpoints out of the box?

On 2021-Nov-03, Jan Wieck wrote: > On 11/3/21 09:09, Robert Haas wrote: > > > For better or for worse, the distinction between ERROR, FATAL, and > > PANIC is entirely based on what we do after printing the message, > > and NOT on how serious the message is. > > THAT is a real problem with our

Re: [PATCH] rename column if exists

On Friday, November 5, 2021, Daniel Gustafsson wrote: > > I know that, I'm just not convinced that it's a feature (in the case at > hand) > I don’t see how this one should be expected to meet a higher bar than drop table or other existing commands. I get why in the nearby discussion create role

Re: remove internal support in pgcrypto?

> On 5 Nov 2021, at 15:04, Peter Eisentraut > wrote: > > On 03.11.21 21:10, Daniel Gustafsson wrote: >>> Here is a consolidated patch. I have tested it locally, so it should be >>> okay on Windows. >> I don't think this bit is correct, as OSSL_TESTS have been removed from the >> Makefie: >>

Re: remove internal support in pgcrypto?

On 03.11.21 21:10, Daniel Gustafsson wrote: Here is a consolidated patch. I have tested it locally, so it should be okay on Windows. I don't think this bit is correct, as OSSL_TESTS have been removed from the Makefie: - $config->{openssl} - ?

Re: pg14 psql broke \d datname.nspname.relname

Alvaro Herrera writes: > I think it would appropriate to normalize identifiers that are going to > be stored in catalogs. As presented, this is a bit ridiculous and I see > no reason to continue to support it. If we had any sort of convention about the encoding of identifiers stored in shared

Re: removing global variable ThisTimeLineID

I looked at these in a very quick skim. I agree that this is a good step in a good direction. I 'git rebase -x'd this series in order to compile and run the tests on each patch individually. There are no compiler warnings anywhere and no test failures. -- Álvaro Herrera

Re: Extending amcheck to check toast size and compression

On Thu, Nov 4, 2021 at 6:58 PM Mark Dilger wrote: > It only takes about 20 additional lines in the regression test to check the > code paths for raw sizes which are too large and too small, so I've done that > in this next version. Testing corrupt compressed data in a deterministic, > cross

Re: pg14 psql broke \d datname.nspname.relname

On 2021-Oct-20, Mark Dilger wrote: > I tried testing how this plays out by handing `createdb` the name é > (U+00E9 "LATIN SMALL LETTER E WITH ACCUTE") and then again the name é > (U+0065 "LATIN SMALL LETTER E" followed by U+0301 "COMBINING ACCUTE > ACCENT".) That results in two distinct

Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.

On 2021-Nov-04, Jeff Davis wrote: > But I don't see it generalizing to a lot of commands, either. I looked > at the list, and it's taking some creativity to think of more than a > couple other commands where it makes sense. Maybe LISTEN/NOTIFY? But > even then, there are three related commands:

Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.

On Thu, Nov 4, 2021 at 6:46 PM Andres Freund wrote: > What about extending GRANT to allow to grant rights on commands? Yes, it'd be > a bit of work to make that work in the catalogs, but it doesn't seem too hard > to tackle. I think that there aren't too many commands where the question is just

Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.

On Thu, Nov 4, 2021 at 7:38 PM Jeff Davis wrote: > It seems like this specific approach has been mostly shot down already. > But out of curiosity, are you intending to run CHECKPOINT during > bootstrap or something? Imagine a system with corruption in pg_proc. Right now, that won't prevent you

Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.

On Thu, Nov 4, 2021 at 5:25 PM Jeff Davis wrote: > On Thu, 2021-11-04 at 12:37 -0400, Robert Haas wrote: > > I don't have anything specific to propose, which I realize is kind of > > unhelpful ... but I don't like this, either. > > We can go back to having a pg_checkpoint predefined role that is

Re: [PATCH] Added TRANSFORM FOR for COMMENT tab completion

On 2021/11/05 21:35, Michael Paquier wrote: On Fri, Nov 05, 2021 at 10:39:36AM +0100, Daniel Gustafsson wrote: Is there anything left on this or can we close it in the commitfest? Oops. I have missed that there was a CF entry for this patch, and missed that Fujii-san was registered as a

Re: [PATCH] Added TRANSFORM FOR for COMMENT tab completion

On Fri, Nov 05, 2021 at 10:39:36AM +0100, Daniel Gustafsson wrote: > Is there anything left on this or can we close it in the commitfest? Oops. I have missed that there was a CF entry for this patch, and missed that Fujii-san was registered as a committer for it. My apologies! -- Michael

Re: WIP: expression evaluation improvements

On Thu, Nov 4, 2021 at 7:47 PM Andres Freund wrote: > The immediate goal is to be able to generate JITed code/LLVM-IR that doesn't > contain any absolute pointer values. If the generated code doesn't change > regardless of any of the other contents of ExprEvalStep, we can still cache > the JIT

Re: pgsql: Fix WAL replay in presence of an incomplete record

On 2021-Nov-05, Alvaro Herrera wrote: > On 2021-Nov-04, Tom Lane wrote: > > > the standbys > > would be unable to proceed anyway in case of a primary crash at the > > wrong time, because an un-updated primary would send them inconsistent > > WAL. If anything, it seems like it might be

Re: [PATCH] rename column if exists

> On 5 Nov 2021, at 13:03, Isaac Morland wrote: > > On Fri, 5 Nov 2021 at 05:21, Daniel Gustafsson > wrote: > > > Same reasoning as for all the other if exists we have, idempotence. Being > > able to run the command on an object that is already in the desired state >

Re: pgsql: Fix WAL replay in presence of an incomplete record

On 2021-Nov-04, Tom Lane wrote: > Is there really any point in issuing such advice? IIUC, the standbys > would be unable to proceed anyway in case of a primary crash at the > wrong time, because an un-updated primary would send them inconsistent > WAL. If anything, it seems like it might be

Re: [PATCH] rename column if exists

On Fri, 5 Nov 2021 at 05:21, Daniel Gustafsson wrote: > > Same reasoning as for all the other if exists we have, idempotence. > Being able to run the command on an object that is already in the desired > state without provoking an error. > > If the object is known to be in the desired state,

Re: Feature request for adoptive indexes

Hi All I did final research and saw that the difference between best and worst cases is indeed really small. I want to thank you guys for your time and efforts. Best regards. вт, 2 нояб. 2021 г. в 18:04, Pavel Borisov : > вт, 2 нояб. 2021 г. в 16:04, Hayk Manukyan : > >> Tomas Vondra >> > Are

Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?

> 4 нояб. 2021 г., в 20:58, Peter Geoghegan написал(а): > That's a pretty unlikely scenario. And even > if it happened it would only happen once (until the next time we get > unlucky). What are the chances of somebody noticing a more or less > once-off, slightly wrong answer? I'd say next to

Re: Supply restore_command to pg_rewind via CLI argument

> 4 нояб. 2021 г., в 17:55, Daniel Gustafsson написал(а): > > The patch no longer applies, can you submit a rebased version please? Thanks, Daniel! PFA rebase. Best regards, Andrey Borodin. v3-0001-Allow-providing-restore_command-as-a-command-line.patch Description: Binary data

Re: [PATCH] Added TRANSFORM FOR for COMMENT tab completion

> On 5 Nov 2021, at 07:30, Michael Paquier wrote: > > On Fri, Nov 05, 2021 at 12:31:42PM +0900, Ken Kato wrote: >> I found unnecessary line deletion in my previous patch, so I made a minor >> update for that. > > I have looked at this version, and this is much simpler than what was > proposed

Re: [PATCH] rename column if exists

> On 4 Nov 2021, at 14:26, David G. Johnston wrote: > > On Thursday, November 4, 2021, Daniel Gustafsson > wrote: > > On 22 Mar 2021, at 20:40, David Oksman > > wrote: > > > > Added the ability to specify IF EXISTS when renaming a column of

Re: row filtering for logical replication

On Fri, Nov 5, 2021 at 10:44 AM Peter Smith wrote: > > PSA new set of v37* patches. > Few comments about changes made to the patch to rebase it: 1. +#if 1 + // FIXME - can we do a better job if integrating this with the schema changes + /* + * Remove all publication-table mappings. We could

RE: Failed transaction statistics to measure the logical replication progress

On Thursday, November 4, 2021 9:54 AM Greg Nancarrow wrote: > On Tue, Nov 2, 2021 at 12:18 AM osumi.takami...@fujitsu.com > wrote: > > > > On Thursday, October 28, 2021 11:19 PM I wrote: > > > I've created a new patch that extends pg_stat_subscription_workers > > > to include other transaction

Re: Teach pg_receivewal to use lz4 compression

‐‐‐ Original Message ‐‐‐ On Friday, November 5th, 2021 at 3:47 AM, Michael Paquier wrote: > > I have spent an extra couple of hours staring at the code, and the > whole looked fine, so applied. While on it, I have tested the new TAP > tests with all the possible combinations of

RE: Added schema level support for publication.

> On Thu, Nov 4, 2021 at 3:24 PM vignesh C wrote: > > > > On Thu, Nov 4, 2021 at 5:41 AM Peter Smith > wrote: > > > > > > FYI - I found a small problem with one of the new PublicationObjSpec > > > parser error messages that was introduced by the recent schema > > > publication commit [1]. > > >

Re: lastOverflowedXid does not handle transaction ID wraparound

At Thu, 4 Nov 2021 01:07:05 +0300, Alexander Korotkov wrote in > Hi! > > On Wed, Nov 3, 2021 at 8:51 PM Simon Riggs > wrote: > > It is however, an undocumented modularity violation. I think that is > > acceptable because of the ProcArrayLock traffic, but needs to have a > > comment to

Re: Map WAL segment files on PMEM as WAL buffers

Hi Daniel, The issue you told has been fixed. I attach the v5 patchset to this email. The v5 has all the patches in the v4, and in addition, has the following two new patches: - (v5-0002) Support build with MSVC on Windows: Please have src\tools\msvc\config.pl as follows to "configure

Re: [PATCH] Added TRANSFORM FOR for COMMENT tab completion

On Fri, Nov 05, 2021 at 12:31:42PM +0900, Ken Kato wrote: > I found unnecessary line deletion in my previous patch, so I made a minor > update for that. I have looked at this version, and this is much simpler than what was proposed upthread. This looks good, so applied after fixing a couple of