Re: WAL usage calculation patch

At Thu, 23 Apr 2020 07:33:13 +0200, Julien Rouhaud wrote in > > > > > I think we should keep both version consistent, whether lower or upper > > > > > case. The uppercase version is probably more correct, but it's a > > > > > little bit weird to have it being the only upper case label in all >

Re: [PATCH] Fix buffer not null terminated on (ecpg lib)

At Thu, 23 Apr 2020 01:21:21 -0300, Ranier Vilela wrote in > Em qua., 22 de abr. de 2020 às 23:27, Kyotaro Horiguchi < > horikyota@gmail.com> escreveu: > > > > - strncpy(sqlca->sqlerrm.sqlerrmc, message, > > sizeof(sqlca->sqlerrm.sqlerrmc)); > > -

Re: WAL usage calculation patch

On Thu, Apr 23, 2020 at 7:20 AM Amit Kapila wrote: > > On Wed, Apr 22, 2020 at 9:15 AM Amit Kapila wrote: > > > > On Mon, Apr 20, 2020 at 1:17 PM Kyotaro Horiguchi > > wrote: > > > > > > At Sun, 19 Apr 2020 16:22:26 +0200, Julien Rouhaud > > > wrote in > > > > Hi Justin, > > > > > > > >

Re: WAL usage calculation patch

On Wed, Apr 22, 2020 at 2:27 PM Amit Kapila wrote: > > On Wed, Apr 22, 2020 at 9:25 AM Justin Pryzby wrote: > > > > On Wed, Apr 22, 2020 at 09:15:08AM +0530, Amit Kapila wrote: > > > > > > And add the acronym to the docs: > > > > > > > > > > > > $ git grep 'full page' '*/explain.sgml' > > > > >

Re: WAL usage calculation patch

On Wed, Apr 22, 2020 at 9:15 AM Amit Kapila wrote: > > On Mon, Apr 20, 2020 at 1:17 PM Kyotaro Horiguchi > wrote: > > > > At Sun, 19 Apr 2020 16:22:26 +0200, Julien Rouhaud > > wrote in > > > Hi Justin, > > > > > > Thanks for the review! > > > > > > On Sat, Apr 18, 2020 at 10:41 PM Justin

Re: More efficient RI checks - take 2

čt 23. 4. 2020 v 7:06 odesílatel Antonin Houska napsal: > Tom Lane wrote: > > > Robert Haas writes: > > > Right -- the idea I was talking about was to create a Plan tree > > > without using the main planner. So it wouldn't bother costing an index > > > scan on each index, and a sequential

Re: More efficient RI checks - take 2

Tom Lane wrote: > Robert Haas writes: > > Right -- the idea I was talking about was to create a Plan tree > > without using the main planner. So it wouldn't bother costing an index > > scan on each index, and a sequential scan, on the target table - it > > would just make an index scan plan, or

Re: [PATCH] Skip llvm bytecode generation if LLVM is missing

On Thu, 19 Mar 2020 at 18:47, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2020-03-15 02:28, Craig Ringer wrote: > > On Fri, 13 Mar 2020 at 15:04, Andres Freund > > wrote: > > > > On 2020-03-13 14:08:12 +0800, Craig Ringer wrote: > > > The

[PATCH] Fix install-tests target for vpath builds

Patch 0001 fixes this issue with vpath postgres builds: $ make -C src/test/regress install-tests /usr/bin/install: cannot create regular file 'PGPREFIX/lib/postgresql/regress/PGPREFIX/src/test/regress/expected/errors.out': No such file or directory make: *** [GNUmakefile:90: install-tests] Error

Re: Parallel Append can break run-time partition pruning

On Thu, 23 Apr 2020 at 14:37, Robert Haas wrote: > > On Wed, Apr 22, 2020 at 7:36 PM David Rowley wrote: > > If there was some reason that a Parallel Append could come out more > > expensive, then maybe we could just create a non-parallel Append using > > the same subpath list and

Re: [PATCH] Fix buffer not null terminated on (ecpg lib)

Em qua., 22 de abr. de 2020 às 23:27, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > Hello. > > At Wed, 22 Apr 2020 19:48:07 -0300, Ranier Vilela > wrote in > > Hi, > > strncpy, it is not a safe function and has the risk of corrupting memory. > > On ecpg lib, two sources, make use of

Re: xid wraparound danger due to INDEX_CLEANUP false

On Wed, Apr 22, 2020 at 8:33 PM Andres Freund wrote: > On 2020-04-22 20:08:42 -0700, Peter Geoghegan wrote: > > I can get Valgrind to complain about it when the regression tests are > > run with the attached patch applied. > > Nice! Have you checked how much of an incremental slowdown this

Re: HEAPDEBUGALL is broken

On 2020-04-19 09:37:08 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > The HEAPDEBUGALL define has been broken since PG12 due to tableam > > changes. Should we just remove this? It doesn't look very useful. > > It's been around since Postgres95. > > If we opt for removing: PG12 added an

Re: xid wraparound danger due to INDEX_CLEANUP false

Hi, On 2020-04-22 20:08:42 -0700, Peter Geoghegan wrote: > I can get Valgrind to complain about it when the regression tests are > run with the attached patch applied. Nice! Have you checked how much of an incremental slowdown this causes? > This patch is very rough -- it was just the first

Re: PG compilation error with Visual Studio 2015/2017/2019

On Wed, Apr 22, 2020 at 9:27 PM Juan José Santamaría Flecha wrote: > > > On Wed, Apr 22, 2020 at 1:43 PM Amit Kapila wrote: >> >> >> >> 4. In the patch, first, we try to get with LCType as LOCALE_SNAME and >> >> then with LOCALE_SENGLISHLANGUAGENAME and LOCALE_SENGLISHCOUNTRYNAME. >> >> I think

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

On Wed, Apr 22, 2020 at 9:31 PM Erik Rijkers wrote: > > On 2020-04-22 16:49, Dilip Kumar wrote: > > On Tue, Apr 21, 2020 at 5:30 PM Dilip Kumar > > wrote: > >> > >> > > >> > (by the way: this build's regression tests 'ddl', 'toast', and > >> > 'spill' fail) > >> > >> Yeah, this is a. known

Re: PG compilation error with Visual Studio 2015/2017/2019

On Wed, Apr 22, 2020 at 7:37 PM Ranier Vilela wrote: > > Em qua., 22 de abr. de 2020 às 08:43, Amit Kapila > escreveu: >> >> On Tue, Apr 21, 2020 at 5:32 PM Juan José Santamaría Flecha >> wrote: >> > >> > On Tue, Apr 21, 2020 at 12:41 PM Amit Kapila >> > wrote: >> >> >> >> 6. I have

Re: xid wraparound danger due to INDEX_CLEANUP false

On Wed, Apr 22, 2020 at 6:05 PM Peter Geoghegan wrote: > (It would be nice if we could teach Valgrind to "poison" buffers when > we don't have a pin held...that would probably have caught this issue > almost immediately.) I can get Valgrind to complain about it when the regression tests are run

Re: create partition table caused server crashed with self-referencing foreign key

On Wed, 22 Apr 2020 at 23:50, Michael Paquier wrote: > > On Wed, Apr 22, 2020 at 10:21:21PM +1200, David Rowley wrote: > > I pushed a patch to remove the Assert. I didn't really feel a need to > > make any adjustments to the regression tests for this. The Assert was > > clearly out of place, it's

Re: new heapcheck contrib module

> On Apr 20, 2020, at 12:42 PM, Andres Freund wrote: > > Hi, > > On 2020-04-20 10:59:28 -0700, Mark Dilger wrote: >> I have been talking with Robert about table corruption that occurs >> from time to time. The page checksum feature seems sufficient to >> detect most random corruption

Re: Parallel Append can break run-time partition pruning

On Wed, Apr 22, 2020 at 7:36 PM David Rowley wrote: > If there was some reason that a Parallel Append could come out more > expensive, then maybe we could just create a non-parallel Append using > the same subpath list and add_partial_path() it. I just don't quite > see how that would ever win

Re: Remove non-fast promotion Re: Should we remove a fallback promotion? take 2

On 2020/04/23 3:56, Jehan-Guillaume de Rorthais wrote: On Wed, 22 Apr 2020 11:51:15 +0900 Fujii Masao wrote: On 2020/04/22 10:53, Kyotaro Horiguchi wrote: [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] [...] Thanks all for checking whether the change

Re: backup manifests

On 2020/04/23 1:28, Robert Haas wrote: On Wed, Apr 22, 2020 at 12:21 PM Fujii Masao wrote: I found three minor issues in pg_verifybackup. + {"print-parse-wal", no_argument, NULL, 'p'}, This is unused option, so this line should be removed. + printf(_(" -m,

Re: [PATCH] Fix buffer not null terminated on (ecpg lib)

Hello. At Wed, 22 Apr 2020 19:48:07 -0300, Ranier Vilela wrote in > Hi, > strncpy, it is not a safe function and has the risk of corrupting memory. > On ecpg lib, two sources, make use of strncpy risk, this patch tries to fix. > > 1. Make room for the last null-characte; > 2. Copies Maximum

Re: More efficient RI checks - take 2

On Wed, Apr 22, 2020 at 6:40 PM Tom Lane wrote: > But it's not entirely clear to me that we know the best plan for a > statement-level RI action with sufficient certainty to go that way. > Is it really the case that the plan would not vary based on how > many tuples there are to check, for

Re: Parallel Append can break run-time partition pruning

On Thu, 23 Apr 2020 at 11:39, Tom Lane wrote: > > David Rowley writes: > > On Thu, 23 Apr 2020 at 11:11, Tom Lane wrote: > >> Well, anytime the parallel startup cost is significant, for starters. > >> But maybe we account for that at some other point, like when building > >> the Gather? > > >

Re: [PATCH] FIx explicit null dereference pointer (nbtree.c)

Em qua., 22 de abr. de 2020 às 21:24, Peter Geoghegan escreveu: > On Wed, Apr 22, 2020 at 3:55 PM Ranier Vilela wrote: > > per Coverity. > > Some Postgres hackers have access to a dedicated coverity > installation, and this issue has probably already been dismissed. > I will take a note. > > >

Re: xid wraparound danger due to INDEX_CLEANUP false

On Thu, Apr 16, 2020 at 12:30 AM Masahiko Sawada wrote: > For btree indexes, IIRC skipping index cleanup could not be a cause of > corruption, but be a cause of index bloat since it leaves recyclable > pages which are not marked as recyclable. I spotted a bug in "Skip full index scan during

Re: Header / Trailer Comment Typos for M4 macros

Jesse Zhang writes: > I didn't make my question clear though: I'm curious what motivated the > original addition of -Wno-unused-command-line-argument in commit > 73b416b2e412, and how that problem did't quite manifest itself with Clang++. We didn't then have the convention of mentioning relevant

Re: [PATCH] FIx explicit null dereference pointer (nbtree.c)

On Wed, Apr 22, 2020 at 3:55 PM Ranier Vilela wrote: > per Coverity. Some Postgres hackers have access to a dedicated coverity installation, and this issue has probably already been dismissed. > 1. assign_zero: Assigning: opaque = NULL. > 2. Condition buf < 0, taking true branch. > 3. Condition

Re: Header / Trailer Comment Typos for M4 macros

On Wed, Apr 22, 2020 at 12:29 PM Tom Lane wrote: > > Jesse Zhang writes: > > either way: either changing the macro names or changing the comment. PFA > > a patch that keeps the macro names. > > Pushed, thanks. > Thanks! > > Also in hindsight: it seems that, as suggested in the trailer typo, > >

Re: Parallel Append can break run-time partition pruning

David Rowley writes: > On Thu, 23 Apr 2020 at 11:11, Tom Lane wrote: >> Well, anytime the parallel startup cost is significant, for starters. >> But maybe we account for that at some other point, like when building >> the Gather? > Yeah. There's no mention of parallel_setup_cost or

Re: Parallel Append can break run-time partition pruning

On Thu, 23 Apr 2020 at 11:11, Tom Lane wrote: > > David Rowley writes: > > Given the same set of paths, when would a non-parallel append be > > cheaper than a parallel one? > > Well, anytime the parallel startup cost is significant, for starters. > But maybe we account for that at some other

Re: Parallel Append can break run-time partition pruning

David Rowley writes: > Given the same set of paths, when would a non-parallel append be > cheaper than a parallel one? Well, anytime the parallel startup cost is significant, for starters. But maybe we account for that at some other point, like when building the Gather?

Re: sqlsmith crash incremental sort

On Mon, Apr 20, 2020 at 01:47:29AM +0200, Tomas Vondra wrote: On Sat, Apr 18, 2020 at 02:23:25PM -0400, James Coleman wrote: On Thu, Apr 16, 2020 at 9:26 PM Tom Lane wrote: Tomas Vondra writes: I think we have essentially three options: 1) assuming there's just a single group 2) assuming

Re: Parallel Append can break run-time partition pruning

On Thu, 23 Apr 2020 at 02:37, Amit Langote wrote: > One thing I remain concerned about is that it appears like we are no > longer leaving the choice between parallel and non-parallel Append to > the cost machinery which is currently the case. AFAICS with patched, > as long as parallel Append is

[PATCH] FIx explicit null dereference pointer (nbtree.c)

Hi, per Coverity. 1. assign_zero: Assigning: opaque = NULL. 2. Condition buf < 0, taking true branch. 3. Condition !(((PageHeader)page)->pd_upper == 0), taking false branch. 4. Condition blkno != orig_blkno, taking true branch. 5. Condition _bt_page_recyclable(page), taking false branch. CID

[PATCH] Fix buffer not null terminated on (ecpg lib)

Hi, strncpy, it is not a safe function and has the risk of corrupting memory. On ecpg lib, two sources, make use of strncpy risk, this patch tries to fix. 1. Make room for the last null-characte; 2. Copies Maximum number of characters - 1. per Coverity. regards, Ranier Vilela

Re: More efficient RI checks - take 2

Robert Haas writes: > Right -- the idea I was talking about was to create a Plan tree > without using the main planner. So it wouldn't bother costing an index > scan on each index, and a sequential scan, on the target table - it > would just make an index scan plan, or maybe an index path that it

Regression instability + performance issue in TRIGGERS view

I looked into the cause of several recent buildfarm failures: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=handfish=2020-04-20%2020%3A32%3A23 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake=2020-04-18%2018%3A20%3A12

Re: More efficient RI checks - take 2

On Wed, Apr 22, 2020 at 2:36 PM Andres Freund wrote: > > If it's any consolation, I had the same idea very recently while > > chatting with Amit Langote. Maybe it's a bad idea, but you're not the > > only one who had it. :-) > > That seems extremely hard, given our current infrastructure. I think

Re: design for parallel backup

On Wed, Apr 22, 2020 at 3:03 PM Andres Freund wrote: > The 7zip format, perhaps. Does have format level support to address what > we were discussing earlier: "Support for solid compression, where > multiple files of like type are compressed within a single stream, in > order to exploit the

Re: Header / Trailer Comment Typos for M4 macros

Jesse Zhang writes: > While poking at the build system I stumbled upon some trivial trailer > comment inconsistencies in config/c-compiler.m4. They can be fixed > either way: either changing the macro names or changing the comment. PFA > a patch that keeps the macro names. Pushed, thanks. > In

Re: More efficient RI checks - take 2

On Wed, Apr 22, 2020 at 2:36 PM Andres Freund wrote: > Hi, > > On 2020-04-22 13:46:22 -0400, Robert Haas wrote: > > On Wed, Apr 22, 2020 at 1:18 PM Alvaro Herrera > wrote: > > > Well, I was actually thinking in building ready-made execution trees, > > > bypassing the planner altogether. But

Re: 2pc leaks fds

On 2020-Apr-22, Andres Freund wrote: > On 2020-04-22 13:57:54 -0400, Alvaro Herrera wrote: > > Concretely, I propose to have a new struct like > > > > typedef struct xlogReaderFuncs > > { > > XLogPageReadCB read_page; > > XLogSegmentOpenCB open_segment; > > XLogSegmentCloseCB

Re: design for parallel backup

Hi, On 2020-04-22 14:40:17 -0400, Robert Haas wrote: > > Oh? I find it *extremely* exciting here. This is pretty close to the > > worst case compressability-wise, and zstd takes only ~22% of the time as > > gzip does, while still delivering better compression. A nearly 5x > > improvement in

Re: Remove non-fast promotion Re: Should we remove a fallback promotion? take 2

On Wed, 22 Apr 2020 11:51:15 +0900 Fujii Masao wrote: > On 2020/04/22 10:53, Kyotaro Horiguchi wrote: > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > > Thanks all for checking whether the change affects each HA solution!

Re: More efficient RI checks - take 2

Hi, On 2020-04-08 13:55:55 -0400, Corey Huinker wrote: > In doing my initial attempt, the feedback I was getting was that the people > who truly understood the RI checks fell into the following groups: > 1. people who wanted to remove the SPI calls from the triggers > 2. people who wanted to

Re: design for parallel backup

On Wed, Apr 22, 2020 at 2:06 PM Andres Freund wrote: > I also can see a case for using N backends and one connection, but I > think that'll be too complicated / too much bound by lcoking around the > socket etc. Agreed. > Oh? I find it *extremely* exciting here. This is pretty close to the >

Re: More efficient RI checks - take 2

Hi, On 2020-04-22 13:46:22 -0400, Robert Haas wrote: > On Wed, Apr 22, 2020 at 1:18 PM Alvaro Herrera > wrote: > > Well, I was actually thinking in building ready-made execution trees, > > bypassing the planner altogether. But apparently no one thinks that > > this is a good idea, and we don't

Re: 2pc leaks fds

On 2020-04-22 13:57:54 -0400, Alvaro Herrera wrote: > Concretely, I propose to have a new struct like > > typedef struct xlogReaderFuncs > { > XLogPageReadCB read_page; > XLogSegmentOpenCB open_segment; > XLogSegmentCloseCB open_segment; > } xlogReaderFuncs; > > #define

Re: More efficient RI checks - take 2

Hi, On 2020-04-22 13:18:06 -0400, Alvaro Herrera wrote: > > But honestly, my gut feeling is that for a lot of cases it'd be best > > just bypass parser, planner *and* executor. And just do manual > > systable_beginscan() style checks. For most cases we exactly know what > > plan shape we expect,

Re: design for parallel backup

Hi, On 2020-04-22 12:12:32 -0400, Robert Haas wrote: > On Wed, Apr 22, 2020 at 11:24 AM Andres Freund wrote: > > *My* gut feeling is that you're going to have a harder time using CPU > > time efficiently when doing parallel compression via multiple processes > > and independent connections.

Re: Do we need to handle orphaned prepared transactions in the server?

On Wed, Apr 22, 2020 at 01:05:17PM -0400, Robert Haas wrote: > On Tue, Apr 21, 2020 at 6:10 PM Bruce Momjian wrote: > > I thought if something was wrong, they might look at the server logs > > after a restart, or they might have a higher probability of having > > orphaned prepared transactions

Re: 2pc leaks fds

Concretely, I propose to have a new struct like typedef struct xlogReaderFuncs { XLogPageReadCB read_page; XLogSegmentOpenCB open_segment; XLogSegmentCloseCB open_segment; } xlogReaderFuncs; #define XLOGREADER_FUNCS(...) &(xlogReaderFuncs){__VA_ARGS__} and then invoke it

Re: More efficient RI checks - take 2

On Wed, Apr 22, 2020 at 1:18 PM Alvaro Herrera wrote: > Well, I was actually thinking in building ready-made execution trees, > bypassing the planner altogether. But apparently no one thinks that > this is a good idea, and we don't have any code that does that already, > so maybe it's not a

Re: More efficient RI checks - take 2

On 2020-Apr-22, Andres Freund wrote: > I assume that with constructing plans "manually" you don't mean to > create a plan tree, but to invoke parser/planner directly? I think > that'd likely be better than going through SPI, and there's precedent > too. Well, I was actually thinking in building

Re: Do we need to handle orphaned prepared transactions in the server?

On Tue, Apr 21, 2020 at 6:10 PM Bruce Momjian wrote: > I thought if something was wrong, they might look at the server logs > after a restart, or they might have a higher probability of having > orphaned prepared transactions after a restart. Maybe slightly, but having a monitoring tool like

Re: design for parallel backup

On Wed, Apr 22, 2020 at 12:20 PM Peter Eisentraut wrote: > On 2020-04-20 22:36, Robert Haas wrote: > > My suspicion is that it has mostly to do with adequately utilizing the > > hardware resources on the server side. If you are network-constrained, > > adding more connections won't help, unless

Re: backup manifests

On Wed, Apr 22, 2020 at 12:21 PM Fujii Masao wrote: > I found three minor issues in pg_verifybackup. > > + {"print-parse-wal", no_argument, NULL, 'p'}, > > This is unused option, so this line should be removed. > > + printf(_(" -m, --manifest=PATH use specified path

Re: WIP/PoC for parallel backup

On Wed, Apr 22, 2020 at 10:18 AM Asif Rehman wrote: > I don't foresee memory to be a challenge here. Assuming a database containing > 10240 > relation files (that max reach to 10 TB of size), the list will occupy > approximately 102MB > of space in memory. This obviously can be reduced, but it

Re: Concurrency bug in amcheck

On Tue, Apr 21, 2020 at 2:54 AM Alexander Korotkov wrote: > Proposed fix is attached. Spotted by Konstantin Knizhnik, > reproduction case and fix from me. I wonder if we should fix btree_xlog_unlink_page() instead of amcheck. We already know that its failure to be totally consistent with the

Re: backup manifests

On 2020/04/15 11:18, Fujii Masao wrote: On 2020/04/14 0:15, Robert Haas wrote: On Sun, Apr 12, 2020 at 10:09 PM Fujii Masao wrote: I found other minor issues. I think these are all correct fixes. Thanks for the post-commit review, and sorry for this mistakes. Thanks for the review,

Re: design for parallel backup

On 2020-04-20 22:36, Robert Haas wrote: My suspicion is that it has mostly to do with adequately utilizing the hardware resources on the server side. If you are network-constrained, adding more connections won't help, unless there's something shaping the traffic which can be gamed by having

Re: design for parallel backup

On Wed, Apr 22, 2020 at 11:24 AM Andres Freund wrote: > *My* gut feeling is that you're going to have a harder time using CPU > time efficiently when doing parallel compression via multiple processes > and independent connections. You're e.g. going to have a lot more > context switches, I think.

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

On 2020-04-22 16:49, Dilip Kumar wrote: On Tue, Apr 21, 2020 at 5:30 PM Dilip Kumar wrote: > > (by the way: this build's regression tests 'ddl', 'toast', and > 'spill' fail) Yeah, this is a. known issue, actually, while streaming the transaction the output message is changed. I have a

Re: PG compilation error with Visual Studio 2015/2017/2019

On Wed, Apr 22, 2020 at 1:43 PM Amit Kapila wrote: > On Tue, Apr 21, 2020 at 5:32 PM Juan José Santamaría Flecha > wrote: > > > > I cannot reproduce any of these errors on my end. > > > The first problem related to the English_United Kingdom was due to the > usage of wcslen instead of

Re: Concurrency bug in amcheck

Hi, Peter, Just thought you might want to see this one... On 2020-04-21 15:31:13 +0300, Alexander Korotkov wrote: > On Tue, Apr 21, 2020 at 12:54 PM Alexander Korotkov > wrote: > > I found concurrency bug in amcheck running on replica. When > > btree_xlog_unlink_page() replays changes to

Re: More efficient RI checks - take 2

Hi, On 2020-04-21 16:14:53 -0400, Tom Lane wrote: > AFAIK, we do not have any code besides the planner that is capable of > building a plan tree at all, and I'd be pretty hesitant to try to create > such; those things are complicated. I suspect what was meant was not to create the plan tree

Re: More efficient RI checks - take 2

Hi, On 2020-04-21 11:34:54 -0400, Alvaro Herrera wrote: > On 2020-Apr-20, Corey Huinker wrote: > > > > I can imagine removal of the SPI from the current implementation (and > > > constructing the plans "manually"), but note that the queries I use in my > > > patch are no longer that trivial. So

Re: design for parallel backup

Hi, On 2020-04-22 09:52:53 -0400, Robert Haas wrote: > On Tue, Apr 21, 2020 at 6:57 PM Andres Freund wrote: > > I agree that trying to make backups very fast is a good goal (or well, I > > think not very slow would be a good descriptor for the current > > situation). I am just trying to make

Re: [Proposal] Global temporary tables

st 22. 4. 2020 v 16:38 odesílatel Prabhat Sahu < prabhat.s...@enterprisedb.com> napsal: > > > On Wed, Apr 22, 2020 at 2:49 PM 曾文旌 wrote: > >> >> Although the implementation of GTT is different, I think so TRUNCATE on >> Postgres (when it is really finalized) can remove session metadata of GTT >>

Re: [Proposal] Global temporary tables

On Wed, Apr 22, 2020 at 2:49 PM 曾文旌 wrote: > > Although the implementation of GTT is different, I think so TRUNCATE on > Postgres (when it is really finalized) can remove session metadata of GTT > too (and reduce usage's counter). It is not critical feature, but I think > so it should not be

Re: Parallel Append can break run-time partition pruning

On Wed, Apr 22, 2020 at 12:22 PM David Rowley wrote: > On Tue, 21 Apr 2020 at 15:03, David Rowley wrote: > > I wonder if the fix should be more something along the lines of trying > > to merge things do we only generate a single partial path. That way > > we wouldn't be at the mercy of the

Re: ALTER TABLE ... SET STORAGE does not propagate to indexes

On 2020-04-22 01:56, Alvaro Herrera wrote: I'm surprised that this hasn't applied yet, because: On 2020-Apr-09, Peter Eisentraut wrote: One thing to remember is that the current situation is broken. While you can set index columns to have different storage than the corresponding table

Re: Fix for pg_statio_all_tables

On Tue, Apr 21, 2020 at 4:59 PM Tom Lane wrote: > Alexander Korotkov writes: > > On Tue, Apr 21, 2020 at 7:58 AM Tom Lane wrote: > >> Yeah, but that was for a security hole. I am doubtful that the > >> severity of this problem is bad enough to justify jumping through > >> similar hoops. Even

Re: HEAPDEBUGALL is broken

Alexander Lakhin writes: > 21.04.2020 21:01, Peter Eisentraut wrote: >> Do you have a proposed patch? > As this is broken at least since the invention of the generational > allocator (2017-11-23, a4ccc1ce), I believe than no one uses this (and > slab is broken too). Nonetheless, HAVE_ALLOCINFO

Re: WIP/PoC for parallel backup

Hi Dipesh, The rebased and updated patch is attached. Its rebased to (9f2c4ede). > +typedef struct > +{ > ... > +} BackupFile; > + > +typedef struct > +{ > ... > +} BackupState; > > These structures need comments. > Done. > > +list_wal_files_opt_list: > + SCONST SCONST >

Header / Trailer Comment Typos for M4 macros

Hi hackers, While poking at the build system I stumbled upon some trivial trailer comment inconsistencies in config/c-compiler.m4. They can be fixed either way: either changing the macro names or changing the comment. PFA a patch that keeps the macro names. In hindsight though, it seems that

Re: HEAPDEBUGALL is broken

Peter Eisentraut writes: > On 2020-04-21 20:27, Tom Lane wrote: >> I don't see a commit? > pushed now Looking at this, I'm tempted to nuke ACLDEBUG as well, which is the only remaining undocumented symbol in pg_config_manual.h. The code it controls looks equally forlorn and not-useful-as-is.

Re: PG compilation error with Visual Studio 2015/2017/2019

Em qua., 22 de abr. de 2020 às 08:43, Amit Kapila escreveu: > On Tue, Apr 21, 2020 at 5:32 PM Juan José Santamaría Flecha > wrote: > > > > On Tue, Apr 21, 2020 at 12:41 PM Amit Kapila > wrote: > >> > 6. I have additionally done some cosmetic changes in the attached patch. > I made some style

Re: design for parallel backup

On Tue, Apr 21, 2020 at 6:57 PM Andres Freund wrote: > I agree that trying to make backups very fast is a good goal (or well, I > think not very slow would be a good descriptor for the current > situation). I am just trying to make sure we tackle the right problems > for that. My gut feeling is

Re: WAL usage calculation patch

On Wed, Apr 22, 2020 at 9:25 AM Justin Pryzby wrote: > > On Wed, Apr 22, 2020 at 09:15:08AM +0530, Amit Kapila wrote: > > > > > And add the acronym to the docs: > > > > > > > > > > $ git grep 'full page' '*/explain.sgml' > > > > > doc/src/sgml/ref/explain.sgml: number of records, number of

Re: create partition table caused server crashed with self-referencing foreign key

On Wed, Apr 22, 2020 at 10:21:21PM +1200, David Rowley wrote: > I pushed a patch to remove the Assert. I didn't really feel a need to > make any adjustments to the regression tests for this. The Assert was > clearly out of place, it's hard to imagine that this could ever get > broken again.

Re: PG compilation error with Visual Studio 2015/2017/2019

On Tue, Apr 21, 2020 at 5:32 PM Juan José Santamaría Flecha wrote: > > On Tue, Apr 21, 2020 at 12:41 PM Amit Kapila wrote: >> >> On Tue, Apr 21, 2020 at 12:51 PM Amit Kapila wrote: >> > >> > I have tried a simple test with the latest patch and it failed for me. >> > >> > Set

Re: create partition table caused server crashed with self-referencing foreign key

Thanks all for quick fix and push. Thanks & Regards, Rajkumar Raghuwanshi On Wed, Apr 22, 2020 at 4:14 PM Ahsan Hadi wrote: > > > On Wed, Apr 22, 2020 at 2:45 PM amul sul wrote: > >> >> >> On Wed, Apr 22, 2020 at 2:59 PM amul sul wrote: >> >>> >>> >>> On Wed, Apr 22, 2020 at 2:27 PM David

Re: HEAPDEBUGALL is broken

On 2020-04-21 20:27, Tom Lane wrote: Peter Eisentraut writes: On 2020-04-19 15:37, Tom Lane wrote: +1 for removing both. There are a lot of such debug "features" in the code, and few of them are worth anything IME. removed I don't see a commit? pushed now -- Peter Eisentraut

Re: WIP/PoC for parallel backup

Hi Asif, I am reviewing your recent patch and found the patch is not applicable on latest master. Could you please resolve the conflicts and update a new patch? Thanks, Dipesh EnterpriseDB: http://www.enterprisedb.com

Extension to monitor errors in log

Hi! I wrote extension for postgresql that is collecting statistics about errors in logfile. This extension counts the number of messages of each type and code. It's designed to enable monitoring tools. I'm going to use it as a data source for plot of number of errors, warnings and fatals.

Re: create partition table caused server crashed with self-referencing foreign key

On Wed, Apr 22, 2020 at 2:45 PM amul sul wrote: > > > On Wed, Apr 22, 2020 at 2:59 PM amul sul wrote: > >> >> >> On Wed, Apr 22, 2020 at 2:27 PM David Rowley >> wrote: >> >>> On Wed, 22 Apr 2020 at 20:11, amul sul wrote: >>> > >>> > On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi < >>>

Re: create partition table caused server crashed with self-referencing foreign key

On Wed, 22 Apr 2020 at 21:30, amul sul wrote: > > On Wed, Apr 22, 2020 at 2:27 PM David Rowley wrote: >> >> On Wed, 22 Apr 2020 at 20:11, amul sul wrote: >> > >> > On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi >> > wrote: >> >> #2 0x00acd16a in ExceptionalCondition

Re: create partition table caused server crashed with self-referencing foreign key

On Wed, Apr 22, 2020 at 2:59 PM amul sul wrote: > > > On Wed, Apr 22, 2020 at 2:27 PM David Rowley wrote: > >> On Wed, 22 Apr 2020 at 20:11, amul sul wrote: >> > >> > On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi < >> rajkumar.raghuwan...@enterprisedb.com> wrote: >> >> #2

Re: create partition table caused server crashed with self-referencing foreign key

On Wed, Apr 22, 2020 at 2:27 PM David Rowley wrote: > On Wed, 22 Apr 2020 at 20:11, amul sul wrote: > > > > On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi < > rajkumar.raghuwan...@enterprisedb.com> wrote: > >> #2 0x00acd16a in ExceptionalCondition (conditionName=0xc32310 >

Re: create partition table caused server crashed with self-referencing foreign key

On Wed, 22 Apr 2020 at 20:11, amul sul wrote: > > On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi > wrote: >> #2 0x00acd16a in ExceptionalCondition (conditionName=0xc32310 >> "numfks == attmap->maplen", errorType=0xc2ea23 "FailedAssertion", >> fileName=0xc2f0bf "tablecmds.c",

Re: create partition table caused server crashed with self-referencing foreign key

On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi < rajkumar.raghuwan...@enterprisedb.com> wrote: > Hi, > > Getting a server crash while creating partition table which have > self-referencing foreign key > > postgres=# CREATE TABLE part1 (c1 int PRIMARY KEY, c2 int REFERENCES > part1)

create partition table caused server crashed with self-referencing foreign key

Hi, Getting a server crash while creating partition table which have self-referencing foreign key postgres=# CREATE TABLE part1 (c1 int PRIMARY KEY, c2 int REFERENCES part1) PARTITION BY LIST (c1); CREATE TABLE postgres=# CREATE TABLE part1_p1 PARTITION OF part1 FOR VALUES IN (1); server closed

Re: [PATCH] distinct aggregates within a window function WIP

Hello Andreas, Tuesday, April 21, 2020, 6:17:00 PM, you wrote: > On 4/21/20 5:06 PM, Eugen Konkov wrote: >> Hi. I read the thread. >> >> Probably this fiddle will be helpful for testing: >> >> https://dbfiddle.uk/?rdbms=postgres_12=abe845142a5099d921d3729043fb8491 >> >> I recently encountered

Re: [IBM z Systems] Getting server crash when jit_above_cost =0

On 4/22/20 2:40 AM, Thomas Munro wrote: I'm not sure if you're seeing the same problem or another similar one, but I know that Andres got a patch along those lines into llvm. Maybe you could try on a more recent llvm release? Thanks a lot Thomas. it is working fine with llvm-toolset-7.0. look

[IBM z Systems] Rpm package issues.

HI, I tried to install PG v11 and v12 on IBM z/OS using YUM command , following -https://wiki.postgresql.org/wiki/YUM_Installation_on_z_Systems Found that 2 issues 1) rpm packages  are failing  due to " Package .  is not signed " PG v12 - Package