Re: Modernize const handling with readline

On 04.10.23 17:09, Aleksander Alekseev wrote: Hi, On 03.10.23 13:28, Aleksander Alekseev wrote: While examining the code for similar places I noticed that the following functions can also be const'ified: - crc32_sz I suppose this could be changed. OK, that's a simple change. Here is the p

Re: Extract numeric filed in JSONB more effectively

Hi, I am feeling this topic has been well discussed and the only pending issues are below, it would be great that any committer can have a look at these, so I mark this entry as "Ready for Committer". Things are not addressed yet: > 1. the error message handling. > You can check [1] for more

Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag

Hi, On 10/5/23 7:10 AM, Michael Paquier wrote: On Wed, Oct 04, 2023 at 12:54:24PM +0200, Drouvot, Bertrand wrote: Except the Nit that I mentioned in 0001, that looks all good to me (with the new wait in 001_worker_spi.pl). Thanks, I've applied the refactoring, including in it the stuff to be

Re: pg16: XX000: could not find pathkey item to sort

On Tue, 3 Oct 2023 at 20:16, David Rowley wrote: > I wonder if the attached patch is too much of a special case fix. I > guess from the lack of complaints previously that there are no other > cases where we could possibly have pathkeys that belong to columns > that are aggregated. I've not gone

Re: [PoC/RFC] Multiple passwords, interval expirations

I had an idea to simplify this feature/patch and after some validation in internal discussions, I am posting the new approach here. I'd appreciate any feedback and comments. To begin with, the feature we are chasing is to make it convenient for the users to rollover their passwords. Currently ther

Re: Making aggregate deserialization (and WAL receive) functions slightly faster

On Wed, Oct 04, 2023 at 07:47:11PM +1300, David Rowley wrote: > The original patch had a new function in stringinfo.c which allowed a > StringInfoData to be initialised from an existing string with some > given length. Tom wasn't a fan of that because there wasn't any > protection against someone

Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag

On Wed, Oct 04, 2023 at 12:54:24PM +0200, Drouvot, Bertrand wrote: > Except the Nit that I mentioned in 0001, that looks all good to me (with the > new wait in 001_worker_spi.pl). Thanks, I've applied the refactoring, including in it the stuff to be able to control the flags used when launching a

post-recovery amcheck expectations

Suppose we start with this nbtree (subset of a diagram from verify_nbtree.c): * 1 * / \ *2 <-> 3 We're deleting 2, the leftmost leaf under a leftmost internal page. After the MARK_PAGE_HALFDEAD record, the first downlink from 1 will lead to 3, whi

Re: Rethink the wait event names for postgres_fdw, dblink and etc

On Wed, Oct 04, 2023 at 05:19:40PM +0900, Michael Paquier wrote: > I am lacking a bit of time now, but I have applied the bits for > test_shm_mq and worker_spi. Note that I have not added tests for > test_shm_mq as it may be possible that the two events (for the > bgworker startup and for a messag

Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers

On Wed, Oct 4, 2023 at 9:42 AM Robert Haas wrote: > > On Wed, Oct 4, 2023 at 9:36 AM James Coleman wrote: > > Are you thinking we should simply elide the fact that there is pruning > > that happens outside of HOT? Or add that information onto the HOT > > page, even though it doesn't directly fit?

Re: make add_paths_to_append_rel aware of startup cost

On Wed, Oct 4, 2023 at 8:41 AM David Rowley wrote: > On Sun, 1 Oct 2023 at 21:26, Andy Fan wrote: > >> But overall, I'm more inclined to just go with the more simple "add a > >> cheap unordered startup append path if considering cheap startup > >> plans" version. I see your latest patch does bot

Re: Pre-proposal: unicode normalized text

On Wed, 4 Oct 2023 at 17:37, Jeff Davis wrote: > On Wed, 2023-10-04 at 14:14 -0400, Isaac Morland wrote: > > Always store only UTF-8 in the database > > What problem does that solve? I don't see our encoding support as a big > source of problems, given that database-wide UTF-8 already works fine.

Re: Pre-proposal: unicode normalized text

On Wed, Oct 04, 2023 at 04:01:26PM -0700, Jeff Davis wrote: > On Wed, 2023-10-04 at 16:15 -0500, Nico Williams wrote: > > Better that than TEXT blobs w/ the encoding given by the `CREATE > > DATABASE` or `initdb` default! > > From an engineering perspective, yes, per-column encodings would be > mo

Re: Pre-proposal: unicode normalized text

On Wed, 2023-10-04 at 16:15 -0500, Nico Williams wrote: > Better that than TEXT blobs w/ the encoding given by the `CREATE > DATABASE` or `initdb` default! >From an engineering perspective, yes, per-column encodings would be more flexible. But I still don't understand who exactly would use that, a

Re: Add annotation syntax to pg_hba.conf entries

Robert Haas writes: > You're probably not going to like this answer very much, but this > doesn't seem particularly worthwhile to me. Yeah, I was unconvinced about the number of use-cases too. As you say, some support from other potential users could convince me otherwise, but right now the evide

Re: Pre-proposal: unicode normalized text

On Wed, Oct 04, 2023 at 05:32:50PM -0400, Chapman Flack wrote: > Well, for what reason does anybody run PG now with the encoding set > to anything besides UTF-8? I don't really have my finger on that pulse. Because they still have databases that didn't use UTF-8 10 or 20 years ago that they haven'

Re: Pre-proposal: unicode normalized text

On Wed, 2023-10-04 at 14:14 -0400, Isaac Morland wrote: > Always store only UTF-8 in the database What problem does that solve? I don't see our encoding support as a big source of problems, given that database-wide UTF-8 already works fine. In fact, some postgres features only work with UTF-8. I

Re: Pre-proposal: unicode normalized text

On 2023-10-04 16:38, Jeff Davis wrote: On Wed, 2023-10-04 at 14:02 -0400, Chapman Flack wrote: The SQL standard would have me able to: CREATE TABLE foo (    a CHARACTER VARYING CHARACTER SET UTF8,    b CHARACTER VARYING CHARACTER SET LATIN1 ) and so on Is there a use case for that? UTF-8 is

Re: Pre-proposal: unicode normalized text

On Wed, Oct 04, 2023 at 01:38:15PM -0700, Jeff Davis wrote: > On Wed, 2023-10-04 at 14:02 -0400, Chapman Flack wrote: > > The SQL standard would have me able to: > > > > [...] > > _UTF8'Hello, world!' and _LATIN1'Hello, world!' > > Is there a use case for that? UTF-8 is able to encode any unicode

Re: [PATCH] Add CANONICAL option to xmlserialize

On 2023-10-04 12:19, Jim Jones wrote: On 04.10.23 11:39, vignesh C wrote: 1) Why the default option was chosen without comments shouldn't it be the other way round? I'm not sure it is the way to go. The main idea is to check if two documents have the same content, and comments might be differen

Re: Opportunistically pruning page before update

On Tue, Sep 26, 2023 at 8:30 AM James Coleman wrote: > > On Tue, Sep 5, 2023 at 1:40 PM Melanie Plageman > wrote: > > > > On Wed, Jun 21, 2023 at 8:51 AM James Coleman wrote: > > > While at PGCon I was chatting with Andres (and I think Peter G. and a > > > few others who I can't remember at the

Re: Pre-proposal: unicode normalized text

On Wed, 2023-10-04 at 14:02 -0400, Chapman Flack wrote: > The SQL standard would have me able to: > > CREATE TABLE foo ( >    a CHARACTER VARYING CHARACTER SET UTF8, >    b CHARACTER VARYING CHARACTER SET LATIN1 > ) > > and so on, and write character literals like > > _UTF8'Hello, world!' and _L

Re: Add annotation syntax to pg_hba.conf entries

On Wed, Oct 4, 2023 at 4:06 PM Jim Jones wrote: > Any thoughts? You're probably not going to like this answer very much, but this doesn't seem particularly worthwhile to me. If somebody needs to document why they did something in pg_hba.conf, they can already put a comment in the file to explain

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

On Tue, Oct 3, 2023 at 9:58 AM Bharath Rupireddy wrote: > > On Fri, Sep 29, 2023 at 5:27 PM Hayato Kuroda (Fujitsu) > wrote: > > > > Yeah, the approach enforces developers to check the decodability. > > But the benefit seems smaller than required efforts for it because the > > function > > would

Re: Pre-proposal: unicode normalized text

On Wed, 2023-10-04 at 13:16 -0400, Robert Haas wrote: > any byte sequence at all is accepted when you try to > put values into the database. We support SQL_ASCII, which allows something similar. > At any rate, if we were to go in the direction of rejecting code > points that aren't yet assigned,

Add annotation syntax to pg_hba.conf entries

Hi, I'm opening this thread after a brief discussion regarding a potential new syntax to enable annotations in pg_hba entries. [1] This feature mainly aims to annotate pg_hba entries in a way that the annotations can be parsed and displayed in the pg_hba_file_rule view for reporting purposes

Re: --sync-method isn't documented to take an argument

On Wed, Oct 04, 2023 at 12:24:36PM -0400, Tom Lane wrote: > In any case, trying to standardize this looks like it would be a > huge amount of churn for very little gain. I'd recommend making > your markup look similar to what's immediately adjacent, if possible, > and not sweating too much otherwi

Re: trying again to get incremental backup

On Thu, Sep 28, 2023 at 6:22 AM Jakub Wartak wrote: > all those basic tests had GOOD results. Please find attached. I'll try > to schedule some more realistic (in terms of workload and sizes) test > in a couple of days + maybe have some fun with cross-backup-and > restores across standbys. That's

Re: POC, WIP: OR-clause support for indexes

On 29.09.2023 20:35, a.rybakina wrote: I'm sorry I didn't write for a long time, but I really had a very difficult month, now I'm fully back to work. *I was able to implement the patches to the end and moved the transformation of "OR" expressions to ANY.* I haven't seen a big difference bet

Re: Request for comment on setting binary format output per session

On Wed, Oct 4, 2023 at 10:17 AM Peter Eisentraut wrote: > I think intuitively, this facility ought to work like client_encoding. I hadn't really considered client_encoding as a precedent for this setting. A lot of my discomfort with the proposed mechanism also applies to client_encoding, namely,

Re: Request for comment on setting binary format output per session

On Wed, 4 Oct 2023 at 10:17, Peter Eisentraut wrote: > On 31.07.23 18:27, Dave Cramer wrote: > > On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson > > wrote: > > > > > On 25 Apr 2023, at 16:47, Dave Cramer > > wrote: > > > > > Pat

Re: Pre-proposal: unicode normalized text

On Wed, 4 Oct 2023 at 14:05, Chapman Flack wrote: > On 2023-10-04 13:47, Robert Haas wrote: > > The SQL standard would have me able to: > > CREATE TABLE foo ( >a CHARACTER VARYING CHARACTER SET UTF8, >b CHARACTER VARYING CHARACTER SET LATIN1 > ) > > and so on, and write character litera

Re: Pre-proposal: unicode normalized text

On Wed, Oct 4, 2023 at 2:02 PM Chapman Flack wrote: > Clearly, part of the job would involve making the wire protocol > able to transmit binary values and identify their encodings. Right. Which unfortunately is moving the goal posts into the stratosphere compared to any other work mentioned so fa

Re: Pre-proposal: unicode normalized text

On 2023-10-04 13:47, Robert Haas wrote: On Wed, Oct 4, 2023 at 1:27 PM Nico Williams wrote: A UTEXT type would be helpful for specifying that the text must be Unicode (in which transform?) even if the character data encoding for the database is not UTF-8. That's actually pretty thorny ... bec

Re: Pre-proposal: unicode normalized text

On Wed, Oct 4, 2023 at 1:27 PM Nico Williams wrote: > A UTEXT type would be helpful for specifying that the text must be > Unicode (in which transform?) even if the character data encoding for > the database is not UTF-8. That's actually pretty thorny ... because right now client_encoding specifi

Re: Pre-proposal: unicode normalized text

On Tue, Sep 12, 2023 at 03:47:10PM -0700, Jeff Davis wrote: > The idea is to have a new data type, say "UTEXT", that normalizes the > input so that it can have an improved notion of equality while still > using memcmp(). A UTEXT type would be helpful for specifying that the text must be Unicode (i

Re: Pre-proposal: unicode normalized text

On Tue, Oct 3, 2023 at 3:54 PM Jeff Davis wrote: > I assume you mean because we reject invalid byte sequences? Yeah, I'm > sure that causes a problem for some (especially migrations), but it's > difficult for me to imagine a database working well with no rules at > all for the the basic data types

Re: Request for comment on setting binary format output per session

On Wed, Oct 4, 2023 at 9:17 AM Peter Eisentraut wrote: > I think intuitively, this facility ought to work like client_encoding. > There, the client declares its capabilities, and the server has to > format the output according to the client's capabilities. That works, > and it also works through

Re: --sync-method isn't documented to take an argument

Robert Haas writes: > On Wed, Oct 4, 2023 at 11:27 AM Nathan Bossart > wrote: >> Here's a patch. I didn't address the class="parameter" stuff at all. I >> figured it would be best to handle that separately. > I guess I'll vote for including class=parameter in this addition for > now, as that

Re: [PATCH] Add CANONICAL option to xmlserialize

Hi Vignesh Thanks for the thorough review! On 04.10.23 11:39, vignesh C wrote: Few comments: 1) Why the default option was chosen without comments shouldn't it be the other way round? +opt_xml_serialize_format: + INDENT { $$ = XMLSERIALIZE_INDENT;

Re: --sync-method isn't documented to take an argument

On Wed, Oct 04, 2023 at 11:51:32AM -0400, Robert Haas wrote: > On Wed, Oct 4, 2023 at 11:27 AM Nathan Bossart > wrote: >> Here's a patch. I didn't address the class="parameter" stuff at all. I >> figured it would be best to handle that separately. > > I guess I'll vote for including class=para

Re: --sync-method isn't documented to take an argument

On Wed, Oct 4, 2023 at 11:27 AM Nathan Bossart wrote: > Here's a patch. I didn't address the class="parameter" stuff at all. I > figured it would be best to handle that separately. I guess I'll vote for including class=parameter in this addition for now, as that appears to be the majority posit

Re: --sync-method isn't documented to take an argument

On Wed, Oct 04, 2023 at 05:00:26PM +0200, Alvaro Herrera wrote: > On 2023-Oct-04, Robert Haas wrote: > >> The original issue I reported does make a real difference, though. :-) > > Yes, absolutely, and I agree that it'd be better to get it fixed. Here's a patch. I didn't address the class="para

Re: should frontend tools use syncfs() ?

On Wed, Sep 27, 2023 at 01:56:08PM +0100, Peter Eisentraut wrote: > I think it's a bit much to add a whole appendix for that little content. I'm inclined to agree. > We have a collection of platform-specific notes in chapter 19, including > file-system-related notes in section 19.2. Maybe it cou

Re: --sync-method isn't documented to take an argument

> On 4 Oct 2023, at 17:07, Tom Lane wrote: > OK, so now I know what the possible values of "class" are, but > I'm still not seeing a reason why we shouldn't just assume that > "parameter" is the only one of interest. I think "parameter" is the only one of interest for this usecase (params to app

Re: Modernize const handling with readline

Hi, > On 03.10.23 13:28, Aleksander Alekseev wrote: > > While examining the code for similar places I noticed that the > > following functions can also be const'ified: > > > > - crc32_sz > > I suppose this could be changed. OK, that's a simple change. Here is the patch. -- Best regards, Aleksan

Re: --sync-method isn't documented to take an argument

Daniel Gustafsson writes: > On 4 Oct 2023, at 16:51, Tom Lane wrote: >> To do that, we'd need some sort of agreement on what the possible >> "class" values are and when to use each one. I've never seen any >> documentation about that. > Thats fair. The 4.5 docbook guide isn't terribly helpful

Re: --sync-method isn't documented to take an argument

On 2023-Oct-04, Robert Haas wrote: > The original issue I reported does make a real difference, though. :-) Yes, absolutely, and I agree that it'd be better to get it fixed. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "Learn about compilers. Then everything

Re: --sync-method isn't documented to take an argument

> On 4 Oct 2023, at 16:51, Tom Lane wrote: > > Daniel Gustafsson writes: >> On 4 Oct 2023, at 16:39, Tom Lane wrote: >>> I concluded a long time ago that it does nothing. > >> It does nothing in our current doc rendering, but if someone would like to >> render docs with another style where it

Re: --sync-method isn't documented to take an argument

On Wed, Oct 04, 2023 at 09:08:57AM -0400, Robert Haas wrote: > The various command-line utilities that have recently acquired a > --sync-method option document it like this: > > --sync-method > > But that is not how we document options which take an argument. We do > it like this: > > --pgdata=dire

Re: stopgap fix for signal handling during restore_command

On Sun, Oct 01, 2023 at 08:50:15PM +0200, Peter Eisentraut wrote: > Is this still being contemplated? What is the status of this? I'll plan on committing this in the next couple of days. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com

Re: --sync-method isn't documented to take an argument

Daniel Gustafsson writes: > On 4 Oct 2023, at 16:39, Tom Lane wrote: >> I concluded a long time ago that it does nothing. > It does nothing in our current doc rendering, but if someone would like to > render docs with another style where it does make a difference it seems > unhelpful to not be c

Re: --sync-method isn't documented to take an argument

> On 4 Oct 2023, at 16:39, Tom Lane wrote: > > Alvaro Herrera writes: >> So I'm not sure that specifying the class="parameter" bit does anything in >> reality, or that changing lines to add or remove it will have any effect. > > I concluded a long time ago that it does nothing. It does nothing

Re: Add support for AT LOCAL

On 9/29/23 09:27, Michael Paquier wrote: On Sat, Sep 23, 2023 at 12:54:01AM +0200, Vik Fearing wrote: On 9/22/23 23:46, cary huang wrote: I think this feature can be a useful addition in dealing with time zones. I have applied and tried out the patch, The feature works as described and seems pr

Re: --sync-method isn't documented to take an argument

Alvaro Herrera writes: > So I'm not sure that specifying the class="parameter" bit does anything in > reality, or that changing lines to add or remove it will have any effect. I concluded a long time ago that it does nothing. We have a good mix of places that write with or without that, and I'v

Re: --sync-method isn't documented to take an argument

On Wed, Oct 4, 2023 at 10:35 AM Alvaro Herrera wrote: > So I'm not sure that specifying the class="parameter" bit does anything in > reality, or that changing lines to add or remove it will have any effect. Interesting. I wondered whether that might be the case. The original issue I reported doe

Re: Modernize const handling with readline

On 03.10.23 13:28, Aleksander Alekseev wrote: While examining the code for similar places I noticed that the following functions can also be const'ified: - crc32_sz I suppose this could be changed. - pg_checksum_page (? temporary modifies the page but then restores it) Then it's not really

Re: --sync-method isn't documented to take an argument

On 2023-Oct-04, Daniel Gustafsson wrote: > I can take a stab at tidying this up during breaks at the conference. It > might > not be the most important bit of markup, but for anyone building the docs who > might want to use this it seems consistency will help. So for HTML, the result of the pg_

Re: Request for comment on setting binary format output per session

On 31.07.23 18:27, Dave Cramer wrote: On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson > wrote: > On 25 Apr 2023, at 16:47, Dave Cramer mailto:davecra...@gmail.com>> wrote: > Patch attached with comments removed This patch no longer applies, please submit a

Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers

On Wed, Oct 4, 2023 at 9:36 AM James Coleman wrote: > Are you thinking we should simply elide the fact that there is pruning > that happens outside of HOT? Or add that information onto the HOT > page, even though it doesn't directly fit? I think we should elide it. Maybe with a much larger rewrit

Re: Document efficient self-joins / UPDATE LIMIT techniques.

On Wed, 2023-06-28 at 14:20 -0400, Corey Huinker wrote: > This patch adds a few examples to demonstrate the following: > > * The existence of the ctid column on every table > * The utility of ctds in self joins > * A practical usage of SKIP LOCKED I had a look at your patch, and I am in favor of

Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers

On Wed, Oct 4, 2023 at 9:18 AM Robert Haas wrote: > > On Tue, Oct 3, 2023 at 3:35 PM James Coleman wrote: > > I like your changes. Reading through this several times, and noting > > Peter's comments about pruning being more than just HOT, I'm thinking > > that rather than a simple fixup for this

Re: --sync-method isn't documented to take an argument

> On 4 Oct 2023, at 15:22, Robert Haas wrote: > > On Wed, Oct 4, 2023 at 9:15 AM Daniel Gustafsson wrote: >>> On 4 Oct 2023, at 15:08, Robert Haas wrote: >>> This one should be something like this: >>> >>> --sync-method=method >> >> Shouldn't it be method ? > > Hmm, I think you're probably r

Re: Infinite Interval

On Fri, Sep 29, 2023 at 12:43 PM Dean Rasheed wrote: > > I think that part is now ready to commit, and I plan to push this fix > to make_interval() separately, since it's really a bug-fix, not > related to support for infinite intervals. In line with recent > precedent, I don't think it's worth ba

Re: remaining sql/json patches

On Tue, Oct 3, 2023 at 10:11 PM Amit Langote wrote: > On Mon, Oct 2, 2023 at 2:26 PM Amit Langote wrote: > > On Mon, Oct 2, 2023 at 1:24 PM Amit Langote wrote: > > > Pushed this 30 min ago (no email on -committers yet!) and am looking > > > at the following llvm crash reported by buildfarm anima

Re: --sync-method isn't documented to take an argument

On Wed, Oct 4, 2023 at 9:15 AM Daniel Gustafsson wrote: > > On 4 Oct 2023, at 15:08, Robert Haas wrote: > > This one should be something like this: > > > > --sync-method=method > > Shouldn't it be method ? Hmm, I think you're probably right. But look at this: -S slotname --slot=slot

Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers

On Tue, Oct 3, 2023 at 3:35 PM James Coleman wrote: > I like your changes. Reading through this several times, and noting > Peter's comments about pruning being more than just HOT, I'm thinking > that rather than a simple fixup for this one paragraph what we > actually want is to split out the con

Re: --sync-method isn't documented to take an argument

> On 4 Oct 2023, at 15:08, Robert Haas wrote: > This one should be something like this: > > --sync-method=method Shouldn't it be method ? -- Daniel Gustafsson

--sync-method isn't documented to take an argument

The various command-line utilities that have recently acquired a --sync-method option document it like this: --sync-method But that is not how we document options which take an argument. We do it like this: --pgdata=directory --filenode=filenode etc. This one should be something like this: --

Re: Eager page freeze criteria clarification

On Mon, Oct 2, 2023 at 4:25 PM Robert Haas wrote: > On Mon, Oct 2, 2023 at 11:37 AM Peter Geoghegan wrote: > > If no vacuuming against pgbench_accounts is strictly better than some > > vacuuming (unless it's just to advance relfrozenxid, which can't be > > avoided), then to what extent is Melanie

Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound

On Mon, Oct 2, 2023 at 1:25 PM Robert Haas wrote: > I'm also pretty happy with these patches and would like to see at > least 0001 and 0002 committed, and probably 0003 as well. I am, > however, -1 on back-patching. Perhaps that is overly cautious, but I > don't like changing existing messages in

Re: Synchronizing slots from primary to standby

Hi, On 10/4/23 1:50 PM, shveta malik wrote: On Wed, Oct 4, 2023 at 5:00 PM Amit Kapila wrote: On Wed, Oct 4, 2023 at 11:55 AM Drouvot, Bertrand wrote: On 10/4/23 6:26 AM, shveta malik wrote: On Wed, Oct 4, 2023 at 5:36 AM Amit Kapila wrote: How about an alternate scheme where we defin

Re: Synchronizing slots from primary to standby

On Wed, Oct 4, 2023 at 12:08 PM Drouvot, Bertrand wrote: > > Hi, > > On 10/4/23 7:00 AM, shveta malik wrote: > > On Wed, Oct 4, 2023 at 9:56 AM shveta malik wrote: > > > The most simplistic approach would be: > > > > 1) maintain standby_slot_names GUC on primary > > 2) maintain synchronize_slot_n

Re: Synchronizing slots from primary to standby

On Wed, Oct 4, 2023 at 5:00 PM Amit Kapila wrote: > > On Wed, Oct 4, 2023 at 11:55 AM Drouvot, Bertrand > wrote: > > > > On 10/4/23 6:26 AM, shveta malik wrote: > > > On Wed, Oct 4, 2023 at 5:36 AM Amit Kapila > > > wrote: > > >> > > >> > > >> How about an alternate scheme where we define sync_

Is the logfile the only place to find the finish LSN?

Hello all, on pgsql-general this got no answers, so... According to: https://www.postgresql.org/docs/current/logical-replication-conflicts.html or https://www.postgresql.fastware.com/blog/addressing-replication-conflicts-using-alter-subscription-skip The logfile is the _only_ place to find t

RE: [PATCH] Fix memory leak in memoize for numeric key

I've finished testing the patch. I confirm that the patch solves the problem and works just as fast. Thanks, Alexey Orlov.

Re: Invalidate the subscription worker in cases where a user loses their superuser status

On Wed, 4 Oct 2023 at 16:56, Peter Smith wrote: > > On Tue, Oct 3, 2023 at 5:42 PM vignesh C wrote: > > > > Thanks for the comments, the attached v6 version patch has the changes > > for the same. > > > > v6 LGTM. > I have verified the patch and it is working fine for me.

Re: Synchronizing slots from primary to standby

On Wed, Oct 4, 2023 at 11:55 AM Drouvot, Bertrand wrote: > > On 10/4/23 6:26 AM, shveta malik wrote: > > On Wed, Oct 4, 2023 at 5:36 AM Amit Kapila wrote: > >> > >> > >> How about an alternate scheme where we define sync_slot_names on > >> standby but then store the physical_slot_name in the corr

Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)

On 9/30/23 01:57, Tom Lane wrote: > Thomas Munro writes: >> Does the image lack a /etc/localtime file/link, but perhaps one of you >> did something to create it? > > Hah! I thought it had to be some sort of locale effect, but I failed > to think of that as a contributor :-(. My installation doe

Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag

Hi, On 10/4/23 8:20 AM, Michael Paquier wrote: On Mon, Oct 02, 2023 at 10:53:22AM +0200, Drouvot, Bertrand wrote: On 10/2/23 10:17 AM, Michael Paquier wrote: On Mon, Oct 02, 2023 at 10:01:04AM +0200, Drouvot, Bertrand wrote: I think that would make sense to have more flexibility in the worker

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hi, Ivan! On Fri, Jun 30, 2023 at 11:32 AM Картышов Иван wrote: > All rebased and tested > Thank you for continuing to work on this patch. I see you're concentrating on the procedural version of this feature. But when you're calling a procedure within a normal SQL statement, the executor gets

Re: [PATCH] Add CANONICAL option to xmlserialize

On Fri, 17 Mar 2023 at 18:01, Jim Jones wrote: > > After some more testing I realized that v5 was leaking the xmlDocPtr. > > Now fixed in v6. Few comments: 1) Why the default option was chosen without comments shouldn't it be the other way round? +opt_xml_serialize_format: +

Re: Rethink the wait event names for postgres_fdw, dblink and etc

On Mon, Aug 21, 2023 at 11:04:23AM +0900, Masahiro Ikeda wrote: > I updated the patch to v2. > * Update a comment instead writing documentation about > the wait events for pg_prewarm. Right. It does not seem worth the addition currently, so I am discarded this part. It's just not worth the ext

Re: Removing unneeded self joins

Hi! On Wed, Oct 4, 2023 at 9:56 AM Andrei Lepikhov wrote: > On 4/10/2023 07:12, Alexander Korotkov wrote: > > On Tue, Sep 12, 2023 at 4:58 PM Andrey Lepikhov > > wrote: > >> On 5/7/2023 21:28, Andrey Lepikhov wrote: > >>> During the significant code revision in v.41 I lost some replacement > >>>