Re: Added schema level support for publication.

On Fri, Oct 8, 2021 at 4:34 PM Amit Kapila wrote: > > On Thu, Oct 7, 2021 at 5:19 PM Amit Kapila wrote: > > > > On Wed, Oct 6, 2021 at 11:12 AM vignesh C wrote: > > > > > > Attached v37 patch has the changes for the same. > > > > > > > Few comments: > > == > > > > Few more comments:

Re: Added schema level support for publication.

On Mon, Oct 11, 2021 at 7:46 AM tanghy.f...@fujitsu.com wrote: > > > On Friday, October 8, 2021 7:05 PM Amit Kapila > > wrote: > > > > v37-0003-Tests-for-FOR-ALL-TABLES-IN-SCHEMA-publication > > 3. > > --- a/src/bin/pg_dump/t/002_pg_dump.pl > > +++ b/src/bin/pg_dump/t/002_pg_dump.pl > > .. > > +

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

At Mon, 11 Oct 2021 15:24:46 +0900, Fujii Masao wrote in > > > On 2021/10/09 22:22, Bharath Rupireddy wrote: > > Hi, > > It looks like auxiliary processes will not have a valid MyBackendId as > > they don't call InitPostgres() and SharedInvalBackendInit() unlike > > backends. But the startup p

RE: Added schema level support for publication.

On Monday, October 11, 2021 2:39 PM vignesh C wrote: > > These comments are fixed in the v38 patch attached. Thanks for updating the patches. Here are a few comments on the v38-0004-Doc patch. 1. + + Adding/Setting a table that is part of schema specified in + ALL TABLES IN SCHEMA, adding

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

On Mon, Oct 11, 2021 at 11:37 AM Fujii Masao wrote: > On 2021/10/10 22:33, Bharath Rupireddy wrote: > >>> IIUC, the "server crash" includes any backend, auxiliary process, > >>> postmaster crash i.e. database cluster/instance crash. The commit > >>> cd91de0d1 especially added the temp file cleanup

RE: Skipping logical replication transactions on subscriber side

On Monday, October 11, 2021 11:51 AM Masahiko Sawada wrote: > On Fri, Oct 8, 2021 at 4:09 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

Re: Skipping logical replication transactions on subscriber side

On Sun, Oct 10, 2021 at 11:04 PM Peter Eisentraut wrote: > > On 04.10.21 02:31, Masahiko Sawada wrote: > > I guess disabling subscriptions on error/conflict and skipping the > > particular transactions are somewhat different types of functions. > > Disabling subscriptions on error/conflict seems l

Re: Added schema level support for publication.

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 HEAD as at about October 6). Regards, Greg Nancarrow Fujitsu Australia

Drop replslot after pgstat_shutdown cause assert coredump

Hi, When testing logical replication, I found a case which caused assert coredump on latest HEAD. The reproduction steps are as follows: 1) publisher create table test(i int); create publication pub for table test; begin; insert into test values(1); 2) subscriber create table te

postgres_fdw: misplaced? comments in connection.c

Hi, 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 entire toplevel transaction even if subtransactions * we

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

On Sun, Oct 10, 2021 at 8:00 PM Tom Lane wrote: > =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes: > > curculio: Is not able to connect to https://git.postgresql.org due to > > the Let's Encrypt expired CA. > > We're working on fixing things so that git.postgresql.org will > advertise a cert chain tha

Re: storing an explicit nonce

On 2021/10/6 23:01, Robert Haas wrote: > This seems wrong to me. CTR requires that you not reuse the IV. If you > re-encrypt the page with a different IV, torn pages are a problem. If > you re-encrypt it with the same IV, then it's not secure any more. for CBC if the IV is predictable will case "

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

On Mon, Oct 11, 2021 at 12:50:28PM +0530, Bharath Rupireddy wrote: > I noticed another thing that the remove_temp_files_after_crash is > categorized as DEVELOPER_OPTIONS, shouldn't it be under > RESOURCES_DISK? See here: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=797b0fc0b078c7

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

On Mon, Oct 11, 2021 at 2:53 PM Justin Pryzby wrote: > > On Mon, Oct 11, 2021 at 12:50:28PM +0530, Bharath Rupireddy wrote: > > I noticed another thing that the remove_temp_files_after_crash is > > categorized as DEVELOPER_OPTIONS, shouldn't it be under > > RESOURCES_DISK? > > See here: > https://

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

Hi! It seems like this patch causes another problem. If I explain a simple row generator **without** verbose, it fails: postgres=# EXPLAIN (VERBOSE FALSE) WITH RECURSIVE gen (n) AS ( VALUES (1) UNION ALL SELECT n+1 FR

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

On Mon, Oct 11, 2021 at 12:41 PM Kyotaro Horiguchi wrote: > > > > These are the following ways I think we can fix it, if at all some > > > other hacker agrees that it is actually an issue: > > > 1) Fix the startup process code, probably by unregistering the > > > procsignal array entry that was ma

Re: Multi-Column List Partitioning

Hi Nitin, While testing further I got a crash with partition wise join enabled for multi-col list partitions. please find test case & stack-trace below. SET enable_partitionwise_join TO on; CREATE TABLE plt1 (c varchar, d varchar) PARTITION BY LIST(c,d); CREATE TABLE plt1_p1 PARTITION OF plt1 FOR

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

On Mon, Oct 11, 2021 at 11:54 AM Fujii Masao wrote: > > How about modifying SharedInvalBackendInit() so that it accepts > BackendId as an argument and allocates the ProcState entry of > the specified BackendId? That is, the startup process determines > that its BackendId is "MaxBackends + MyAuxPro

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

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 snapshot can not cross the > "GetMaxSnapshotXidCount()"?. > > Basically, while converting the HISTORIC snapshot to the MVCC snapshot > in "Sn

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

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 snapshot can not cross the > > "GetMaxSnapshotXidCount()"?. > > > > Basical

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

On 10/10/21 10:07 AM, Peter Eisentraut wrote: > On 03.10.21 09:03, Michael Paquier wrote: >> On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote: >>> Maybe we could leave test.sh in place for awhile?  I'd rather >>> not cause a flag day for buildfarm owners.  (Also, how do we >>> see this wo

Re: Drop replslot after pgstat_shutdown cause assert coredump

On Mon, Oct 11, 2021 at 6:55 PM houzj.f...@fujitsu.com wrote: > > I can see the walsender tried to release a not-quite-ready repliaction slot > that was created when create a subscription. But the pgstat has been shutdown > before invoking ReplicationSlotRelease(). > > The stack is as follows: > >

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

> 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

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

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

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

  1   2   >