Re: [bug?] Missed parallel safety checks, and wrong parallel safety

On Tue, Jul 27, 2021 at 10:44 AM Amit Kapila wrote: > > On Mon, Jul 26, 2021 at 8:33 PM Robert Haas wrote: > Consider below ways to allow the user to specify the parallel-safety option: > > (a) > CREATE TABLE table_name (...) PARALLEL DML { UNSAFE | RESTRICTED | SAFE } ... > ALTER TABLE

pg_receivewal starting position

Hello, I've notived that pg_receivewal logic for deciding which LSN to start streaming at consists of: - looking up the latest WAL file in our destination folder, and resume from here - if there isn't, use the current flush location instead. This behaviour surprised me when using it with a

Re: Removing unneeded self joins

On 7/16/21 12:28 AM, Zhihong Yu wrote: On Thu, Jul 15, 2021 at 8:25 AM Zhihong Yu > wrote: bq. We can proof the uniqueness proof -> prove Fixed 1. Collect all mergejoinable join quals looks like a.x = b.x  quals looks like -> quals which look

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

On Mon, Jul 26, 2021 at 11:03 PM Bossart, Nathan wrote: > > For PreAuthDelay, with the comment I wanted to say that the MyLatch is > > not the correct one we would want to wait for. Since there is no > > problem in using it there, I changed the comment to following: > > /* > > *

Re: ORDER BY pushdowns seem broken in postgres_fdw

Le mardi 27 juillet 2021, 03:19:18 CEST David Rowley a écrit : > On Thu, 22 Jul 2021 at 20:49, Ronan Dunklau wrote: > > Le jeudi 22 juillet 2021, 09:44:54 CEST David Rowley a écrit : > > > Can you also use explain (verbose, costs off) the same as the other > > > tests in that area. Having the

Re: [bug?] Missed parallel safety checks, and wrong parallel safety

On Mon, Jul 26, 2021 at 8:33 PM Robert Haas wrote: > > On Sat, Jul 24, 2021 at 5:52 AM Amit Kapila wrote: > > I think for the consistency argument how about allowing users to > > specify a parallel-safety option for both partitioned and > > non-partitioned relations but for non-partitioned

Re: Slim down integer formatting

> "David" == David Rowley writes: David> I think the mistake is that the header file is not in David> src/include/common. For some reason, it's ended up with all the David> .c files in src/common. David> I imagine Andrew did this because he didn't ever expect anything David> else to

Re: Some code cleanup for pgbench and pg_verifybackup

Bonjour Michaël-san, The semantics for fatal vs error is that an error is somehow handled while a fatal is not. If the log message is followed by an cold exit, ISTM that fatal is the right call, and I cannot help if other commands do not do that. ISTM more logical to align other commands to

Re: Slim down integer formatting

On Tue, 27 Jul 2021 at 15:08, Greg Nancarrow wrote: > > On Tue, Jul 27, 2021 at 12:42 PM Michael Paquier wrote: > > > > #include "common/int.h" > > +#include "d2s_intrinsics.h" > > Er, are you sure about this part? The first version of the patch did > > that in a different, also incorrect,

Re: row filtering for logical replication

On Tue, Jul 27, 2021 at 6:21 AM houzj.f...@fujitsu.com wrote: > 1) UPDATE a nonkey column in publisher. > 2) Use debugger to block the walsender process in function >pgoutput_row_filter_exec_expr(). > 3) Open another psql to connect the publisher, and drop the table which > updated >in

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Mon, Jul 26, 2021 at 11:01 PM Masahiko Sawada wrote: > > I'll experiment with the proposed ideas including this idea in more > scenarios and share the results tomorrow. > I've done some benchmarks for proposed data structures. In this trial, I've done with the scenario where dead tuples are

Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness

On 7/26/21, 5:48 PM, "Andres Freund" wrote: > On 2021-07-26 20:27:21 +, Bossart, Nathan wrote: >> +1. I was confused by this when working on a WAL pre-allocation >> patch [0]. Perhaps it could be replaced by a new parameter and a new >> field in pg_stat_wal. How about something like

Re: Slim down integer formatting

On Tue, Jul 27, 2021 at 12:42 PM Michael Paquier wrote: > > #include "common/int.h" > +#include "d2s_intrinsics.h" > Er, are you sure about this part? The first version of the patch did > that in a different, also incorrect, way. Er, I was just trying to help out, so at least the patch could

Re: Slim down integer formatting

On Tue, 27 Jul 2021 at 14:42, Michael Paquier wrote: > When applying some micro-benchmarking to stress those APIs, how much > does this change things? At the end of the day, this also comes down > to an evaluation of pg_ulltoa_n() and pg_ultoa_n(). I'd suggest something like creating a table

Re: Slim down integer formatting

On Tue, Jul 27, 2021 at 12:28:22PM +1000, Greg Nancarrow wrote: > That patch didn't apply for me (on latest source) so I've attached an > equivalent with those changes, that does apply, and also tweaks the > Makefile include path to address that #include issue. When applying some

Re: visibility map corruption

On Sat, Jul 24, 2021 at 10:01:05AM -0400, Bruce Momjian wrote: > On Fri, Jul 23, 2021 at 09:01:18PM -0400, Bruce Momjian wrote: > > On Fri, Jul 23, 2021 at 05:47:18PM -0700, Peter Geoghegan wrote: > > > > I could perhaps see corruption happening if pg_control's oldest xid > > > > value was closer

Re: [UNVERIFIED SENDER] Re: pg_upgrade can result in early wraparound on databases with high transaction load

This patch has been applied back to 9.6 and will appear in the next minor release. --- On Tue, May 18, 2021 at 01:26:38PM +0200, Drouvot, Bertrand wrote: > Hi, > > On 5/4/21 10:17 AM, Drouvot, Bertrand wrote: > > >

Re: Allow batched insert during cross-partition updates

On Thu, Jul 22, 2021 at 2:18 PM vignesh C wrote: > On Fri, Jul 2, 2021 at 7:35 AM Amit Langote wrote: > > On Fri, Jul 2, 2021 at 1:39 AM Tom Lane wrote: > > > > > > Amit Langote writes: > > > > [ v6-0001-Allow-batching-of-inserts-during-cross-partition-.patch ] > > > > > > Per the cfbot, this

Re: Slim down integer formatting

On Tue, Jul 27, 2021 at 9:51 AM David Fetter wrote: > > In covering the int64 versions, I swiped a light weight division from > the Ryu stuff. I'm pretty sure that what I did is not how to do > #includes, but it's a PoC. What would be a better way to do this? > That patch didn't apply for me

a thinko in b676ac443b6

Hi, I noticed $subject while rebasing my patch at [1] to enable batching for the inserts used in cross-partition UPDATEs. b676ac443b6 did this: - resultRelInfo->ri_PlanSlots[resultRelInfo->ri_NumSlots] = - MakeSingleTupleTableSlot(planSlot->tts_tupleDescriptor, -

Re: Fix around conn_duration in pgbench

Hello Fujii-san, Thank you for looking at it. On Tue, 27 Jul 2021 03:04:35 +0900 Fujii Masao wrote: > case CSTATE_FINISHED: > + /* per-thread last disconnection time is not > measured */ > > Could you tell me why we don't need to do this

Re: Incorrect usage of strtol, atoi for non-numeric junk inputs

On Mon, Jul 26, 2021 at 05:46:22PM +0900, Kyotaro Horiguchi wrote: > Thanks for revising and committing! I'm fine with all of the recent > discussions on the committed part. Though I don't think it works for > "live" command line options, making the omitting policy symmetric > looks good. I see

Re: shared-memory based stats collector

Hi, On 2021-07-26 17:52:01 +0900, Kyotaro Horiguchi wrote: > > > Yeah, thank you very much for checking that. However, this patch is > > > now developed in Andres' GitHub repository. So I'm at a loss what to > > > do for the failure.. > > > > I'll post a rebased version soon. > > (Sorry if you

Re: ORDER BY pushdowns seem broken in postgres_fdw

On Thu, 22 Jul 2021 at 20:49, Ronan Dunklau wrote: > > Le jeudi 22 juillet 2021, 09:44:54 CEST David Rowley a écrit : > > Can you also use explain (verbose, costs off) the same as the other > > tests in that area. Having the costs there would never survive a run > > of the buildfarm. Different

RE: row filtering for logical replication

On July 23, 2021 6:16 PM Amit Kapila wrote: > On Fri, Jul 23, 2021 at 2:27 PM Rahila Syed wrote: > > > > The column comparison for row filtering happens before the unchanged > > toast columns are filtered. Unchanged toast columns are filtered just > > before writing the tuple to output stream. >

Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness

Hi, On 2021-07-25 12:10:07 +0900, Fujii Masao wrote: > It's also worth showing them in monitoring stats view like pg_stat_wal? I'm not convinced that's all that meaningful. It makes sense to include it as part of the checkpoint output, because checkpoints determine when WAL can be recycled etc.

Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness

Hi, On 2021-07-26 20:27:21 +, Bossart, Nathan wrote: > +1. I was confused by this when working on a WAL pre-allocation > patch [0]. Perhaps it could be replaced by a new parameter and a new > field in pg_stat_wal. How about something like log_wal_init_interval, > where the value is the

Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness

On 7/26/21, 5:23 PM, "Fujii Masao" wrote: > On 2021/07/27 5:27, Bossart, Nathan wrote: >> +1. I was confused by this when working on a WAL pre-allocation >> patch [0]. Perhaps it could be replaced by a new parameter and a new >> field in pg_stat_wal. How about something like

Re: needless complexity in StartupXLOG

On Mon, Jul 26, 2021 at 03:53:20PM -0400, Robert Haas wrote: > Yeah, and there again, it's a lot easier to test if we don't have as > many cases. Now no single change is going to fix that, but the number > of flag variables in xlog.c is simply bonkers. This particular stretch > of code uses 3 of

Re: list of extended statistics on psql (\dX)

Hi Tomas and Justin, On 2021/07/27 4:26, Tomas Vondra wrote: Hi, I've pushed the last version of the fix, including the regression tests etc. Backpatch to 14, where \dX was introduced. Thank you! Regards, Tatsuro Yamada

Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness

On 2021/07/27 5:27, Bossart, Nathan wrote: +1. I was confused by this when working on a WAL pre-allocation patch [0]. Perhaps it could be replaced by a new parameter and a new field in pg_stat_wal. How about something like log_wal_init_interval, where the value is the minimum amount of

Re: Some code cleanup for pgbench and pg_verifybackup

On Mon, Jul 26, 2021 at 03:35:29PM -0400, Alvaro Herrera wrote: > On 2021-Jul-26, Fabien COELHO wrote: >> The semantics for fatal vs error is that an error is somehow handled while a >> fatal is not. If the log message is followed by an cold exit, ISTM that >> fatal is the right call, and I cannot

Slim down integer formatting

Folks, Please find attached a patch to do $subject. It's down to a one table lookup and 3 instructions. In covering the int64 versions, I swiped a light weight division from the Ryu stuff. I'm pretty sure that what I did is not how to do #includes, but it's a PoC. What would be a better way to

Re: Added schema level support for publication.

On Mon, Jul 26, 2021 at 3:21 PM vignesh C wrote: > > Thanks for the comment, this is modified in the v15 patch attached. > I have several minor review comments. (1) src/backend/catalog/objectaddress.c Should start comment sentences with an uppercase letter, for consistency. + /* fetch

pg_settings.pending_restart not set when line removed

Hi I got a report from Gabriele Bartolini and team that the pg_settings view does not get the pending_restart flag set when a setting's line is removed from a file (as opposed to its value changed). The explanation seems to be that GUC_PENDING_RESTART is set by set_config_option, but when

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On Mon, Jul 26, 2021 at 4:28 PM Stephen Frost wrote: > so ... yes and no. There's an awful lot being ascribed to > 'administrator' without any definition of it being actually given. We > are working in this thread to explicitly split up superuser privileges > to allow them to be granted to

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Alvaro Herrera writes: > On 2021-Jul-26, Tom Lane wrote: >> Uh, why not? If you own the trigger, you can drop it, so why shouldn't >> you be able to temporarily disable it? > I think an auditing system that can be turned off by the audited user is > pretty much useless. Or did I misunderstood

Re: automatically generating node support functions

Peter Eisentraut writes: >> The first eight patches are to clean up various inconsistencies to make >> parsing or generation easier. > Are there any concerns about the patches 0001 through 0008? Otherwise, > maybe we could get those out of the way. I looked through those and don't have any

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On 2021-Jul-26, Tom Lane wrote: > Stephen Frost writes: > > ... Tom's suggestion > > would work, of course, but it would mean having to create event triggers > > for all the roles in the system, and would those roles who own those > > event triggers be able to disable them..? > > Uh, why not?

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Stephen Frost writes: > ... Tom's suggestion > would work, of course, but it would mean having to create event triggers > for all the roles in the system, and would those roles who own those > event triggers be able to disable them..? Uh, why not? If you own the trigger, you can drop it, so why

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

I wrote: > Possibly this could be generalized to "fire on commands performed by > any role the trigger owner is a member of", but then I'm a bit less > sure that it's safe from both roles' perspectives. After further thought, I can't poke a hole in that concept. We'd keep the rule that the

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > On 2021-Jul-26, Tom Lane wrote: > > > What if we allow event triggers owned by non-superusers, but only fire > > them on commands performed by the trigger's owner? This sidesteps all > > the issues of who has which privileges and

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On 2021-Jul-26, Tom Lane wrote: > What if we allow event triggers owned by non-superusers, but only fire > them on commands performed by the trigger's owner? This sidesteps all > the issues of who has which privileges and whether Alice is malicious > towards Bob or vice versa, because there is

Re: Removing "long int"-related limit on hash table sizes

On 2021-Jul-26, Tom Lane wrote: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > > We also have the (U)INT64CONST() macros, which are about about two > > thirds as common as the U?LL? suffixes. > > Yeah. Ideally we'd forbid direct use of the suffixes and insist > you go

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jul 26, 2021 at 4:12 PM Robert Haas wrote: > > I think I may not have expressed myself clearly enough here. What I'm > > concerned about is: Alice should not be permitted to preventing Bob > > from doing something which Bob is

Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness

On 7/24/21, 8:10 PM, "Fujii Masao" wrote: > On 2021/07/25 7:50, Andres Freund wrote: >> Hi, >> >> I've been repeatedly confused by the the number of WAL files supposedly >> added. Even when 100s of new WAL files are created the relevant portion >> of log_checkpoints will only ever list zero or

Re: Removing "long int"-related limit on hash table sizes

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > We also have the (U)INT64CONST() macros, which are about about two > thirds as common as the U?LL? suffixes. Yeah. Ideally we'd forbid direct use of the suffixes and insist you go through those macros, but I don't know of

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

> On Jul 26, 2021, at 1:12 PM, Robert Haas wrote: > > Alice should not be permitted to preventing Bob > from doing something which Bob is allowed to do and Alice is not > allowed to do. That sounds intuitively reasonable, though it depends on what "which Bob is allowed to do" means. For

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Stephen Frost writes: > As I understood Mark's suggestion, the trigger would run but would have > the privileges of the intersection of both user's permissions, which is > an interesting idea but not one we've got any way to really do today as > each privilege check would now need to check two

Re: Removing "long int"-related limit on hash table sizes

Alvaro Herrera writes: > On 2021-Jul-25, Ranier Vilela wrote: > >> > BTW, one aspect of this that I'm unsure how to tackle is the >> > common usage of "L" constants; in particular, "work_mem * 1024L" >> > is a really common idiom that we'll need to get rid of. Not sure >> > that grep will be a

Re: needless complexity in StartupXLOG

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jul 26, 2021 at 1:32 PM Stephen Frost wrote: > > Yeah, tend to agree with this too ... but something I find a bit curious > > is the comment: > > > > * Insert a special WAL record to mark the end of > > * recovery, since we aren't

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On Mon, Jul 26, 2021 at 4:12 PM Robert Haas wrote: > I think I may not have expressed myself clearly enough here. What I'm > concerned about is: Alice should not be permitted to preventing Bob > from doing something which Bob is allowed to do and Alice is not > allowed to do. If Alice is the

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On Mon, Jul 26, 2021 at 4:05 PM Stephen Frost wrote: > As I understood Mark's suggestion, the trigger would run but would have > the privileges of the intersection of both user's permissions, which is > an interesting idea but not one we've got any way to really do today as > each privilege check

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Jul 23, 2021 at 4:57 PM Mark Dilger > wrote: > > > On Jul 23, 2021, at 1:54 PM, Robert Haas wrote: > > > Yeah, but you're inventing a system for allowing the restriction on a > > > GUC to be something other than is-superuser in

Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace

Gilles Darold writes: > [ v4-0001-regexp-foo-functions.patch ] I started to work through this and was distressed to realize that it's trying to redefine regexp_replace() in an incompatible way. We already have regression=# \df regexp_replace List of functions

Re: needless complexity in StartupXLOG

On Mon, Jul 26, 2021 at 1:32 PM Stephen Frost wrote: > Yeah, tend to agree with this too ... but something I find a bit curious > is the comment: > > * Insert a special WAL record to mark the end of > * recovery, since we aren't doing a checkpoint. > > ... immediately after setting promoted =

Re: Some code cleanup for pgbench and pg_verifybackup

On 2021-Jul-26, Fabien COELHO wrote: > > - pgbench and pg_verifybackup make use of pg_log_fatal() to report > > some failures in code paths dedicated to command-line options, which > > is inconsistent with all the other tools that use pg_log_error(). > > The semantics for fatal vs error is that

Re: list of extended statistics on psql (\dX)

Hi, I've pushed the last version of the fix, including the regression tests etc. Backpatch to 14, where \dX was introduced. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Removing "long int"-related limit on hash table sizes

On 2021-Jul-25, Ranier Vilela wrote: > > BTW, one aspect of this that I'm unsure how to tackle is the > > common usage of "L" constants; in particular, "work_mem * 1024L" > > is a really common idiom that we'll need to get rid of. Not sure > > that grep will be a useful aid for finding those. >

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On Fri, Jul 23, 2021 at 4:57 PM Mark Dilger wrote: > > On Jul 23, 2021, at 1:54 PM, Robert Haas wrote: > > Yeah, but you're inventing a system for allowing the restriction on a > > GUC to be something other than is-superuser in the very patch we're > > talking about. So it could be something

Re: Skip temporary table schema name from explain-verbose output.

Alvaro Herrera writes: > Oh, you meant this one. To be honest I don't remember *why* this code > wants to show remote temp tables as just "pg_temp" ... it's possible > that some test in the DDL-to-JSON code depended on this behavior. > Without spending too much time analyzing it, I agree that it

Re: Rename of triggers for partitioned tables

From: Tom Lane Sent: Monday, July 26, 2021 19:38 To: Alvaro Herrera Subject: Re: Rename of triggers for partitioned tables > Yeah, we don't support partial indexes on catalogs, and this example > doesn't make me feel like we ought to open that can of worms. I asked why such an index doesn't

Why don't update minimum recovery point in xact_redo_abort

Hi, all Recently, I got a PANIC while restarts standby, which can be reproduced by the following steps, based on pg 11: 1. begin a transaction in primary node; 2. create a table in the transaction; 3. insert lots of data into the table; 4. do a checkpoint, and restart standby after checkpoint is

Re: Fix around conn_duration in pgbench

On 2021/06/30 14:43, Yugo NAGATA wrote: On Wed, 30 Jun 2021 14:35:37 +0900 Yugo NAGATA wrote: Hello Asif, On Tue, 29 Jun 2021 13:21:54 + Asif Rehman wrote: The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements

Re: Skip temporary table schema name from explain-verbose output.

On 2021-Jul-26, Tom Lane wrote: > On the other hand, I don't like 0002 one bit, because it's not accounting > for whether the temp schema it's mangling is *our own* temp schema or some > other session's. I do not think it is wise or even safe to report some > other temp schema as being

Re: Rename of triggers for partitioned tables

Alvaro Herrera writes: > Arne complained that there should be a unique constraint on (tgrelid, > tgparentid) which would sidestep the need for this to be a loop. I > don't think it's really necessary, and I'm not sure how to create a > system index WHERE tgparentid <> 0. Yeah, we don't support

Re: Have I found an interval arithmetic bug?

On Sun, Jul 25, 2021 at 11:56:54AM -0700, Bryn Llewellyn wrote: > As far as I’ve been able, the PG documentation doesn’t do a good job of > defining the semantics of any of these operations. Some (like the “justify” This is because fractional interval values are not used or asked about often. >

Re: Skip temporary table schema name from explain-verbose output.

Robert Haas writes: > On Mon, Jul 26, 2021 at 12:49 PM Tom Lane wrote: >> I can't really see any situation in which it's important >> to report the exact schema name of our own temp schema. > It would actually be nice if there were some easy way of getting that > for the rare situations in

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

On 7/24/21, 9:16 AM, "Bharath Rupireddy" wrote: > On Fri, Jul 23, 2021 at 4:40 AM Bossart, Nathan wrote: >> I would suggest changing "attach from a debugger" to "attaching with a >> debugger." > > Thanks. IMO, the following looks better: > Waiting on connection startup before authentication

Re: needless complexity in StartupXLOG

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > So at the moment I am leaning toward the view that we should just > remove this check entirely, as in the attached, proposed patch. Haven't dug in deeply but at least following your explanation and reading over the patch and the code a

Re: Skip temporary table schema name from explain-verbose output.

On 2021-Jul-26, Tom Lane wrote: > Alvaro, you seem to be responsible for both the existence of the separate > get_namespace_name_or_temp function and the fact that it's being avoided > here. I wonder what you think about this. The reason I didn't touch get_namespace_name then (e9a077cad379) was

Re: badly calculated width of emoji in psql

On Fri, 2021-07-23 at 17:42 +0200, Pavel Stehule wrote: > čt 22. 7. 2021 v 0:12 odesílatel Jacob Champion napsal: > > > > Pavel, I'd be interested to see what your benchmarks find with this > > code. Does this fix the original issue for you? > > I can confirm that the original issue is fixed.

Re: Skip temporary table schema name from explain-verbose output.

On Mon, Jul 26, 2021 at 12:49 PM Tom Lane wrote: > I can't really see any situation in which it's important > to report the exact schema name of our own temp schema. It would actually be nice if there were some easy way of getting that for the rare situations in which there are problems. For

Re: Avoiding data loss with synchronous replication

On 7/24/21, 5:25 PM, "Andres Freund" wrote: > First, from the user experience side of things, the issue is that this seems > to propose violating read-your-own-writes. Within a single connection to a > single node. Which imo is *far* worse than seeing writes that haven't yet been > acknowledged

Re: Rename of triggers for partitioned tables

On 2021-Jul-25, Tom Lane wrote: > Perhaps there's no actual bug there, but it's still horrible coding. > For one thing, the implication that found could be negative is extremely > confusing to readers. A boolean might be better. However, I wonder why > you bothered with a flag in the first

Re: when the startup process doesn't (logging startup delays)

On Mon, Jul 26, 2021 at 11:30 AM Justin Pryzby wrote: > > Maybe I'm missing something here, but I don't understand the purpose > > of this. You can always combine two functions into one, but it's only > > worth doing if you end up with less code, which doesn't seem to be the > > case here. > > 4

Re: Skip temporary table schema name from explain-verbose output.

On Mon, 26 Jul 2021 at 17:49, Tom Lane wrote: > > I wrote: > > Simon Riggs writes: > >> Surely we need a test to exercise this works? Otherwise ready... > > > There are lots of places in the core regression tests where we'd have > > used a temp table, except that we needed to do EXPLAIN and the

Re: Skip temporary table schema name from explain-verbose output.

I wrote: > Simon Riggs writes: >> Surely we need a test to exercise this works? Otherwise ready... > There are lots of places in the core regression tests where we'd have > used a temp table, except that we needed to do EXPLAIN and the results > would've been unstable, so we used a short-lived

Re: .ready and .done files considered harmful

On 7/26/21, 6:31 AM, "Robert Haas" wrote: > In terms of immediate next steps, I think we should focus on > eliminating the O(n^2) problem and not get sucked into a bigger > redesign. The patch on the table aims to do just that much and I think > that's a good thing. I agree. I'll leave further

needless complexity in StartupXLOG

StartupXLOG() has code beginning around line 7900 of xlog.c that decides, at the end of recovery, between four possible courses of action. It either writes an end-of-recovery record, or requests a checkpoint, or creates a checkpoint, or does nothing, depending on the value of 3 flag variables, and

Re: Inaccurate error message when set fdw batch_size to 0

On 2021/07/26 13:56, Bharath Rupireddy wrote: On Thu, Jul 15, 2021 at 7:54 PM Bharath Rupireddy wrote: On Mon, Jul 12, 2021 at 10:11 PM Bharath Rupireddy wrote: On Mon, Jul 12, 2021 at 9:20 PM Fujii Masao wrote: + + Avoid Using non-negative Word in Error Messages + + +Do

Re: Case expression pushdown

Tom Lane писал 2021-07-26 18:18: Alexander Pyhalov writes: [ 0001-Allow-pushing-CASE-expression-to-foreign-server-v6.patch ] This doesn't compile cleanly: deparse.c: In function 'foreign_expr_walker.isra.4': deparse.c:920:8: warning: 'collation' may be used uninitialized in this function

Re: when the startup process doesn't (logging startup delays)

On Mon, Jul 26, 2021 at 10:13:09AM -0400, Robert Haas wrote: > I don't think walkdir() has any business calling LogStartupProgress() > at all. It's supposed to be a generic function, not one that is only > available to be called from the startup process, or has different > behavior there. From my

Re: Case expression pushdown

Alexander Pyhalov writes: > [ 0001-Allow-pushing-CASE-expression-to-foreign-server-v6.patch ] This doesn't compile cleanly: deparse.c: In function 'foreign_expr_walker.isra.4': deparse.c:920:8: warning: 'collation' may be used uninitialized in this function [-Wmaybe-uninitialized] if

Re: [bug?] Missed parallel safety checks, and wrong parallel safety

On Sat, Jul 24, 2021 at 5:52 AM Amit Kapila wrote: > I think for the consistency argument how about allowing users to > specify a parallel-safety option for both partitioned and > non-partitioned relations but for non-partitioned relations if users > didn't specify, it would be computed

Re: Skip temporary table schema name from explain-verbose output.

Simon Riggs writes: > Sounds like a good change. > Surely we need a test to exercise this works? Otherwise ready... There are lots of places in the core regression tests where we'd have used a temp table, except that we needed to do EXPLAIN and the results would've been unstable, so we used a

Re: when the startup process doesn't (logging startup delays)

On Sun, Jul 25, 2021 at 1:56 PM Justin Pryzby wrote: > On Fri, Jul 23, 2021 at 04:09:47PM +0530, Nitin Jadhav wrote: > > > I think walkdir() should only call LogStartupProgress(FSYNC_IN_PROGRESS, > > > path); > > > when action == datadir_fsync_fname. > > > > I agree and fixed it. > > I saw that

Re: SQL/JSON: JSON_TABLE

Below are a few small comments from a casual read-through. I noticed that there was a new version posted after I had finished perusing, but it seems to address other aspects. + Gerenates a column and inserts a composite SQL/JSON s/Gerenates/Generates/ + into both child and parrent

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Mon, Jul 26, 2021 at 1:07 AM Yura Sokolov wrote: > > Hi, > > I've dreamed to write more compact structure for vacuum for three > years, but life didn't give me a time to. > > Let me join to friendly competition. > > I've bet on HATM approach: popcount-ing bitmaps for non-empty elements. Thank

Re: WIP: Relaxing the constraints on numeric scale

On Fri, 23 Jul 2021 at 16:50, Tom Lane wrote: > > OK, I've now studied this more closely, and have some additional > nitpicks: > > * I felt the way you did the documentation was confusing. It seems > better to explain the normal case first, and then describe the two > extended cases. OK, that

Re: .ready and .done files considered harmful

On Fri, Jul 23, 2021 at 5:46 PM Bossart, Nathan wrote: > My apologies for chiming in so late to this thread, but a similar idea > crossed my mind while working on a bug where .ready files get created > too early [0]. Specifically, instead of maintaining a status file per > WAL segment, I was

Re: speed up verifying UTF-8

On Mon, Jul 26, 2021 at 7:55 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > > Just wondering, do you have the code in a GitHub/Gitlab branch? Sorry, I didn't see this earlier. No, I don't. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

On Mon, Jul 26, 2021 at 7:55 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > > Just wondering, do you have the code in a GitHub/Gitlab branch? > > >+ utf8_advance(s, state, len); > >+ > >+ /* > >+ * If we saw an error during the loop, let the caller handle it. We treat > >+ * all

Re: Skip temporary table schema name from explain-verbose output.

On Thu, 29 Apr 2021 at 08:17, Amul Sul wrote: > On Wed, Apr 28, 2021 at 7:56 PM Tom Lane wrote: > > I don't think we should remove them. However, it could make sense to > > print the "pg_temp" alias instead of the real schema name when we > > are talking about myTempNamespace. Basically try to

Re: 2021-07 CF now in progress

On Mon, Jul 19, 2021 at 4:37 PM Ibrar Ahmed wrote: > > > On Mon, Jul 12, 2021 at 4:59 PM Ibrar Ahmed wrote: > >> >> Hackers, >> >> The Commitfest 2021-07 is now in progress. It is one of the biggest one. >> Total number of patches of this commitfest is 342. >> >> Needs review: 204. >> Waiting

Re: speed up verifying UTF-8

Just wondering, do you have the code in a GitHub/Gitlab branch? >+ utf8_advance(s, state, len); >+ >+ /* >+ * If we saw an error during the loop, let the caller handle it. We treat >+ * all other states as success. >+ */ >+ if (state == ERR) >+ return 0; Did you mean state = utf8_advance(s,

Re: speed up verifying UTF-8

Attached is v20, which has a number of improvements: 1. Cleaned up and explained DFA coding. 2. Adjusted check_ascii to return bool (now called is_valid_ascii) and to produce an optimized loop, using branch-free accumulators. That way, it doesn't need to be rewritten for different input lengths.

Re: shared-memory based stats collector

> > Yeah, thank you very much for checking that. However, this patch is > > now developed in Andres' GitHub repository. So I'm at a loss what to > > do for the failure.. > > I'll post a rebased version soon. (Sorry if you feel being hurried, which I didn't meant to.) regards. -- Kyotaro

Re: Incorrect usage of strtol, atoi for non-numeric junk inputs

At Mon, 26 Jul 2021 15:01:35 +0900, Michael Paquier wrote in > On Sat, Jul 24, 2021 at 07:41:12PM +0900, Michael Paquier wrote: > > I have looked at that over the last couple of days, and applied it > > after some small fixes, including an indentation. > > One thing that we forgot here is the

Re: [HACKERS] logical decoding of two-phase transactions

On Fri, Jul 23, 2021 at 8:08 PM Amit Kapila wrote: > > On Tue, Jul 20, 2021 at 9:24 AM Peter Smith wrote: > > > > Please find attached the latest patch set v98* > > > > Review comments: > [...] > With Regards, > Amit Kapila. Thanks for your review comments. I having been

  1   2   >