Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser)

2022-12-11 Thread Amit Langote
Hi, On Sun, Dec 11, 2022 at 5:17 AM Justin Pryzby wrote: > On Tue, Nov 29, 2022 at 10:37:56PM +0900, Amit Langote wrote: > > 0002 contains changes that has to do with changing how we access > > checkAsUser in some foreign table planning/execution code sites. > > Thought it might be better to desc

Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser)

2022-12-11 Thread Justin Pryzby
On Sun, Dec 11, 2022 at 06:25:48PM +0900, Amit Langote wrote: > On Sun, Dec 11, 2022 at 5:17 AM Justin Pryzby wrote: > > The original code rechecks rte->checkAsUser with the rte of the parent > > rel. The patch changed to access onerel instead, but that's not updated > > after looping to find the

Re: Error-safe user functions

2022-12-11 Thread Andrew Dunstan
On 2022-12-10 Sa 19:00, Tom Lane wrote: > Looking at my notes, there's one other loose end > I forgot to mention: > > * Note: pg_unicode_to_server() will throw an error for a > * conversion failure, rather than returning a failure > *

Date-Time dangling unit fix

2022-12-11 Thread Joseph Koshakow
Hi all, Attached is a patch to fix a parsing error for date-time types that allow dangling units in the input. For example, `date '1995-08-06 m y d'` was considered a valid date and the dangling units were ignored. Intervals also suffer from a similar issue, but the attached patch doesn't fix tha

Re: Date-Time dangling unit fix

2022-12-11 Thread Joseph Koshakow
On Sun, Dec 11, 2022 at 10:29 AM Joseph Koshakow wrote: > > Hi all, > > Attached is a patch to fix a parsing error for date-time types that > allow dangling units in the input. For example, > `date '1995-08-06 m y d'` was considered a valid date and the dangling > units were ignored. > > Intervals

Re: Error-safe user functions

2022-12-11 Thread Tom Lane
Andrew Dunstan writes: > On 2022-12-10 Sa 14:38, Tom Lane wrote: >> I have not done anything here about errors within JsonbValueToJsonb. >> There would need to be another round of API-extension in that area >> if we want to be able to trap its errors. As you say, those are mostly >> about exceedi

Re: Error-safe user functions

2022-12-11 Thread Andrew Dunstan
On 2022-12-11 Su 12:24, Tom Lane wrote: > Andrew Dunstan writes: >> On 2022-12-10 Sa 14:38, Tom Lane wrote: >>> I have not done anything here about errors within JsonbValueToJsonb. >>> There would need to be another round of API-extension in that area >>> if we want to be able to trap its errors

Re: Error-safe user functions

2022-12-11 Thread Tom Lane
Andrew Dunstan writes: > Maybe as we work through the remaining input functions (there are about > 60 core candidates left on my list) we should mark them with a comment > if no adjustment is needed. I did a quick pass through them last night. Assuming that we don't need to touch the unimplement

Re: Checksum errors in pg_stat_database

2022-12-11 Thread Magnus Hagander
On Thu, Dec 8, 2022 at 2:35 PM Drouvot, Bertrand < bertranddrouvot...@gmail.com> wrote: > > > On 4/2/19 7:06 PM, Magnus Hagander wrote: > > On Tue, Apr 2, 2019 at 8:47 AM Michael Paquier > wrote: > > > > On Tue, Apr 02, 2019 at 07:43:12AM +0200, Julien Rouhaud wrot

Re: Error-safe user functions

2022-12-11 Thread Andres Freund
Hi, On 2022-12-11 12:24:11 -0500, Tom Lane wrote: > Andrew Dunstan writes: > > On 2022-12-10 Sa 14:38, Tom Lane wrote: > >> I have not done anything here about errors within JsonbValueToJsonb. > >> There would need to be another round of API-extension in that area > >> if we want to be able to tr

Re: Error-safe user functions

2022-12-11 Thread Tom Lane
Andres Freund writes: > On 2022-12-11 12:24:11 -0500, Tom Lane wrote: >> I spent some time looking at this, and was discouraged to conclude >> that the notational mess would probably be substantially out of >> proportion to the value. The main problem is that we'd have to change >> the API of pus

Re: static assert cleanup

2022-12-11 Thread Peter Smith
On Fri, Dec 9, 2022 at 6:47 PM Peter Eisentraut wrote: > > A number of static assertions could be moved to better places. > > We first added StaticAssertStmt() in 2012, which required all static > assertions to be inside function bodies. We then added > StaticAssertDecl() in 2020, which enabled s

Date-time extraneous fields with reserved keywords

2022-12-11 Thread Joseph Koshakow
Hi all, Attached is a patch to fix another parsing error for date-time types that allow extraneous fields with certain reserved keywords. For example both `date '1995-08-06 epoch'` and `date 'today epoch'` were considered valid dates that both resolve to 1970-01-01. - Joe Koshakow From fb4c161aff

Re: PGDOCS - Logical replication GUCs - added some xrefs

2022-12-11 Thread Peter Smith
On Sat, Dec 10, 2022 at 5:10 AM samay sharma wrote: > > > I don't have any other feedback. This looks good to me. > > Also, I don't see this patch in the 2023/01 commitfest. Might be worth moving > to that one. > Hmm, it was already recorded in the 2022-11 commitfest [1], so I assumed it would

Re: PGDOCS - Logical replication GUCs - added some xrefs

2022-12-11 Thread Tom Lane
Peter Smith writes: > On Sat, Dec 10, 2022 at 5:10 AM samay sharma wrote: >> Also, I don't see this patch in the 2023/01 commitfest. Might be worth >> moving to that one. > Hmm, it was already recorded in the 2022-11 commitfest [1], so I > assumed it would just carry forward to the next one. I

Re: Checksum errors in pg_stat_database

2022-12-11 Thread Michael Paquier
On Sun, Dec 11, 2022 at 09:18:42PM +0100, Magnus Hagander wrote: > It would be less of a concern yes, but I think it still would be a concern. > If you have a large amount of corruption you could quickly get to millions > of rows to keep track of which would definitely be a problem in shared > memo

Re: Force streaming every change in logical decoding

2022-12-11 Thread Peter Smith
On Sat, Dec 10, 2022 at 5:03 PM Dilip Kumar wrote: > > On Tue, Dec 6, 2022 at 11:53 AM shiy.f...@fujitsu.com > wrote: > > > > Hi hackers, > > > > In logical decoding, when logical_decoding_work_mem is exceeded, the > > changes are > > sent to output plugin in streaming mode. But there is a restr

Re: GetNewObjectId question

2022-12-11 Thread Michael Paquier
On Sun, Dec 11, 2022 at 04:20:17PM +0900, Michael Paquier wrote: > Looks OK seen from here. Thanks for the patch! I don't have much > freshness and time today, but I can get back to this thread tomorrow. Applied as of eae7fe4. -- Michael signature.asc Description: PGP signature

Re: Checksum errors in pg_stat_database

2022-12-11 Thread Andres Freund
Hi, On 2022-12-12 08:40:04 +0900, Michael Paquier wrote: > What about just adding a counter tracking the number of checksum > failures for relfilenodes in a new structure related to them (note > that I did not write PgStat_StatTabEntry)? Why were you thinking of tracking it separately from PgStat

Re: Checksum errors in pg_stat_database

2022-12-11 Thread Michael Paquier
On Sun, Dec 11, 2022 at 04:51:49PM -0800, Andres Freund wrote: > Why were you thinking of tracking it separately from PgStat_StatTabEntry? We only know the relfilenode when loading the page on a checksum failure, not its parent relation, and there are things like physical base backups where we wou

Why does L&Y Blink Tree need lock coupling?

2022-12-11 Thread Oliver Yang
Hi, The README in nbtree mentions that L&Y algorithm must couple locks when moving right during ascent for insertion. However, it's hard to see why that's necessary. Since L&Y mostly discussed concurrent insertions and searches, what can go wrong if inserters only acquire one lock at a time? Th

Re: Checksum errors in pg_stat_database

2022-12-11 Thread Tom Lane
Michael Paquier writes: > On Sun, Dec 11, 2022 at 04:51:49PM -0800, Andres Freund wrote: >> I think there's a good argument for starting to track some stats based on the >> relfilenode, rather the oid, because it'd allow us to track e.g. the number >> of >> writes for a relation too (we don't hav

Re: Speedup generation of command completion tags

2022-12-11 Thread David Rowley
Thanks for having a look at this. On Sun, 11 Dec 2022 at 11:05, Andres Freund wrote: > > On 2022-12-10 20:32:06 +1300, David Rowley wrote: > > @@ -20,13 +20,14 @@ > > typedef struct CommandTagBehavior > > { > > const char *name; > > + const uint8 namelen; > > Perhaps worth adding a co

Re: Why does L&Y Blink Tree need lock coupling?

2022-12-11 Thread Peter Geoghegan
On Sun, Dec 11, 2022 at 5:38 PM Oliver Yang wrote: > The README in nbtree mentions that L&Y algorithm must couple > locks when moving right during ascent for insertion. However, > it's hard to see why that's necessary. You're not the first person to ask about this exact point in the last few yea

Re: Tree-walker callbacks vs -Wdeprecated-non-prototype

2022-12-11 Thread Thomas Munro
As visible on seawasp and locally (16/main branch nightly packages), they decided to start warning about these casts with a new strict variant of the warning. Their discussion: https://reviews.llvm.org/D134831 There are also a few other cases unrelated to this thread's original problem, for exam

Re: Improve WALRead() to suck data directly from WAL buffers when possible

2022-12-11 Thread Kyotaro Horiguchi
At Fri, 9 Dec 2022 14:33:39 +0530, Bharath Rupireddy wrote in > The patch introduces concurrent readers for the WAL buffers, so far > only there are concurrent writers. In the patch, WALRead() takes just > one lock (WALBufMappingLock) in shared mode to enable concurrent > readers and does minima

Re: Improve WALRead() to suck data directly from WAL buffers when possible

2022-12-11 Thread Kyotaro Horiguchi
At Mon, 12 Dec 2022 11:57:17 +0900 (JST), Kyotaro Horiguchi wrote in > This patch copies the bleeding edge WAL page without recording the > (next) insertion point nor checking whether all in-progress insertion > behind the target LSN have finished. Thus the copied page may have > holes. That be

Re: Tree-walker callbacks vs -Wdeprecated-non-prototype

2022-12-11 Thread Tom Lane
Thomas Munro writes: > As visible on seawasp and locally (16/main branch nightly packages), > they decided to start warning about these casts with a new strict > variant of the warning. Their discussion: > https://reviews.llvm.org/D134831 > There are also a few other cases unrelated to this thr

Re: Improve WALRead() to suck data directly from WAL buffers when possible

2022-12-11 Thread Kyotaro Horiguchi
Sorry for the confusion. At Mon, 12 Dec 2022 12:06:36 +0900 (JST), Kyotaro Horiguchi wrote in > At Mon, 12 Dec 2022 11:57:17 +0900 (JST), Kyotaro Horiguchi > wrote in > > This patch copies the bleeding edge WAL page without recording the > > (next) insertion point nor checking whether all in

Re: Tree-walker callbacks vs -Wdeprecated-non-prototype

2022-12-11 Thread Thomas Munro
On Mon, Dec 12, 2022 at 4:07 PM Tom Lane wrote: > Thomas Munro writes: > > As visible on seawasp and locally (16/main branch nightly packages), > > they decided to start warning about these casts with a new strict > > variant of the warning. Their discussion: > > > https://reviews.llvm.org/D1348

Re: Checksum errors in pg_stat_database

2022-12-11 Thread Michael Paquier
On Sun, Dec 11, 2022 at 08:48:15PM -0500, Tom Lane wrote: > I think a stats table indexed solely by relfilenode wouldn't be a great > idea, because you'd lose all the stats about a table as soon as you > do vacuum full/cluster/rewriting-alter-table/etc. Can we create two > index structures over th

Re: Testing DDL Deparser

2022-12-11 Thread Zheng Li
Hi, Thanks for working on this and for the feedback! I've added the updated deparser testing module to the DDL replication thread in [1]. We'll add more test cases to the testing module and continue the discussion there. [1] https://www.postgresql.org/message-id/CAAD30U%2BA%3D2rjZ%2BxejNz%2Be1

Re: Time delayed LR (WAS Re: logical replication restrictions)

2022-12-11 Thread Kyotaro Horiguchi
Hello. I asked about unexpected walsender termination caused by this feature but I think I didn't received an answer for it and the behavior is still exists. Specifically, if servers have the following settings, walsender terminates for replication timeout. After that, connection is restored afte

Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser)

2022-12-11 Thread Amit Langote
On Sun, Dec 11, 2022 at 6:25 PM Amit Langote wrote: > I've attached 0001 to remove those extraneous code blocks and add a > comment mentioning that userid need not be recomputed. > > While staring at the build_simple_rel() bit mentioned above, I > realized that this code fails to set userid correc

Re: Checksum errors in pg_stat_database

2022-12-11 Thread Drouvot, Bertrand
On 12/12/22 12:40 AM, Michael Paquier wrote: On Sun, Dec 11, 2022 at 09:18:42PM +0100, Magnus Hagander wrote: It would be less of a concern yes, but I think it still would be a concern. If you have a large amount of corruption you could quickly get to millions of rows to keep track of which w

Re: slab allocator performance issues

2022-12-11 Thread John Naylor
On Sat, Dec 10, 2022 at 11:02 AM David Rowley wrote: > [v4] Thanks for working on this! I ran an in-situ benchmark using the v13 radix tree patchset ([1] WIP but should be useful enough for testing allocation speed), only applying the first five, which are local-memory only. The benchmark is not

Re: Checksum errors in pg_stat_database

2022-12-11 Thread Drouvot, Bertrand
On 12/12/22 5:09 AM, Michael Paquier wrote: On Sun, Dec 11, 2022 at 08:48:15PM -0500, Tom Lane wrote: I think a stats table indexed solely by relfilenode wouldn't be a great idea, because you'd lose all the stats about a table as soon as you do vacuum full/cluster/rewriting-alter-table/etc.

RE: Time delayed LR (WAS Re: logical replication restrictions)

2022-12-11 Thread Takamichi Osumi (Fujitsu)
On Wednesday, December 7, 2022 2:07 PM Amit Kapila wrote: > On Tue, Dec 6, 2022 at 5:44 PM Takamichi Osumi (Fujitsu) > wrote: > > > > On Friday, December 2, 2022 4:05 PM Amit Kapila > wrote: > > > On Tue, Nov 15, 2022 at 12:33 PM Amit Kapila > > > > > > wrote: > > > > One more thing I would li

RE: Time delayed LR (WAS Re: logical replication restrictions)

2022-12-11 Thread Hayato Kuroda (Fujitsu)
Dear Amit, This is a reply for later part of your e-mail. > > (2) About the timeout issue > > > > When having a look at the physical replication internals, > > it conducts sending feedback and application of delay separately on > > different > processes. > > OTOH, the logical replication needs t

RE: Time delayed LR (WAS Re: logical replication restrictions)

2022-12-11 Thread Takamichi Osumi (Fujitsu)
On Monday, December 12, 2022 2:54 PM Kyotaro Horiguchi wrote: > I asked about unexpected walsender termination caused by this feature but I > think I didn't received an answer for it and the behavior is still exists. > > Specifically, if servers have the following settings, walsender terminates