Re: xid wraparound danger due to INDEX_CLEANUP false

On Tue, Dec 15, 2020 at 6:44 PM Masahiko Sawada wrote: > In connection with this change, we would need to rethink the meaning > of the INDEX_CLEANUP option. As of now, if it's not set (i.g. > VACOPT_TERNARY_DEFAULT in the code), it's treated as true and will do > heap clean. But I think we can mak

RE: [Patch] Optimize dropping of relation buffers using dlist

Hello Kirk, I noticed you have pushed a new version for your patch which has some changes on TRUNCATE on TOAST relation. Although you've done performance test for your changed part. I'd like to do a double check for your patch(hope you don't mind). Below is the updated recovery performance test

Incorrect allocation handling for cryptohash functions with OpenSSL

Hi all, As of the work done in 87ae9691, I have played with error injections in the code paths using this code, but forgot to count for cases where cascading resowner cleanups are involved. Like other resources (JIT, DSM, etc.), this requires an allocation in TopMemoryContext to make sure that no

Re: allow to \dtS+ pg_toast.*

Thanks for looking On Thu, Dec 17, 2020 at 04:16:52PM +0100, Laurenz Albe wrote: > On Mon, 2020-11-30 at 10:54 -0600, Justin Pryzby wrote: > > This makes toast tables a bit less special and easier to inspect. > > > > postgres=# \dtS+ pg_toast.pg_toast_2619 > > pg_toast | pg_toast_2619 | toast ta

Re: Refactoring HMAC in the core code

On Fri, Dec 18, 2020 at 08:41:01AM +0900, Michael Paquier wrote: > Knowing that we are in a period of vacations for a lot of people, and > that this is a sensitive area of the code that involves > authentication, I think that it is better to let this thread brew > longer and get more eyes to look a

pgbench failed when -f option contains a char '@'

Hi, hackers pgbench use -f filename[@weight] to receive a sql script file with a weight, but if I create a file contains char'@', like a...@2.sql, specify this file without weigth, pgbench will failed with error: pgbench: fatal: invalid weight specification: @2.sql This action may be unf

Re: [HACKERS] [PATCH] Generic type subscripting

čt 17. 12. 2020 v 22:47 odesílatel Tom Lane napsal: > Chapman Flack writes: > > That's likely to be what a programmer intends when writing > > (variable explicitly typed integer) := js['n'] and > > (variable explicitly types varchar) := js['v'] > > I think that what we want, if we're to support

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

On Thu, Dec 17, 2020 at 11:47 PM Amit Kapila wrote: > I went ahead and used both origin_lsn and origin_timestamp to avoid > the possibility of a match of prepared xact from two different nodes. > We can handle this at begin_prepare and prepare time but we don't have > prepare_lsn and prepare_time

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

At Wed, 16 Dec 2020 11:01:20 +0900 (JST), Kyotaro Horiguchi wrote in > - Record the beginning LSN of the first cross-seg record and the end > LSN of the last cross-seg recrod in a consecutive segments bonded by > cross-seg recrods. Spcifically X and Y below. > >X Z

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

At Thu, 17 Dec 2020 22:20:35 +, "Bossart, Nathan" wrote in > On 12/15/20, 2:33 AM, "Kyotaro Horiguchi" wrote: > > You're right in that regard. There's a window where partial record is > > written when write location passes F0 after insertion location passes > > F1. However, remembering all

Re: Parallel Inserts in CREATE TABLE AS

On Wed, Dec 16, 2020 at 12:06 PM Bharath Rupireddy wrote: > > On Tue, Dec 15, 2020 at 5:53 PM Bharath Rupireddy > wrote: > > I'm merging them to the original patch set and adding the test cases > > to cover these cases. I will post the updated patch set soon. > > Attaching v12 patch set. > > 0001

Refactor routine to check for ASCII-only case

Hi all, As mentioned in [1], there are three places where there is the same routine to check if a string is made only of ASCII characters. This makes for a small-ish but nice cleanup, as per the attached. Thanks, [1]: https://www.postgresql.org/message-id/x9lvlgrug0hth...@paquier.xyz -- Michael

Re: Proposed patch for key managment

On Fri, Dec 18, 2020 at 10:01:22AM +0900, Michael Paquier wrote: > On Thu, Dec 17, 2020 at 12:10:22PM -0500, Bruce Momjian wrote: > > On Thu, Dec 17, 2020 at 11:39:55AM -0500, Stephen Frost wrote: > >> I don't think there's any need for us to implement a fallback > >> implementation of AES. I'm no

Re: Proposed patch for key managment

On Fri, Dec 18, 2020 at 11:19:02AM +0800, Neil Chen wrote: > > > On Fri, Dec 18, 2020 at 3:02 AM Bruce Momjian wrote: > > > Here is a run of all four authentication methods, and updated scripts. > I have renamed Yubiki to PIV since the script should work with anY > PIV-enabled devi

Re: Proposed patch for key managment

On Fri, Dec 18, 2020 at 3:02 AM Bruce Momjian wrote: > > Here is a run of all four authentication methods, and updated scripts. > I have renamed Yubiki to PIV since the script should work with anY > PIV-enabled deviced, like a CAC. > > Thanks for attaching these patches. The unfortunate thing is

Re: Fail Fast In CTAS/CMV If Relation Already Exists To Avoid Unnecessary Rewrite, Planning Costs

On Fri, Dec 18, 2020 at 7:18 AM Michael Paquier wrote: > On Thu, Dec 17, 2020 at 03:06:59PM +0530, Bharath Rupireddy wrote: > > The behavior of the ctas/cmv, in case the relation already exists is as > > shown in [1]. The things that have been changed with the patch are: 1) In > > any case we do n

Re: STANDBY_LOCK_TIMEOUT may not interrupt ProcWaitForSignal()?

On 2020/12/17 18:45, Fujii Masao wrote: On 2020/12/17 11:04, Fujii Masao wrote: Hi, When the startup process needs to wait for recovery conflict on lock, STANDBY_LOCK_TIMEOUT is enabled to interrupt ProcWaitForSignal() if necessary. If this timeout happens, StandbyLockTimeoutHandler() is c

Re: New Table Access Methods for Multi and Single Inserts

On Fri, Dec 18, 2020 at 2:14 AM Justin Pryzby wrote: > On Thu, Dec 17, 2020 at 04:35:33PM +0530, Bharath Rupireddy wrote: > > > You made the v2 insert interface a requirement for all table AMs. > > > Should it be optional, and fall back to simple inserts if not implemented > > > ? > > > > I tried

Re: Feature improvement for pg_stat_statements

On 2020/12/17 22:59, Seino Yuki wrote: 2020-12-14 23:01 に Fujii Masao さんは書きました: On 2020/12/14 18:17, Seino Yuki wrote: 2020-12-09 21:14 に Fujii Masao さんは書きました: On 2020/12/09 20:42, Li Japin wrote: Hi, On Dec 9, 2020, at 6:37 PM, Seino Yuki mailto:sein...@oss.nttdata.com>> wrote: 2020-12

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Thu, Dec 17, 2020 at 10:32 PM Alexey Kondratov wrote: > On 2020-12-17 18:02, Bharath Rupireddy wrote: > > On Thu, Dec 17, 2020 at 5:38 PM Hou, Zhijie > > wrote: > >> I took a look into the patch, and have a little issue: > >> > >> +bool disconnect_cached_connections(uint32 hashvalue, bool all)

Re: Fail Fast In CTAS/CMV If Relation Already Exists To Avoid Unnecessary Rewrite, Planning Costs

On Thu, Dec 17, 2020 at 03:06:59PM +0530, Bharath Rupireddy wrote: > The behavior of the ctas/cmv, in case the relation already exists is as > shown in [1]. The things that have been changed with the patch are: 1) In > any case we do not rewrite or plan the select part if the relation already > exi

Re: Minor documentation error regarding streaming replication protocol

On Thu, Dec 17, 2020 at 03:13:25PM -0800, Jeff Davis wrote: > On second thought, I'm going to retract this patch. The docs[1] say: > > "You can, if you like, add comments to a history file to record your > own notes about how and why this particular timeline was created. Such > comments will be es

Re: Proposed patch for key managment

On Thu, Dec 17, 2020 at 12:10:22PM -0500, Bruce Momjian wrote: > On Thu, Dec 17, 2020 at 11:39:55AM -0500, Stephen Frost wrote: >> I don't think there's any need for us to implement a fallback >> implementation of AES. I'm not entirely sure we need it for hashes >> but since we've already got it..

Re: multi-install PostgresNode

On Thu, Dec 17, 2020 at 04:37:54PM -0500, Andrew Dunstan wrote: > The proposed module would look something like this: > > [...] > > use parent PostgresNode; > > sub get_new_node > { >     my $installpath= shift; >     my $node = PostgresNode::get_new_node(@_); >     bless $

Re: Refactoring HMAC in the core code

On Thu, Dec 17, 2020 at 12:53:06PM -0500, Bruce Momjian wrote: > Very nice. Are you planning to apply this soon? If so, I will delay > my key management patch until this is applied. If not, I will update my > HMAC call when you apply this. Knowing that we are in a period of vacations for a lot

Re: [BUG] orphaned function

Gilles Darold writes: > The same problem applies if the returned type or the procedural language > is dropped. I have tried to fix that in ProcedureCreate() by using an > AccessSharedLock for the data types and languages involved in the > function declaration. With this patch the race condition

Re: Minor documentation error regarding streaming replication protocol

On Tue, 2020-12-15 at 12:54 -0800, Andres Freund wrote: > Hi, > > On 2020-12-15 01:22:44 -0800, Jeff Davis wrote: > > Attached a simple patch that enforces an all-ASCII restore point > > name > > rather than documenting the possibility of non-ASCII text. > > +1 On second thought, I'm going to re

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

On 12/15/20, 2:33 AM, "Kyotaro Horiguchi" wrote: > You're right in that regard. There's a window where partial record is > written when write location passes F0 after insertion location passes > F1. However, remembering all spanning records seems overkilling to me. I'm curious why you feel that r

Re: [UNVERIFIED SENDER] Re: [BUG] orphaned function

Le 02/12/2020 à 11:46, Drouvot, Bertrand a écrit : I ended up making more changes in QualifiedNameGetCreationNamespace () to mimic the retry() logic that is in RangeVarGetAndCheckCreationNamespace(). The att

Re: [HACKERS] [PATCH] Generic type subscripting

On 12/17/20 16:56, Chapman Flack wrote: >> that, it's called a cast. > > I find them different; XQuery was the first language I had encountered > that provides both (a cast in XQuery is spelled 'cast as', just as you'd > expect), and the idea of an explicit operation that means "I am only > assert

Re: [HACKERS] [PATCH] Generic type subscripting

On 12/17/20 16:47, Tom Lane wrote: > As far as "treat as" is concerned, we already have a spelling for > that, it's called a cast. I find them different; XQuery was the first language I had encountered that provides both (a cast in XQuery is spelled 'cast as', just as you'd expect), and the idea o

Re: [HACKERS] [PATCH] Generic type subscripting

Chapman Flack writes: > That's likely to be what a programmer intends when writing > (variable explicitly typed integer) := js['n'] and > (variable explicitly types varchar) := js['v'] I think that what we want, if we're to support that sort of thing, is that the js[] constructs produce jsonb by

multi-install PostgresNode

I've been giving some thought to $subject. The initial impetus is the promise I made to assist with testing of clients built with NSS against servers built with openssl, and vice versa. I've already generalized the process of saving binaries by the buildfarm client. And we could proceed with a pur

Re: [HACKERS] [PATCH] Generic type subscripting

On 12/17/20 15:50, Tom Lane wrote: > Chapman Flack writes: >> On 12/17/20 14:28, Tom Lane wrote: >>> If you're imagining that js['n'] and js['v'] would emit different >>> datatypes, forget it. That would require knowing at parse time >>> what the structure of the json object will be at run time.

Re: [HACKERS] [PATCH] Generic type subscripting

Chapman Flack writes: > On 12/17/20 14:28, Tom Lane wrote: >> If you're imagining that js['n'] and js['v'] would emit different >> datatypes, forget it. That would require knowing at parse time >> what the structure of the json object will be at run time. > Would it be feasible to analyze that a

Re: New Table Access Methods for Multi and Single Inserts

On Thu, Dec 17, 2020 at 04:35:33PM +0530, Bharath Rupireddy wrote: > > You made the v2 insert interface a requirement for all table AMs. > > Should it be optional, and fall back to simple inserts if not implemented ? > > I tried to implement the APIs mentioned by Andreas here in [1]. I just > used

Re: [HACKERS] [PATCH] Generic type subscripting

Dmitry Dolgov <9erthali...@gmail.com> writes: > On Thu, Dec 17, 2020 at 01:49:17PM -0500, Tom Lane wrote: >> We can certainly reconsider the API for the parsing hook if there's >> really a good reason for these to be different types, but it seems >> like that would just be encouraging poor design.

Re: [HACKERS] [PATCH] Generic type subscripting

čt 17. 12. 2020 v 20:28 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > čt 17. 12. 2020 v 19:49 odesílatel Tom Lane napsal: > >> So ... what's the problem with that? Seems like what you should put > >> in and what you should get out should be the same type. > > > I don't think so. For

Re: [HACKERS] [PATCH] Generic type subscripting

On 12/17/20 14:28, Tom Lane wrote: > Pavel Stehule writes: >> n int; >> v varchar; >> js jsonb default '{"n": 100, "v" : "Hello"}; >> BEGIN >> n := js['n']; >> v := js['v']; > > If you're imagining that js['n'] and js['v'] would emit different > datatypes, forget it. That would require

Re: [HACKERS] [PATCH] Generic type subscripting

> On Thu, Dec 17, 2020 at 01:49:17PM -0500, Tom Lane wrote: > Dmitry Dolgov <9erthali...@gmail.com> writes: > > While rebasing the jsonb patch I found out that the current subscripting > > assignment implementation in transformAssignmentIndirection always > > coerce the value to be assigned to the

Re: [HACKERS] [PATCH] Generic type subscripting

Pavel Stehule writes: > čt 17. 12. 2020 v 19:49 odesílatel Tom Lane napsal: >> So ... what's the problem with that? Seems like what you should put >> in and what you should get out should be the same type. > I don't think so. For XML or JSON the target can be different, and it can > safe one

Re: Optimizing the documentation

On Thu, Dec 17, 2020 at 7:42 AM Bruce Momjian wrote: > I agree a holistic review of the docs can yield great benefits. No one > usually complains about overly verbose text, but making it clearer is > always a win. Anyway, of course, it is going to be very specific for > each case. As an extreme

Re: [PATCH] nbtree: Do not show debugmessage if deduplication is disabled

On Wed, Dec 16, 2020 at 5:28 PM Justin Pryzby wrote: > Even though the message literally says whether the index "can safely" or > "cannot" use deduplication, the function specifically avoids the debug message > for system columns, so I think it also makes sense to hide it when > deduplication is t

Re: Proposed patch for key managment

On Mon, Dec 14, 2020 at 11:16:18PM -0500, Bruce Momjian wrote: > On Tue, Dec 15, 2020 at 10:36:56AM +0800, Neil Chen wrote: > > Since our implementation is not in contrib, I don't think we should put the > > script there. Maybe we can refer to postgresql.conf.sample?   > > Uh, the script are 20-60

Re: [HACKERS] [PATCH] Generic type subscripting

čt 17. 12. 2020 v 19:49 odesílatel Tom Lane napsal: > Dmitry Dolgov <9erthali...@gmail.com> writes: > > While rebasing the jsonb patch I found out that the current subscripting > > assignment implementation in transformAssignmentIndirection always > > coerce the value to be assigned to the type w

Re: [HACKERS] [PATCH] Generic type subscripting

Dmitry Dolgov <9erthali...@gmail.com> writes: > While rebasing the jsonb patch I found out that the current subscripting > assignment implementation in transformAssignmentIndirection always > coerce the value to be assigned to the type which subscripting result > suppose to have (refrestype). For a

Re: On login trigger: take three

čt 17. 12. 2020 v 14:04 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 17.12.2020 9:31, Pavel Stehule wrote: > > > > st 16. 12. 2020 v 20:38 odesílatel Pavel Stehule > napsal: > >> Attached please find new versoin of the patch based on >> on_connect_event_trigger_WIT

Re: [HACKERS] [PATCH] Generic type subscripting

> On Fri, Dec 11, 2020 at 10:38:07AM -0500, Tom Lane wrote: > Dmitry Dolgov <9erthali...@gmail.com> writes: > >> On Wed, Dec 09, 2020 at 04:59:34PM -0500, Tom Lane wrote: > >> 0001 adds the ability to attach a subscript handler to an existing > >> data type with ALTER TYPE. This is clearly going t

Re: Perform COPY FROM encoding conversions in larger chunks

On Wed, Dec 16, 2020 at 02:17:58PM +0200, Heikki Linnakangas wrote: > I've been looking at the COPY FROM parsing code, trying to refactor it so > that the parallel COPY would be easier to implement. I haven't touched > parallelism itself, just looking for ways to smoothen the way. And for ways > to

Re: Refactoring HMAC in the core code

On Wed, Dec 16, 2020 at 04:17:50PM +0900, Michael Paquier wrote: > Please note that I have added code that should be enough for the > compilation on Windows, but I have not taken the time to check that. > I have checked that things compiled and that check-world passes > with and without OpenSSL 1.1

Re: Proposed patch for key managment

On Thu, Dec 17, 2020 at 11:39:55AM -0500, Stephen Frost wrote: > Greetings, > > * Michael Paquier (mich...@paquier.xyz) wrote: > > On Wed, Dec 16, 2020 at 05:04:12PM -0500, Bruce Momjian wrote: > > >> fallback implementation. Finally, pgcrypto is not touched, but we > > > > > > I have a fallback

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On 2020-12-17 18:02, Bharath Rupireddy wrote: On Thu, Dec 17, 2020 at 5:38 PM Hou, Zhijie wrote: I took a look into the patch, and have a little issue: +bool disconnect_cached_connections(uint32 hashvalue, bool all) + if (all) + { + hash_destroy(ConnectionHash); +

Re: Change seconds argument of make_*() functions to numeric

Peter Eisentraut writes: > Along with the discussed change of the return type of EXTRACT from > float8 to numeric [0], I was looking around what other date/time APIs > might be using float arguments or return values. The only thing left > appears to be the functions make_time, make_timestamp,

Re: Change seconds argument of make_*() functions to numeric

čt 17. 12. 2020 v 17:43 odesílatel Peter Eisentraut < peter.eisentr...@enterprisedb.com> napsal: > Along with the discussed change of the return type of EXTRACT from > float8 to numeric [0], I was looking around what other date/time APIs > might be using float arguments or return values. The only

Change seconds argument of make_*() functions to numeric

Along with the discussed change of the return type of EXTRACT from float8 to numeric [0], I was looking around what other date/time APIs might be using float arguments or return values. The only thing left appears to be the functions make_time, make_timestamp, make_timestamptz, and make_interv

Re: Proposed patch for key managment

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Wed, Dec 16, 2020 at 05:04:12PM -0500, Bruce Momjian wrote: > >> fallback implementation. Finally, pgcrypto is not touched, but we > > > > I have a fallback implemention --- it fails? ;-) Did you want me to > > include an AES imple

Re: Optimizing the documentation

On Mon, Dec 14, 2020 at 01:38:05PM -0800, Peter Geoghegan wrote: > On Mon, Dec 14, 2020 at 12:50 PM Tom Lane wrote: > > Most of the docs contain pretty dense technical > > material that's not going to be improved by making it even denser. > > It's always hard to write dense technical prose, for

Re: \gsetenv

On 12/16/20 10:54 PM, David Fetter wrote: > >> Besides which, you haven't bothered with even one word of positive >> justification. What's the non-hazardous use case? > Thanks for asking, and my apologies for not including it. > > I ran into a situation where we sometimes got a very heavily load

Re: allow to \dtS+ pg_toast.*

On Mon, 2020-11-30 at 10:54 -0600, Justin Pryzby wrote: > This makes toast tables a bit less special and easier to inspect. > > postgres=# \dtS+ pg_toast.pg_toast_2619 > pg_toast | pg_toast_2619 | toast table | pryzbyj | permanent | heap > | 56 kB | > > This follows commit from last

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Thu, Dec 17, 2020 at 5:38 PM Hou, Zhijie wrote: > > Discussion here is on the point - whether to show up the invalidated > > connections in the output of the new postgres_fdw_get_connections() > > function? If we were to show, then because of the solution we proposed for > > the connection leak

Re: cutting down the TODO list thread

On Thu, Dec 10, 2020 at 03:29:07PM -0400, John Naylor wrote: > Hi, I agree with all of your analysis, but have some feedback; > Continuing with TODO list maintenance, first a couple things to clean up: > > - Allow ALTER INDEX ... RENAME concurrently > > This was in the wrong section, but it's i

Re: libpq compression

On 17.12.2020 16:39, Denis Smirnov wrote: Hello all, I’ve finally read the whole thread (it was huge). It is extremely sad that this patch hang without progress for such a long time. It seems that the main problem in discussion is that everyone has its own view what problems should be solve

Re: Feature improvement for pg_stat_statements

2020-12-14 23:01 に Fujii Masao さんは書きました: On 2020/12/14 18:17, Seino Yuki wrote: 2020-12-09 21:14 に Fujii Masao さんは書きました: On 2020/12/09 20:42, Li Japin wrote: Hi, On Dec 9, 2020, at 6:37 PM, Seino Yuki > wrote: 2020-12-01 01:04 に Fujii Masao さんは書きました: On 2020

Re: libpq compression

Hello all, I’ve finally read the whole thread (it was huge). It is extremely sad that this patch hang without progress for such a long time. It seems that the main problem in discussion is that everyone has its own view what problems should be solve with this patch. Here are some of positions (

Re: On login trigger: take three

Hi, On 17.12.2020 3:31, Zhihong Yu wrote: Hi, For EventTriggerOnConnect(): +           PG_CATCH(); +           { ... +               AbortCurrentTransaction(); +               return; Should runlist be freed in the catch block ? No need: it is allocated in transaction memory context and remo

Re: On login trigger: take three

On 17.12.2020 9:31, Pavel Stehule wrote: st 16. 12. 2020 v 20:38 odesílatel Pavel Stehule mailto:pavel.steh...@gmail.com>> napsal: Attached please find new versoin of the patch based on on_connect_event_trigger_WITH_SUGGESTED_UPDATES.patch So there is still only "disable_c

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

On Thu, Dec 17, 2020 at 9:30 AM Ajin Cherian wrote: > > On Thu, Dec 17, 2020 at 2:41 PM Amit Kapila wrote: > > > On again thinking about this, I think it is good to disable it during > > slot initialization but will it create any problem because during slot > > initialization we don't stream any

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

On Thu, Dec 17, 2020 at 6:19 PM Amit Kapila wrote: > > On Wed, Dec 16, 2020 at 2:54 PM Amit Kapila wrote: > > > > On Wed, Dec 16, 2020 at 1:04 PM Masahiko Sawada > > wrote: > > > > > > > > Also, I guess we can improve the description of > > > ’two_phase’ option of CREATE SUBSCRIPTION in the doc

Lock level of create table partition of

Hello In commit 898e5e3290a72d288923260143930fb32036c00c [1] we lowered the lock level on the parent relation. I found in discussion [2]: > David Rowley recently pointed out that we can modify > CREATE TABLE .. PARTITION OF to likewise not obtain AEL anymore. > Apparently it just requires remov

RE: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

Hi > Discussion here is on the point - whether to show up the invalidated > connections in the output of the new postgres_fdw_get_connections() > function? If we were to show, then because of the solution we proposed for > the connection leak problem in [1], will the invalidated entries be shown >

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Mon, Dec 14, 2020 at 11:13 PM Bharath Rupireddy wrote: > On Mon, Dec 14, 2020 at 11:00 PM Fujii Masao > wrote: > > > One more point for the above scenario: if the user mapping is dropped > > > in another session, then cache lookup for that entry in the > > > postgres_fdw_get_connections() retu

Re: New Table Access Methods for Multi and Single Inserts

Thanks a lot for taking a look at the patches. On Thu, Dec 17, 2020 at 10:35 AM Justin Pryzby wrote: > Typos: > > + * 1) Specify is_multi as true, then multi insert state is allcoated. > => allocated > + * dropped, short-lived memory context is delted and mistate is freed up. > => deleted > + *

Re: STANDBY_LOCK_TIMEOUT may not interrupt ProcWaitForSignal()?

On 2020/12/17 11:04, Fujii Masao wrote: Hi, When the startup process needs to wait for recovery conflict on lock, STANDBY_LOCK_TIMEOUT is enabled to interrupt ProcWaitForSignal() if necessary. If this timeout happens, StandbyLockTimeoutHandler() is called and this function does nothing as foll

Re: Fail Fast In CTAS/CMV If Relation Already Exists To Avoid Unnecessary Rewrite, Planning Costs

On Mon, Dec 14, 2020 at 1:54 PM Bharath Rupireddy wrote: > On Mon, Dec 14, 2020 at 11:52 AM Michael Paquier wrote: > > On Mon, Dec 14, 2020 at 03:15:12PM +0900, Michael Paquier wrote: > > > Please note that this case fails with your patch, but the presence of > > > IF NOT EXISTS should ensure tha

Re: Cache relation sizes?

Hi Thomas, Thank you for your quick response. On Thu, Dec 17, 2020 at 3:05 PM Thomas Munro wrote: > Hi Andy, > > On Thu, Dec 17, 2020 at 7:29 PM Andy Fan wrote: > > I spent one day studying the patch and I want to talk about one question > for now. > > What is the purpose of calling smgrimmeds

Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

On 2020/12/16 18:12, Fujii Masao wrote: On 2020/12/16 16:24, Kyotaro Horiguchi wrote: At Tue, 15 Dec 2020 23:10:28 +0900, Fujii Masao wrote in I pushed the following two patches. - v1-use-standard-SIGHUP-hanlder-in-syslogger-process.patch - v1-use-MyLatch-and-standard-SIGHUP-handler-in-s