Re: Allow escape in application_name

At Tue, 12 Oct 2021 15:42:23 +0900 (JST), Kyotaro Horiguchi wrote in > If we code as the following: ... > A. "^-?[0-9]+.*" : same to the current > B. "^[^0-9-].*" : same to the current > C. "^-[^0-9].*" : padding = 0, p doesn't advance. > D. "^-" : padding = 0, p doesn't advan

RE: Added schema level support for publication.

On Monday, October 11, 2021 11:02 PM vignesh C wrote: > The attached v39 patch has the fixes for the above issues. Thanks for the updates. I have a few minor suggestions about the testcases in the v39-0003-Test patch. 1) +-- alter publication drop CURRENT_SCHEMA +ALTER PUBLICATION testpub1_forsc

Re: Parallel vacuum workers prevent the oldest xmin from advancing

On Mon, Oct 11, 2021 at 9:51 AM Michael Paquier wrote: > > On Mon, Oct 11, 2021 at 09:23:32AM +0900, Masahiko Sawada wrote: > > On Sat, Oct 9, 2021 at 12:13 AM Alvaro Herrera > > wrote: > >> * PROC_VACUUM_FOR_WRAPAROUND. Should be innocuous I think, since the > >> "parent" process already has t

Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.

On Tue, Oct 12, 2021 at 5:37 AM Fujii Masao wrote: > > On 2021/10/12 4:07, Bharath Rupireddy wrote: > > Hi, > > > > While working on [1], it is found that currently the ProcState array > > doesn't have entries for auxiliary processes, it does have entries for > > MaxBackends. But the startup proce

Re: Allow escape in application_name

At Tue, 12 Oct 2021 15:06:11 +0900 (JST), Kyotaro Horiguchi wrote in > "%4%5%6%7p" is converted to "57p". Do we need to imitate that bug > with this patch? So.. I try to describe the behavior for exhaustive patterns.. current: A. "^-?[0-9]+.*" : returns valid padding. p goes after the last d

Re: Reword docs of feature "Remove temporary files after backend crash"

On Mon, Oct 11, 2021 at 11:37 AM Fujii Masao wrote: > > IMO, we can add the new description as proposed in my v1 patch (after > > adding startup process to the exception list) to both the GUCs > > restart_after_crash and remove_temp_files_after_crash. And, in > > remove_temp_files_after_crash GUC

Re: Allow escape in application_name

At Tue, 12 Oct 2021 13:25:01 +0900, Fujii Masao wrote in > > > On 2021/10/07 11:46, kuroda.hay...@fujitsu.com wrote: > > So now we can choose from followings: > >* ignore such differences and use isdigit() and strtol() > > * give up using them and implement two static support functions > >How

Re: Error "initial slot snapshot too large" in create replication slot

On Tue, Oct 12, 2021 at 10:35 AM Kyotaro Horiguchi wrote: > > At Tue, 12 Oct 2021 13:59:59 +0900 (JST), Kyotaro Horiguchi > wrote in > > So I came up with the attached version. > > Sorry, it was losing a piece of change. Yeah, at a high level this is on the idea I have in mind, I will do a deta

Re: Bug in DefineRange() with multiranges

On 10.10.2021 20:12, Peter Eisentraut wrote: On 04.10.21 19:09, Sergey Shinderuk wrote: I wonder what is the proper fix.  Just drop pfree() altogether or add pstrdup() instead?  I see that makeMultirangeTypeName() doesn't bother freeing its buf. I think removing the pfree()s is a correct fix.

Re: storing an explicit nonce

On Mon, 11 Oct 2021 at 22:15, Bruce Momjian wrote: > > Yes, that's the direction that I was thinking also and specifically with > > XTS as the encryption algorithm to allow us to exclude the LSN but keep > > everything else, and to address the concern around the nonce/tweak/etc > > being the same

Re: Printing backtrace of postgres processes

Hi, The previous patch was failing because of the recent test changes made by commit 201a76183e2 which unified new and get_new_node, attached patch has the changes to handle the changes accordingly. Thanks for your update! I have two comments. 1.Do we need “set_backtrace(NULL, 0);” on “HandleM

Re: Error "initial slot snapshot too large" in create replication slot

At Tue, 12 Oct 2021 13:59:59 +0900 (JST), Kyotaro Horiguchi wrote in > So I came up with the attached version. Sorry, it was losing a piece of change. -- Kyotaro Horiguchi NTT Open Source Software Center >From 424f405b4c9d41471eae1edd48cdbb6a6d47217e Mon Sep 17 00:00:00 2001 From: Kyotaro Hor

Re: Skipping logical replication transactions on subscriber side

On Fri, Oct 8, 2021 at 9:22 PM osumi.takami...@fujitsu.com wrote: > > On Thursday, September 30, 2021 2:45 PM Masahiko Sawada > wrote: > > I've attached updated patches that incorporate all comments I got so far. > > Please > > review them. > Hello > > > Minor two comments for v15-0001 patch. >

Re: Error "initial slot snapshot too large" in create replication slot

At Mon, 11 Oct 2021 16:48:10 +0530, Dilip Kumar wrote in > On Mon, Oct 11, 2021 at 4:29 PM Kyotaro Horiguchi > wrote: > > > > At Mon, 11 Oct 2021 11:49:41 +0530, Dilip Kumar > > wrote in > > > While creating an "export snapshot" I don't see any protection why the > > > number of xids in the s

Re: Skipping logical replication transactions on subscriber side

On Fri, Oct 8, 2021 at 8:17 PM Greg Nancarrow wrote: > > On Thu, Sep 30, 2021 at 3:45 PM Masahiko Sawada wrote: > > > > I've attached updated patches that incorporate all comments I got so > > far. Please review them. > > > > Some comments about the v15-0001 patch: Thank you for the comments! >

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

On Mon, Oct 11, 2021 at 09:04:47AM -0400, Andrew Dunstan wrote: > Keeping test.sh is not necessary - I mis-remembered what the test module > does. So.. Are people fine to remove entirely test.sh at the end, requiring the tests of pg_upgrade to have TAP installed? I'd rather raise the bar here, a

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

On Sun, Oct 03, 2021 at 08:22:57AM -0400, Andrew Dunstan wrote: > Actually, I was wrong. The module just does "make check" for non-MSVC. > For MSVC it calls vcregress.pl, which the patch doesn't touch (it > should, I think). Yes, it should. And I'd like to do things so as we replace all the inter

Re: postgres_fdw: misplaced? comments in connection.c

On Mon, Oct 11, 2021 at 5:05 PM Etsuro Fujita wrote: > The comments for pgfdw_get_cleanup_result() say this: > > * It's not a huge problem if we throw an ERROR here, but if we get into error > * recursion trouble, we'll end up slamming the connection shut, which will > * necessitate failing the

Re: Allow escape in application_name

On 2021/10/07 11:46, kuroda.hay...@fujitsu.com wrote: So now we can choose from followings: * ignore such differences and use isdigit() and strtol() * give up using them and implement two static support functions How do you think? Someone knows any other knowledge about locale? Replacing p

Re: Corruption with IMMUTABLE functions in index expression.

Andres Freund writes: > On 2021-10-11 14:59:22 -0400, Tom Lane wrote: >> I doubt we need any code changes beyond changing the indisvalid state. > I was thinking we'd want to throw an error if an index that's being created is > accessed during the index build, rather than just not include it in >

Re: Corruption with IMMUTABLE functions in index expression.

Hi, On 2021-10-11 14:59:22 -0400, Tom Lane wrote: > Andres Freund writes: > > Perhaps we could set pg_index.indisvalid to false initially, and if opening > > an > > index where pg_index.indisvalid error out with a different error message if > > TransactionIdIsCurrentTransactionId(xmin). And then

Re: row filtering for logical replication

On Tue, Oct 12, 2021 at 1:37 AM Dilip Kumar wrote: > > On Wed, Oct 6, 2021 at 2:33 PM Ajin Cherian wrote: > > > > On Sat, Oct 2, 2021 at 5:44 PM Ajin Cherian wrote: > > > > > > I have for now also rebased the patch and merged the first 5 patches > > > into 1, and added my changes for the above i

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

On Mon, Oct 11, 2021 at 7:09 PM Mark Dilger wrote: > I was just wondering when it might be time to stop being lenient in psql and > instead reject malformed identifiers. I suppose that I probably wouldn't have chosen this behavior in a green field situation. But Hyrum's law tells us that there a

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 11, 2021, at 5:37 PM, Peter Geoghegan wrote: > > Cool. I pushed just the amcheck changes a moment ago. I attach the > remaining changes from your v3, with a new draft commit message (no > real changes). I didn't push the rest (what remains in the attached > revision) just yet because

Re: More business with $Test::Builder::Level in the TAP tests

On Mon, Oct 11, 2021 at 10:48:54AM -0400, Andrew Dunstan wrote: > I would say: > > This should be incremented by any subroutine which directly or > indirectly calls test routines from Test::More, such as ok() or > is(). Indeed, that looks better. I have just used that and applied the

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

> On Oct 11, 2021, at 4:49 PM, Tom Lane wrote: > > You are attacking a straw man here. To use a period in an identifier, > you have to double-quote it; that's the same in SQL or \d. That's a strange argument. If somebody gives an invalid identifier, we shouldn't assume they know the proper

Re: is possible an remote access to some macos?

On 10/11/2021 8:49 pm, Noah Misch wrote: On Mon, Oct 11, 2021 at 06:31:03AM +0200, Pavel Stehule wrote: I would like to fix an issue https://github.com/okbob/pspg/issues/188 where the write to clipboard from pspg doesn`t work on macos. But it is hard to fix it without any macos. I am not a use

Re: [PATCH] ProcessInterrupts_hook

On Sat, 2 Oct 2021 at 01:24, Jaime Casanova wrote: > On Tue, Jun 29, 2021 at 01:32:26PM +0800, Craig Ringer wrote: > > On Sat, 20 Mar 2021 at 03:46, Tom Lane wrote: > > > > > Robert Haas writes: > > > > On Fri, Mar 19, 2021 at 3:25 PM Tom Lane wrote: > > > >> I'm not very comfortable about the

Re: is possible an remote access to some macos?

On Mon, Oct 11, 2021 at 06:31:03AM +0200, Pavel Stehule wrote: > I would like to fix an issue https://github.com/okbob/pspg/issues/188 where > the write to clipboard from pspg doesn`t work on macos. But it is hard to > fix it without any macos. I am not a user of macos and I would not buy it > jus

Re: automatically generating node support functions

> > build support and made the Perl code more portable, so that the cfbot > doesn't have to be sad. > Was this also the reason for doing the output with print statements rather than using one of the templating libraries? I'm mostly just curious, and certainly don't want it to get in the way of wor

Re: Fix pg_log_backend_memory_contexts() 's delay

On 2021/10/11 14:40, Fujii Masao wrote: On 2021/10/11 14:28, torikoshia wrote: Thanks for the patch! It might be self-evident, but since there are comments on other process handlings in HandleAutoVacLauncherInterrupts like below, how about adding a comment for the consistency? +1 I ap

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Mon, Oct 11, 2021 at 2:41 PM Mark Dilger wrote: > > Overall, your approach looks good to me. Will Robert take care of > > committing this, or should I? > > I'd appreciate if you could fix up the in the docs and do the > commit. Cool. I pushed just the amcheck changes a moment ago. I attach t

Re: Parallel vacuum workers prevent the oldest xmin from advancing

On Mon, Oct 11, 2021 at 3:01 PM Greg Nancarrow wrote: > > On Wed, Oct 6, 2021 at 6:11 PM Masahiko Sawada wrote: > > > > To fix it, I thought that we change the create index code and the > > vacuum code so that the individual parallel worker sets its status > > flags according to the leader’s one.

Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.

On 2021/10/12 4:07, Bharath Rupireddy wrote: Hi, While working on [1], it is found that currently the ProcState array doesn't have entries for auxiliary processes, it does have entries for MaxBackends. But the startup process is eating up one slot from MaxBackends. We need to increase the siz

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

Mark Dilger writes: > But since we allow tables and schemas with dotted names in them, I'm > uncertain what \d foo.bar.baz is really asking. That could be > "foo.bar"."baz", or "foo"."bar"."baz", or "foo"."bar.baz", or even > "public"."foo.bar.baz". The old behavior seems a bit dangerous. T

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

On Mon, 11 Oct 2021 at 19:35, Mark Dilger wrote: > But since we allow tables and schemas with dotted names in them, I'm > uncertain what \d foo.bar.baz is really asking. > FWIW, it’s absolutely clear to me that "." is a special character which has to be quoted in order to be in an identifier.

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

> On Oct 11, 2021, at 3:37 PM, Tom Lane wrote: > >> REL_13_STABLE appears to accept any amount of nonsense you like: > > Yeah, I'm pretty sure that the old rule was to just ignore whatever > appeared in the database-name position. While we could tighten that > up to insist that it match the

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

On Mon, Oct 11, 2021 at 02:47:59PM -0700, Mark Dilger wrote: > > |$ LD_LIBRARY_PATH=tmp_install/usr/local/pgsql/lib/ src/bin/psql/psql -h > > /tmp regression > > |psql (15devel) > > |Type "help" for help. > > |regression=# \d regresion.public.bit_defaults > > |Did not find any relation named "regr

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

Mark Dilger writes: >> On Oct 11, 2021, at 3:04 PM, Tom Lane wrote: >> Doesn't work with the correct DB name, either: >> regression=# \d regression.public.bit_defaults >> Did not find any relation named "regression.public.bit_defaults". > REL_13_STABLE appears to accept any amount of nonsense yo

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

> On Oct 11, 2021, at 3:26 PM, Justin Pryzby wrote: > > It looks like before v13 any "datname" prefix was ignored. The evidence so far suggests that something is broken in v14, but it is less clear to me what the appropriate behavior is. The v14 psql is rejecting even a correctly named dat

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

> On Oct 11, 2021, at 3:04 PM, Tom Lane wrote: > > Doesn't work with the correct DB name, either: > > regression=# \d public.bit_defaults > Table "public.bit_defaults" > Column | Type | Collation | Nullable | Default > ++-

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

Mark Dilger writes: > I can only assume that you are intentionally misspelling "regression" as > "regresion" (with only one "s") as part of the test. I have not checked if > that worked before v14, but if it ignored the misspelled database name before > v14, and it rejects it now, I'm not sure

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

> On Oct 11, 2021, at 2:24 PM, Justin Pryzby wrote: > > This commit broke psql \d datname.nspname.relname > > commit 2c8726c4b0a496608919d1f78a5abc8c9b6e0868 > Author: Robert Haas > Date: Wed Feb 3 13:19:41 2021 -0500 > >Factor pattern-construction logic out of processSQLNamePattern.

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 11, 2021, at 2:33 PM, Peter Geoghegan wrote: > > On Mon, Oct 11, 2021 at 1:20 PM Mark Dilger > wrote: >> Ok, I went with this suggestion, and also your earlier suggestion to have a >> in the pg_amcheck docs about using --parent-check and/or >> --rootdescend against servers in reco

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Mon, Oct 11, 2021 at 1:20 PM Mark Dilger wrote: > Ok, I went with this suggestion, and also your earlier suggestion to have a > in the pg_amcheck docs about using --parent-check and/or > --rootdescend against servers in recovery. My concern with --parent-check (and with --rootdescend) had l

pg14 psql broke \d datname.nspname.relname

This commit broke psql \d datname.nspname.relname commit 2c8726c4b0a496608919d1f78a5abc8c9b6e0868 Author: Robert Haas Date: Wed Feb 3 13:19:41 2021 -0500 Factor pattern-construction logic out of processSQLNamePattern. ... patternToSQLRegex is a little more general than what is required

Re: pgsql: Adjust configure to insist on Perl version >= 5.8.3.

I wrote: > Andrew Dunstan writes: >> Why don't we specify the minimum versions required of these somewhere in >> the perl code? Perl is pretty good at this. > configure already checks Test::More's version. I proposed downthread > that it should also check IPC::Run, but didn't pull that trigger y

Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

On Fri, Oct 8, 2021 at 1:56 PM Andres Freund wrote: > > Hi, > > On 2021-10-01 16:05:31 -0400, Melanie Plageman wrote: > > From 40c809ad1127322f3462e85be080c10534485f0d Mon Sep 17 00:00:00 2001 > > From: Melanie Plageman > > Date: Fri, 24 Sep 2021 17:39:12 -0400 > > Subject: [PATCH v13 1/4] Allow

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 11, 2021, at 12:25 PM, Mark Dilger > wrote: > > Your proposal sounds good. Let me try it and get back to you shortly. Ok, I went with this suggestion, and also your earlier suggestion to have a in the pg_amcheck docs about using --parent-check and/or --rootdescend against servers

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 11, 2021, at 11:53 AM, Peter Geoghegan wrote: > > On Mon, Oct 11, 2021 at 11:40 AM Peter Geoghegan wrote: >> A NOTICE message is supposed to be surfaced to clients (but not stored >> in the server log), pretty much by definition. >> >> It's not unreasonable to argue that I was mista

Re: storing an explicit nonce

On Mon, Oct 11, 2021 at 01:30:38PM -0400, Stephen Frost wrote: > Greetings, > > > Keep in mind that in our existing code (not my patch), the LSN is zero > > for unlogged relations, a fixed value for some GiST index pages, and > > unchanged for some hint bit changes. Therefore, while we can includ

Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()

On Mon, Oct 11, 2021 at 8:59 PM Fujii Masao wrote: > > On 2021/10/11 19:46, Bharath Rupireddy wrote: > > If we do the above, then the problem might arise if somebody calls > > SICleanupQueue and wants to signal the startup process, the below code > > (from SICleanupQueue) can't get the startup pro

Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.

Hi, While working on [1], it is found that currently the ProcState array doesn't have entries for auxiliary processes, it does have entries for MaxBackends. But the startup process is eating up one slot from MaxBackends. We need to increase the size of the ProcState array by 1 at least for the sta

Re: Corruption with IMMUTABLE functions in index expression.

Andres Freund writes: > Perhaps we could set pg_index.indisvalid to false initially, and if opening an > index where pg_index.indisvalid error out with a different error message if > TransactionIdIsCurrentTransactionId(xmin). And then use an inplace update to > set indisvalid to true, to avoid the

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Mon, Oct 11, 2021 at 11:40 AM Peter Geoghegan wrote: > A NOTICE message is supposed to be surfaced to clients (but not stored > in the server log), pretty much by definition. > > It's not unreasonable to argue that I was mistaken to ever think that > about this particular message. In fact, I su

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Mon, Oct 11, 2021 at 11:37 AM Mark Dilger wrote: > The documentation for contrib/amcheck has a paragraph but not a warning box. > Should that be changed also? Maybe. I think that the pg_amcheck situation is a lot worse, because users could easily interpret --parent-check as an additive thing

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Mon, Oct 11, 2021 at 11:26 AM Mark Dilger wrote: > That's fine by me, but I was under the impression that people wanted the > extraneous noise removed. A NOTICE message is supposed to be surfaced to clients (but not stored in the server log), pretty much by definition. It's not unreasonable

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 11, 2021, at 11:33 AM, Peter Geoghegan wrote: > > I definitely think that it warrants a warning box. This is a huge > practical difference. > > Note that I'm talking about a standard thing, which there are > certainly a dozen or more examples of in the docs already. Just grep > for "

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Mon, Oct 11, 2021 at 11:29 AM Mark Dilger wrote: > The recently submitted patch already contains a short paragraph for each of > these, but not a warning box. Should I reformat those as warning boxes? I > don't know the current thinking on the appropriateness of that documentation > style.

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 11, 2021, at 11:26 AM, Peter Geoghegan wrote: > > We should have a warning box about this in the pg_amcheck docs. Users > should think carefully about ever using --parent-check, since it alone > totally changes the locking requirements (actually --rootdescend will > do that too, but o

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Mon, Oct 11, 2021 at 11:12 AM Peter Geoghegan wrote: > Sure, the user might not be happy with --parent-check throwing an > error on a replica. But in practice most users won't want to do that > anyway. Even on a primary it's usually not possible as a practical > matter, because the locking impl

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 11, 2021, at 11:12 AM, Peter Geoghegan wrote: > > What's the problem with just having pg_amcheck pass through the notice > to the user, without it affecting anything else? Why should a simple > notice message need to affect its return code, or anything else? That's fine by me, but I

Re: Corruption with IMMUTABLE functions in index expression.

Hi, On 2021-10-11 12:27:44 -0400, Tom Lane wrote: > While that could be argued to be a bug, I share David's lack of interest in > fixing it, because I do not believe that there are any cases where a > function that accesses an index's subject table is really going to be > immutable. > To prevent

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Mon, Oct 11, 2021 at 10:46 AM Mark Dilger wrote: > > On Oct 11, 2021, at 10:10 AM, Peter Geoghegan wrote: > > This mostly looks good to me. Just one thing occurs to me: I suspect > > that we don't need to call pg_is_in_recovery() from SQL at all. What's > > wrong with just letting verify_heapa

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 11, 2021, at 10:10 AM, Peter Geoghegan wrote: > > This mostly looks good to me. Just one thing occurs to me: I suspect > that we don't need to call pg_is_in_recovery() from SQL at all. What's > wrong with just letting verify_heapam() (the C function from amcheck > proper) show those n

Re: RFC: compression dictionaries for JSONB

On Mon, 11 Oct 2021 at 15:25, Aleksander Alekseev wrote: > Agree, add / change / remove of a column should be handled > automatically. Just to clarify, by column option do you mean syntax > like ALTER TABLE ... ALTER COLUMN ... etc, right? Correct, either SET (option) or maybe using typmod (which

Re: storing an explicit nonce

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Fri, Oct 8, 2021 at 02:34:20PM -0400, Stephen Frost wrote: > > What I think is missing from this discussion is the fact that, with XTS > > (and XEX, on which XTS is built), the IV *is* run through a forward > > cipher function, just as sug

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Mon, Oct 11, 2021 at 9:53 AM Mark Dilger wrote: > > Right. I never meant anything like making a would-be > > bt_index_parent_check() call into a bt_index_check() call, just > > because of the state of the system (e.g., it's in recovery). That > > seems awful, in fact. > > Please find attached t

Re: storing an explicit nonce

On Mon, Oct 11, 2021 at 01:01:08PM -0400, Stephen Frost wrote: > > It is more than just the page format --- it would also be the added > > code, possible performance impact, and later code maintenance to allow > > for are a more complex or two different page formats. > > Yes, there is more to it t

Re: storing an explicit nonce

On Fri, Oct 8, 2021 at 02:34:20PM -0400, Stephen Frost wrote: > What I think is missing from this discussion is the fact that, with XTS > (and XEX, on which XTS is built), the IV *is* run through a forward > cipher function, just as suggested above needs to be done for CBC. I > don't see any reas

Re: storing an explicit nonce

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Oct 7, 2021 at 11:32:07PM -0400, Stephen Frost wrote: > > Part of the meeting was specifically about "why are we doing this?" and > > there were a few different answers- first and foremost was "because > > people are asking for it", f

Re: storing an explicit nonce

On Thu, Oct 7, 2021 at 11:32:07PM -0400, Stephen Frost wrote: > Part of the meeting was specifically about "why are we doing this?" and > there were a few different answers- first and foremost was "because > people are asking for it", from which followed that, yes, in many cases > it's to satisfy

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 6, 2021, at 4:12 PM, Peter Geoghegan wrote: > >> >> Ok, excellent, that was probably the only thing that had me really hung up. >> I thought you were still asking for pg_amcheck to filter out the >> --parent-check option when in recovery, but if you're not asking for that, >> then

Re: Corruption with IMMUTABLE functions in index expression.

On Mon, Oct 11, 2021 at 9:27 AM Tom Lane wrote: > Yeah. What is happening is that the function's SELECT on the subject > table is trying to examine the not-yet-valid new index. While that could > be argued to be a bug, I share David's lack of interest in fixing it, > because I do not believe tha

Re: Corruption with IMMUTABLE functions in index expression.

Tomas Vondra writes: > True, but I can't reproduce it. So either the build is broken in some > way, or perhaps there's something else going on. What would be quite > helpful is a backtrace showing why the error was triggered. i.e. set a > breakpoint on the ereport in mdread(). It reproduced as

Re: Returning to Postgres community work

On Tue, Aug 31, 2021 at 11:24 AM Gurjeet Singh wrote: > Hi All, > > I'm very happy to announce that I now work for Supabase [1]. They > have hired me so that I can participate in, and contribute to the > Postgres community. > Welcome back Gurjeet. > > I'm announcing it here in the hop

Re: Corruption with IMMUTABLE functions in index expression.

"David G. Johnston" writes: > On Monday, October 11, 2021, Prabhat Sahu > wrote: >> While using IMMUTABLE functions in index expression, we are getting below >> corruption on HEAD. > That function is not actually immutable (the system doesn’t check whether > your claim of immutability and the fu

Re: Corruption with IMMUTABLE functions in index expression.

On 10/11/21 18:08, Andrey Borodin wrote: 11 окт. 2021 г., в 20:47, David G. Johnston написал(а): On Monday, October 11, 2021, Prabhat Sahu wrote: While using IMMUTABLE functions in index expression, we are getting below corruption on HEAD. That function is not actually immutable (the

Re: Corruption with IMMUTABLE functions in index expression.

> 11 окт. 2021 г., в 20:47, David G. Johnston > написал(а): > > On Monday, October 11, 2021, Prabhat Sahu > wrote: > While using IMMUTABLE functions in index expression, we are getting below > corruption on HEAD. > > That function is not actually immutable (the system doesn’t check whethe

Re: Proposal: allow database-specific role memberships

Greetings, * David G. Johnston (david.g.johns...@gmail.com) wrote: > On Monday, October 11, 2021, Stephen Frost wrote: > > I don't think "just don't grant access to those other databases" > > is actually a proper answer- there is certainly a use-case for "I want > > user X to have read access to

Re: Corruption with IMMUTABLE functions in index expression.

On Monday, October 11, 2021, Prabhat Sahu wrote: > > While using IMMUTABLE functions in index expression, we are getting below > corruption on HEAD. > That function is not actually immutable (the system doesn’t check whether your claim of immutability and the function definition match, its up to

Re: Proposal: allow database-specific role memberships

On Monday, October 11, 2021, Stephen Frost wrote: > > I don't think "just don't grant access to those other databases" > is actually a proper answer- there is certainly a use-case for "I want > user X to have read access to all tables in *this* database, and also > allow them to connect to some o

Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()

On 2021/10/11 19:46, Bharath Rupireddy wrote: If we do the above, then the problem might arise if somebody calls SICleanupQueue and wants to signal the startup process, the below code (from SICleanupQueue) can't get the startup process backend id. So, the backend id calculation for the startup

Reset snapshot export state on the transaction abort

As reported at [1], if the transaction is aborted during export snapshot then ExportInProgress and SavedResourceOwnerDuringExport are not getting reset and that is throwing an error "clearing exported snapshot in wrong transaction state" while executing the next command. The attached patch clears

Re: Proposal: allow database-specific role memberships

On Mon, 11 Oct 2021 at 11:01, Stephen Frost wrote: > Having an ability to GRANT predefined roles within a particular database > is certainly something that I'd considered when adding the pg_read/write > data roles. I'm not super thrilled with the idea of adding a column to > pg_auth_members jus

Re: pgsql: Adjust configure to insist on Perl version >= 5.8.3.

Andrew Dunstan writes: > On 10/9/21 10:25 PM, Noah Misch wrote: >> You mentioned prairiedog uses IPC::Run 0.79. That's from 2005. (Perl 5.8.3 >> is from 2004, and Test::More 0.87 is from 2009.) I'd just use 0.79 in the >> README recipe. IPC::Run is easy to upgrade, so if we find cause to rely

Re: Proposal: allow database-specific role memberships

Greetings, * David G. Johnston (david.g.johns...@gmail.com) wrote: > On Sun, Oct 10, 2021 at 2:29 PM Kenaniah Cerny wrote: > > > In building off of prior art regarding the 'pg_read_all_data' and > > 'pg_write_all_data' roles, I would like to propose an extension to roles > > that would allow for

Re: Added schema level support for publication.

On Mon, Oct 11, 2021 at 1:21 PM Greg Nancarrow wrote: > > On Mon, Oct 11, 2021 at 5:39 PM vignesh C wrote: > > > > These comments are fixed in the v38 patch attached. > > > > Thanks for the updates. > I noticed that these patches don't apply on the latest source (last > seemed to apply cleanly on

Re: pgsql: Adjust configure to insist on Perl version >= 5.8.3.

On 10/9/21 10:25 PM, Noah Misch wrote: > On Sat, Oct 09, 2021 at 04:34:46PM -0400, Tom Lane wrote: >> Hah ... your backpan link led me to realize the actual problem with >> Test::More. It got folded into Test::Simple at some point, and >> evidently cpanm isn't smart enough to handle a request fo

Re: EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST fails

Markus Winand writes: > What I meant is that it was still working on > 4ac0f450b698442c3273ddfe8eed0e1a7e56645f, but not on the next > (3f50b82639637c9908afa2087de7588450aa866b). Yeah, silly oversight in that patch. Will push a fix shortly. regards, tom lane

Re: More business with $Test::Builder::Level in the TAP tests

On 10/10/21 7:18 AM, Michael Paquier wrote: > On Fri, Oct 08, 2021 at 12:14:57PM -0400, Andrew Dunstan wrote: >> I think we need to be more explicit about it, especially w.r.t. indirect >> calls. Every subroutine in the call stack below where you want to error >> reported as coming from should co

Corruption with IMMUTABLE functions in index expression.

Hi All, While using IMMUTABLE functions in index expression, we are getting below corruption on HEAD. postgres=# CREATE TABLE tab1 (c1 numeric, c2 numeric); CREATE TABLE postgres=# INSERT INTO tab1 values (10, 100); INSERT 0 1 postgres=# CREATE OR REPLACE FUNCTION func1(var1 numeric) RETURNS

Re: row filtering for logical replication

On Wed, Oct 6, 2021 at 2:33 PM Ajin Cherian wrote: > > On Sat, Oct 2, 2021 at 5:44 PM Ajin Cherian wrote: > > > > I have for now also rebased the patch and merged the first 5 patches > > into 1, and added my changes for the above into the second patch. > > I have split the patches back again, jus

Re: EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST fails

> On 11.10.2021, at 16:27, Peter Eisentraut > wrote: > > On 11.10.21 12:22, Markus Winand wrote: >> Both variants work fine before that patch >> (4ac0f450b698442c3273ddfe8eed0e1a7e56645f). > > That commit is a message wording patch. Are you sure you meant that one? > What I meant is that

Re: EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST fails

On 11.10.21 12:22, Markus Winand wrote: Both variants work fine before that patch (4ac0f450b698442c3273ddfe8eed0e1a7e56645f). That commit is a message wording patch. Are you sure you meant that one?

Re: automatically generating node support functions

On 15.09.21 21:01, Peter Eisentraut wrote: On 17.08.21 16:36, Peter Eisentraut wrote: Here is another set of preparatory patches that clean up various special cases and similar in the node support. This set of patches has been committed.  I'll close this commit fest entry and come back with

Re: Time to upgrade buildfarm coverage for some EOL'd OSes?

On 2021-10-11 10:20, Magnus Hagander wrote: It was indeed supposed to, but didn't. It has now been done though, so git.postgresql.org should now be compatible with ancient OpenSSL. And curculio is back to life and shows as all green on the status page. So it's ind

Re: Add client connection check during the execution of the query

On 12.06.2021 07:24, Thomas Munro wrote: On Fri, Apr 30, 2021 at 2:23 PM Thomas Munro wrote: Here's something I wanted to park here to look into for the next cycle: it turns out that kqueue's EV_EOF flag also has the right semantics for this. That leads to the idea of exposing the event via

Re: Double partition lock in bufmgr

В Пт, 18/12/2020 в 15:20 +0300, Konstantin Knizhnik пишет: > Hi hackers, > > I am investigating incident with one of out customers: performance of > the system isdropped dramatically. > Stack traces of all backends can be found here: > http://www.garret.ru/diag_20201217_102056.stacks_59644 > (th

Re: RFC: compression dictionaries for JSONB

Matthias, Alvaro, Many thanks for your comments and suggestions! > Well, I for one would like access to manually add entries to the > dictionary. What I'm not interested in is being required to manually > update the dictionary; but the ability to manually insert into the > dictionary however is m

  1   2   >