Re: Disk-based hash aggregate's cost model

On Sun, 2020-08-30 at 17:03 +0200, Tomas Vondra wrote: > So I'm wondering if the hashagg is not ignoring similar non-I/O costs > for the spilling case. In particular, the initial section computing > startup_cost seems to ignore that we may need to so some of the stuff > repeatedly - for example we'

Reloptions for table access methods

A custom table access method might want to add a new reloption to control something specific to that table access method. Unfortunately, if you add a new option of type RELOPT_KIND_HEAP, it will immediately fail because of the validation that happens in fillRelOptions(). Right now, heap reloptions

Re: Use T_IntList for uint32

On Tue, Sep 01, 2020 at 01:27:15AM -0400, Tom Lane wrote: > I've occasionally wondered about having exactly two physical List > implementations, one for 32-bit payloads and one for 64-bit payloads, and > then putting a trivial macros-or-static-inlines layer in front of that > that uses casts to sup

Re: 回复：how to create index concurrently on partitioned table

On Sun, Aug 09, 2020 at 06:44:23PM -0500, Justin Pryzby wrote: > Thanks for looking. The REINDEX patch is progressing its way, so I have looked a bit at the part for CIC. Visibly, the case of multiple partition layers is not handled correctly. Here is a sequence that gets broken: CREATE TABLE pa

Re: Remove line length restriction in passwordFromFile()

On 2020/09/01 10:00, Fujii Masao wrote: On 2020/09/01 6:24, Tom Lane wrote: Per the discussion at [1], we're now aware of actual use-cases for password strings approaching a kilobyte in length.  I think this puts the final nail in the coffin of the idea that passwordFromFile() can use a fix

Re: Use T_IntList for uint32

Amit Kapila writes: > On Mon, Aug 31, 2020 at 5:44 PM Ashutosh Bapat > wrote: >> May be we should have separate list APIs for XID like OID, in case we >> change underlying datatype of XID in future (unlikely but we have had >> discussion about 64bit XIDs in the past). Apart from that it helps us

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

At Mon, 31 Aug 2020 11:34:29 -0400, Bruce Momjian wrote in > On Mon, Aug 31, 2020 at 05:56:58PM +0900, Kyotaro Horiguchi wrote: > > Ok, this is that. If we spcify clientcert=no-verify other than for > > "cert" authentication, server complains as the following at startup. > > Why does clientcert=

Re: Ideas about a better API for postgres_fdw remote estimates

On 8/31/20 6:19 PM, Ashutosh Bapat wrote: On Mon, Aug 31, 2020 at 3:36 PM Andrey V. Lepikhov wrote: I agreed that this task needs to implement an API for serialization/deserialization of statistics: pg_load_relation_statistics(json_string text); pg_get_relation_statistics(relname text); We can

Re: Include access method in listTables output

On Thu, Aug 20, 2020 at 08:16:19AM +, Georgios wrote: > Please find version 7 attached which hopefully addresses the error along with > a proper > expansion of the test coverage and removal of recently introduced > whitespace warnings. +CREATE ROLEconditional_tableam_display_role; As a co

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Aug 31, 2020 at 10:27 PM Neha Sharma wrote: > > Hi Amit/Dilip, > > I have tested a few scenarios on top of the v56 patches, where the > replication worker still had few subtransactions in uncommitted state and we > restart the publisher server. > No crash or data discrepancies were obse

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Aug 31, 2020 at 7:28 PM Dilip Kumar wrote: > > On Mon, Aug 31, 2020 at 1:24 PM Amit Kapila wrote: > > > > On Mon, Aug 31, 2020 at 10:49 AM Amit Kapila > > wrote: > > > > > > On Sun, Aug 30, 2020 at 2:43 PM Dilip Kumar wrote: > > > > > > > > > > Another comment: > > > > > > +cleanup_rel

Re: Use T_IntList for uint32

On Mon, Aug 31, 2020 at 5:44 PM Ashutosh Bapat wrote: > > On Mon, Aug 31, 2020 at 4:59 PM Amit Kapila wrote: > > > Now, as far as I can see there is no problem in using T_IntList in > > such usage because we are not going to fetch stored unsigned value as > > a signed value, so the comparison in

Re: Use T_IntList for uint32

On Mon, Aug 31, 2020 at 6:58 PM Tom Lane wrote: > > Amit Kapila writes: > > Currently pg_list.h doesn't have a variant for uint32 list (like > > T_UIntList), is there a reason other than that that we don't need it > > till now? > > I'm not in favor of adding another list variant code just for tha

Re: doc review for v13

On Mon, Aug 31, 2020 at 08:42:08AM -0500, Justin Pryzby wrote: > On Mon, Aug 31, 2020 at 04:28:20PM +0900, Michael Paquier wrote: >> Wouldn't it be more simple to use "to prepare for a base backup" here? > > I think it's useful to say "prepare to take" since it's more specific.. It's > not "prepa

Re: Documentation patch for backup manifests in protocol.sgml

On Mon, Aug 31, 2020 at 06:48:53PM -0400, Bruce Momjian wrote: > Patch applied through 13. Thanks. -- Michael signature.asc Description: PGP signature

Re: Get memory contexts of an arbitrary backend process

Hi, On 2020-08-31 20:22:18 +0900, torikoshia wrote: > After commit 3e98c0bafb28de, we can display the usage of the > memory contexts using pg_backend_memory_contexts system > view. > > However, its target is limited to the process attached to > the current session. > > As discussed in the threa

Re: Manager for commit fest 2020-09

On Mon, Aug 31, 2020 at 04:37:12PM +0900, Michael Paquier wrote: > We are going to be in September in a couple of hours, meaning that the > second commit fest for Postgres 14 will begin soon. Do we have any > volunteers to take the role of CFM this time? As of the moment this message is written,

Re: REINDEX SCHEMA/DATABASE/SYSTEM weak with dropped relations

On Mon, Aug 31, 2020 at 06:10:46PM +0300, Anastasia Lubennikova wrote: > I reviewed the patch. It does work and the code is clean and sane. It > implements a logic that we already had in CLUSTER, so I think it was simply > an oversight. Thank you for fixing this. Thanks Anastasia for the review.

Re: v13: show extended stats target in \d

Hi Justin, On 2020/08/31 14:00, Justin Pryzby wrote: The stats target can be set since commit d06215d03, but wasn't shown by psql. ALTER STATISISTICS .. SET STATISTICS n. Normal (1-D) stats targets are shown in \d+ table. Stats objects are shown in \d (no plus). Arguably, this should be shown

Re: v13: show extended stats target in \d

On Mon, Aug 31, 2020 at 07:47:35AM +, gkokola...@pm.me wrote: > ‐‐‐ Original Message ‐‐‐ > On Monday, 31 August 2020 08:00, Justin Pryzby wrote: > > > The stats target can be set since commit d06215d03, but wasn't shown by > > psql. > > ALTER STATISISTICS .. SET STATISTICS n. > > > >

Re: Remove line length restriction in passwordFromFile()

On 2020/09/01 6:24, Tom Lane wrote: Per the discussion at [1], we're now aware of actual use-cases for password strings approaching a kilobyte in length. I think this puts the final nail in the coffin of the idea that passwordFromFile() can use a fixed-length line buffer. Therefore, commit 2

Re: Maximum password length

Alexander Kukushkin writes: > Self-containing tokens, for example JWT, could be easily longer than 100 > bytes. > We at Zalando are using such tokens and the usual size of JWT token is > 600-700 bytes. > It is not possible to "paste" such token into psql password prompt, > because the input is t

Re: Append with naive multiplexing of FDWs

Fujita-san, thank you for taking time! At Mon, 31 Aug 2020 19:10:39 +0900, Etsuro Fujita wrote in > On Mon, Aug 31, 2020 at 6:20 PM Etsuro Fujita wrote: > > * I know your patch is a POC one, but one concern about it (and > > Horiguchi-san's patch set) is concurrent data fetches by multiple > >

Re: Get rid of runtime handling of AlternativeSubPlan?

On Tue, Sep 1, 2020 at 1:42 AM Tom Lane wrote: > Andy Fan writes: > > Thank you for this code! I still have some confusion about when a > SubPlan > > should be executed when a join is involved. I care about this because > this > > has an impact on when we can get the num_exec for a subplan. >

Re: Boundary value check in lazy_tid_reaped()

On Mon, Aug 31, 2020 at 1:56 PM Peter Geoghegan wrote: > I wonder if Roaring bitmaps would work well for this: > > https://arxiv.org/abs/1709.07821 Alternatively, perhaps we could use a negative cache of heap blocks that have no tuples to kill at all. Maybe just a simple array whose elements are

Re: Documentation patch for backup manifests in protocol.sgml

On Mon, Aug 24, 2020 at 04:58:34PM +0900, Michael Paquier wrote: > On Fri, Aug 21, 2020 at 06:03:32PM -0400, Bruce Momjian wrote: > > On Tue, Aug 18, 2020 at 02:41:09PM +0200, Bernd Helmle wrote: > >> protocol.sgml describes the protocol messages received by a BASE_BACKUP > >> streaming command, bu

Re: Hybrid Hash/Nested Loop joins and caching results from subplans

Thanks for chipping in here. On Mon, 31 Aug 2020 at 17:57, Thomas Munro wrote: > I wonder what it would take to overcome the overheads of the separate > Result Cache node, with techniques to step out of the way or something > like that. So far it looks like there are more overheads to having the

Re: Ideas about a better API for postgres_fdw remote estimates

On Mon, Aug 31, 2020 at 05:46:22PM -0400, Bruce Momjian wrote: > On Mon, Aug 31, 2020 at 01:53:01PM -0400, Tom Lane wrote: > > Stephen Frost writes: > > > Feature work either requires changes to pg_dump, or not. I agree that > > > features which don't require pg_dump changes are definitionally le

Re: Ideas about a better API for postgres_fdw remote estimates

On Mon, Aug 31, 2020 at 01:53:01PM -0400, Tom Lane wrote: > Stephen Frost writes: > > Feature work either requires changes to pg_dump, or not. I agree that > > features which don't require pg_dump changes are definitionally less > > work than features which do (presuming the rest of the feature i

Re: Ideas about a better API for postgres_fdw remote estimates

On Mon, Aug 31, 2020 at 01:26:59PM -0400, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us) wrote: > > I actually don't know which statement above is correct, because of the > > "forever" maintenance. > > I can understand not being sure which is correct, and we can all have > different poi

Remove line length restriction in passwordFromFile()

Per the discussion at [1], we're now aware of actual use-cases for password strings approaching a kilobyte in length. I think this puts the final nail in the coffin of the idea that passwordFromFile() can use a fixed-length line buffer. Therefore, commit 2eb3bc588 (which added a warning for overl

Re: Boundary value check in lazy_tid_reaped()

On Mon, Aug 31, 2020 at 12:22 PM Thomas Munro wrote: > On Sun, Aug 30, 2020 at 11:08 PM Masahiko Sawada > wrote: > > So my proposal is to add boundary value check in lazy_tid_reaped() > > before executing bsearch(3). This will help when index vacuum happens > > multiple times or when garbage tupl

Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

Hi, On 2020-08-31 17:35:14 -0300, Ranier Vilela wrote: > Em seg., 31 de ago. de 2020 às 17:05, Andres Freund > escreveu: > > So it seems Rainier needs to turn this test off, because it actually is > > intentional. > > > No problem. > If intentional, the code at TransactionIdPrecedes, already know

Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

Em seg., 31 de ago. de 2020 às 17:05, Andres Freund escreveu: > Hi, > > On 2020-08-31 12:38:51 -0700, Peter Geoghegan wrote: > > On Mon, Aug 31, 2020 at 11:42 AM Andres Freund > wrote: > > > Unsigned integer overflow is well defined in the standard. So I don't > understand what this is purportin

Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

Em seg., 31 de ago. de 2020 às 16:39, Peter Geoghegan escreveu: > On Mon, Aug 31, 2020 at 11:42 AM Andres Freund wrote: > > Unsigned integer overflow is well defined in the standard. So I don't > understand what this is purporting to warn about. > > Presumably it's simply warning that the value

Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

Hi, On 2020-08-31 12:38:51 -0700, Peter Geoghegan wrote: > On Mon, Aug 31, 2020 at 11:42 AM Andres Freund wrote: > > Unsigned integer overflow is well defined in the standard. So I don't > > understand what this is purporting to warn about. > > Presumably it's simply warning that the value -429

Re: Boundary value check in lazy_tid_reaped()

On Tue, Sep 1, 2020 at 7:21 AM Thomas Munro wrote: > On Sun, Aug 30, 2020 at 11:08 PM Masahiko Sawada > wrote: > > So my proposal is to add boundary value check in lazy_tid_reaped() > > before executing bsearch(3). This will help when index vacuum happens > > multiple times or when garbage tuples

Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

On Mon, Aug 31, 2020 at 11:42 AM Andres Freund wrote: > Unsigned integer overflow is well defined in the standard. So I don't > understand what this is purporting to warn about. Presumably it's simply warning that the value -4294901760 (i.e. the result of 3 - 4294901763) cannot be faithfully rep

Re: Sometimes the output to the stdout in Windows disappears

I only found that calling WSACleanup instead of PQfinish has the same effect. I don't see any big performance issues due to the extra fflush call in this place. I will be glad to find a more elegant solution. Victor Spirin Postgres Professional:http://www.postgrespro.com The Russian Postgres

Re: Boundary value check in lazy_tid_reaped()

On Sun, Aug 30, 2020 at 11:08 PM Masahiko Sawada wrote: > So my proposal is to add boundary value check in lazy_tid_reaped() > before executing bsearch(3). This will help when index vacuum happens > multiple times or when garbage tuples are concentrated to a narrow > range. Makes sense if it's of

Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

Hi, On August 31, 2020 11:08:49 AM PDT, Ranier Vilela wrote: >Em seg., 31 de ago. de 2020 às 14:43, Ranier Vilela > >escreveu: > >> Em seg., 31 de ago. de 2020 às 14:00, Alvaro Herrera < >> alvhe...@2ndquadrant.com> escreveu: >> >>> On 2020-Aug-31, Ranier Vilela wrote: >>> >>> > More troubles wi

Re: list of extended statistics on psql

po 31. 8. 2020 v 18:32 odesílatel Tomas Vondra napsal: > On Mon, Aug 31, 2020 at 12:18:09PM -0400, Alvaro Herrera wrote: > >On 2020-Aug-31, Tomas Vondra wrote: > > > >> I wonder if trying to list info about all stats from the statistics > >> object in a single line is necessary. Maybe we should s

Re: LogwrtResult contended spinlock

Hi, On August 31, 2020 11:34:45 AM PDT, Alvaro Herrera wrote: >On 2020-Aug-31, Andres Freund wrote: > >> Hi, >> >> On August 31, 2020 11:21:56 AM PDT, Alvaro Herrera > wrote: > >> >At first I wanted to make the new LWLock cover only LogwrtResult >> >proper, >> >and leave LogwrtRqst alone. Ho

Re: LogwrtResult contended spinlock

On 2020-Aug-31, Andres Freund wrote: > Hi, > > On August 31, 2020 11:21:56 AM PDT, Alvaro Herrera > wrote: > >At first I wanted to make the new LWLock cover only LogwrtResult > >proper, > >and leave LogwrtRqst alone. However on doing it, it seemed that that > >might change the locking protoc

Re: Sometimes the output to the stdout in Windows disappears

Victor Spirin writes: > Sometimes the output to stdout on Windows on multicore machines does not > go through after connecting and disconnecting to the server using the > PQconnectdbParams and PQfinish functions. I tested on 6 cores. Hm, why is this not Microsoft's bug to solve? I do wonder if

Re: Get memory contexts of an arbitrary backend process

Hi po 31. 8. 2020 v 17:03 odesílatel Kasahara Tatsuhito < kasahara.tatsuh...@gmail.com> napsal: > Hi, > > On Mon, Aug 31, 2020 at 8:22 PM torikoshia > wrote: > > As discussed in the thread[1], it'll be useful to make it > > possible to get the memory contexts of an arbitrary backend > > process.

Re: LogwrtResult contended spinlock

Hi, On August 31, 2020 11:21:56 AM PDT, Alvaro Herrera wrote: >Jaime Casanova recently reported a situation where pglogical >replicating >from 64 POS sites to a single central (64-core) node, each with two >replication sets, causes XLog's info_lck to become highly contended >because of frequent

LogwrtResult contended spinlock

Jaime Casanova recently reported a situation where pglogical replicating from 64 POS sites to a single central (64-core) node, each with two replication sets, causes XLog's info_lck to become highly contended because of frequently reading LogwrtResult. We tested the simple fix of adding a new LWLo

Sometimes the output to the stdout in Windows disappears

Hi! Sometimes the output to stdout on Windows on multicore machines does not go through after connecting and disconnecting to the server using the PQconnectdbParams and PQfinish functions. I tested on 6 cores. First we appeared this in some pgbench tests.  Then we found that this happens on

Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

Em seg., 31 de ago. de 2020 às 14:43, Ranier Vilela escreveu: > Em seg., 31 de ago. de 2020 às 14:00, Alvaro Herrera < > alvhe...@2ndquadrant.com> escreveu: > >> On 2020-Aug-31, Ranier Vilela wrote: >> >> > More troubles with undefined-behavior. >> > >> > This type of code can leaves overflow: >>

Re: xl_heap_header alignment?

On Sat, Aug 22, 2020 at 09:00:15PM +0200, Antonin Houska wrote: > Antonin Houska wrote: > > > If the comment tells that t_hoff can be computed (i.e. it's no necessary to > > include it in the structure), I think the comment should tell why it's yet > > included. Maybe something about "historical

Re: Ideas about a better API for postgres_fdw remote estimates

Stephen Frost writes: > Feature work either requires changes to pg_dump, or not. I agree that > features which don't require pg_dump changes are definitionally less > work than features which do (presuming the rest of the feature is the > same in both cases) but that isn't a justification to not

Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

Em seg., 31 de ago. de 2020 às 14:00, Alvaro Herrera < alvhe...@2ndquadrant.com> escreveu: > On 2020-Aug-31, Ranier Vilela wrote: > > > More troubles with undefined-behavior. > > > > This type of code can leaves overflow: > > var = (cast) (expression); > > diff = (int32) (id1 - id2); > > > > See:

Re: Get rid of runtime handling of AlternativeSubPlan?

Andy Fan writes: > Thank you for this code! I still have some confusion about when a SubPlan > should be executed when a join is involved. I care about this because this > has an impact on when we can get the num_exec for a subplan. > The subplan in a target list, it is executed after the join

Re: Ideas about a better API for postgres_fdw remote estimates

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Mon, Aug 31, 2020 at 12:56:21PM -0400, Stephen Frost wrote: > > The point I was making was that it has value and people did realize it > > but there's only so many resources to go around when it comes to hacking > > on PG and therefore it s

Re: Get rid of runtime handling of AlternativeSubPlan?

I wrote: > One inefficiency I see that we could probably get rid of is > where make_subplan() is doing > /* Now we can check if it'll fit in hash_mem */ > /* XXX can we check this at the Path stage? */ I went ahead and fixed that, and I also realized there's another small i

Re: Ideas about a better API for postgres_fdw remote estimates

On Mon, Aug 31, 2020 at 12:56:21PM -0400, Stephen Frost wrote: > Greetings, > * Bruce Momjian (br...@momjian.us) wrote: > The point I was making was that it has value and people did realize it > but there's only so many resources to go around when it comes to hacking > on PG and therefore it simply

Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

On 2020-Aug-31, Ranier Vilela wrote: > More troubles with undefined-behavior. > > This type of code can leaves overflow: > var = (cast) (expression); > diff = (int32) (id1 - id2); > > See: > diff64 = ((long int) d1 - (long int) d2); > diff64=-4294901760 Did you compile this with gcc -f

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

Hi Amit/Dilip, I have tested a few scenarios on top of the v56 patches, where the replication worker still had few subtransactions in uncommitted state and we restart the publisher server. No crash or data discrepancies were observed, attached are the test scenarios verified. *Data Setup:* *Publ

Re: Ideas about a better API for postgres_fdw remote estimates

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Mon, Aug 31, 2020 at 12:19:52PM -0400, Stephen Frost wrote: > > * Bruce Momjian (br...@momjian.us) wrote: > > > I don't think there was enough value to do statistics migration just for > > > pg_upgrade, but doing it for pg_upgrade and FDWs

Re: Ideas about a better API for postgres_fdw remote estimates

On Mon, Aug 31, 2020 at 12:19:52PM -0400, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us) wrote: > > I don't think there was enough value to do statistics migration just for > > pg_upgrade, but doing it for pg_upgrade and FDWs seems like it might > > have enough demand to justify the requ

Re: list of extended statistics on psql

On Mon, Aug 31, 2020 at 12:18:09PM -0400, Alvaro Herrera wrote: On 2020-Aug-31, Tomas Vondra wrote: I wonder if trying to list info about all stats from the statistics object in a single line is necessary. Maybe we should split the info into one line per statistics, so for example CREATE S

Re: Ideas about a better API for postgres_fdw remote estimates

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Sat, Aug 29, 2020 at 12:50:59PM -0400, Tom Lane wrote: > > Stephen Frost writes: > > > Isn't this going to create a version dependency that we'll need to deal > > > with..? What if a newer major version has some kind of improved ANALYZE >

Re: list of extended statistics on psql

On 2020-Aug-31, Tomas Vondra wrote: > I wonder if trying to list info about all stats from the statistics > object in a single line is necessary. Maybe we should split the info > into one line per statistics, so for example > > CREATE STATISTICS s (mcv, ndistinct, dependencies) ON ... > > wo

Re: Ideas about a better API for postgres_fdw remote estimates

On Sat, Aug 29, 2020 at 12:50:59PM -0400, Tom Lane wrote: > Stephen Frost writes: > > Isn't this going to create a version dependency that we'll need to deal > > with..? What if a newer major version has some kind of improved ANALYZE > > command, in terms of what it looks at or stores, and it's t

Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior

More troubles with undefined-behavior. This type of code can leaves overflow: var = (cast) (expression); diff = (int32) (id1 - id2); See: diff64 = ((long int) d1 - (long int) d2); diff64=-4294901760 #include #include int main() { unsigned int d1 = 3; unsigned int d2 = 4294901

Re: PATCH: Batch/pipelining support for libpq

Hi, It seems like this patch is nearly finished. I fixed all the remaining issues. I'm also asking a confirmation of the test scenarios you want to see in the next version of the patch. > Hi, > > On 2020-07-10 19:01:49 -0400, Alvaro Herrera wrote: > > Totally unasked for, here's a rebase of this

Re: Get rid of runtime handling of AlternativeSubPlan?

David Rowley writes: > Do you feel that the choice to create_plan() on the subplan before > planning the outer query is still a good one? ISTM that that was > required when the AlternativeSubplan decision was made during > execution, since we, of course, need a plan to execute. If the > decision

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

On Mon, Aug 31, 2020 at 05:56:58PM +0900, Kyotaro Horiguchi wrote: > Hello, Bruce. > > At Thu, 27 Aug 2020 15:41:40 -0400, Bruce Momjian wrote in > > > My point here is just "are we OK to remove it?" > > > > Yes, in PG 14. Security is confusing enough, so having a mis-named > > option that doe

Re: list of extended statistics on psql

On Mon, Aug 31, 2020 at 10:28:38AM -0400, Alvaro Herrera wrote: On 2020-Aug-30, Tomas Vondra wrote: On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote: > I wonder how to report that. Knowing that psql \-commands are not meant > for anything other than human consumption, maybe we

Re: list of extended statistics on psql

On Mon, Aug 31, 2020 at 10:58:11AM -0400, Tom Lane wrote: Alvaro Herrera writes: If we do put each type in its own row -- at least "logical" row, say string_agg(unnest(array_of_types), '\n') -- then we can put the size of each type in a separate column with string_agg(unnest(array_of_sizes), '

Re: Continuing instability in insert-conflict-specconflict test

Let me (rather shamelessly) extract a couple of patches from the patch set that was already shared in the fault injection framework proposal [1]. The first patch incorporates a new syntax in isolation spec grammar to explicitly mark a step that is expected to block (due to reasons other than locks

Re: REINDEX SCHEMA/DATABASE/SYSTEM weak with dropped relations

On 13.08.2020 07:38, Michael Paquier wrote: Hi all, While working on support for REINDEX for partitioned relations, I have noticed an old bug in the logic of ReindexMultipleTables(): the list of relations to process is built in a first transaction, and then each table is done in an independent t

Re: file_fdw vs relative paths

On Mon, Aug 31, 2020 at 01:16:05PM +0200, Magnus Hagander wrote: > Bruce, I've applied and backpatched your docs patch for this. > > Gah, and of course right after doing that, I remembered I wanted to get a > second change in :) To solve the "who's this Josh" question, I suggest we also > chan

Re: Get memory contexts of an arbitrary backend process

Hi, On Mon, Aug 31, 2020 at 8:22 PM torikoshia wrote: > As discussed in the thread[1], it'll be useful to make it > possible to get the memory contexts of an arbitrary backend > process. +1 > Attached PoC patch makes pg_get_backend_memory_contexts() > display meory contexts of the specified PID

Re: list of extended statistics on psql

Alvaro Herrera writes: > If we do put each type in its own row -- at least "logical" row, say > string_agg(unnest(array_of_types), '\n') -- then we can put the size of each > type > in a separate column with string_agg(unnest(array_of_sizes), '\n') > statname | definition| type

Re: list of extended statistics on psql

On 2020-Aug-30, Tomas Vondra wrote: > On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote: > > I wonder how to report that. Knowing that psql \-commands are not meant > > for anything other than human consumption, maybe we can use a format() > > string that says "built: %d bytes" when

Re: Deprecating postfix and factorial operators in PostgreSQL 13

> On Aug 30, 2020, at 11:50 AM, Tom Lane wrote: > > Mark Dilger writes: >> [ v3-0001-Adding-deprecation-notices.patch ] > > Pushed with some fiddling. Thanks! — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: New default role- 'pg_read_all_data'

‐‐‐ Original Message ‐‐‐ On Monday, 31 August 2020 02:20, Stephen Frost wrote: > Greetings, > > - Stephen Frost (sfr...@snowman.net) wrote: > > > - Magnus Hagander (mag...@hagander.net) wrote: > > > > > On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost sfr...@snowman.net wrote: > > >

Re: INSERT ON CONFLICT and RETURNING

On 24.08.2020 13:37, Geoff Winkless wrote: On Sat, 22 Aug 2020 at 08:16, Konstantin Knizhnik wrote: It is possible to do something like this: with ins as (insert into jsonb_schemas (schema) values (obj_schema) on conflict(schema) do nothing returning id) select coalesce((select id from

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Aug 31, 2020 at 1:24 PM Amit Kapila wrote: > > > 2. > 009_stream_simple.pl > +# Insert, update and delete enough rows to exceed the 64kB limit. > +$node_publisher->safe_psql('postgres', q{ > +BEGIN; > +INSERT INTO test_tab SELECT i, md5(i::text) FROM generate_series(3, 5000) > s(i); > +UP

Re: Use T_IntList for uint32

Amit Kapila writes: > Currently pg_list.h doesn't have a variant for uint32 list (like > T_UIntList), is there a reason other than that that we don't need it > till now? I'm not in favor of adding another list variant code just for that; the overhead is nonzero, and the gain negligible. (I think

Re: Ideas about a better API for postgres_fdw remote estimates

On Mon, Aug 31, 2020 at 3:36 PM Andrey V. Lepikhov wrote: > > Thanks for this helpful feedback. > > I found several threads related to the problem [1-3]. > I agreed that this task needs to implement an API for > serialization/deserialization of statistics: > pg_load_relation_statistics(json_string

Re: Use T_IntList for uint32

On Mon, Aug 31, 2020 at 4:59 PM Amit Kapila wrote: > Now, as far as I can see there is no problem in using T_IntList in > such usage because we are not going to fetch stored unsigned value as > a signed value, so the comparison in get_schema_sent_in_streamed_txn > should work well. However, still

Re: Yet another fast GiST build (typo)

> > Pavel sent me few typos offlist. PFA v12 fixing these typos. > Thanks! > Now I consider the patch ready to be committed and mark it so on CF. Thank you! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com

Re: [PATCH] Covering SPGiST index

> > But let's change macro a bit. When I see > SGLT_SET_OFFSET(leafTuple->nextOffset, InvalidOffsetNumber); > I expect that leafTuple->nextOffset is function argument by value and will > not be changed. > For example see ItemPointerSetOffsetNumber() - it's not exposing ip_posid. > > Also, I'd propo

Use T_IntList for uint32

Currently pg_list.h doesn't have a variant for uint32 list (like T_UIntList), is there a reason other than that that we don't need it till now? I see that one can use T_OidList instead (as Oid is uint32) but I am not sure if that is a good idea to say use it for maintaining a list of TransactionIds

Get memory contexts of an arbitrary backend process

Hi, After commit 3e98c0bafb28de, we can display the usage of the memory contexts using pg_backend_memory_contexts system view. However, its target is limited to the process attached to the current session. As discussed in the thread[1], it'll be useful to make it possible to get the memory con

Re: file_fdw vs relative paths

On Mon, Aug 31, 2020 at 1:10 PM Magnus Hagander wrote: > > > On Tue, Aug 25, 2020 at 9:28 AM Li Japin wrote: > >> >> On Aug 25, 2020, at 8:26 AM, Bruce Momjian wrote: >> >> Yes, I tested back to 9.5 too: >> >> CREATE EXTENSION file_fdw; >> CREATE SERVER pgconf FOREIGN DATA WRAPPER file_fdw; >>

Re: file_fdw vs relative paths

On Tue, Aug 25, 2020 at 9:28 AM Li Japin wrote: > > On Aug 25, 2020, at 8:26 AM, Bruce Momjian wrote: > > Yes, I tested back to 9.5 too: > > CREATE EXTENSION file_fdw; > CREATE SERVER pgconf FOREIGN DATA WRAPPER file_fdw; > CREATE FOREIGN TABLE pgconf (line TEXT) SERVER pgconf OPTIONS ( filename

Re: Parallel copy

On Thu, Aug 27, 2020 at 8:04 AM Greg Nancarrow wrote: > - Parallel Copy with 1 worker ran slower than normal Copy in a couple > of cases (I did question if allowing 1 worker was useful in my patch > review). Thanks Greg for your review & testing. I had executed various tests with 1GB, 2GB & 5GB w

Re: Append with naive multiplexing of FDWs

On Mon, Aug 31, 2020 at 6:20 PM Etsuro Fujita wrote: > * I know your patch is a POC one, but one concern about it (and > Horiguchi-san's patch set) is concurrent data fetches by multiple > foreign scan nodes using the same connection in the case of > postgres_fdw. Here is an example causing an er

Re: Ideas about a better API for postgres_fdw remote estimates

On 8/29/20 9:50 PM, Tom Lane wrote: Years ago (when I was still at Salesforce, IIRC, so ~5 years) we had some discussions about making it possible for pg_dump and/or pg_upgrade to propagate stats data forward to the new database. There is at least one POC patch in the archives for doing that by

Re: Append with naive multiplexing of FDWs

On Thu, Dec 5, 2019 at 1:46 PM Thomas Munro wrote: > On Thu, Dec 5, 2019 at 4:26 PM Kyotaro Horiguchi > wrote: > > There's my pending (somewhat stale) patch, which allows to run local > > scans while waiting for remote servers. > > > > https://www.postgresql.org/message-id/20180515.202945.6933278

Re: Append with naive multiplexing of FDWs

On Sun, Dec 1, 2019 at 4:26 AM Bruce Momjian wrote: > On Sun, Nov 17, 2019 at 09:54:55PM +1300, Thomas Munro wrote: > > On Sat, Sep 28, 2019 at 4:20 AM Bruce Momjian wrote: > > > On Wed, Sep 4, 2019 at 06:18:31PM +1200, Thomas Munro wrote: > > > > A few years back[1] I experimented with a simple

Re: [PATCH] - Provide robust alternatives for replace_string

‐‐‐ Original Message ‐‐‐ On Wednesday, 19 August 2020 11:07, Georgios wrote: > > > ‐‐‐ Original Message ‐‐‐ > On Friday, 7 August 2020 09:02, Asim Praveen pa...@vmware.com wrote: > > > > On 05-Aug-2020, at 7:01 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: > > > On 2020-Aug

Re: Is it worth accepting multiple CRLs?

At Tue, 18 Aug 2020 16:43:47 +0900 (JST), Kyotaro Horiguchi wrote in > Thank you very much. I'll do that after some polishing. > > A near-by discussion about OpenSSL3.0 conflicts with this but it's > easy to follow. Rebased. Fixed bogus tests and strange tentative API change of SSLServer.pm.

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

Hello, Bruce. At Thu, 27 Aug 2020 15:41:40 -0400, Bruce Momjian wrote in > > My point here is just "are we OK to remove it?" > > Yes, in PG 14. Security is confusing enough, so having a mis-named > option that doesn't do anything more than just not specifying clientcert > is not useful and sho

Re: Handing off SLRU fsyncs to the checkpointer

Hi Thomas, hackers, >> ... %CPU ... COMMAND >> ... 97.4 ... postgres: startup recovering 00010089 > So, what else is pushing this thing off CPU, anyway? For one thing, I > guess it might be stalling while reading the WAL itself, because (1) > we only read it 8KB at a time, relying

Re: Switch to multi-inserts for pg_depend

On Sat, Aug 15, 2020 at 10:50:37AM +0900, Michael Paquier wrote: > What are you suggesting here? A new API layer to manage a set of > slots? It has been a couple of weeks, and I am not really sure what is the suggestion here. So I would like to move on with this patch set as the changes are stra

  1   2   >