Re: [17] Special search_path names "!pg_temp" and "!pg_catalog"

Hi pá 18. 8. 2023 v 23:44 odesílatel Jeff Davis napsal: > The attached patch adds some special names to prevent pg_temp and/or > pg_catalog from being included implicitly. > > This is a useful safety feature for functions that don't have any need > to search pg_temp. > > The current (v16)

Re: Ignore 2PC transaction GIDs in query jumbling

On Fri, Aug 18, 2023 at 11:31:03AM +0100, Dagfinn Ilmari Mannsåker wrote: > I don't have a particularly strong opinion on whether we should > distinguish DEALLOCATE ALL from DEALLOCATE (call it +0.5), but The difference looks important to me, especially for monitoring. And pgbouncer may also use

Re: pg_upgrade fails with in-place tablespace

On Fri, Aug 18, 2023 at 10:47:04PM +0800, Rui Zhao wrote: > I have implemented the changes you suggested in our previous > discussion. I have added the necessary code to ensure that > pg_upgrade fails gracefully with in-place tablespaces and reports a > hint to let the check pass. + /* +

Re: [PATCH] Add function to_oct

On Thu, Aug 17, 2023 at 10:26 PM Nathan Bossart wrote: > > On Thu, Aug 17, 2023 at 12:35:54PM +0700, John Naylor wrote: > > That makes it a lexically-scoped global variable, which we don't need > > either. Can we have the internal function allocate on the stack, then > > call cstring_to_text() on

Re: PG 16 draft release notes ready

I posted to pgsql-docs first, but was kindly redirected here by Jonathan: The release notes for Postgres 16 says here: https://www.postgresql.org/docs/16/release-16.html#RELEASE-16-PERFORMANCE Same as here: https://momjian.us/pgsql_docs/release-16.html#RELEASE-16-PERFORMANCE Allow window

Re: Use of additional index columns in rows filtering

On Tue, Aug 8, 2023 at 11:36 AM Peter Geoghegan wrote: > > The only thing the patch does is it looks at clauses we decided not to > > treat as index quals, and do maybe still evaluate them on index. And I > > don't think I want to move these goalposts much further. > > Avoiding the need for

Re: Use of additional index columns in rows filtering

On Thu, Aug 17, 2023 at 4:29 PM Jeff Davis wrote: > On Wed, 2023-08-09 at 17:14 -0700, Peter Geoghegan wrote: > > + Index quals are better than equivalent index filters because bitmap > > index scans can only use index quals > > It seems there's consensus that: > > * Index Filters (Tomas's

[17] Special search_path names "!pg_temp" and "!pg_catalog"

The attached patch adds some special names to prevent pg_temp and/or pg_catalog from being included implicitly. This is a useful safety feature for functions that don't have any need to search pg_temp. The current (v16) recommendation is to include pg_temp last, which does add to the safety, but

Re: Extract numeric filed in JSONB more effectively

On 2023-08-18 15:08, Chapman Flack wrote: But I don't know that adding relabel nodes wouldn't still be the civilized thing to do. Interestingly, when I relabel both places, like this: Oid targetOid = fexpr->funcresulttype; Const *target = makeConst( OIDOID, -1, InvalidOid,

Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }

On Fri, 2023-08-18 at 14:25 +0200, Peter Eisentraut wrote: > > Not specifying SEARCH would have the same issue? Not specifying SEARCH is equivalent to SEARCH DEFAULT, and that gives us some control over what happens. In the proposed patch, a GUC determines whether it behaves like SEARCH SESSION

Re: Extract numeric filed in JSONB more effectively

On 2023-08-18 14:50, Chapman Flack wrote: Now, my guess is EXPLAIN is complaining when it sees the Const of type internal, and doesn't know how to show that value. Perhaps makeRelabelType is the answer there, too: what if the Const has Oid type, so EXPLAIN can show it, and what's inserted as the

Re: Extract numeric filed in JSONB more effectively

On 2023-08-18 03:41, Andy Fan wrote: I just have a quick hack on this, and crash happens at the simplest case. If I build from this patch, this test: SELECT (test_json -> 0)::int4, test_json -> 0 FROM test_jsonb WHERE json_type = 'scalarint'; fails like this: Program received signal

Re: pgbench - adding pl/pgsql versions of tests

I will address the comments here over this coming weekend. I think that in addition to current "tpc-b like" test we could also have more modern "tpc-c like" and "tpc-h like" tests And why not any other "* -like" from the rest of TPC-*, YCSP, sysbench, ... :) though maybe not as part of

Re: SLRUs in the main buffer pool - Page Header definitions

On Fri, Aug 18, 2023 at 08:12:41AM +, Bagga, Rishu wrote: > * Frost, Stephen (sfrowt(at)snowman(dot)net) wrote: >> Haven't really looked over the patches yet but I wanted to push back >> on this a bit- you're suggesting that we'd continue to maintain and >> update slru.c for the benefit of

Re: should frontend tools use syncfs() ?

On Thu, Aug 17, 2023 at 12:50:31PM +0900, Michael Paquier wrote: > On Wed, Aug 16, 2023 at 08:17:05AM -0700, Nathan Bossart wrote: >> The patch does have the following note: >> >> +On Linux, syncfs may be used instead to ask the >> +operating system to synchronize the whole file

Re: pg_upgrade fails with in-place tablespace

On Wed, Aug 09, 2023 at 09:20 AM +0800, Michael Paquier wrote: > This does not really explain the reason why in-place tablespaces need > to be skipped (in short they don't need a separate creation or check > like the others in create_script_for_old_cluster_deletion because they > are part of the

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

Dear Peter, PSA new version patch set. > Here are some review comments for the patch v21-0003 > > == > Commit message > > 1. > pg_upgrade fails if the old node has slots which status is 'lost' or they do > not > consume all WAL records. These are needed for prevent the data loss. > > ~ >

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

Dear Peter, Thanks for reviewing! > For patch v21-0001... > > == > 1. SaveSlotToPath > > - /* and don't do anything if there's nothing to write */ > - if (!was_dirty) > + /* > + * and don't do anything if there's nothing to write, unless it's this is > + * called for a logical slot during

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

Dear Amit, > > Few minor comments > 1. Why the patch updates the slots info at the end of > create_logical_replication_slots()? Can you please update the comments > for the same? I checked and agreed that it was not needed. More detail, please see [1]. > 2. > @@ -36,6 +36,7 @@

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

Dear Hou, Thank you for reviewing! > +static void > +create_logical_replication_slots(void) > ... > + query = createPQExpBuffer(); > + escaped = createPQExpBuffer(); > + conn = connectToServer(_cluster, old_db->db_name); > > Since the connection here is not

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

Dear Amit, > I was thinking whether we can go a step ahead and remove this variable > altogether. In old cluster handling, we can get and check together at > the same place and for the new cluster, if we have a function that > returns slot_count by traversing old clusterinfo that should be >

Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }

On 16.08.23 19:44, Jeff Davis wrote: On Wed, 2023-08-16 at 08:51 +0200, Peter Eisentraut wrote: On 12.08.23 04:35, Jeff Davis wrote: The attached patch implements a new SEARCH clause for CREATE FUNCTION. The SEARCH clause controls the search_path used when executing functions that were created

Re: Allow parallel plan for referential integrity checks?

On Thu, Aug 17, 2023 at 3:51 PM Frédéric Yhuel wrote: > On 8/17/23 14:00, Frédéric Yhuel wrote: > > On 8/17/23 09:32, Frédéric Yhuel wrote: > >> On 8/10/23 17:06, Juan José Santamaría Flecha wrote: > >>> Recently I restored a database from a directory format backup and > >>> having this feature

Re: logical decoding and replication of sequences, take 2

On Fri, Aug 18, 2023 at 10:37 AM Amit Kapila wrote: > > On Thu, Aug 17, 2023 at 7:13 PM Ashutosh Bapat > wrote: > > > > On Wed, Aug 16, 2023 at 7:56 PM Tomas Vondra > > wrote: > > > > > > > > > > > But whether or not that's the case, downstream should not request (and > > > > hence receive) any

Re: Ignore 2PC transaction GIDs in query jumbling

Michael Paquier writes: > On Tue, Aug 15, 2023 at 08:49:37AM +0900, Michael Paquier wrote: >> Hmm. One issue with the patch is that we finish by considering >> DEALLOCATE ALL and DEALLOCATE $1 as the same things, compiling the >> same query IDs. The difference is made in the Nodes by assigning

Re: WIP: new system catalog pg_wait_event

On Fri, Aug 18, 2023 at 10:56:55AM +0200, Drouvot, Bertrand wrote: > Okay, using the plural form in v8 attached. Noting in passing: - Here is an example of how wait events can be viewed: + Here is are examples of how wait events can be viewed: s/is are/are/. -- Michael signature.asc

Re: WIP: new system catalog pg_wait_event

On Fri, Aug 18, 2023 at 10:57:28AM +0200, Drouvot, Bertrand wrote: > I did use "defined by an extension module" in v8 (also that's aligned with > the wording used in wait_event.h). WFM. -- Michael signature.asc Description: PGP signature

PostgreSQL 17 alpha RPMs

Hi hackers, Just a FYI: Started building daily snapshot RPMs using the tarball at: https://download.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2 Packages are available on these platforms: * RHEL 9 (x86_64 & aarch64) * RHEL 8 (x86_64, aarch64 and ppc64le) * Fedora 38 (x86_64) *

[dsm] comment typo

In the following sentence, I believe either 'the' or 'a' should be kept, not both. I here keep the 'the', but feel free to change. --- src/backend/storage/ipc/dsm_impl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/storage/ipc/dsm_impl.c

Re: WIP: new system catalog pg_wait_event

Hi, On 8/18/23 12:37 AM, Michael Paquier wrote: On Thu, Aug 17, 2023 at 04:37:22PM +0900, Masahiro Ikeda wrote: On 2023-08-17 14:53, Drouvot, Bertrand wrote: BTW, is it better to start with "Waiting" like any other lines? For example, "Waiting for custom event \"worker_spi_main\" defined by an

Re: WIP: new system catalog pg_wait_event

Hi, On 8/17/23 9:37 AM, Masahiro Ikeda wrote: Hi, On 2023-08-17 14:53, Drouvot, Bertrand wrote: The followings are additional comments for v7. 1) I am not sure that "pg_wait_event" is a good idea for the name if the new view.  How about "pg_wait_events" instead, in plural form?  There is

Re: Remove distprep

Re: Michael Paquier > This one comes down to Debian that patches autoconf with its own set > of options, requiring a new ./configure in the tree, right? Yes, mostly. Since autoconf had not seen a new release for so long, everyone started to patch it, and one of the things that Debian and others

RE: Adding a LogicalRepWorker type field

On Friday, August 18, 2023 11:20 AM Amit Kapila wrote: > > On Mon, Aug 14, 2023 at 12:08 PM Peter Smith > wrote: > > > > The main patch for adding the worker type enum has been pushed [1]. > > > > Here is the remaining (rebased) patch for changing some previous > > cascading if/else to switch

Re: Extract numeric filed in JSONB more effectively

> because as long as it has parameters declared internal, > no SQL can ever call it. I was confused about the difference between anyelement and internal, and I want to know a way to create a function which is disallowed to be called by the user. Your above words resolved two questions of mine!

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

On Fri, Aug 18, 2023 at 12:47 PM Amit Kapila wrote: > > On Thu, Aug 17, 2023 at 2:10 PM Peter Smith wrote: > > > > Here are some review comments for the first 2 patches. > > > > /* > > - * Fetch all libraries containing non-built-in C functions in this DB. > > + * Fetch all libraries

Re: pg_rewind WAL segments deletion pitfall

On 2022-09-29 17:18, Polina Bungina wrote: I agree with your suggestions, so here is the updated version of patch. Hope I haven't missed anything. Thanks for the patch, I've marked this as ready-for-committer. BTW, this issue can be considered a bug, right? I think it would be appropriate to

Re: dubious warning: FORMAT JSON has no effect for json and jsonb types

On 16.08.23 16:59, Merlin Moncure wrote: On Wed, Aug 16, 2023 at 8:55 AM Peter Eisentraut > wrote: This warning comes from parse_expr.c transformJsonValueExpr() and is triggered for example by the following test case: SELECT JSON_OBJECT('foo':