Re: New statistics for tuning WAL buffer size

On 2020-09-11 01:40, Fujii Masao wrote: On 2020/09/09 13:57, Masahiro Ikeda wrote: On 2020-09-07 16:19, Fujii Masao wrote: On 2020/09/07 9:58, Masahiro Ikeda wrote: Thanks for the review and advice! On 2020-09-03 16:05, Fujii Masao wrote: On 2020/09/02 18:56, Masahiro Ikeda wrote: +/* -

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Thu, 2020-09-10 at 18:42 -0700, Peter Geoghegan wrote: > We still need to put the reliance on ltsWriteBlock() allocating many > blocks before they've been logically written on some kind of formal > footing for Postgres 13 -- it is now possible that an all-zero block > will be left behind even af

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, 2020-09-14 at 20:48 -0700, Peter Geoghegan wrote: > On Mon, Sep 14, 2020 at 8:07 PM Jeff Davis wrote: > > Sure. Will backporting either patch into REL_13_STABLE now > > interfere > > with RC1 release in any way? > > The RMT will discuss this. > > It would help if there was a patch ready

Re: tab completion of IMPORT FOREIGN SCHEMA

On Mon, Aug 17, 2020 at 02:15:34PM +0900, Michael Paquier wrote: > Sounds fine to me as well. The LIMIT TO and EXCEPT clauses are > optional, so using TailMatches() looks fine. > > + else if (TailMatches("FROM", "SERVER", MatchAny, "INTO", MatchAny)) > + COMPLETE_WITH("OPTIONS") > Shouldn

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

On 2020-09-15 10:54:29 +0530, Dilip Kumar wrote: > What problem do you see if we set xmax to the InvalidTransactionId and > HEAP_XMAX_INVALID flag in the infomask ? 1) It'll make a dead tuple appear live. You cannot do this for tuples with an xid below the horizon. 2) it'll break HOT chain foll

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

On Tue, Sep 15, 2020 at 2:35 AM Andres Freund wrote: > > Hi, > > On 2020-09-14 17:00:48 -0400, Robert Haas wrote: > > On Mon, Sep 14, 2020 at 4:13 PM Andres Freund wrote: > > > My understanding of the case we're discussing is that it's corruption > > > (e.g. relfrozenxid being different than tabl

Re: Gripes about walsender command processing

On Mon, Sep 14, 2020 at 11:34:44PM -0400, Tom Lane wrote: > (I don't quite follow your comment about repslot drop, btw.) There is already a command tag equivalent to DROP_REPLICATION_SLOT: $ git grep REPLICATION -- */cmdtaglist.h src/include/tcop/cmdtaglist.h:PG_CMDTAG(CMDTAG_DROP_REPLICATION_SLOT

Re: PG 13 release notes, first draft

On 2020-09-09 22:57, Jonathan S. Katz wrote: + + + Parallelized vacuuming of B-tree indexes + + I don't think B-tree indexes are relevant here. AFAICT, this feature applies to all indexes. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Develop

Re: pg_restore causing deadlocks on partitioned tables

Alvaro Herrera writes: > On 2020-Sep-14, Tom Lane wrote: >> AFAICS, it is utterly silly for InitResultRelInfo to be forcing >> a partition qual to be computed when we might not need it. >> We could flush ResultRelInfo.ri_PartitionCheck altogether and >> have anything that was reading it instead do

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

On Tue, Sep 15, 2020 at 8:38 AM Tom Lane wrote: > > Amit Kapila writes: > > On Mon, Sep 14, 2020 at 9:42 PM Tom Lane wrote: > >> BTW, unless someone has changed the behavior of dynahash when I > >> wasn't looking, those MemoryContextSwitchTos shown above are useless. > > > As far as I can see th

Re: I'd like to discuss scaleout at PGCon

Hello all, # I'm resending because some error occurred I've overhauled the scaleout design wiki I presented at PGCon 2018 developer unconference and assembled the research of other DBMSs' scale-out features. Scaleout Design https://wiki.postgresql.org/wiki/Scaleout_Design I intentionally have p

Re: Parallelize stream replication process

On Tue, Sep 15, 2020 at 9:27 AM Li Japin wrote: > > For now, postgres use single process to send, receive and replay the WAL when > we use stream replication, > is there any point to parallelize this process? If it does, how do we start? > > Any thoughts? > I think we must ask few questions: 1.

Re: pg_restore causing deadlocks on partitioned tables

On 2020-Sep-14, Tom Lane wrote: > > (1) TRUNCATE on a partition tries to get AccessShareLock on the parent; > > The reason for this is that > > (a) ExecuteTruncateGuts calls InitResultRelInfo, because it might > need that to fire TRUNCATE triggers for the child relation. Hmm, this seems legitim

Re: I'd like to discuss scaleout at PGCon

Hello all, I've overhauled the scaleout design wiki I presented at PGCon 2018 developer unconference and assembled the research of other DBMSs' scale-out features. Scaleout Design https://wiki.postgresql.org/wiki/Scaleout_Design I intentionally have put little conclusion on our specification an

Parallelize stream replication process

Hi, hackers For now, postgres use single process to send, receive and replay the WAL when we use stream replication, is there any point to parallelize this process? If it does, how do we start? Any thoughts? Best regards Japin Li

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, Sep 14, 2020 at 8:07 PM Jeff Davis wrote: > Sure. Will backporting either patch into REL_13_STABLE now interfere > with RC1 release in any way? The RMT will discuss this. It would help if there was a patch ready to go. Thanks -- Peter Geoghegan

Re: Gripes about walsender command processing

Michael Paquier writes: > On Mon, Sep 14, 2020 at 12:51:39PM -0400, Tom Lane wrote: >> (Is there a better way to get the name of a replication command? >> I didn't look very hard for one.) > Wouldn't that just be in cmdtaglist.h, but extended for nodes used for > replication commands? Then you c

Re: Fix for parallel BTree initialization bug

Amit Kapila writes: > On Mon, Sep 14, 2020 at 11:26 PM Peter Geoghegan wrote: >> The fix seems sensible to me. > Thanks, I think it is better to wait for a day or two as yesterday > only we stamped 13 and we need to backpatch this. Right, please avoid pushing anything non-critical to REL_13_STA

Re: Gripes about walsender command processing

On Mon, Sep 14, 2020 at 12:51:39PM -0400, Tom Lane wrote: > I looked into the other point about ps status always claiming the > walsender is "idle". This turns out to be something PostgresMain > does automatically, so unless we want to uglify that logic, we have > to make walsenders set the field

Re: Avoid useless retrieval of defaults and check constraints in pg_dump -a

On Mon, Sep 14, 2020 at 10:56:01PM -0400, Tom Lane wrote: > (Note that we disallow sub-queries in CHECK constraints, and also > disclaim responsibility for what happens if you cheat by hiding > the subquery in a function. So while it's certainly possible to > build CHECK constraints that only work

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

Amit Kapila writes: > On Mon, Sep 14, 2020 at 9:42 PM Tom Lane wrote: >> BTW, unless someone has changed the behavior of dynahash when I >> wasn't looking, those MemoryContextSwitchTos shown above are useless. > As far as I can see they are useless in this case but I think they > might be requir

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, 2020-09-14 at 19:29 -0700, Peter Geoghegan wrote: > Let's assume that we'll teach LogicalTapeSetBlocks() to use > nBlocksWritten in place of nBlocksAllocated in all cases, as now > seems > likely. Rather than asserting "nBlocksWritten == nBlocksAllocated" > inside LogicalTapeSetBlocks() (as

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-09-15 11:56:24 +0900, Michael Paquier wrote: > On Mon, Sep 14, 2020 at 05:42:51PM -0700, Andres Freund wrote: > > My test uses IPC::Run - although I'm indirectly 'use'ing, which I guess > > isn't pretty. Just as 013_crash_restart.pl already did (even before > > psql/t/010_tab_completio

Re: Fix for parallel BTree initialization bug

On Mon, Sep 14, 2020 at 11:26 PM Peter Geoghegan wrote: > > On Mon, Sep 14, 2020 at 5:37 AM Amit Kapila wrote: > > I am planning to push this tomorrow after doing testing on > > back-branches. Let me know if you have any comments. > > The fix seems sensible to me. > Thanks, I think it is better

Re: Improving connection scalability: GetSnapshotData()

On Mon, Sep 14, 2020 at 05:42:51PM -0700, Andres Freund wrote: > My test uses IPC::Run - although I'm indirectly 'use'ing, which I guess > isn't pretty. Just as 013_crash_restart.pl already did (even before > psql/t/010_tab_completion.pl). I am mostly wondering whether we could > avoid copying the

Re: Avoid useless retrieval of defaults and check constraints in pg_dump -a

Michael Paquier writes: > On Tue, Jul 14, 2020 at 11:14:50AM +0200, Julien Rouhaud wrote: >> Note that those extraneous queries were found while trying to dump >> data out of a corrupted database. The issue wasn't an excessive >> runtime but corrupted catalog entries, so bypassing this code (sinc

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

On Mon, Sep 14, 2020 at 9:42 PM Tom Lane wrote: > > Amit Kapila writes: > > The attached patch will fix the issue. What do you think? > > I think it'd be cleaner to separate the initialization of a new entry from > validation altogether, along the lines of > > /* Find cached function info, cr

Re: Avoid useless retrieval of defaults and check constraints in pg_dump -a

On Thu, Sep 10, 2020 at 02:31:32PM +0200, Daniel Gustafsson wrote: > Given how unintrusive this optimization is, +1 from me to go ahead with this > patch. pg_dump tests pass. Personally I would've updated the nearby comments > to reflect why the check for dataOnly is there, but MMV there. I'm mo

Re: Avoid useless retrieval of defaults and check constraints in pg_dump -a

On Tue, Jul 14, 2020 at 11:14:50AM +0200, Julien Rouhaud wrote: > Note that those extraneous queries were found while trying to dump > data out of a corrupted database. The issue wasn't an excessive > runtime but corrupted catalog entries, so bypassing this code (since I > was only interested in t

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, Sep 14, 2020 at 7:09 PM Peter Geoghegan wrote: > Oh, wait. Of course the point was that we wouldn't even have to use > nBlocksAllocated in LogicalTapeSetBlocks() anymore -- we would make > the assumption that nBlocksWritten could be used for all callers in > all cases. Which is a reasonabl

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, Sep 14, 2020 at 6:56 PM Peter Geoghegan wrote: > I'm not sure what I was talking about earlier when I connected this > with the main/instrumentation issue, since preallocation used by > logtape.c to help HashAggs-that-spill necessarily reserves blocks > without writing them out for a while

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, Sep 14, 2020 at 5:50 PM Jeff Davis wrote: > Yes, it was apparently an oversight. Patch attached. This is closer to how logical tapes are used within tuplesort.c. I notice that this leads to about a 50% reduction in temp file usage for a test case involving very little work_mem (work_mem i

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

On Tuesday, September 8, 2020 1:02 PM, Amit Kapila wrote: Hello, > On Mon, Sep 7, 2020 at 1:33 PM k.jami...@fujitsu.com > wrote: > > > > On Wednesday, September 2, 2020 5:49 PM, Amit Kapila wrote: > > > On Wed, Sep 2, 2020 at 9:17 AM Tom Lane wrote: > > > > > > > > Amit Kapila writes: > > > > >

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, 2020-09-14 at 15:54 -0700, Peter Geoghegan wrote: > Maybe the LogicalTapeRewindForRead() inconsistency you mention could > be fixed, which would enable the simplification you suggested. What > do > you think? Yes, it was apparently an oversight. Patch attached. RC1 was just stamped, are w

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-09-14 20:14:48 -0400, Tom Lane wrote: > Andres Freund writes: > > I think the approach of having a long running psql session is really > > useful, and probably would speed up some tests. Does anybody have a good > > idea for how to best, and without undue effort, to integrate this int

Re: Improving connection scalability: GetSnapshotData()

Andres Freund writes: > I think the approach of having a long running psql session is really > useful, and probably would speed up some tests. Does anybody have a good > idea for how to best, and without undue effort, to integrate this into > PostgresNode.pm? I don't really have a great idea, so

Re: pg_restore causing deadlocks on partitioned tables

I wrote: >> (2) ALTER TABLE ONLY ... ADD CONSTRAINT on a partition root tries to get >> AccessExclusiveLock on all child partitions, despite the ONLY. > The cause of this seems to be that ATPrepSetNotNull is too dumb to > avoid recursing to all the child tables when the parent is already > attnotn

Re: Adding Support for Copy callback functionality on COPY TO api

Hi Bilva, Thank you for registering this patch! I had a few suggestions: 1. Please run pg_indent[1] on your code. Make sure you add copy_data_destination_cb to src/tools/pgindent/typedefs.list. Please run pg_indent on only the files you changed (it will take files as command line args) 2. For f

Re: Use incremental sort paths for window functions

On Tue, 15 Sep 2020 at 00:02, Daniel Gustafsson wrote: > > > On 8 Jul 2020, at 06:57, David Rowley wrote: > > > > Over on [1] someone was asking about chained window paths making use > > of already partially sorted input. (The thread is on -general, so I > > guessed they're not using PG13.) > >

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-09-09 17:02:58 +0900, Ian Barwick wrote: > Attached, though bear in mind I'm not very familiar with parts of this, > particularly 2PC stuff, so consider it educated guesswork. Thanks for this, and the test case! Your commit fixes the issues, but not quite correctly. Multixacts should

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, Sep 14, 2020 at 3:54 PM Peter Geoghegan wrote: > If I add the assertion described above and run the regression tests, > it fails within "select_distinct" (and at other points). This is the > specific code: This variant of the same assertion works fine: +Assert(lts->enable_prealloc ||

Re: Simplified version of read_binary_file (src/backend/utils/adt/genfile.c)

Em sex., 11 de set. de 2020 às 17:44, Tom Lane escreveu: > Ranier Vilela writes: > > New version, with support to read Virtual File (pipe, FIFO and socket). > > With assert, in case, erroneous, of trying to read a pipe, with offset. > > I do agree that it might be worth skipping the fseeko call

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, Sep 14, 2020 at 3:39 PM Peter Geoghegan wrote: > I think that they are an exact match in practice (i.e. nBlocksWritten > == nBlocksAllocated), given when and how we call > LogicalTapeSetBlocks(). Just to be clear: this is only true for external sorts. The preallocation stuff can make nBlo

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, Sep 14, 2020 at 3:20 PM Jeff Davis wrote: > In the comment in the patch, you say: > > "In practice this probably doesn't matter because we'll be called after > the flush anyway, but be tidy." > > By which I assume you mean that LogicalTapeRewindForRead() will be > called before LogicalTape

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, Sep 14, 2020 at 3:24 PM Alvaro Herrera wrote: > I don't understand this patch. Or maybe I should say I don't understand > the code you're patching. Why isn't the correct answer *always* > nBlocksWritten? The comment in LogicalTapeSet says: I think that they are an exact match in practi

Re: pg_restore causing deadlocks on partitioned tables

I wrote: > However, the deadlock report suggests, and manual experimentation > confirms, that > (1) TRUNCATE on a partition tries to get AccessShareLock on the parent; The reason for this is that (a) ExecuteTruncateGuts calls InitResultRelInfo, because it might need that to fire TRUNCATE trigger

Re: logtape.c stats don't account for unused "prefetched" block numbers

On 2020-Sep-14, Peter Geoghegan wrote: > On Fri, Sep 11, 2020 at 6:37 PM Peter Geoghegan wrote: > > It would be awkward if we just used nBlocksWritten within > > LogicalTapeSetBlocks() in the case where we didn't preallocate (or in > > all cases). Not entirely sure what to do about that just yet.

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Mon, 2020-09-14 at 14:24 -0700, Peter Geoghegan wrote: > On Fri, Sep 11, 2020 at 6:37 PM Peter Geoghegan wrote: > > It would be awkward if we just used nBlocksWritten within > > LogicalTapeSetBlocks() in the case where we didn't preallocate (or > > in > > all cases). Not entirely sure what to d

Re: Division in dynahash.c due to HASH_FFACTOR

On Mon, Sep 14, 2020 at 11:35 PM David Rowley wrote: > I just did some benchmarking with this patch using the same recovery > benchmark that I used in [1] and also the two patches that I posted in > [2]. Additionally, I added a PANIC at the end of recovery so that I > could repeat the recovery ove

Re: logtape.c stats don't account for unused "prefetched" block numbers

On Fri, Sep 11, 2020 at 6:37 PM Peter Geoghegan wrote: > It would be awkward if we just used nBlocksWritten within > LogicalTapeSetBlocks() in the case where we didn't preallocate (or in > all cases). Not entirely sure what to do about that just yet. I guess that that's the logical thing to do, a

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

Hi, On 2020-09-14 17:00:48 -0400, Robert Haas wrote: > On Mon, Sep 14, 2020 at 4:13 PM Andres Freund wrote: > > My understanding of the case we're discussing is that it's corruption > > (e.g. relfrozenxid being different than table contents) affecting a HOT > > chain. I.e. by definition all withi

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

On Mon, Sep 14, 2020 at 4:13 PM Andres Freund wrote: > My understanding of the case we're discussing is that it's corruption > (e.g. relfrozenxid being different than table contents) affecting a HOT > chain. I.e. by definition all within a single page. We won't have > modified part of it independ

"Unified logging system" breaks access to pg_dump debug outputs

pg_dump et al have some low-level debug log messages that commit cc8d41511 converted to pg_log_debug() calls, replacing the previous one-off logging verbosity system that was there. However, these calls are dead code as things stand, because there is no way to set __pg_log_level high enough to get

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

Hi, On 2020-09-14 15:50:49 -0400, Robert Haas wrote: > On Mon, Sep 14, 2020 at 3:00 PM Alvaro Herrera > wrote: > > FWIW I agree with Andres' stance on this. The current system is *very* > > complicated and bugs are obscure already. If we hide them, what we'll > > be getting is a system where d

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

On Mon, Sep 14, 2020 at 3:00 PM Alvaro Herrera wrote: > FWIW I agree with Andres' stance on this. The current system is *very* > complicated and bugs are obscure already. If we hide them, what we'll > be getting is a system where data can become corrupted for no apparent > reason. I think I mig

Re: pg_restore causing deadlocks on partitioned tables

I wrote: > If memory serves, which it may not given my undercaffeinated state, > we would not expect there to be a direct dependency link between the > constraint and the table data "object". What there should be is > dependencies forcing the data to be restored before the post-data > boundary pse

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

On 2020-Sep-14, Andres Freund wrote: > It seems pretty dangerous to me. What exactly are you going to put into > xmin/xmax here? And how would anything you put into the first tuple not > break index lookups? There's no such thing as a frozen xmax (so far), so > what are you going to put in there?

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

Em seg., 14 de set. de 2020 às 15:33, Tom Lane escreveu: > Ranier Vilela writes: > > msvc 2019 (64 bits), is worried about it: > > C:\dll\postgres\src\backend\utils\adt\dbsize.c(630,20): warning C4334: > > '<<': resultado de 32-bit shift convertido implicitamente para 64 bits > > (64-bit shift

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

Hi, On 2020-09-14 13:26:27 -0400, Robert Haas wrote: > On Sat, Aug 29, 2020 at 4:36 AM Dilip Kumar wrote: > > One example is, suppose during vacuum, there are 2 tuples in the hot > > chain, and the xmin of the first tuple is corrupted (i.e. smaller > > than relfrozenxid). And the xmax of this

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

Ranier Vilela writes: > msvc 2019 (64 bits), is worried about it: > C:\dll\postgres\src\backend\utils\adt\dbsize.c(630,20): warning C4334: > '<<': resultado de 32-bit shift convertido implicitamente para 64 bits > (64-bit shift era pretendid > o?) [C:\dll\postgres\postgres.vcxproj] Yeah, most/a

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

Peter Eisentraut writes: > ok done msvc 2019 (64 bits), is worried about it: https://github.com/postgres/postgres/commit/0aa8f764088ea0f36620ae2955fa6c54ec736c46 "C:\dll\postgres\pgsql.sln" (default target) (1) -> "C:\dll\postgres\cyrillic_and_mic.vcxproj" (default target) (37) -> "C:\dll\postgr

Re: Fix overflow at return wchar2char (src/backend/utils/adt/pg_locale.c)

Ranier Vilela writes: > Em seg., 14 de set. de 2020 às 10:53, Daniel Gustafsson > escreveu: >> If the objection is that an unsigned var is tested with <= 0, then >> changing the >> semantics of the function seems a rather drastic solution: > But if wchar2char must be follow wcstombs_l API. > wch

Re: Fix for parallel BTree initialization bug

On Mon, Sep 14, 2020 at 5:37 AM Amit Kapila wrote: > I am planning to push this tomorrow after doing testing on > back-branches. Let me know if you have any comments. The fix seems sensible to me. -- Peter Geoghegan

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

On Sat, Aug 29, 2020 at 4:36 AM Dilip Kumar wrote: > One example is, suppose during vacuum, there are 2 tuples in the hot > chain, and the xmin of the first tuple is corrupted (i.e. smaller > than relfrozenxid). And the xmax of this tuple (which is same as the > xmin of the second tuple) is sma

Re: Use incremental sort paths for window functions

On Wed, Jul 08, 2020 at 04:57:21PM +1200, David Rowley wrote: Over on [1] someone was asking about chained window paths making use of already partially sorted input. (The thread is on -general, so I guessed they're not using PG13.) However, On checking PG13 to see if incremental sort would help

Re: Gripes about walsender command processing

Michael Paquier writes: > On Sun, Sep 13, 2020 at 03:47:51PM -0400, Tom Lane wrote: >> While trying to fix this, I also observed that exec_replication_command >> fails to clean up the temp context it made for parsing the command string, >> if that turns out to be a SQL command. This very accident

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

Amit Kapila writes: > The attached patch will fix the issue. What do you think? I think it'd be cleaner to separate the initialization of a new entry from validation altogether, along the lines of /* Find cached function info, creating if not found */ oldctx = MemoryContextSwitchTo(Cache

Re: On login trigger: take three

po 14. 9. 2020 v 17:53 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 14.09.2020 17:34, Pavel Stehule wrote: > > If we introduce buildin session trigger , we should to define what is the > session. Your design is much more related to the process than to session. > So

Re: Fix overflow at return wchar2char (src/backend/utils/adt/pg_locale.c)

Em seg., 14 de set. de 2020 às 10:53, Daniel Gustafsson escreveu: > > On 14 Sep 2020, at 14:41, Ranier Vilela wrote: > > > 1. wchar2char has a mistake when checking the return of > WideCharToMultiByte call. > > result variable is unsigned, therefore, cannot be less than zero, > returning -1 is n

Re: On login trigger: take three

On 14.09.2020 17:34, Pavel Stehule wrote: If we introduce buildin session trigger , we should to define what is the session. Your design is much more related to the process than to session. So the correct name should be "process_start" trigger, or some should be different. I think there are t

Re: pg_restore causing deadlocks on partitioned tables

Alvaro Herrera writes: > On 2020-Sep-14, Tom Lane wrote: >> Hm, this seems related to 2ba5b2db7, but not the same thing. >> Alvaro, any thoughts? > So apparently when we go to restore the table data for the partition, > the TRUNCATE deadlocks with the PK addition ... that's pretty odd; > shouldn'

Subscription test 013_partition.pl fails under CLOBBER_CACHE_ALWAYS

In connection with a nearby thread, I tried to run the subscription test suite in a CLOBBER_CACHE_ALWAYS build. I soon found that I had to increase wal_receiver_timeout, but after doing this: diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm index 1488bff..5fe6810 100644

Re: pg_dump --where option

> On 14 Sep 2020, at 12:04, Surafel Temesgen wrote: > On Fri, Jul 31, 2020 at 1:38 AM Daniel Gustafsson > wrote: > > > $ pg_dump -d cary --where="test1:a3 = ( select max(aa1) from test2 )" > > > testdump2 > > $ pg_dump: error: processing of table "public.test1" failed

Re: Function to execute a program

Greetings. * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Magnus Hagander (mag...@hagander.net) wrote: > >> Would it make sense to have a pg_execute_program() that corresponds to COPY > >> FROM PROGRAM? This would obviously have the same permissions restrictions > >> as COPY

RE: pg_restore causing deadlocks on partitioned tables

Forgot to mention the versions: pg_restore (PostgreSQL) 12.4 source/ destination databases also 12.4 D. -Original Message- From: Alvaro Herrera Sent: 14. rujna 2020. 16:40 To: Tom Lane Cc: Domagoj Smoljanovic ; pgsql-hack...@postgresql.org Subject: Re: pg_restore causing deadlocks on

Re: Function to execute a program

Stephen Frost writes: > * Magnus Hagander (mag...@hagander.net) wrote: >> Would it make sense to have a pg_execute_program() that corresponds to COPY >> FROM PROGRAM? This would obviously have the same permissions restrictions >> as COPY FROM PROGRAM. > I'd rather come up with a way to import thi

Re: pg_restore causing deadlocks on partitioned tables

On 2020-Sep-14, Tom Lane wrote: > Domagoj Smoljanovic writes: > > I have pg_restore running in parallel (3 or more) and processing large > > amount of data that is in partitioned tables. However it seems that > > sometime deadlock appears when one process is trying to process primary key > > o

Re: On login trigger: take three

po 14. 9. 2020 v 16:12 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 14.09.2020 12:44, Pavel Stehule wrote: > > Hi > > > > I am checking last patch, and there are notices > > > > 1. disable_session_start_trigger should be SU_BACKEND instead SUSET > > > > 2. The docum

Re: Function to execute a program

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > Would it make sense to have a pg_execute_program() that corresponds to COPY > FROM PROGRAM? This would obviously have the same permissions restrictions > as COPY FROM PROGRAM. Eh, perhaps. > The usecase would be to for example execute a

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

On Sat, Sep 12, 2020 at 10:35:34AM +0900, Michael Paquier wrote: > On Fri, Sep 11, 2020 at 07:13:01PM -0500, Justin Pryzby wrote: > > On Tue, Sep 08, 2020 at 01:31:05PM +0900, Michael Paquier wrote: > >> - CIC on partitioned relations. (Should we also care about DROP INDEX > >> CONCURRENTLY as wel

Re: pg_restore causing deadlocks on partitioned tables

Domagoj Smoljanovic writes: > I have pg_restore running in parallel (3 or more) and processing large amount > of data that is in partitioned tables. However it seems that sometime > deadlock appears when one process is trying to process primary key on parent > table while data still hasn’t been

Re: On login trigger: take three

On 14.09.2020 12:44, Pavel Stehule wrote: Hi I am checking last patch, and there are notices 1. disable_session_start_trigger should be SU_BACKEND instead SUSET 2. The documentation should be enhanced - there is not any note about behave when there are unhandled exceptions, about motivation

Re: Fix overflow at return wchar2char (src/backend/utils/adt/pg_locale.c)

> On 14 Sep 2020, at 14:41, Ranier Vilela wrote: > 1. wchar2char has a mistake when checking the return of WideCharToMultiByte > call. > result variable is unsigned, therefore, cannot be less than zero, returning > -1 is not an option. If the objection is that an unsigned var is tested with <=

Re: problem with RETURNING and update row movement

On Mon, Sep 14, 2020 at 5:56 PM Etsuro Fujita wrote: > On Mon, Sep 14, 2020 at 3:53 PM Amit Langote wrote: > > On Sat, Sep 12, 2020 at 5:42 AM Alvaro Herrera > > wrote: > > > I noticed that this bugfix has stalled, probably because the other > > > bugfix has also stalled. > > > > > > It seems t

pg_restore causing deadlocks on partitioned tables

Hi all. I tried searching for the response to this but couldn’t find any. Tried also posting to general but got no love there. I have pg_restore running in parallel (3 or more) and processing large amount of data that is in partitioned tables. However it seems that sometime deadlock appears wh

Fix overflow at return wchar2char (src/backend/utils/adt/pg_locale.c)

Hi, 1. wchar2char has a mistake when checking the return of WideCharToMultiByte call. result variable is unsigned, therefore, cannot be less than zero, returning -1 is not an option. 2. strftime or strftime_win32, return cannot be less than zero. 3. If strftime or strftime_win32, fails, why not

Re: TDE (Transparent Data Encryption) supported ?

Greetings, We'd prefer it if you didn't top-post (just write some stuff at the top) when you respond and post to these mailing lists. * laurent.fe...@free.fr (laurent.fe...@free.fr) wrote: > I come back to your comments about vestor attacks. I know that TDE protects > against disk thefts, not re

Re: Fix for parallel BTree initialization bug

On Fri, Sep 11, 2020 at 4:41 PM Amit Kapila wrote: > > On Fri, Sep 11, 2020 at 8:07 AM Justin Pryzby wrote: > > > I have tested this on HEAD. It would be great if you can verify in > back branches as well. I'll also do it before commit. > I am planning to push this tomorrow after doing testing o

Re: Use incremental sort paths for window functions

> On 8 Jul 2020, at 06:57, David Rowley wrote: > > Over on [1] someone was asking about chained window paths making use > of already partially sorted input. (The thread is on -general, so I > guessed they're not using PG13.) The [1] reference wasn't qualified, do you remember which thread it wa

Re: TDE (Transparent Data Encryption) supported ?

hi … well, the reason why there is no key management is that we wanted to keep the interface open so that people can integrate with everything they want. i have seen keymanagement tools come and go. postgresql is certainly gonna live longer than many of those things. thus we intentionally decid

Re: Avoid incorrect allocation in buildIndexArray

Em dom., 13 de set. de 2020 às 22:46, Michael Paquier escreveu: > On Sat, Sep 12, 2020 at 12:40:49PM +0200, Julien Rouhaud wrote: > > agreed. > > Ok, done as ac673a1 then. > Thanks Michael. regards, Ranier Vilela

Re: [PATCH] Automatic HASH and LIST partition creation

On 08.09.2020 17:03, Pavel Borisov wrote: The patch lacks documentation, because I expect some details may change during discussion. Other than that, the feature is ready for review. Hi, hackers! From what I've read I see there is much interest in automatic partitions creation. (O

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

On Mon, Sep 14, 2020 at 4:50 PM Amit Kapila wrote: > > On Mon, Sep 14, 2020 at 1:23 PM Dilip Kumar wrote: > > > > On Mon, Sep 14, 2020 at 8:48 AM Amit Kapila wrote: > > > > > > > > > Yeah, this is right, and here is some initial analysis. It seems to be > > > failing in below code: > > > rel_syn

Re: Division in dynahash.c due to HASH_FFACTOR

On Thu, 10 Sep 2020 at 14:55, Thomas Munro wrote: > > I wrote a draft commit message for Jakub's proposed change (attached), > and did a little bit of testing, but I haven't seen a case where it > wins yet; I need to work on something else now but thought I'd share > this much anyway. One observa

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

On Mon, Sep 14, 2020 at 1:23 PM Dilip Kumar wrote: > > On Mon, Sep 14, 2020 at 8:48 AM Amit Kapila wrote: > > > > > > Yeah, this is right, and here is some initial analysis. It seems to be > > failing in below code: > > rel_sync_cache_relation_cb(){ ...list_free(entry->streamed_txns);..} > > > >

Re: recovering from "found xmin ... from before relfrozenxid ..."

On Sun, Sep 13, 2020 at 3:30 AM Tom Lane wrote: > > Robert Haas writes: > > I have committed this version. > > This failure says that the test case is not entirely stable: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2020-09-12%2005%3A13%3A12 > > diff -U3 > /home/nm/fa

Re: pg_dump --where option

On Fri, Jul 31, 2020 at 1:38 AM Daniel Gustafsson wrote: > > > $ pg_dump -d cary --where="test1:a3 = ( select max(aa1) from test2 )" > > testdump2 > > $ pg_dump: error: processing of table "public.test1" failed > > > > both test1 and test2 exist in the database and the same subquery works > und

Re: On login trigger: take three

Hi I am checking last patch, and there are notices 1. disable_session_start_trigger should be SU_BACKEND instead SUSET 2. The documentation should be enhanced - there is not any note about behave when there are unhandled exceptions, about motivation for this event trigger 3. regress tests shoul

unusual use of "path" in pg_verifybackup?

pg_verifybackup and the associated backup manifest functionality uses "path", "path name", etc. throughout where other components might just say "file", "file name". This isn't wrong, if you follow POSIX terminology, but it's a bit unusual, I think. Specifically, option naming like -i, --

Re: problem with RETURNING and update row movement

On Mon, Sep 14, 2020 at 3:53 PM Amit Langote wrote: > On Sat, Sep 12, 2020 at 5:42 AM Alvaro Herrera > wrote: > > I noticed that this bugfix has stalled, probably because the other > > bugfix has also stalled. > > > > It seems that cleanly returning system columns from table AM is not > > going

  1   2   >