Re: Collation versioning

On Tue, Nov 3, 2020 at 10:49 PM Thomas Munro wrote: > > So we have: > > 1. Windows locale names, like "English_United States.1252". Windows > still returns these from setlocale(), so they finish up in datcollate, > and yet some relevant APIs don't accept them, at least on some > machines. > >

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

Hi Amit I have rebased, split, and addressed (most of) the review comments of the v15-0003 patch. So the previous v15-0003 patch is now split into three as follows: - v16-0001-Support-2PC-txn-spoolfile.patch - v16-0002-Support-2PC-txn-pgoutput.patch -

Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843

On Wed, Nov 4, 2020 at 2:57 PM Tomas Vondra wrote: > On Wed, Nov 04, 2020 at 02:49:24PM +1300, Thomas Munro wrote: > >On Wed, Nov 4, 2020 at 2:32 PM Tomas Vondra > > wrote: > >> After a while (~1h on my machine) the pg_multixact gets over 10GB, which > >> triggers a more aggressive cleanup (per

Re: "unix_socket_directories" should be GUC_LIST_INPUT?

On Tue, Oct 27, 2020 at 12:23:22PM -0400, Tom Lane wrote: > Robert Haas writes: >> If we change this, is it going to be a compatibility break for the >> contents of postgresql.conf files? > > I think not, at least not for the sorts of values you'd ordinarily > find in that variable, say '/tmp,

RE: extension patch of CREATE OR REPLACE TRIGGER

Hi Peter-San, thanks for your support. On Monday, November 2, 2020 2:39 PM Peter Smith wrote: > === > > (1) COMMENT > File: NA > Maybe next time consider using format-patch to make the patch. Then you > can include a comment to give the background/motivation for this change. OK. How about v15 ?

Re: Parallel INSERT (INTO ... SELECT ...)

On Wed, Nov 4, 2020 at 6:11 AM Greg Nancarrow wrote: > > On Tue, Nov 3, 2020 at 5:25 PM vignesh C wrote: > > > > -> commandType is not used, we can remove it. > > + * Prepare for entering parallel mode by assigning a FullTransactionId, to > > be > > + * included in the transaction state that is

Re: list of extended statistics on psql

Hi, I addressed it, so I keep the size of extended stats with the unit. Changes:   - Use pg_size_pretty to show the size of extended stats by \dX+ I rebased the patch on the head and also added tab-completion. Any feedback is welcome. Preparing for tests: === create

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

Hi, I've updated the patch 0004 (Truncate optimization) with the previous comments of Tsunakawa-san already addressed in the patch. (Thank you very much for the review.) The change here compared to the previous version is that in DropRelFileNodesAllBuffers() we don't check for the accurate

Re: ModifyTable overheads in generic plans

On Tue, Nov 3, 2020 at 9:05 PM Heikki Linnakangas wrote: > On 03/11/2020 10:27, Amit Langote wrote: > > Please check the attached if that looks better. > > Great, thanks! Yeah, I like that much better. > > This makes me a bit unhappy: > > > > > /* Also let FDWs init themselves for

Re: Collation versioning

On Wed, Nov 4, 2020 at 2:56 PM David Rowley wrote: > initdb works fine. I ran vcregress upgradecheck and it passes. > > With my default locale of English.New Zealand.1252 I get zero rows from: > > select * from pg_depend where coalesce(refobjversion,'') <> ''; > > if I initdb with

Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843

On Wed, Nov 04, 2020 at 02:49:24PM +1300, Thomas Munro wrote: On Wed, Nov 4, 2020 at 2:32 PM Tomas Vondra wrote: After a while (~1h on my machine) the pg_multixact gets over 10GB, which triggers a more aggressive cleanup (per MultiXactMemberFreezeThreshold). My guess is that this discards some

Re: Collation versioning

On Wed, 4 Nov 2020 at 14:21, Thomas Munro wrote: > > On Wed, Nov 4, 2020 at 10:56 AM Thomas Munro wrote: > > On Wed, Nov 4, 2020 at 10:52 AM Tom Lane wrote: > > > Thomas Munro writes: > > > > We want the same algorithm that Windows uses internally to resolve the > > > > old style name to a

Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843

On Wed, Nov 4, 2020 at 2:32 PM Tomas Vondra wrote: > After a while (~1h on my machine) the pg_multixact gets over 10GB, which > triggers a more aggressive cleanup (per MultiXactMemberFreezeThreshold). > My guess is that this discards some of the files, but checkpointer is > not aware of that, or

Re: Explicit NULL dereference (src/backend/utils/adt/ruleutils.c)

At Mon, 02 Nov 2020 14:49:50 -0500, Tom Lane wrote in > Ranier Vilela writes: > > Em seg., 2 de nov. de 2020 às 01:36, Kyotaro Horiguchi < > > horikyota@gmail.com> escreveu: > >> Doesn't seem that ev_qual and ev_action can be NULL. The same > >> function in the current converts action list

Re: Collation versioning

Thomas Munro writes: > I can't bring myself to commit that, it's not really in the spirit of > this data integrity feature, and it's not our business to second guess > the relationship between different locale naming schemes through fuzzy > logic. Instead, I propose to just neuter the feature if

Re: Online checksums verification in the backend

On Tue, Nov 03, 2020 at 06:46:12PM +0900, Michael Paquier wrote: > Yep, that's clear. I'll deal with that tomorrow. That's more than a > simple rework. This part is now done as of e152506a. -- Michael signature.asc Description: PGP signature

PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843

Hi, While running some multixact-oriented stress tests, I noticed that commit dee663f7843: Defer flushing of SLRU files. Previously, we called fsync() after writing out individual pg_xact, pg_multixact and pg_commit_ts pages due to cache pressure, leading to regular I/O stalls

Re: Collation versioning

On Wed, Nov 4, 2020 at 10:56 AM Thomas Munro wrote: > On Wed, Nov 4, 2020 at 10:52 AM Tom Lane wrote: > > Thomas Munro writes: > > > We want the same algorithm that Windows uses internally to resolve the > > > old style name to a collation; in other words we probably want > > > something more

Re: -O switch

Magnus Hagander writes: > [ remove_option_o_2.patch ] This seems committable to me now, although ... > On Mon, Nov 2, 2020 at 6:58 PM Tom Lane wrote: >> Magnus Hagander writes: >>> Initially I kept the dynamic argv/argc in even though it's now >>> hardcoded, in case we wanted to add something

Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)

At Tue, 3 Nov 2020 20:44:23 +1300, Thomas Munro wrote in > On Tue, Nov 3, 2020 at 12:50 AM Kyotaro Horiguchi > wrote: > > With the fix patch, it changes to: > > > > [16632] LOG: FALSE LATCH: > > Nice repo. But is it OK to not reset the Win32 event in this case? > Does it

Fix brin_form_tuple to properly detoast data

Hi, As pointed out in [1], BRIN is not properly handling toasted data, which may easily lead to index tuples referencing TOAST-ed values. Which is clearly wrong - it's trivial to trigger failues after a DELETE. Attached is a patch that aims to fix this - AFAIK the brin_form_tuple was simply

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

On Tue, Nov 03, 2020 at 01:46:38PM +0100, Magnus Hagander wrote: > On Tue, Nov 3, 2020 at 1:00 PM Daniel Gustafsson wrote: >> I kind of like the idea of continuing to abstract this functionality, not >> pulling in OpenSSL headers in fork_process.c is a neat bonus. I'd say it's >> worth

Re: Parallel INSERT (INTO ... SELECT ...)

Hi Vignesh, Thanks for reviewing the patches. On Tue, Nov 3, 2020 at 5:25 PM vignesh C wrote: > > -> commandType is not used, we can remove it. > + * Prepare for entering parallel mode by assigning a FullTransactionId, to be > + * included in the transaction state that is serialized in the

Re: Delay of standby shutdown

Hello Fujii, On Thu, Sep 17, 2020 at 6:49 AM Fujii Masao wrote: As far as I understand after debugging, the problem is as follows: 1. After the primary is stopped, and the standby startup process is waiting inside: (void) WaitLatch(>recoveryWakeupLatch, WL_LATCH_SET | WL_TIMEOUT |

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

I wrote: > * I notice that this will sometimes transform non-SQL-spec syntax > into SQL-spec, for example ... > I'm not sure that that satisfies the POLA. This particular case is > especially not great, because this is really textregexsubstr() which > is *not* SQL compatible, so the display is

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

Here's an updated version of this patch. Apart from rebasing to current master, I made the following changes: * On the first transaction (the one that marks the partition as detached), the partition is locked with ShareLock rather than ShareUpdateExclusiveLock. This means that DML is not

Re: Collation versioning

Re: Thomas Munro > for all I know, "en" variants might change > independently (I doubt it in practice, but in theory it's wrong). Long before the glibc 2.28 incident, the same collation change had already happened twice, namely between RedHat 5 -> 6 -> 7, for de_DE.UTF-8 only. de_AT.UTF-8 and all

Re: Collation versioning

On Wed, Nov 4, 2020 at 10:52 AM Tom Lane wrote: > Thomas Munro writes: > > We want the same algorithm that Windows uses internally to resolve the > > old style name to a collation; in other words we probably want > > something more like the code path that they took away in VS2015 :-(. > > Yeah.

Re: Collation versioning

Thomas Munro writes: > On Tue, Nov 3, 2020 at 4:38 PM Thomas Munro wrote: >> On Tue, Nov 3, 2020 at 1:51 PM David Rowley wrote: >>> FWIW, the attached does fix the issue for me. It basically just calls >>> the function that converts the windows-type "English_New Zealand.1252" >>> locale name

Re: Collation versioning

On Tue, Nov 3, 2020 at 4:38 PM Thomas Munro wrote: > On Tue, Nov 3, 2020 at 1:51 PM David Rowley wrote: > > On Tue, 3 Nov 2020 at 12:29, David Rowley wrote: > > > Running low on ideas for now, so thought I'd post this in case it > > > someone thinks of something else. > > > > FWIW, the attached

Re: Use of "long" in incremental sort code

On Tue, Nov 03, 2020 at 03:53:53AM +0100, Tomas Vondra wrote: Hi, I took another look at this, and 99% of the patch (the fixes to sort debug messages) seems fine to me. Attached is the part I plan to get committed, including commit message etc. I've pushed this part. Thanks for the patch,

Re: enable_incremental_sort changes query behavior

On Tue, Nov 03, 2020 at 03:37:43AM +0100, Tomas Vondra wrote: On Fri, Oct 30, 2020 at 07:37:33PM -0400, James Coleman wrote: ... I was looking at this some more, and I'm still convinced that this is correct, but I don't think a comment about it being an optimization (though I suspect that

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On Tue, 3 Nov 2020 at 20:08, Peter Eisentraut wrote: > > On 2020-09-29 11:26, David Rowley wrote: > > I've marked this patch back as waiting for review. It would be good if > > someone could run some tests on some intel hardware and see if they > > can see any speedup. > > What is the way forward

Re: libpq compression

Hi,Looks like I found an issue: there can be a situation when libpq frontend hangs after zpq_read(). This may happen when the socket is not read ready and we can't perform another read because we wait on pqWait() but we actually have some buffered rx data.I think we should add a check if there is

Re: Dumping/restoring fails on inherited generated column

On 2020-08-27 13:30, Masahiko Sawada wrote: This issue is not fixed yet. I've attached the updated version patch and registered it to commit fest so as not to forget. Please review it. A few fixes have been committed in this thread, basically to prevent situations that shouldn't have been

Re: remove spurious CREATE INDEX CONCURRENTLY wait

> On Thu, Aug 20, 2020 at 03:11:19PM +0900, Michael Paquier wrote: > On Wed, Aug 19, 2020 at 02:16:46PM -0400, Alvaro Herrera wrote: > > I did not set the flag in REINDEX CONCURRENTLY, but as I understand it > > can be done too, since in essence it's the same thing as a CIC from a > > snapshot

Re: cutting down the TODO list thread

I wrote: > > Ok, that's two votes for a separate page, and one for a new section on the > same page, so it looks like it's a new page. That being the case, I would > think it logical to move "features we don't want" there. As for the name, > we should probably encompass both "won't fix" bugs and

Re: automatic analyze: readahead - add "IO read time" log message

Greetings, * Jakub Wartak (jakub.war...@tomtom.com) wrote: > >Interesting that you weren't seeing any benefit to disabling readahead. > > I've got some free minutes and I have repeated the exercise in more realistic > and strict environment that previous one to conclude that the current >

Re: patch: reduce overhead of execution of CALL statement in no atomic mode from PL/pgSQL

Hi I played with the profiler a little bit to get some data - see attached file. Almost all overhead is related to impossibility to use simple expression evaluation (that has very good performance now). Probably there is no simple way to reduce this overhead. Regards Pavel

Re: PATCH: Batch/pipelining support for libpq

On Mon, Nov 2, 2020 at 8:58 AM Alvaro Herrera wrote: > On 2020-Nov-02, Alvaro Herrera wrote: > > > In v23 I've gone over docs; discovered that PQgetResults docs were > > missing the new values. Added those. No significant other changes yet. > > Just reading the documentation of this patch,

Why does to_json take "anyelement" rather than "any"?

to_json is declared as taking "anyelement" as input, which means you can't pass it something of unknown type: postgres=# SELECT to_json('foo'); ERROR: could not determine polymorphic type because input has type unknown But this works fine with the very similar json_build_array

Re: Online checksums verification in the backend

On Mon, Nov 2, 2020 at 2:35 PM Andres Freund wrote: > Wouldn't this be better served by having a ReadBufferExtended() flag, > preventing erroring out and zeroing the buffer? I'm not sure that > handling both the case where the buffer contents need to be valid and > the one where it doesn't will

Re: [PATCH] remove pg_archivecleanup and pg_standby

On Thu, Oct 29, 2020 at 3:40 PM Michael Banck wrote: > I guess not many will complain about pg_standby going away, but I am > under the impression that pg_archivecleanup is still used a lot in PITR > backup environments as a handy tool to expire WAL related to expired > base backups. I certainly

Re: PATCH: Batch/pipelining support for libpq

I implemented a C++ async HTTP server using this new batch mode and it provides everything I needed to transparently batch sql requests. It gives a performance boost between x2 and x3 on this benchmark:

Re: public schema default ACL

On Mon, Nov 2, 2020 at 1:41 PM Stephen Frost wrote: > > What potentially could move the needle is separate search paths for > > relation lookup and function/operator lookup. We have sort of stuck > > our toe in that pond already by discriminating against pg_temp for > > function/operator lookup,

Re: libpq compression

On 03.11.2020 18:08, Daniil Zakhlystov wrote: Hi, Looks like I found an issue: there can be a situation when libpq frontend hangs after zpq_read(). This may happen when the socket is not read ready and we can't perform another read because we wait on pqWait() but we actually have some

Re: PATCH: Batch/pipelining support for libpq

On Tue, 3 Nov 2020 at 08:42, Alvaro Herrera wrote: > Hi Dave, > > On 2020-Nov-03, Dave Cramer wrote: > > > On Mon, 2 Nov 2020 at 10:57, Alvaro Herrera > wrote: > > > > > On 2020-Nov-02, Alvaro Herrera wrote: > > > > > > > In v23 I've gone over docs; discovered that PQgetResults docs were > > >

Re: [PATCH] remove pg_archivecleanup and pg_standby

On 02/11/2020 20:26, Justin Pryzby wrote: On Thu, Oct 29, 2020 at 08:40:31PM +0100, Michael Banck wrote: Am Mittwoch, den 28.10.2020, 21:44 -0500 schrieb Justin Pryzby: Forking this thread: https://www.postgresql.org/message-id/fd93f1c5-7818-a02c-01e5-1075ac0d4...@iki.fi I think these are

Re: language cleanups in code and docs

On Wed, Oct 21, 2020 at 11:23 PM Thomas Munro wrote: > > On Wed, Jun 17, 2020 at 10:32 PM Magnus Hagander wrote: > > In looking at this I realize we also have exactly one thing referred to as > > "blacklist" in our codebase, which is the "enum blacklist" (and then a > > small internal variable

Re: Dumping/restoring fails on inherited generated column

On 2020-09-25 15:07, Peter Eisentraut wrote: We could probably fix this by having ALTER TABLE ONLY / DROP EXPRESSION update the attlocal column of direct children to true, to make the catalog state look like something that can be restored. However, that's a fair amount of complicated code, so

Re: psql \df choose functions by their arguments

On Sun, Nov 1, 2020 at 12:05 PM David Christensen wrote: > > I can’t speak for the specific patch, but tab completion of proc args for > \df, \ef and friends has long been a desired feature of mine, particularly > when you are dealing with functions with huge numbers of arguments and the > same

Re: psql \df choose functions by their arguments

Thanks for looking this over! > some Abbreviations of common types are not added to the > type_abbreviations[] Such as: > > Int8=> bigint > I wasn't aiming to provide a canonical list, as I personally have never seen anyone use int8 instead of bigint when (for example) creating

Re: PATCH: Batch/pipelining support for libpq

Hi Dave, On 2020-Nov-03, Dave Cramer wrote: > On Mon, 2 Nov 2020 at 10:57, Alvaro Herrera wrote: > > > On 2020-Nov-02, Alvaro Herrera wrote: > > > > > In v23 I've gone over docs; discovered that PQgetResults docs were > > > missing the new values. Added those. No significant other changes

Re: PATCH: Batch/pipelining support for libpq

Alvaro, On Mon, 2 Nov 2020 at 10:57, Alvaro Herrera wrote: > On 2020-Nov-02, Alvaro Herrera wrote: > > > In v23 I've gone over docs; discovered that PQgetResults docs were > > missing the new values. Added those. No significant other changes yet. > > > Thanks for looking at this. What else

Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

David, On Thu, 24 Sep 2020 at 00:22, Michael Paquier wrote: > On Tue, Sep 08, 2020 at 12:18:23PM -0700, Andres Freund wrote: > > A test verifying that a non-transactional message in later aborted > > transaction is handled correctly would be good. > > On top of that, the patch needs a rebase as

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

On Tue, Nov 3, 2020 at 1:00 PM Daniel Gustafsson wrote: > > > On 3 Nov 2020, at 11:35, Michael Paquier wrote: > > > > On Tue, Nov 03, 2020 at 10:15:48AM +0100, Magnus Hagander wrote: > >> On Wed, Aug 26, 2020 at 2:19 PM Daniel Gustafsson wrote: > >>> That's certainly true. The intention though

Re: Re: parallel distinct union and aggregate support patch

On Thu, Oct 29, 2020 at 12:53 PM bu...@sohu.com wrote: > > > 1) It's better to always include the whole patch series - including the > > parts that have not changed. Otherwise people have to scavenge the > > thread and search for all the pieces, which may be a source of issues. > > Also, it

Re: Parallel copy

On 03/11/2020 10:59, Amit Kapila wrote: On Mon, Nov 2, 2020 at 12:40 PM Heikki Linnakangas wrote: However, the point of parallel copy is to maximize bandwidth. Okay, but this first-phase (finding the line boundaries) can anyway be not done in parallel and we have seen in some of the initial

Re: ModifyTable overheads in generic plans

On 03/11/2020 10:27, Amit Langote wrote: Please check the attached if that looks better. Great, thanks! Yeah, I like that much better. This makes me a bit unhappy: /* Also let FDWs init themselves for foreign-table result rels */ if

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

> On 3 Nov 2020, at 11:35, Michael Paquier wrote: > > On Tue, Nov 03, 2020 at 10:15:48AM +0100, Magnus Hagander wrote: >> On Wed, Aug 26, 2020 at 2:19 PM Daniel Gustafsson wrote: >>> That's certainly true. The intention though is to make the code easier to >>> follow (more

Multi Inserts in CREATE TABLE AS - revived patch

Hi, I would like to propose an updated patch on multi/bulk inserts in CTAS [1] that tries to address the review comments that came up in [1]. One of the main review comments was to calculate/estimate the tuple size to decide on when to flush. I tried to solve this point with a new function

Re: contrib/sslinfo cleanup and OpenSSL errorhandling

On Tue, Nov 3, 2020 at 10:22 AM Daniel Gustafsson wrote: > > > On 3 Nov 2020, at 10:05, Magnus Hagander wrote: > > > Applied, with the small adjustment of the comma in the docs. > > Thanks! > > > I wonder if we should perhaps backpatch 0002? The changes to sslinfo > > that were ported go all the

Re: Bogus documentation for bogus geometric operators

Emre, could you please again rebase your patch on top of 2f70fdb0644c32c4154236c2b5c241bec92eac5e ? It is not applied anymore. > -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com

Re: hash_array_extended() needs to pass down collation

On Mon, Nov 02, 2020 at 10:01:53AM -0500, Tom Lane wrote: > Peter Eisentraut writes: >> I noticed that hash_array_extended() does not pass down the collation to >> the element's collation function, unlike hash_array(). As a >> consequence, hash partitioning using text arrays as partition key

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

On Tue, Nov 03, 2020 at 10:15:48AM +0100, Magnus Hagander wrote: > On Wed, Aug 26, 2020 at 2:19 PM Daniel Gustafsson wrote: >> That's certainly true. The intention though is to make the code easier to >> follow (more explicit/discoverable) for anyone trying to implement support >> for > > Is

Re: Online checksums verification in the backend

On Mon, Nov 02, 2020 at 11:34:57AM -0800, Andres Freund wrote: > On 2020-11-02 12:35:30 -0500, Robert Haas wrote: >> On Thu, Oct 29, 2020 at 2:17 PM Andres Freund wrote: >>> I think this needs to be quickly reworked or reverted. > > I think it's fairly clear by now that revert is appropriate for

Re: [PATCH] remove deprecated v8.2 containment operators

On 2020-10-27 04:25, Justin Pryzby wrote: Forking this thread: https://www.postgresql.org/message-id/fd93f1c5-7818-a02c-01e5-1075ac0d4...@iki.fi They have been deprecated for a Long Time, so finally remove them for v14. Four fewer exclamation marks makes the documentation less exciting, which

Re: -O switch

On Mon, Nov 2, 2020 at 6:58 PM Tom Lane wrote: > > Magnus Hagander writes: > > PFA a patch to do this. > > One thing you missed is that the getopt() calls in both postmaster.c > and postgres.c have 'o:' entries that should be removed. Also IIRC > there is a "case 'o'" in postgres.c to go along

Re: Online checksums verification in the backend

On Tue, Nov 03, 2020 at 09:31:20AM +0100, Magnus Hagander wrote: > On Mon, Nov 2, 2020 at 8:35 PM Andres Freund wrote: >> On 2020-11-02 12:35:30 -0500, Robert Haas wrote: >>> It feels really confusing to me that the user-exposed function here is >>> called pg_relation_check_pages(). How is the

Re: automatic analyze: readahead - add "IO read time" log message

Hi Stephen, hackers, >> > With all those 'readahead' calls it certainly makes one wonder if the >> > Linux kernel is reading more than just the block we're looking for >> > because it thinks we're doing a sequential read and will therefore want >> > the next few blocks when, in reality, we're

Re: Bogus documentation for bogus geometric operators

> The subject is about the documentation, but the post reveals > inconsistencies of the operators. Tom Lane fixed the documentation on > the back branches. The new patch is to fix the operators on the > master only. > Nice catch, thanks! I agree that different operators should not have the same

Re: Prefer TG_TABLE_NAME over TG_RELNAME in tests

On Thu, Sep 24, 2020 at 5:17 AM Michael Paquier wrote: > > On Wed, Sep 23, 2020 at 12:07:14PM +0200, Daniel Gustafsson wrote: > > TG_RELNAME was marked deprecated in commit 3a9ae3d2068 some 14 years ago, > > but > > we still use it in the triggers test suite (test added in 59b4cef1eb74a a > >

Re: contrib/sslinfo cleanup and OpenSSL errorhandling

> On 3 Nov 2020, at 10:05, Magnus Hagander wrote: > Applied, with the small adjustment of the comma in the docs. Thanks! > I wonder if we should perhaps backpatch 0002? The changes to sslinfo > that were ported go all the way back to 9.6, so it should be a safe > one I think? It should be

Re: Move OpenSSL random under USE_OPENSSL_RANDOM

On Wed, Aug 26, 2020 at 2:19 PM Daniel Gustafsson wrote: > > > On 26 Aug 2020, at 09:56, Michael Paquier wrote: > > On Tue, Aug 25, 2020 at 03:52:14PM +0200, Daniel Gustafsson wrote: > > >> The attached moves all invocations under the correct guards. RAND_poll() > >> in > >> fork_process.c

Re: contrib/sslinfo cleanup and OpenSSL errorhandling

On Mon, Nov 2, 2020 at 3:19 PM Magnus Hagander wrote: > > On Fri, Oct 30, 2020 at 11:20 PM Daniel Gustafsson wrote: > > > > > On 30 Oct 2020, at 00:40, Andres Freund wrote: > > > > > There's quite a few copies of this code that look exactly the same, > > > except for the be_tls_get_* call. Do

Re: Parallel copy

On Mon, Nov 2, 2020 at 12:40 PM Heikki Linnakangas wrote: > > On 02/11/2020 08:14, Amit Kapila wrote: > > On Fri, Oct 30, 2020 at 10:11 PM Heikki Linnakangas wrote: > >> > >> In this design, you don't need to keep line boundaries in shared memory, > >> because each worker process is responsible

Re: Split copy.c

On 2020-11-03 08:38, Heikki Linnakangas wrote: [v3-0001-Split-copy.c-into-copyto.c-and-copyfrom.c.patch] [v3-0002-Split-copyfrom.c-further-into-copyfrom.c-and-copy.patch] The patches apply ok, but I get these errors: In file included from ../../../src/include/postgres.h:46,

Re: Online checksums verification in the backend

On Mon, Nov 2, 2020 at 8:35 PM Andres Freund wrote: > > Hi, > > On 2020-11-02 12:35:30 -0500, Robert Haas wrote: > > It feels really confusing to me that the user-exposed function here is > > called pg_relation_check_pages(). How is the user supposed to > > understand the difference between what

Re: ModifyTable overheads in generic plans

On Mon, Nov 2, 2020 at 10:53 PM Amit Langote wrote: > On Mon, Nov 2, 2020 at 10:19 PM Heikki Linnakangas wrote: > > (/me reads patch further) I presume that's what you referred to in the > > commit message: > > > > > Also, extend this lazy initialization approach to some of the > > >

Re: Add table AM 'tid_visible'

Hi Andres, > Yea, it's something we should improve. Have you checked if this has > performance impact for heap? Should we also consider planning costs? Since the visibility map is very small, all pages of the visibility map will usually reside in memory. The IO cost of accessing the

Re: Collation versioning

On Tue, Nov 3, 2020 at 4:39 AM Thomas Munro wrote: > On Tue, Nov 3, 2020 at 1:51 PM David Rowley wrote: > > > It would be good if this could also be tested on Visual Studio version > > 12 as I see IsoLocaleName() does something else for anything before > > 15. I only have 10 and 17 installed

Re: [PATCH] Automatic HASH and LIST partition creation

Again I've checked v3 patch. In the discussion, there are several other ideas on its further development, so I consider the patch as the first step to later progress. Though now the patch is fully self-sufficient in functionality and has enough tests etc. I suppose it is ready to be committed. --

RE: psql \df choose functions by their arguments

Hi (sorry forget to cc the hacklist) > Improve psql \df to choose functions by their arguments I think this is useful. I found some comments in the patch. 1. > * Abbreviations of common types is permitted (because who really likes > to type out "character varying"?), so the above could also