Re: Add TLI number to name of files generated by pg_waldump --save-fullpage

On Tue, Jun 27, 2023 at 03:44:04PM +0900, Kyotaro Horiguchi wrote: > +# - Timeline number in hex format. > > Arn't we reffering to it as "Timeline ID"? (I remember there was a > discussion about redefining the "timeline ID" to use non-orderable > IDs. That is, making it non-numbers.) Using ID is

Re: bgwriter doesn't flush WAL stats

Hi, Created a commitfest entry for this. Link: https://commitfest.postgresql.org/43/4405/ Regards, Nazir Bilal Yavuz Microsoft On Thu, 22 Jun 2023 at 17:03, Melanie Plageman wrote: > On Wed, Jun 21, 2023 at 9:49 PM Kyotaro Horiguchi > wrote: > > Regarding the second patch, it introduces WAL I

Re: Add TLI number to name of files generated by pg_waldump --save-fullpage

At Tue, 27 Jun 2023 15:12:43 +0900, Michael Paquier wrote in > Hi all, > (Fujii-san and David in CC.) > > Fujii-san has reported on Twitter that we had better add the TLI > number to what pg_waldump --save-fullpage generates for the file names > of the blocks, as it could be possible that we ov

Re: Add GUC to tune glibc's malloc implementation.

Le mardi 27 juin 2023, 08:35:28 CEST Ronan Dunklau a écrit : > I re-attached the simple script I used. I've run this script with different > values for glibc_malloc_max_trim_threshold. I forgot to add that it was using default parametrers except for work_mem, set to 32M, and max_parallel_workers_

Re: Add GUC to tune glibc's malloc implementation.

Le lundi 26 juin 2023, 23:03:48 CEST Andres Freund a écrit : > Hi, > > On 2023-06-26 08:38:35 +0200, Ronan Dunklau wrote: > > I hope what I'm trying to achieve is clearer that way. Maybe this patch is > > not the best way to go about this, but since the memory allocator > > behaviour can have such

Re: ReadRecentBuffer() doesn't scale well

Hi, On 2023-06-26 21:53:12 -0700, Peter Geoghegan wrote: > It should be safe to allow searchers to see a version of the root page > that is out of date. The Lehman & Yao design is very permissive about > these things. There aren't any special cases where the general rules > are weakened in some wa

Re: Clean up JumbleQuery() from query text

On Mon, Jun 26, 2023 at 08:51:17AM -0700, Nathan Bossart wrote: > On Mon, Jun 26, 2023 at 05:44:49PM +0900, Michael Paquier wrote: >> It is not urgent, so I am fine to postpone that after beta2 is >> released on 17~ if there are any objections to that, of course. > > Even if extensions are using i

Add TLI number to name of files generated by pg_waldump --save-fullpage

Hi all, (Fujii-san and David in CC.) Fujii-san has reported on Twitter that we had better add the TLI number to what pg_waldump --save-fullpage generates for the file names of the blocks, as it could be possible that we overwrite some blocks. This information can be added thanks to ws_tli, that tr

Re: [PATCH] Honor PG_TEST_NOCLEAN for tempdirs

> On 27 Jun 2023, at 07:47, Michael Paquier wrote: > > On Mon, Jun 26, 2023 at 04:55:47PM -0700, Jacob Champion wrote: >> I was running the test_pg_dump extension suite, and I got annoyed that >> I couldn't keep it from deleting its dump artifacts after a successful >> run. Here's a patch to make

Re: logical decoding and replication of sequences, take 2

On Mon, Jun 26, 2023 at 8:35 PM Tomas Vondra wrote: > > > > On 6/26/23 15:18, Ashutosh Bapat wrote: > > This is review of 0003 patch. Overall the patch looks good and helps > > understand the decoding logic better. > > > > + data > > +--

Re: [PATCH] Honor PG_TEST_NOCLEAN for tempdirs

On Mon, Jun 26, 2023 at 04:55:47PM -0700, Jacob Champion wrote: > I was running the test_pg_dump extension suite, and I got annoyed that > I couldn't keep it from deleting its dump artifacts after a successful > run. Here's a patch to make use of PG_TEST_NOCLEAN (which currently > covers the test c

Re: ReadRecentBuffer() doesn't scale well

Hi, On 2023-06-27 16:40:08 +1200, Thomas Munro wrote: > On Tue, Jun 27, 2023 at 4:32 PM Peter Geoghegan wrote: > > On Mon, Jun 26, 2023 at 9:09 PM Andres Freund wrote: > > > I think we should be able to have a post-check that can figure out > > > if the copied root page is out of date after sear

Re: Assert !bms_overlap(joinrel->relids, required_outer)

On Mon, Jun 26, 2023 at 11:05:43PM -0500, Jaime Casanova wrote: > The attached query makes beta2 crash with attached backtrace. > Interestingly the index on ref_6 is needed to make it crash, without > it the query works fine. Issue reproduced here. I am adding an open item, whose owner should be

Re: ReadRecentBuffer() doesn't scale well

On Tue, Jun 27, 2023 at 4:53 PM Peter Geoghegan wrote: > On Mon, Jun 26, 2023 at 9:40 PM Thomas Munro wrote: > > If the goal is to get rid of both pins and content locks, LSN isn't > > enough. A page might be evicted and replaced by another page that has > > the same LSN because they were modifi

Re: Improving btree performance through specializing by key shape, take 2

On Tue, Jun 27, 2023 at 9:42 AM Dilip Kumar wrote: > > On Fri, Jun 23, 2023 at 8:16 PM Matthias van de Meent > wrote: > > > > On Fri, 23 Jun 2023 at 11:26, Dilip Kumar wrote: > > > > > > and I have one confusion in the > > > below hunk in the _bt_moveright function, basically, if the parent > >

Re: ReadRecentBuffer() doesn't scale well

On Mon, Jun 26, 2023 at 9:40 PM Thomas Munro wrote: > If the goal is to get rid of both pins and content locks, LSN isn't > enough. A page might be evicted and replaced by another page that has > the same LSN because they were modified by the same record. Maybe > that's vanishingly rare, but the

Re: ReadRecentBuffer() doesn't scale well

On Tue, Jun 27, 2023 at 4:32 PM Peter Geoghegan wrote: > On Mon, Jun 26, 2023 at 9:09 PM Andres Freund wrote: > > I think we should be able to have a post-check that can figure out > > if the copied root page is out of date after searching it, without needing > > the > > content lock. > > I'm gu

Re: ReadRecentBuffer() doesn't scale well

On Mon, Jun 26, 2023 at 9:09 PM Andres Freund wrote: > I think we should be able to have a post-check that can figure out > if the copied root page is out of date after searching it, without needing the > content lock. I'm guessing that you're thinking of doing something with the page LSN? -- P

Incorrect comment for memset() on pgssHashKey?

Hi, Commit 6b4d23feef introduces a toplevel field in pgssHashKey, which leads padding. In pgss_store(), it comments that memset() is required when pgssHashKey is without padding only. @@ -1224,9 +1227,14 @@ pgss_store(const char *query, uint64 queryId, query = CleanQuerytext(query, &query_

Re: Improving btree performance through specializing by key shape, take 2

On Fri, Jun 23, 2023 at 8:16 PM Matthias van de Meent wrote: > > On Fri, 23 Jun 2023 at 11:26, Dilip Kumar wrote: > > > and I have one confusion in the > > below hunk in the _bt_moveright function, basically, if the parent > > page's right key is exactly matching the HIGH key of the child key >

Re: ReadRecentBuffer() doesn't scale well

Hi, On 2023-06-27 15:33:57 +1200, Thomas Munro wrote: > On Tue, Jun 27, 2023 at 2:05 PM Andres Freund wrote: > > Unfortunately it scaled way worse at first. This is not an inherent issue, > > but > > due to an implementation choice in ReadRecentBuffer(). Whereas the normal > > BufferAlloc() pat

Assert !bms_overlap(joinrel->relids, required_outer)

Hi, The attached query makes beta2 crash with attached backtrace. Interestingly the index on ref_6 is needed to make it crash, without it the query works fine. -- Jaime Casanova Director de Servicios Profesionales SYSTEMGUARDS - Consultores de PostgreSQL #0 __GI_raise (sig=sig@entry=6) at ../sy

Re: ReadRecentBuffer() doesn't scale well

On Mon, Jun 26, 2023 at 8:34 PM Thomas Munro wrote: > Yeah. Aside from inherent nastiness of user-space spinlocks, this new > use case is also enormously more likely to contend and then get into > trouble by being preempted due to btree root pages being about the > hottest pages in the universe t

Re: ReadRecentBuffer() doesn't scale well

On Tue, Jun 27, 2023 at 2:05 PM Andres Freund wrote: > As mentioned nearby [1], Thomas brought up [2] the idea of using > ReadRecentBuffer() _bt_getroot(). I couldn't resist and prototyped it. Thanks! > Unfortunately it scaled way worse at first. This is not an inherent issue, but > due to an i

Re: Add some more corruption error codes to relcache

On Fri, Jun 16, 2023 at 9:18 AM Andrey M. Borodin wrote: > Hi hackers, > > Relcache errors from time to time detect catalog corruptions. For example, > recently I observed following: > 1. Filesystem or nvme disk zeroed out leading 160Kb of catalog index. This > type of corruption passes through d

Re: Do we want a hashset type?

On Tue, Jun 27, 2023 at 4:55 AM Joel Jacobson wrote: > > On Mon, Jun 26, 2023, at 13:06, jian he wrote: > > Can you try to glue the attached to the hashset data type input > > function. > > the attached will parse cstring with double quote and not. so '{1,2,3}' > > == '{"1","2","3"}'. obviously qu

ReadRecentBuffer() doesn't scale well

Hi, As mentioned nearby [1], Thomas brought up [2] the idea of using ReadRecentBuffer() _bt_getroot(). I couldn't resist and prototyped it. Unfortunately it scaled way worse at first. This is not an inherent issue, but due to an implementation choice in ReadRecentBuffer(). Whereas the normal Bu

False sharing for PgBackendStatus, made worse by in-core query_id handling

Hi, On Twitter Thomas thoroughly nerdsniped me [1]. As part of that I ran a concurrent readonly pgbench workload and analyzed cacheline "contention" using perf c2c. One of the cacheline conflicts, by far not the most common, but significant, is one I hadn't noticed in the past. The cacheline acce

RE: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL

> Please see attched script to reproduce that. The final DELETE statement cannot > be > replicated at the subscriber on my env. Sorry, I forgot to attach... Best Regards, Hayato Kuroda FUJITSU LIMITED test_point.sh Description: test_point.sh

Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL

On Mon, Jun 26, 2023 at 11:44 PM Hayato Kuroda (Fujitsu) wrote: ... > BTW, I have doubt that the restriction is not related with your commit. > In other words, if the table has attributes which the datatype is not for > operator > class of Btree, we could not use REPLICA IDENTITY FULL. IIUC it is

Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL

On Thu, Jun 22, 2023 at 11:37 AM Hayato Kuroda (Fujitsu) wrote: > > Dear hackers, > (CC: Önder because he owned the related thread) > ... > The current patch only includes tests for hash indexes. These are separated > into > the file 032_subscribe_use_index.pl for convenience, but will be integra

[PATCH] Honor PG_TEST_NOCLEAN for tempdirs

Hello, I was running the test_pg_dump extension suite, and I got annoyed that I couldn't keep it from deleting its dump artifacts after a successful run. Here's a patch to make use of PG_TEST_NOCLEAN (which currently covers the test cluster's base directory) with the Test::Utils tempdirs too. (Lo

Re: Fixing tab-complete for dollar-names

On 6/26/23 22:10, Mikhail Gribkov wrote: Hi hackers, As not much preliminary interest seem to be here, I'm sending the patch to the upcoming commitfest I have added myself as reviewer. I already had taken a look at it, and it seemed okay, but I have not yet searched for corner cases. -- Vik

Re: Row pattern recognition

On 6/26/23 03:05, Tatsuo Ishii wrote: I don't understand this. RPR in a window specification limits the window to the matched rows, so this looks like your rpr() function is just the regular first_value() window function that we already have? No, rpr() is different from first_value(). rpr() re

Re: Do we want a hashset type?

On Mon, Jun 26, 2023 at 4:55 PM Joel Jacobson wrote: > On Mon, Jun 26, 2023, at 13:06, jian he wrote: > > Can you try to glue the attached to the hashset data type input > > function. > > the attached will parse cstring with double quote and not. so '{1,2,3}' > > == '{"1","2","3"}'. obviously quo

Re: Improve comment on cid mapping (was Re: Adding CommandID to heap xlog records)

Hi, On 2023-06-26 09:57:56 +0300, Heikki Linnakangas wrote: > diff --git a/src/backend/replication/logical/snapbuild.c > b/src/backend/replication/logical/snapbuild.c > index 0786bb0ab7..e403feeccd 100644 > --- a/src/backend/replication/logical/snapbuild.c > +++ b/src/backend/replication/logical/

Re: Optimize walsender handling invalid messages of 'drop publication'

Hi, On 2023-06-26 15:01:22 +0800, Bowen Shi wrote: > This issue has been pending for several months without any response. > And this problem still exists in the latest minor versions of PG 12 > and PG 13. > > I believe that the fix in this patch is helpful. > > The patch has been submitted > https

Re: Add GUC to tune glibc's malloc implementation.

Hi, On 2023-06-26 08:38:35 +0200, Ronan Dunklau wrote: > I hope what I'm trying to achieve is clearer that way. Maybe this patch is not > the best way to go about this, but since the memory allocator behaviour can > have such an impact it's a bit sad we have to leave half the performance on > the

Re: Add GUC to tune glibc's malloc implementation.

Hi, On 2023-06-22 15:35:12 +0200, Ronan Dunklau wrote: > This can cause problems. Let's take for example a table with 10k rows, and 32 > columns (as defined by a bench script David Rowley shared last year when > discussing the GenerationContext for tuplesort), and execute the following > query,

Re: Do we want a hashset type?

On Mon, Jun 26, 2023, at 13:06, jian he wrote: > Can you try to glue the attached to the hashset data type input > function. > the attached will parse cstring with double quote and not. so '{1,2,3}' > == '{"1","2","3"}'. obviously quote will preserve the inner string as > is. > currently int4has

Re: Analyze on table creation?

On Mon, Jun 26, 2023 at 4:00 PM Andres Freund wrote: > > Hi, > > On 2023-06-26 13:40:49 -0400, James Coleman wrote: > > Have we ever discussed running an analyze immediately after creating a > > table? > > That doesn't make a whole lot of sense to me - we could just insert the > constants stats w

Re: Stampede of the JIT compilers

Hi, On 2023-06-24 13:54:53 -0400, Tom Lane wrote: > I think there is *plenty* of evidence that it is too low, or at least > that for some reason we are too willing to invoke JIT when the result > is to make the overall cost of a query far higher than it is without. > Just see all the complaints on

Re: Fixing tab-complete for dollar-names

Hi hackers, As not much preliminary interest seem to be here, I'm sending the patch to the upcoming commitfest -- best regards, Mikhail A. Gribkov On Sat, Jun 17, 2023 at 12:51 AM Mikhail Gribkov wrote: > Hi hackers, > > In modern versions of Postgres the dollar sign is a totally legal >

Re: Analyze on table creation?

Hi, On 2023-06-26 13:40:49 -0400, James Coleman wrote: > Have we ever discussed running an analyze immediately after creating a table? That doesn't make a whole lot of sense to me - we could just insert the constants stats we wanted in that case. > Consider the following: > > create table stat

Detecting use-after-free bugs using gcc's malloc() attribute

Hi, I played around with adding __attribute__((malloc(free_func), malloc(another_free_func))) annotations to a few functions in pg. See https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html Adding them to pg_list.h seems to have found two valid issues when compiling without optimi

Re: Analyze on table creation?

> > > > > Originally, until the table had minimally one row, the PostgreSQL > calculated with 10 pages. It was fixed (changed) in PostgreSQL 14. > > > > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3d351d916b20534f973eda760cde17d96545d4c4 > > > > From that commit message: >

Re: psql: Add role's membership options to the \du+ command

Please find attached new patch version. It implements \drg command and hides duplicates in \du & \dg commands. -- Pavel Luzanov Postgres Professional: https://postgrespro.com From a117f13fd497bf6ff8a504bcda6cb10d34dd22a7 Mon Sep 17 00:00:00 2001 From: Pavel Luzanov Date: Mon, 26 Jun 2023 22:10:3

Re: Analyze on table creation?

cc'ing Tom because I'm curious if he's willing to provide some greater context on the commit in question. On Mon, Jun 26, 2023 at 2:16 PM Pavel Stehule wrote: > > > > po 26. 6. 2023 v 19:48 odesílatel James Coleman napsal: >> >> On Mon, Jun 26, 2023 at 1:45 PM Pavel Stehule >> wrote: >> > >> >

Re: Analyze on table creation?

po 26. 6. 2023 v 19:48 odesílatel James Coleman napsal: > On Mon, Jun 26, 2023 at 1:45 PM Pavel Stehule > wrote: > > > > > > > > po 26. 6. 2023 v 19:43 odesílatel Pavel Stehule > napsal: > >> > >> Hi > >> > >> po 26. 6. 2023 v 19:41 odesílatel James Coleman > napsal: > >>> > >>> Hello, > >>> >

Re: Problems with estimating OR conditions, IS NULL on LEFT JOINs

Hi, all! On 24.06.2023 14:23, Tomas Vondra wrote: On 6/24/23 02:08, Tom Lane wrote: Tomas Vondra writes: The problem is that the selectivity for "IS NULL" is estimated using the table-level statistics. But the LEFT JOIN entirely breaks the idea that the null_frac has anything to do with NULLs

Re: Analyze on table creation?

On Mon, Jun 26, 2023 at 1:45 PM Pavel Stehule wrote: > > > > po 26. 6. 2023 v 19:43 odesílatel Pavel Stehule > napsal: >> >> Hi >> >> po 26. 6. 2023 v 19:41 odesílatel James Coleman napsal: >>> >>> Hello, >>> >>> Have we ever discussed running an analyze immediately after creating a >>> table?

Re: Analyze on table creation?

po 26. 6. 2023 v 19:43 odesílatel Pavel Stehule napsal: > Hi > > po 26. 6. 2023 v 19:41 odesílatel James Coleman napsal: > >> Hello, >> >> Have we ever discussed running an analyze immediately after creating a >> table? >> >> Consider the following: >> >> create table stats(i int, t text not nul

Re: Analyze on table creation?

Hi po 26. 6. 2023 v 19:41 odesílatel James Coleman napsal: > Hello, > > Have we ever discussed running an analyze immediately after creating a > table? > > Consider the following: > > create table stats(i int, t text not null); > explain select * from stats; >Seq Scan on stats (cost=0.00..2

Analyze on table creation?

Hello, Have we ever discussed running an analyze immediately after creating a table? Consider the following: create table stats(i int, t text not null); explain select * from stats; Seq Scan on stats (cost=0.00..22.70 rows=1270 width=36 analyze stats; explain select * from stats; Seq Scan

Re: pgbnech: allow to cancel queries during benchmark

On Mon, Jun 26, 2023 at 9:46 AM Yugo NAGATA wrote: > Hello, > > This attached patch enables pgbench to cancel queries during benchmark. > > Formerly, Ctrl+C during benchmark killed pgbench immediately, but backend > processes executing long queries remained for a while. You can simply > reproduce

Re: Clean up JumbleQuery() from query text

On Mon, Jun 26, 2023 at 05:44:49PM +0900, Michael Paquier wrote: > Joe has reported me offlist that JumbleQuery() includes a dependency > to the query text, but we don't use that anymore as the query ID is > generated from the Query structure instead. > > Any thoughts about the cleanup attached?

Re: ​function arguments are not PG_FUNCTION_ARGS, how to pass Node *escontext

On 2023-06-26 Mo 09:45, jian he wrote: On Mon, Jun 26, 2023 at 9:32 PM jian he wrote: > > On Mon, Jun 26, 2023 at 7:50 PM Andrew Dunstan wrote: > > > > > > On 2023-06-26 Mo 07:20, jian he wrote: > > > > static > > Datum return_numeric_datum(char *token) > > { > >     Datum   numd; > >  

Re: logical decoding and replication of sequences, take 2

On 6/26/23 15:18, Ashutosh Bapat wrote: > This is review of 0003 patch. Overall the patch looks good and helps > understand the decoding logic better. > > + data > +

Changing types of block and chunk sizes in memory contexts

Hi hackers, In memory contexts, block and chunk sizes are likely to be limited by some upper bounds. Some examples of those bounds can be MEMORYCHUNK_MAX_BLOCKOFFSET and MEMORYCHUNK_MAX_VALUE. Both values are only 1 less than 1GB. This makes memory contexts to have blocks/chunks with sizes less th

pgbnech: allow to cancel queries during benchmark

Hello, This attached patch enables pgbench to cancel queries during benchmark. Formerly, Ctrl+C during benchmark killed pgbench immediately, but backend processes executing long queries remained for a while. You can simply reproduce this problem by cancelling the pgbench running a custom script e

Re: ​function arguments are not PG_FUNCTION_ARGS, how to pass Node *escontext

On Mon, Jun 26, 2023 at 9:32 PM jian he wrote: > > On Mon, Jun 26, 2023 at 7:50 PM Andrew Dunstan wrote: > > > > > > On 2023-06-26 Mo 07:20, jian he wrote: > > > > static > > Datum return_numeric_datum(char *token) > > { > > Datum numd; > > Node*escontext; > > > > if (!DirectInp

RE: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL

Dear Önder, Thank you for giving comments! The author's comment is quite helpful for us. > When I last dealt with the same issue, I was examining it from a slightly broader perspective. I think my conclusion was that RelationFindReplTupleByIndex() is designed for the constraints of UNIQUE INDEX

Re: ​function arguments are not PG_FUNCTION_ARGS, how to pass Node *escontext

On Mon, Jun 26, 2023 at 7:50 PM Andrew Dunstan wrote: > > > On 2023-06-26 Mo 07:20, jian he wrote: > > static > Datum return_numeric_datum(char *token) > { > Datum numd; > Node*escontext; > > if (!DirectInputFunctionCallSafe(numeric_in, token, >

Re: logical decoding and replication of sequences, take 2

This is review of 0003 patch. Overall the patch looks good and helps understand the decoding logic better. + data + + BEGIN + sequence public.test_sequence: transactiona

Re: ​function arguments are not PG_FUNCTION_ARGS, how to pass Node *escontext

On 2023-06-26 Mo 07:20, jian he wrote: static Datum return_numeric_datum(char *token) { Datum numd; Node*escontext; if (!DirectInputFunctionCallSafe(numeric_in, token, InvalidOid, -1, escontext,

​function arguments are not PG_FUNCTION_ARGS, how to pass Node *escontext

hi. simple question The following one works. Datum test_direct_inputcall(PG_FUNCTION_ARGS) { char*token = PG_GETARG_CSTRING(0); Datum numd; if (!DirectInputFunctionCallSafe(numeric_in, token,

Re: Stampede of the JIT compilers

On Sun, 2023-06-25 at 11:10 +0200, Michael Banck wrote: > On Sat, Jun 24, 2023 at 01:54:53PM -0400, Tom Lane wrote: > > I don't know whether raising the default would be enough to fix that > > in a nice way, and I certainly don't pretend to have a specific value > > to offer.  But it's undeniable t

Re: Do we want a hashset type?

On Mon, Jun 26, 2023 at 4:36 AM Joel Jacobson wrote: > > On Sun, Jun 25, 2023, at 11:42, Joel Jacobson wrote: > > SELECT hashset_contains('{}'::int4hashset, NULL::int); > > > > would be False, according to the General Rules. > > > ... > > Applying the same rules, we'd have to return Unknown (w

Re: Synchronizing slots from primary to standby

On Mon, Jun 26, 2023 at 11:15 AM Drouvot, Bertrand wrote: > > On 6/20/23 12:22 PM, Amit Kapila wrote: > > On Mon, Jun 19, 2023 at 9:56 PM Drouvot, Bertrand > > wrote: > > >> In such a case (slot valid on the primary but invalidated on the standby) > >> then I think we > >> could drop and recreat

Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes

On Mon, Jun 26, 2023 at 3:07 PM Ashutosh Bapat wrote: > > Hi All, > Every pg_decode routine except pg_decode_message that decodes a > transactional change, has following block > /* output BEGIN if we haven't yet */ > if (data->skip_empty_xacts && !txndata->xact_wrote_changes) > { > pg_output_begi

pg_decode_message vs skip_empty_xacts and xact_wrote_changes

Hi All, Every pg_decode routine except pg_decode_message that decodes a transactional change, has following block /* output BEGIN if we haven't yet */ if (data->skip_empty_xacts && !txndata->xact_wrote_changes) { pg_output_begin(ctx, data, txn, false); } txndata->xact_wrote_changes = true; But pg

Clean up command argument assembly

This is a small code cleanup patch. Several commands internally assemble command lines to call other commands. This includes initdb, pg_dumpall, and pg_regress. (Also pg_ctl, but that is different enough that I didn't consider it here.) This has all evolved a bit organically, with fixed-size

Re: Problems with estimating OR conditions, IS NULL on LEFT JOINs

On 24/6/2023 17:23, Tomas Vondra wrote: I really hope what I just wrote makes at least a little bit of sense. Throw in one more example: SELECT i AS id INTO l FROM generate_series(1,10) i; CREATE TABLE r (id int8, v text); INSERT INTO r (id, v) VALUES (1, 't'), (-1, 'f'); ANALYZE l,r; EXPLA

Re: 'converts internal representation to "..."' comment is confusing

On 24/06/2023 23:52, Steve Chavez wrote: On Tue, 16 May 2023 at 07:49, Robert Haas > wrote: On Sun, May 14, 2023 at 9:37 PM Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: > Steve Chavez mailto:st...@supabase.io>> writes: > > I found "..." confusing in som

Re: Row pattern recognition

>> In this case, we should require the user to specify AFTER MATCH SKIP >> TO NEXT ROW so that behavior doesn't change when we implement the >> standard default. (Your patch might do this already.) > > Agreed. I will implement AFTER MATCH SKIP PAST LAST ROW in the next > patch and I will change t

Clean up JumbleQuery() from query text

Hi all, Joe has reported me offlist that JumbleQuery() includes a dependency to the query text, but we don't use that anymore as the query ID is generated from the Query structure instead. Any thoughts about the cleanup attached? But at the same time, this is simple and a new thing, so I'd rathe

Fwd: Castable Domains for different JSON representations

> The bigger picture here, though, is what are you really buying compared to just invoking the special conversion function explicitly? > If you have to write "sometsrangecolumn::mytsrange::json", that's not shorter and certainly not clearer than writing a function call. The main benefit is to be a

Re: Optimize walsender handling invalid messages of 'drop publication'

Dears, This issue has been pending for several months without any response. And this problem still exists in the latest minor versions of PG 12 and PG 13. I believe that the fix in this patch is helpful. The patch has been submitted https://commitfest.postgresql.org/43/4393/ . Anyone who is int

Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL

Hi Hayato, all > > > This is a follow-up thread of [1]. The commit allowed subscribers to use > indexes > other than PK and REPLICA IDENTITY when REPLICA IDENTITY is FULL on > publisher, > but the index must be a B-tree. In this proposal, I aim to extend this > functionality to allow > for hash in