Re: replay of CREATE TABLESPACE eats data at wal_level=minimal

On Wed, Aug 18, 2021 at 10:47:24AM -0400, Robert Haas wrote: > On Tue, Aug 10, 2021 at 9:35 AM Robert Haas wrote: > > Oh, yeah, I think that works, actually. I was imagining a few problems > > here, but I don't think they really exist. The redo routines for files > > within the directory can't

Re: Skipping logical replication transactions on subscriber side

On Thu, Aug 19, 2021 at 11:48 AM Masahiko Sawada wrote: > > I've attached the updated version patches that incorporated all > comments I got so far unless I'm missing something. Please review > them. > The comments I made on Aug 16 and Aug 17 for the v8-0001 patch don't seem to be addressed in

RE: [PATCH]Remove obsolete macro CHECKFLOATVAL in btree_gist

On Thursday, August 19, 2021 12:28 PM, Michael Paquier wrote >On Wed, Aug 18, 2021 at 10:04:04AM +0900, Michael Paquier wrote: >> Yes, that does not seem wise on performance grounds. The case of >> !zero_is_valid is never reached, so it seems like this code was just a >> copy-paste from the

Re: Skipping logical replication transactions on subscriber side

On Wed, Aug 18, 2021 at 12:12 PM Masahiko Sawada wrote: > > On Wed, Aug 18, 2021 at 3:15 PM Amit Kapila wrote: > > > > On Wed, Aug 18, 2021 at 10:00 AM Masahiko Sawada > > wrote: > > > > > > On Wed, Aug 18, 2021 at 12:02 PM Amit Kapila > > > wrote: > > > > > > > > On Wed, Aug 18, 2021 at

Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o

On Wed, Aug 18, 2021 at 3:45 PM Dilip Kumar wrote: > > On Wed, Aug 18, 2021 at 11:24 AM Amit Kapila wrote: > > > > On Tue, Aug 17, 2021 at 4:34 PM Andres Freund wrote: > > > > > > On 2021-08-17 10:54:30 +0530, Amit Kapila wrote: > > > > 5. How can we provide a strict mechanism to not allow to

Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode

On Wed, Aug 18, 2021 at 09:14:14AM +0900, Michael Paquier wrote: > Sure. aef8948 gets down because of the performance impact. ccf4e27 > was a cleanup following up aef8948, that loses its meaning. And > c3826f8 cannot be let alone because of the reasons why aef8948 was > introduced, as it has no

Re: [PATCH]Remove obsolete macro CHECKFLOATVAL in btree_gist

On Wed, Aug 18, 2021 at 10:04:04AM +0900, Michael Paquier wrote: > Yes, that does not seem wise on performance grounds. The case of > !zero_is_valid is never reached, so it seems like this code was just a > copy-paste from the float code in the backend. Your patch looks right > to me. Applied.

Re: support for windows robocopy in archive_command and restore_command

On 8/18/21 10:32 PM, Julien Rouhaud wrote: > On Thu, Aug 19, 2021 at 5:01 AM Andrew Dunstan wrote: >> It doesn't allow for files to be renamed, but luckily we don't normally >> need it to. > Doesn't the recovery ask to recover the WAL files in > pg_wal/RECOVERYXLOG and the history files in

Re: strange case of "if ((a & b))"

Peter Smith writes: > On Thu, Aug 19, 2021 at 4:29 AM Justin Pryzby wrote: >> - state->oneCol = (origTupdesc->natts == 1) ? true : false; >> + state->oneCol = origTupdesc->natts == 1; FWIW, I am definitely not a fan of removing the parentheses in this context, because readers might

Re: support for windows robocopy in archive_command and restore_command

On Thu, Aug 19, 2021 at 5:01 AM Andrew Dunstan wrote: > > It doesn't allow for files to be renamed, but luckily we don't normally > need it to. Doesn't the recovery ask to recover the WAL files in pg_wal/RECOVERYXLOG and the history files in pg_wal/RECOVERYHISTORY rather than the original names?

Re: Skipping logical replication transactions on subscriber side

On Tue, Aug 17, 2021 at 5:21 PM tanghy.f...@fujitsu.com wrote: > > On Thursday, August 12, 2021 1:53 PM Masahiko Sawada > wrote: > > > > I've attached the updated patches. FYI I've included the patch > > (v8-0005) that fixes the assertion failure during shared fileset > > cleanup to make cfbot

Re: strange case of "if ((a & b))"

On Thu, Aug 19, 2021 at 4:29 AM Justin Pryzby wrote: > > On Wed, Aug 18, 2021 at 02:02:22PM -0400, Bruce Momjian wrote: > > On Thu, Jun 24, 2021 at 09:31:11PM -0500, Justin Pryzby wrote: > > > On Wed, Apr 28, 2021 at 02:40:09PM -0400, Tom Lane wrote: > > > > Justin Pryzby writes: > > > > > These

Re: archive status ".ready" files may be created too early

On 2021-Aug-18, Bossart, Nathan wrote: > As long as XLogBackgroundFlush() found work to do, it would take care > of notifying, but I don't think we can depend on that. However, since > we're primarily using the WAL writer to take care of the case when the > record has already been flushed,

support for windows robocopy in archive_command and restore_command

Quite a few years ago Microsoft recognized that with windows copy and xcopy commands had some serious inadequacies. They therefore created robocopy as a replacement, and it has shipped in all modern versions of Windows. At any rate it's something I think we

Re: .ready and .done files considered harmful

Thanks for the new version of the patch. Overall, I think it is on the right track. +/* + * This .ready file is created out of order, notify archiver to perform + * a full directory scan to archive corresponding WAL file. + */ +StatusFilePath(archiveStatusPath, xlog,

Re: The Free Space Map: Problems and Opportunities

On Tue, Aug 17, 2021 at 5:31 PM Peter Geoghegan wrote: > > Now what's the threshold? 20 out of 100? 50? 80? > > I'm not going to pretend to know the answer. But I will point out that > one DB system whose heap fill factor defaults to 90 seems to have a > symmetric setting for the "open up page

Re: strange case of "if ((a & b))"

On Wed, Aug 18, 2021 at 03:15:21PM -0400, Bruce Momjian wrote: > On Wed, Aug 18, 2021 at 01:28:56PM -0500, Justin Pryzby wrote: > > > > 0002 is a bonus patch I found in my typos branch. I will hold onto it > > > > for > > > > later if nobody wants to deal with it. > > > > > > I am ready to deal

Re: strange case of "if ((a & b))"

On Wed, Aug 18, 2021 at 01:28:56PM -0500, Justin Pryzby wrote: > > > 0002 is a bonus patch I found in my typos branch. I will hold onto it for > > > later if nobody wants to deal with it. > > > > I am ready to deal with this patch. Should I apply it to master soon? > > Thanks for looking at

Re: archive status ".ready" files may be created too early

On 2021-Aug-18, Bossart, Nathan wrote: > I'll add it after XLogBackgroundFlush(). I was wondering which would be better: before or after. XLogBackgroundFlush would do it anyway, so if you do it after then it's not clear to me that it'd do anything (I mean we should not do any new calls of

Re: strange case of "if ((a & b))"

On Wed, Aug 18, 2021 at 02:02:22PM -0400, Bruce Momjian wrote: > On Thu, Jun 24, 2021 at 09:31:11PM -0500, Justin Pryzby wrote: > > On Wed, Apr 28, 2021 at 02:40:09PM -0400, Tom Lane wrote: > > > Justin Pryzby writes: > > > > These look strange to me - the inner parens don't do anything. > > > >

Re: [Patch] change the default value of shared_buffers in postgresql.conf.sample

On Wed, Aug 18, 2021 at 8:16 PM Bruce Momjian wrote: > > On Wed, Aug 18, 2021 at 02:03:56PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > I think the only question is whether this is a PG 15-only patch or a > > > patckpatch to PG 10; I am in favor of the later. > > > > I think you need

Re: RFC: Improve CPU cache locality of syscache searches

OK, here is a hackish WIP to see if we get anywhere with the L1 concept: 0001 is extracted from a patch from Horiguchi-san to remove the "dead" flag 0002 adds the large bucket, but doesn't use it for anything 0003 uses the new bucket for the L1 cache 0004 changes when to rehash 0005 is

Re: [Patch] change the default value of shared_buffers in postgresql.conf.sample

On Wed, Aug 18, 2021 at 02:03:56PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I think the only question is whether this is a PG 15-only patch or a > > patckpatch to PG 10; I am in favor of the later. > > I think you need a lot stronger argument that this is a bug > before you consider

Re: [Patch] change the default value of shared_buffers in postgresql.conf.sample

Bruce Momjian writes: > I think the only question is whether this is a PG 15-only patch or a > patckpatch to PG 10; I am in favor of the later. I think you need a lot stronger argument that this is a bug before you consider back-patching user-visible behavioral changes.

Re: archive status ".ready" files may be created too early

On 8/18/21, 10:48 AM, "alvhe...@alvh.no-ip.org" wrote: > On 2021-Aug-18, alvhe...@alvh.no-ip.org wrote: > >> I realize this means there's a contradiction with my previous argument, >> in that synchronous transaction commit calls XLogWrite at some point, so >> we *are* putting the client-connected

Re: strange case of "if ((a & b))"

On Thu, Jun 24, 2021 at 09:31:11PM -0500, Justin Pryzby wrote: > On Wed, Apr 28, 2021 at 02:40:09PM -0400, Tom Lane wrote: > > Justin Pryzby writes: > > > These look strange to me - the inner parens don't do anything. > > > I wouldn't write it with 2x parens for the same reason I wouldn't write

Re: [Patch] change the default value of shared_buffers in postgresql.conf.sample

On Tue, Jun 29, 2021 at 09:28:04AM +0200, Magnus Hagander wrote: > > 1. Since initdb will replace that string, users will never see this > > entry as-is in live databases. So is it worth doing anything? > > It's not entirely uncommon that users copy the .sample file into their > configuration

Re: archive status ".ready" files may be created too early

On 2021-Aug-18, alvhe...@alvh.no-ip.org wrote: > I realize this means there's a contradiction with my previous argument, > in that synchronous transaction commit calls XLogWrite at some point, so > we *are* putting the client-connected backend in charge of creating the > notify files. However,

Re: archive status ".ready" files may be created too early

On 2021-Aug-18, Bossart, Nathan wrote: > On 8/18/21, 10:06 AM, "alvhe...@alvh.no-ip.org" > wrote: > > So that comment suggests that we should give the responsibility to bgwriter. > > This seems good enough to me. I suppose if bgwriter has a long run of > > buffers to write it could take a

Re: archive status ".ready" files may be created too early

On 8/18/21, 10:06 AM, "alvhe...@alvh.no-ip.org" wrote: > So that comment suggests that we should give the responsibility to bgwriter. > This seems good enough to me. I suppose if bgwriter has a long run of > buffers to write it could take a little bit of time (a few hundred > milliseconds?) but

Re: NAMEDATALEN increase because of non-latin languages

On Thu, Aug 19, 2021 at 12:12 AM Tom Lane wrote: > > Yeah, exactly: conceptually that's simple, but flushing all the bugs > out would be a years-long nightmare. It'd make all the fun we had > with missed attisdropped checks look like a walk in the park. Unless > somebody can figure out a way to

Re: The Free Space Map: Problems and Opportunities

On Wed, Aug 18, 2021 at 7:45 AM Robert Haas wrote: > On Tue, Aug 17, 2021 at 8:31 PM Peter Geoghegan wrote: > > Lets say that VACUUM puts a non-zero usable amount of free space in > > the FSM for a page that it marks all-visible/all-frozen at the same > > time -- this is possible today, of

Re: archive status ".ready" files may be created too early

On 2021-Aug-17, alvhe...@alvh.no-ip.org wrote: > However, why do it in a WAL-producing client-connected backend? It > strikes me as a bad thing to do, because you are possibly causing delays > for client-connected backends. I suggest that we should give this task > to the WAL writer process --

Re: NAMEDATALEN increase because of non-latin languages

On 8/18/21 12:39 PM, Alvaro Herrera wrote: > On 2021-Aug-18, Tom Lane wrote: > >> I wonder though if we could fix the immediate problem with something >> less ambitious. The hard part of the full proposal, I think, is >> separating permanent identity from physical position. If we were to >>

Re: NAMEDATALEN increase because of non-latin languages

On 2021-Aug-18, Tom Lane wrote: > I wonder though if we could fix the immediate problem with something > less ambitious. The hard part of the full proposal, I think, is > separating permanent identity from physical position. If we were to > split out *only* the display order from that, the

Re: The Free Space Map: Problems and Opportunities

On Wed, Aug 18, 2021 at 7:36 AM Robert Haas wrote: > > Though I think that these backends should cooperate more, some amount > > of competition is probably necessary. If FSM_CATEGORIES used 3 bits > > instead of 8, then the backends could fall back on caring about some > > other thing that

Re: NAMEDATALEN increase because of non-latin languages

Andrew Dunstan writes: > On 8/18/21 10:53 AM, Tom Lane wrote: >> Yeah, it would annoy the heck out of me too. Again there's a potential >> technical solution, which is to decouple the user-visible column order >> from the storage order. However, multiple people have tilted at that >> windmill

Re: NAMEDATALEN increase because of non-latin languages

On 8/18/21 10:53 AM, Tom Lane wrote: > Julien Rouhaud writes: >> On Wed, Aug 18, 2021 at 10:21 PM Tom Lane wrote: >>> I wonder if we'd get complaints from changing the catalog column layouts >>> that much. People are used to the name at the front, I think. OTOH, >>> I expected a lot of

Re: Don't clean up LLVM state when exiting in a bad way

On Wed, Aug 18, 2021 at 8:01 AM Jelte Fennema wrote: > Hi, > > I ran into some segfaults when using Postgres that was compiled with LLVM > 7. According to the backtraces these crashes happened during the call to > llvm_shutdown, during cleanup after another out of memory condition. It > seems

Don't clean up LLVM state when exiting in a bad way

Hi, I ran into some segfaults when using Postgres that was compiled with LLVM 7. According to the backtraces these crashes happened during the call to llvm_shutdown, during cleanup after another out of memory condition. It seems that calls to LLVMOrcDisposeInstance, can crash (at least on LLVM

Re: NAMEDATALEN increase because of non-latin languages

Julien Rouhaud writes: > On Wed, Aug 18, 2021 at 10:21 PM Tom Lane wrote: >> I wonder if we'd get complaints from changing the catalog column layouts >> that much. People are used to the name at the front, I think. OTOH, >> I expected a lot of bleating about the OID column becoming frontmost,

Re: replay of CREATE TABLESPACE eats data at wal_level=minimal

On Tue, Aug 10, 2021 at 9:35 AM Robert Haas wrote: > Oh, yeah, I think that works, actually. I was imagining a few problems > here, but I don't think they really exist. The redo routines for files > within the directory can't possibly care about having the old files > erased for them, since that

Re: The Free Space Map: Problems and Opportunities

On Tue, Aug 17, 2021 at 8:31 PM Peter Geoghegan wrote: > Lets say that VACUUM puts a non-zero usable amount of free space in > the FSM for a page that it marks all-visible/all-frozen at the same > time -- this is possible today, of course. To me this seems > contradictory, at least when there

Re: NAMEDATALEN increase because of non-latin languages

On 18.08.21 13:33, Julien Rouhaud wrote: Agreed, but I don't have access to such hardware. However this won't influence the memory overhead part, and there is already frequent problems with that, especially since declarative partitioning, On the flip side, with partitioning you need room for

Re: NAMEDATALEN increase because of non-latin languages

On Wed, Aug 18, 2021 at 10:21 PM Tom Lane wrote: > > Anyway, this whole argument could be rendered moot if we could convert > name to a variable-length type. That would satisfy *both* sides of > the argument, since those who need long names could have them, while > those who don't would see net

Re: The Free Space Map: Problems and Opportunities

On Tue, Aug 17, 2021 at 6:11 PM Peter Geoghegan wrote: > Again, it's all about *systemic* effects. A FSM request is basically a > choice *among* blocks that could in principle satisfy the request -- > often the number of basically-satisfactory blocks is huge (way too > large, even). You have to

Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION

On 10.08.21 05:22, Amit Kapila wrote: Yeah, unless we change design drastically we might not be able to do a refresh for dropped publications, for add it is possible. It seems most of the people responded on this thread that we can be consistent in terms of refreshing for add/drop at this stage

Re: .ready and .done files considered harmful

On Tue, Aug 17, 2021 at 4:19 PM Bossart, Nathan wrote: > Thinking further, I think the most important thing to ensure is that > resetting the flag happens before we begin the directory scan. > Consider the following scenario in which a timeline history file would > potentially be lost: > >

Re: NAMEDATALEN increase because of non-latin languages

John Naylor writes: > The main thing I'm worried about is the fact that a name would no longer > fit in a Datum. The rest I think we can mitigate in some way. Not sure what you mean by that? name is a pass-by-ref data type. Anyway, this whole argument could be rendered moot if we could convert

Re: Parallel scan with SubTransGetTopmostTransaction assert coredump

On Wed, Aug 18, 2021 at 5:00 AM Robert Haas wrote: > > Ah ha! Thank you. So I think what I was missing here is that even > though the transaction snapshot is not a well-defined concept when > !IsolationUsesXactSnapshot(), we still need TransactionXmin to be set > to a value that's earlier than

Re: Use extended statistics to estimate (Var op Var) clauses

> On Aug 18, 2021, at 3:43 AM, Tomas Vondra > wrote: > > I've pushed everything (generator and results) to this github repo Thanks for the link. I took a very brief look. Perhaps we can combine efforts. I need to make progress on several other patches first, but hope to get back to

Re: NAMEDATALEN increase because of non-latin languages

Em qua., 18 de ago. de 2021 às 09:33, Laurenz Albe escreveu: > On Wed, 2021-08-18 at 08:16 -0300, Ranier Vilela wrote: > > Em qua., 18 de ago. de 2021 às 08:08, Денис Романенко < > deromane...@gmail.com> escreveu: > > > Hello dear hackers. I understand the position of the developers > community

Re: Table AM modifications to accept column projection lists

On Thu, Jul 1, 2021 at 7:42 AM Jacob Champion wrote: > > Hi all, > > Ashwin, Deep, and I were discussing this patch today. We agree that > it's fairly difficult to review in its current state, and the lack of a > concrete implementation of the new API isn't helping. (A big chunk of > the context

Re: NAMEDATALEN increase because of non-latin languages

On Wed, 2021-08-18 at 08:16 -0300, Ranier Vilela wrote: > Em qua., 18 de ago. de 2021 às 08:08, Денис Романенко > escreveu: > > Hello dear hackers. I understand the position of the developers community > > about > > NAMEDATALEN length - and, in fact, 63 bytes is more than enough - but only >

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

Hi: patch v4 fixed the 2 bugs Zhihong reported. Any feedback is welcome. v4-0005-Support-UniqueKey-on-JoinRel.patch Description: Binary data v4-0002-Just-some-utils-functions.patch Description: Binary data v4-0004-Support-UniqueKey-on-BaseRel.patch Description: Binary data

Re: NAMEDATALEN increase because of non-latin languages

On Wed, Aug 18, 2021 at 8:03 PM Hannu Krosing wrote: > > Also - have we checked that at least the truncation does not cut utf-8 > characters in half ? Yes, same for all other places that can truncate text (like the query text in pg_stat_activity and similar). See usage of pg_mbcliplen() in

pgbench functions as extension

Has anybody worked on making the pgbench internal functions available as extensions ? I mean the ones from " Built-In Functions" [*] Some of these are probably available in other extensions or even as builtins but having things like hash_fnv1a() or random_zipfian() which are guaranteed to have

Re: Window Function "Run Conditions"

Hi David: Thanks for the patch. On Wed, Aug 18, 2021 at 6:40 PM David Rowley wrote: > > On Tue, 17 Aug 2021 at 03:51, Zhihong Yu wrote: > > + if ((res->monotonic & MONOTONICFUNC_INCREASING) == > > MONOTONICFUNC_INCREASING) > > > > The above can be simplified as 'if

Re: NAMEDATALEN increase because of non-latin languages

On Wed, Aug 18, 2021 at 8:04 PM John Naylor wrote: > > > > > Agreed, but I don't have access to such hardware. However this won't > > Well, by "recent" I had in mind something more recent than 2002, which is the > time where I see a lot of hits in the archives if you search for this topic.

Re: Is there now an official way to pass column projection to heap AM

> On 18 Aug 2021, at 13:55, Hannu Krosing wrote: > As this was already almost a year ago, have there been any > developments in the core PostgreSQL code for supporting this ? This is the thread where that work was discussed:

Re: NAMEDATALEN increase because of non-latin languages

On Wed, Aug 18, 2021 at 8:03 AM Hannu Krosing wrote: > > Could we just make the limitation to be 64 (or 128) _characters_ not _bytes_ ? That couldn't work because characters are variable length. The limit has to be a fixed length in bytes so we can quickly compute offsets in the attribute tuple.

Re: NAMEDATALEN increase because of non-latin languages

On Wed, Aug 18, 2021 at 7:33 AM Julien Rouhaud wrote: > > Some actual numbers on recent hardware would show what kind of tradeoff is involved. No one has done that for a long time that I recall. > > Agreed, but I don't have access to such hardware. However this won't Well, by "recent" I had in

Re: NAMEDATALEN increase because of non-latin languages

Could we just make the limitation to be 64 (or 128) _characters_ not _bytes_ ? Memory sizes and processor speeds have grown by order(s) of magnitude since the 64 byte limit was decided and supporting non-ASCII charsets properly seems like a prudent thing to do. Also - have we checked that at

Is there now an official way to pass column projection to heap AM

When working on zedstore, the developers solved the lack of support for passing column projection into the AM as explained in the zedstore/README [*] -8<--8<--8<---8<--- Current table am API requires enhancement here to pass down column projection to AM. The patch showcases

Re: PoC/WIP: Extended statistics on expressions

On 8/18/21 5:07 AM, Justin Pryzby wrote: Patch 0001 fixes the "double parens" issue discussed elsewhere in this thread, and patch 0002 tweaks CREATE STATISTICS to treat "(a)" as a simple column reference. From: Tomas Vondra Date: Mon, 16 Aug 2021 17:19:33 +0200 Subject: [PATCH 2/2] fix:

Re: NAMEDATALEN increase because of non-latin languages

I don't very close with PG testing methodology, but I can pay for a server (virtual or dedicated, DO maybe) and give access to it, if anyone has time for that. Or if someone describes to me steps and shows where to look - I can do it by myself.

Re: NAMEDATALEN increase because of non-latin languages

On Wed, Aug 18, 2021 at 7:27 PM John Naylor wrote: > > On Wed, Aug 18, 2021 at 7:15 AM Julien Rouhaud wrote: > > > > Unfortunately, the problem isn't really the additional disk space it > > would require. The problem is the additional performance hit and > > memory overhead, as the catalog

Re: NAMEDATALEN increase because of non-latin languages

On Wed, Aug 18, 2021 at 7:15 AM Julien Rouhaud wrote: > > Unfortunately, the problem isn't really the additional disk space it > would require. The problem is the additional performance hit and > memory overhead, as the catalog names are part of the internal > syscache. Some actual numbers on

Re: NAMEDATALEN increase because of non-latin languages

Em qua., 18 de ago. de 2021 às 08:08, Денис Романенко escreveu: > Hello dear hackers. I understand the position of the developers community > about NAMEDATALEN length - and, in fact, 63 bytes is more than enough - but > only if we speak about latin languages. > > Postgresql has wonderful support

Re: NAMEDATALEN increase because of non-latin languages

On Wed, Aug 18, 2021 at 7:08 PM Денис Романенко wrote: > > Hello dear hackers. I understand the position of the developers community > about NAMEDATALEN length - and, in fact, 63 bytes is more than enough - but > only if we speak about latin languages. > > Postgresql has wonderful support for

NAMEDATALEN increase because of non-latin languages

Hello dear hackers. I understand the position of the developers community about NAMEDATALEN length - and, in fact, 63 bytes is more than enough - but only if we speak about latin languages. Postgresql has wonderful support for unicode in table and column names. And it looks like very good idea to

Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)

Em qua., 18 de ago. de 2021 às 05:30, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > At Tue, 17 Aug 2021 17:04:44 +0900, Michael Paquier > wrote in > > On Fri, Jul 02, 2021 at 06:22:56PM -0300, Ranier Vilela wrote: > > > Em qui., 1 de jul. de 2021 às 17:20, Mahendra Singh Thalor < > >

Re: .ready and .done files considered harmful

Hi, Thanks for the feedback. I have incorporated the suggestion to use an unsynchronized boolean flag to force directory scan. This flag is being set if there is a timeline switch or .ready file is created out of order. Archiver resets this flag in case if it is being set before it begins

Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)

On Wed, Aug 18, 2021 at 6:30 PM Kyotaro Horiguchi wrote: > > By a quick look, FreePageBtreeSearch is called only from > FreePageManagerPutInternal at three points. The first one assumes that > result.found == true, at the rest points are passed only when > fpm->btree_depth > 0, i.e,

Re: Use extended statistics to estimate (Var op Var) clauses

Hi Mark, This thread inspired me to do something fairly similar - a generator that generates queries of varying complexity, executes them on table with and without extended statistics. I've been thinking about that before, but this finally pushed me to do that, and some of the results are

Re: Window Function "Run Conditions"

On Tue, 17 Aug 2021 at 03:51, Zhihong Yu wrote: > + if ((res->monotonic & MONOTONICFUNC_INCREASING) == > MONOTONICFUNC_INCREASING) > > The above can be simplified as 'if (res->monotonic & > MONOTONICFUNC_INCREASING) ' True. I've attached an updated patch. David

Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o

On Wed, Aug 18, 2021 at 11:24 AM Amit Kapila wrote: > > On Tue, Aug 17, 2021 at 4:34 PM Andres Freund wrote: > > > > On 2021-08-17 10:54:30 +0530, Amit Kapila wrote: > > > 5. How can we provide a strict mechanism to not allow to use dsm APIs > > > for non-dsm FileSet? One idea could be that we

Re: [bug] Logical Decoding of relation rewrite with toast does not reset toast_hash

On Wed, Aug 18, 2021 at 1:27 PM Drouvot, Bertrand wrote: > > Hi, > > On 8/13/21 11:17 AM, Amit Kapila wrote: > > On Fri, Aug 13, 2021 at 11:47 AM Drouvot, Bertrand > > wrote: > >> On 8/12/21 1:00 PM, Amit Kapila wrote: > - sets "relwrewrite" for the toast. > > >>> ---

Re: Support for NSS as a libpq TLS backend

> On 18 Aug 2021, at 02:32, Michael Paquier wrote: > > On Wed, Aug 18, 2021 at 12:06:59AM +, Jacob Champion wrote: >> I have a local test suite that I've been writing against libpq. With >> the new ssldatabase connection option, one tricky aspect is figuring >> out whether it's supported or

Small typo fix in logical decoding example

The attached fixes s/atleast/at least/ in the logical decoding examples section in the docs, will push in a bit. -- Daniel Gustafsson https://vmware.com/ logdec_example_typo.diff Description: Binary data

Re: Skipping logical replication transactions on subscriber side

On Wed, Aug 18, 2021 at 3:33 PM houzj.f...@fujitsu.com wrote: > > On Tues, Aug 17, 2021 1:01 PM Masahiko Sawada wrote: > > On Mon, Aug 16, 2021 at 3:59 PM houzj.f...@fujitsu.com > > wrote: > > > 3) > > > Do we need to invoke set_apply_error_context_xact() in the function > > >

Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)

At Tue, 17 Aug 2021 17:04:44 +0900, Michael Paquier wrote in > On Fri, Jul 02, 2021 at 06:22:56PM -0300, Ranier Vilela wrote: > > Em qui., 1 de jul. de 2021 às 17:20, Mahendra Singh Thalor < > > mahi6...@gmail.com> escreveu: > >> Please can we try to hit this rare condition by any test case. If

Re: [PATCH] Allow multiple recursive self-references

> Maybe the variable selfrefcountL can be renamed slightly (e.g. > curr_selfrefcount) so that the code is easier to read. Yes, you are absolutely right. Thanks for the suggestion. The new version renames this variable. Best wishes, -- Denis

RE: Skipping logical replication transactions on subscriber side

On Wed, Aug 18, 2021 2:41 PM Masahiko Sawada wrote: > > On Wed, Aug 18, 2021 at 3:15 PM Amit Kapila wrote: > > > > On Wed, Aug 18, 2021 at 10:00 AM Masahiko Sawada > > wrote: > > > > > > In addition of a code readability, there is a description in the doc > > > that mentions "Stream End" but

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

> Anything that's not used in other files should be declared static in > the file itself, and not present in the header. Once you fix this for > reset_startup_progress_timeout, the header won't need to include > datatype/timestamp.h any more, which is good, because we don't want > header files to

Re: Skipping logical replication transactions on subscriber side

On Wed, Aug 18, 2021 at 3:15 PM Amit Kapila wrote: > > On Wed, Aug 18, 2021 at 10:00 AM Masahiko Sawada > wrote: > > > > On Wed, Aug 18, 2021 at 12:02 PM Amit Kapila > > wrote: > > > > > > On Wed, Aug 18, 2021 at 6:53 AM Masahiko Sawada > > > wrote: > > > > > > > > On Tue, Aug 17, 2021 at

RE: Skipping logical replication transactions on subscriber side

On Tues, Aug 17, 2021 1:01 PM Masahiko Sawada wrote: > On Mon, Aug 16, 2021 at 3:59 PM houzj.f...@fujitsu.com > wrote: > > 3) > > Do we need to invoke set_apply_error_context_xact() in the function > > apply_handle_stream_prepare() to save the xid and timestamp ? > > Yes. I think that v8-0001

Re: Skipping logical replication transactions on subscriber side

On Wed, Aug 18, 2021 at 10:00 AM Masahiko Sawada wrote: > > On Wed, Aug 18, 2021 at 12:02 PM Amit Kapila wrote: > > > > On Wed, Aug 18, 2021 at 6:53 AM Masahiko Sawada > > wrote: > > > > > > On Tue, Aug 17, 2021 at 2:35 PM Amit Kapila > > > wrote: > > > > > > > > > It's right that we use