Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

On Tue, Feb 18, 2020 at 4:42 PM Fujii Masao wrote: > On 2020/02/18 16:02, Amit Langote wrote: > > I noticed that there is missing tag in the documentation changes: > > Could you tell me where I should add tag? > > > + > > + waiting for checkpoint to finish > > + > > + The W

Re: Clean up some old cruft related to Windows

On Thu, Dec 19, 2019 at 01:46:33PM +0900, Kyotaro Horiguchi wrote: > I found some similar places by grep'ing for windows version names the > whole source tree. > > - The comment for trapsig is mentioning win98/Me/NT/2000/XP. Let's refresh the comment here, as per the following: https://docs.micro

Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

On 2020/02/18 16:02, Amit Langote wrote: On Mon, Feb 17, 2020 at 10:00 PM Fujii Masao wrote: On 2020/02/06 11:07, Amit Langote wrote: On Thu, Feb 6, 2020 at 9:51 AM Kyotaro Horiguchi wrote: I thought of "establishing checkpoint" or "running a checkpoint" as other candidates. Okay, I un

Re: Parallel copy

On Tue, 18 Feb 2020 at 04:40, Thomas Munro wrote: > +1. That sort of two-queue scheme is exactly how I sketched out a > multi-consumer queue for a hypothetical Parallel Scatter node. It > probably gets a bit trickier when the payload has to be broken up into > fragments to wrap around the "data"

False failure during repeated windows build.

Hello. I found it quite annoying that it stops with complaining as "unused defines" during repeated execution of build.pl. The subroutine GenerateConfigHeader prepares %defines_copy before checking the newness of $config_header and even if it decides not to generate new one, the following code mak

Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

On Mon, Feb 17, 2020 at 10:00 PM Fujii Masao wrote: > On 2020/02/06 11:07, Amit Langote wrote: > > On Thu, Feb 6, 2020 at 9:51 AM Kyotaro Horiguchi > > wrote: > >> I thought of "establishing checkpoint" or "running a checkpoint" as > >> other candidates. > > > > Okay, I understand. I am fine wi

Re: Clean up some old cruft related to Windows

On Thu, Dec 19, 2019 at 08:09:45PM +0100, Juan José Santamaría Flecha wrote: > This is probably not an issue for the supported MSVC and their SDK, but > current MinGW defaults to Windows 2003 [1]. So I would suggest a logic like: > > #define WINNTVER(ver) ((ver) >> 16) > #define NTDDI_VERSION 0x06

Re: reindex concurrently and two toast indexes

On Tue, Feb 18, 2020 at 7:19 AM Michael Paquier wrote: > > On Tue, Feb 18, 2020 at 07:06:25AM +0100, Julien Rouhaud wrote: > > On Tue, Feb 18, 2020 at 6:30 AM Michael Paquier wrote: > >> Hmm. There could be an argument here for skipping invalid toast > >> indexes within reindex_index(), because

Re: reindex concurrently and two toast indexes

On Tue, Feb 18, 2020 at 07:06:25AM +0100, Julien Rouhaud wrote: > On Tue, Feb 18, 2020 at 6:30 AM Michael Paquier wrote: >> Hmm. There could be an argument here for skipping invalid toast >> indexes within reindex_index(), because we are sure about having at >> least one valid toast index at anyt

Re: [Patch] Make pg_checksums skip foreign tablespace directories

On Fri, Jan 31, 2020 at 11:33:34AM +0100, Bernd Helmle wrote: > And to be honest, even PostgreSQL itself allows you to reuse tablespace > locations for multiple instances as well, so the described problem > should exist not in upgraded clusters only. Fair point. Now, while the proposed patch is r

Re: logical decoding : exceeded maxAllocatedDescs for .spill files

On 2020-02-18 11:20:17 +0530, Amit Kapila wrote: > Andres, any objections on proceeding with Kuntal's patch for > back-branches (10, 9.6 and 9.5)? Yes. In my past experiments that lead to *terrible* allocator performance due to fragmentation. Like, up to 90% of the time spent in aset.c. Try a wor

Re: reindex concurrently and two toast indexes

On Tue, Feb 18, 2020 at 6:30 AM Michael Paquier wrote: > > On Sun, Feb 16, 2020 at 01:08:35PM -0600, Justin Pryzby wrote: > > Forking old, long thread: > > https://www.postgresql.org/message-id/36712441546604286%40sas1-890ba5c2334a.qloud-c.yandex.net > > On Fri, Jan 04, 2019 at 03:18:06PM +0300, S

Re: plan cache overhead on plpgsql expression

út 18. 2. 2020 v 6:03 odesílatel Amit Langote napsal: > Hi, > > On Sun, Feb 16, 2020 at 11:13 PM Pavel Stehule > wrote: > > when I do some profiling of plpgsql, usually I surprised how significant > overhead has expression execution. Any calculations are very slow. > > > > This is not typical ex

Re: logical decoding : exceeded maxAllocatedDescs for .spill files

On Fri, Feb 14, 2020 at 4:06 PM Kuntal Ghosh wrote: > > On Sun, Feb 9, 2020 at 9:18 AM Amit Kapila wrote: > > > > It seems for this we formed a cache of max_cached_tuplebufs number of > > objects and we don't need to allocate more than that number of tuples > > of size MaxHeapTupleSize because we

Re: logical decoding : exceeded maxAllocatedDescs for .spill files

On Fri, Feb 7, 2020 at 5:32 PM Kuntal Ghosh wrote: > > On Tue, Feb 4, 2020 at 2:40 PM Amit Kapila wrote: > > > > I don't think we can just back-patch that part of code as it is linked > > to the way we are maintaining a cache (~8MB) for frequently allocated > > objects. See the comments around t

Re: Flexible pglz_stategy values and delete const.

Hello. On Tue, Feb 18, 2020 at 1:20 PM Michael Paquier wrote: > > On Mon, Feb 17, 2020 at 11:04:47AM +0900, Moon, Insung wrote: > > The compression-related strategy is applied only when compressed. > > Decompression does not use strategy, so the old compressed data is not > > affected by the new

Re: reindex concurrently and two toast indexes

On Sun, Feb 16, 2020 at 01:08:35PM -0600, Justin Pryzby wrote: > Forking old, long thread: > https://www.postgresql.org/message-id/36712441546604286%40sas1-890ba5c2334a.qloud-c.yandex.net > On Fri, Jan 04, 2019 at 03:18:06PM +0300, Sergei Kornilov wrote: >> About reindex invalid indexes - i found o

Re: RecoveryWalAll and RecoveryWalStream wait events

Hello. At Tue, 18 Feb 2020 12:25:51 +0900, Fujii Masao wrote in > Hi, > > RecoveryWalAll and RecoveryWalStream wait events are documented as > follows. > > RecoveryWalAll > Waiting for WAL from any kind of source (local, archive or stream) at > recovery. > > RecoveryWalStream

Re: plan cache overhead on plpgsql expression

Hi, On Sun, Feb 16, 2020 at 11:13 PM Pavel Stehule wrote: > when I do some profiling of plpgsql, usually I surprised how significant > overhead has expression execution. Any calculations are very slow. > > This is not typical example of plpgsql, but it shows cleanly where is a > overhead > > CR

Re: LOCK TABLE and DROP TABLE on temp tables of other sessions

On Fri, Feb 14, 2020 at 05:59:34PM +0530, Ashutosh Bapat wrote: > On Fri, Feb 14, 2020 at 11:35 AM Michael Paquier wrote: >> One thing that we need to consider is if there are applications which >> take advantage of LOCK allowed on temp relations from other backends >> or not. One downside is tha

Re: Flexible pglz_stategy values and delete const.

On Mon, Feb 17, 2020 at 11:04:47AM +0900, Moon, Insung wrote: > The compression-related strategy is applied only when compressed. > Decompression does not use strategy, so the old compressed data is not > affected by the new patch. This may be a difficult question, but do you have examples of work

Re: table partitioning and access privileges

On 2020/02/17 17:13, Amit Langote wrote: On Mon, Feb 17, 2020 at 4:59 PM Fujii Masao wrote: On 2020/02/14 10:28, Amit Langote wrote: On Thu, Feb 13, 2020 at 8:39 PM Fujii Masao wrote: We can verify that even "LOCK TABLE ONLY" command works expectedly on the inherited tables by keeping t

Re: pg_trigger.tgparentid

On Tue, Feb 18, 2020 at 6:56 AM Alvaro Herrera wrote: > As mentioned in https://postgr.es/m/20191231194759.GA24692@alvherre.pgsql > I propose to add a new column to pg_trigger, which allows us to remove a > pg_depend scan when cloning triggers when adding/attaching partitions. > (It's not that I t

Re: Wait event that should be reported while waiting for WAL archiving to finish

On Mon, Feb 17, 2020 at 10:21:23PM +0900, Fujii Masao wrote: > On 2020/02/17 18:48, Michael Paquier wrote: >> Actually, I have some questions: >> 1) Should a new wait event be added in recoveryPausesHere()? That >> would be IMO useful. > > Yes, it's useful, I think. But it's better to implement t

Re: ssl passphrase callback

On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan wrote: > Not sure if the placement is what you want, but maybe something like this? Hi Andrew, FYI this failed here: t/001_testfunc.pl .. Bailout called. Further testing stopped: pg_ctl start failed FAILED--Further testing stopped: pg_ctl start fail

Re: Duplicate words in comments

On Mon, Feb 17, 2020 at 10:57:33PM +0100, Vik Fearing wrote: > These changes look good to me. Applied. The indentation in nodeAgg.c had a nit. -- Michael signature.asc Description: PGP signature

RecoveryWalAll and RecoveryWalStream wait events

Hi, RecoveryWalAll and RecoveryWalStream wait events are documented as follows. RecoveryWalAll Waiting for WAL from any kind of source (local, archive or stream) at recovery. RecoveryWalStream Waiting for WAL from a stream at recovery. But as far as I read the code, RecoveryWa

Re: WAL usage calculation patch

On Mon, Feb 10, 2020 at 8:20 PM Craig Ringer wrote: > On Wed, 5 Feb 2020 at 21:36, Kirill Bychik wrote: > > Patch is separated in two parts: core changes and pg_stat_statements > > additions. Essentially the extension has its schema updated to allow > > two more fields, docs updated to reflect th

Re: tiny documentation fix

On Tue, Feb 18, 2020 at 10:56 Michael Paquier wrote: > On Mon, Feb 17, 2020 at 01:06:21PM +0100, Daniel Gustafsson wrote: > > Changing as per the patch makes these consistent, so +1 on doing that. > > Thanks, applied. Thank you. - Amit >

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

On Sat, Jan 25, 2020 at 11:59 PM Dent John wrote: > Attached patch addresses these points, so should now apply cleanly agains dev. >From the trivialities department, I see a bunch of warnings about local declaration placement (we're still using C90 rules for those by project policy): refcursor.c

Re: [HACKERS] WAL logging problem in 9.4.3?

On Mon, Jan 27, 2020 at 11:30 PM Kyotaro Horiguchi wrote: > Hello, this is rebased then addressed version. Hi, I haven't followed this thread but I just noticed this strange looking failure: CREATE TYPE priv_testtype1 AS (a int, b text); +ERROR: relation 24844 deleted while still in use REVOKE U

Re: pgsql: walreceiver uses a temporary replication slot by default

On Mon, Feb 17, 2020 at 04:57:04PM +0300, Sergei Kornilov wrote: > Thank you, here is updated patch Thanks > I changed this comments because they describes behavior during > change value of wal_receiver_create_temp_slot. But yes, I need to > add some comments to RequestXLogStreaming. I have rew

Re: Parallel copy

On Tue, Feb 18, 2020 at 4:04 AM Ants Aasma wrote: > On Sat, 15 Feb 2020 at 14:32, Amit Kapila wrote: > > Good point and I agree with you that having a single process would > > avoid any such stuff. However, I will think some more on it and if > > you/anyone else gets some idea on how to deal wi

Re: Parallel copy

At Mon, 17 Feb 2020 16:49:22 +0530, Amit Kapila wrote in > On Sun, Feb 16, 2020 at 12:21 PM Andrew Dunstan > wrote: > > On 2/15/20 7:32 AM, Amit Kapila wrote: > > > On Sat, Feb 15, 2020 at 4:08 PM Alastair Turner > > > wrot> > So why not just forbid parallel copy in CSV > > mode, at least for

Re: tiny documentation fix

On Mon, Feb 17, 2020 at 01:06:21PM +0100, Daniel Gustafsson wrote: > Changing as per the patch makes these consistent, so +1 on doing that. Thanks, applied. -- Michael signature.asc Description: PGP signature

Re: Print physical file path when checksum check fails

On Wed, Feb 12, 2020 at 5:22 PM Hubert Zhang wrote: > Thanks Andres, > > On Tue, Feb 11, 2020 at 5:30 AM Andres Freund wrote: > >> HHi, >> >> On 2020-02-10 16:04:21 +0800, Hubert Zhang wrote: >> > Currently we only print block number and relation path when checksum >> check >> > fails. See examp

Re: Resolving the python 2 -> python 3 mess

> > A possible gotcha in this approach is if there are any python 2/3 > incompatibilities that would not manifest as syntax errors or > obvious runtime errors, but would allow old code to execute and > silently do the wrong thing. One would hope that the Python crowd > weren't dumb enough to do th

Re: Resolving the python 2 -> python 3 mess

Jesse Zhang writes: > I really like the "stub .so" idea, but feel pretty uncomfortable for the > "transparent" upgrade. Response inlined. Fair enough, but ... >> 2. On platforms where Python 2.x is no longer supported, transparently >> map plpythonu and plpython2u to plpython3u. "Transparent" m

Re: more ALTER .. DEPENDS ON EXTENSION fixes

On 2020-Feb-17, Alvaro Herrera wrote: > * More than one 'x' dependencies are allowed for the same object on the > same extension. That's useless and polluting, so should be prevented. > > * There's no way to remove an 'x' dependency. Here's these two patches. There's an "if (true)" in 0002 w

Re: pgindent && weirdness

Thomas Munro writes: > Another problem is that there is one thing in our tree that looks like > a non-cast under the new rule, but it actually expands to a type name, > so now we get that wrong! (I mean, unpatched indent doesn't really > understand it either, it thinks it's a cast, but at least i

Re: Error on failed COMMIT

On 2020-Feb-14, Dave Cramer wrote: > On Fri, 14 Feb 2020 at 15:19, Alvaro Herrera > wrote: > > > Do you mean "if con.commit() results in a rollback, then an exception is > > thrown, unless the parameter XYZ is set to PQR"? > > No. JDBC has a number of connection parameters which change internal

Re: Resolving the python 2 -> python 3 mess

Hi Tom, I really like the "stub .so" idea, but feel pretty uncomfortable for the "transparent" upgrade. Response inlined. On Mon, Feb 17, 2020 at 8:49 AM Tom Lane wrote: > > 2. On platforms where Python 2.x is no longer supported, transparently > map plpythonu and plpython2u to plpython3u. "Tra

more ALTER .. DEPENDS ON EXTENSION fixes

ALTER ... DEPENDS ON EXTENSION (dependencies of type 'x' on an extension) was found to have a few problems. One was fixed as CVE-2020-1720. Other issues: * pg_dump does not reproduce database state correctly. The attached fixes it. * More than one 'x' dependencies are allowed for the sam

Re: pgindent && weirdness

On Tue, Feb 18, 2020 at 4:35 AM Alvaro Herrera wrote: > Hmm ... this suggests to me that if you remove these alleged special > cases for offsetof and sizeof, the new code handles them correctly > anyway. Do you think it's worth giving that a try? Not because > removing the special cases would ha

Re: Error on failed COMMIT

On Mon, 17 Feb 2020 at 13:02, Haumacher, Bernhard wrote: > Am 14.02.2020 um 20:36 schrieb Robert Haas: > > On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer > wrote: > >> Well now you are asking the driver to re-interpret the results in a > different way than the server which is not what we tend to do

Re: pg_trigger.tgparentid

Alvaro Herrera writes: > As mentioned in https://postgr.es/m/20191231194759.GA24692@alvherre.pgsql > I propose to add a new column to pg_trigger, which allows us to remove a > pg_depend scan when cloning triggers when adding/attaching partitions. > (It's not that I think the scan is a performance

Re: Duplicate words in comments

On 17/02/2020 15:36, Daniel Gustafsson wrote: > When applying the recent "the the" comment fixup to downstream docs I happened > to notice other cases of duplicated words in comments. The attached trivial > diff removes the few that I came across (the last one was perhaps correct but > if so seeme

pg_trigger.tgparentid

As mentioned in https://postgr.es/m/20191231194759.GA24692@alvherre.pgsql I propose to add a new column to pg_trigger, which allows us to remove a pg_depend scan when cloning triggers when adding/attaching partitions. (It's not that I think the scan is a performance problem, but rather than notiona

SPI Concurrency Precautions?

Dear Hackers I've been working on an extension and using SPI to execute some queries. I am in a situation where I have the option to issue multiple queries concurrently, ideally under same snapshot and transaction. In short, I am achieving this by creating multiple dynamic background workers,

Re: Unicode normalization SQL functions

One nitpick: Around this hunk: - * unicode_normalize_kc - Normalize a Unicode string to NFKC form. + * unicode_normalize - Normalize a Unicode string to the specified form. * * The input is a 0-terminated array of codepoints. * @@ -304,8 +306,10 @@ decompose_code(pg_wchar code, pg_wchar **

Re: Unicode normalization SQL functions

Hi, I've checked the v3 patch against the results of the normalization done by ICU [1] on my test data again, and they're identical (as they were with v1; v2 had the bug discussed upthread, now fixed). Concerning execution speed, there's an excessive CPU usage when normalizing into NFC or NFKC.

Re: Error on failed COMMIT

Am 14.02.2020 um 20:36 schrieb Robert Haas: On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer wrote: Well now you are asking the driver to re-interpret the results in a different way than the server which is not what we tend to do. The server throws an error we throw an error. We really aren't in t

Re: base backup client as auxiliary backend process

On 2020-02-03 13:47, Andres Freund wrote: Comment: - It'd be good to split out the feature independent refactorings, like the introduction of InitControlFile(), into their own commit. Right now it's hard to separate out what should just should be moved code, and what should be behaviour

Re: Fix compiler warnings on 64-bit Windows

On Mon, Feb 17, 2020 at 4:52 PM Tom Lane wrote: > > Anyway, I'll have a go at updating gaur to use 4.5.x. There is a > sane-looking stdint.h on my second-oldest dinosaur, prairiedog. > Don't know about the situation on Windows, though. We might want > to take a close look at NetBSD, too, based

Resolving the python 2 -> python 3 mess

We've had multiple previous discussions of $SUBJECT (eg [1][2]), without any resolution of what to do exactly. Thinking about this some more, I had an idea that I don't think has been discussed. To wit: 1. On platforms where Python 2.x is still supported, recommend that packagers continue to buil

Re: Index Skip Scan

> On Fri, Feb 14, 2020 at 01:18:20PM +0100, Dmitry Dolgov wrote: > > On Fri, Feb 14, 2020 at 05:23:13PM +0900, Kyotaro Horiguchi wrote: > > The first attached (renamed to .txt not to confuse the cfbots) is a > > small patch that makes sure if _bt_readpage is called with the proper > > condition as

Re: Unicode normalization SQL functions

On 2020-02-13 01:23, Andreas Karlsson wrote: A potential optimization would be to merge utf8_to_unicode() and pg_utf_mblen() into one function in unicode_normalize_func() since utf8_to_unicode() already knows length of the character. Probably not worth it though. This would also require untangl

Re: Fix compiler warnings on 64-bit Windows

I wrote: > Ooops. Poking around, it looks like this version of gcc has brought its > own stdbool.h, but not stdint.h: > ... > Kind of annoying. Perhaps more recent gcc versions fixed that? Here we go, in the gcc 4.5.x release notes: GCC now ensures that a C99-conforming is present on most

Re: [HACKERS] Transactions involving multiple postgres foreign servers, take 2

Hi Sawada San, I have a couple of comments on "v27-0002-Support-atomic-commit-among-multiple-foreign-ser.patch" 1- As part of the XLogReadRecord refactoring commit the signature of XLogReadRecord was changed, so the function call to XLogReadRecord() needs a small adjustment. i.e. In function

Re: pgindent && weirdness

On 2020-Feb-17, Thomas Munro wrote: > Thinking about this again: It's obviously not true that everything > that looks like a function call is not a cast. You could have > "my_cast(Type)" that expands to "(Type)" or some slightly more useful > variant of that, and then "my_cast(Type) -1" would, wi

Re: Optimize update of tables with generated columns

On 2020-02-13 16:16, Pavel Stehule wrote: čt 13. 2. 2020 v 14:40 odesílatel Peter Eisentraut > napsal: On 2019-12-21 07:47, Peter Eisentraut wrote: > When updating a table row with generated columns, we only need to > recompute those genera

Re: Parallel copy

On Sat, 15 Feb 2020 at 14:32, Amit Kapila wrote: > Good point and I agree with you that having a single process would > avoid any such stuff. However, I will think some more on it and if > you/anyone else gets some idea on how to deal with this in a > multi-worker system (where we can allow each

Duplicate words in comments

When applying the recent "the the" comment fixup to downstream docs I happened to notice other cases of duplicated words in comments. The attached trivial diff removes the few that I came across (the last one was perhaps correct but if so seemed strange to a non-native speaker). cheers ./daniel

Re: Fix compiler warnings on 64-bit Windows

Peter Eisentraut writes: > On 2020-02-14 15:52, Tom Lane wrote: >> BTW: I'm still concerned about the possibility of the C library being >> less than C99. The model that was popular back then, and which still >> exists on e.g. gaur, was that you could install a C99 *compiler* on >> a pre-C99 syst

Re: pgsql: walreceiver uses a temporary replication slot by default

Hello > Thanks for posting this patch, Sergei. Here is a review to make > things move on. Thank you, here is updated patch > The set of comments you are removing from walreceiver.c to decide if a > temporary slot needs to be created or not should be moved to > walreceiverfuncs.c as you move the

Re: Wait event that should be reported while waiting for WAL archiving to finish

On 2020/02/17 18:48, Michael Paquier wrote: On Mon, Feb 17, 2020 at 04:30:00PM +0900, Fujii Masao wrote: On 2020/02/14 23:43, Robert Haas wrote: On Thu, Feb 13, 2020 at 10:47 PM Fujii Masao wrote: Fixed. Thanks for the review! I think it would be safer to just report the wait event durin

Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

On 2020/02/06 11:35, Amit Langote wrote: On Wed, Feb 5, 2020 at 4:29 PM Amit Langote wrote: On Wed, Feb 5, 2020 at 3:36 PM Fujii Masao wrote: Yeah, I understand your concern. The pg_basebackup document explains the risk when --progress is specified, as follows. Since I imagined that someon

Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

On 2020/02/06 11:07, Amit Langote wrote: On Thu, Feb 6, 2020 at 9:51 AM Kyotaro Horiguchi wrote: On Wed, Feb 5, 2020 at 18:25 Amit Langote wrote: So, maybe you're saying that "waiting for checkpoint" is ambiguous and most people will assume it means "...to start". As for me, I assume it en

Re: tiny documentation fix

> On 17 Feb 2020, at 10:42, Michael Paquier wrote: > > On Mon, Feb 17, 2020 at 03:55:46PM +0900, Amit Langote wrote: >> I propose this small fix for 27.4. Progress Reporting: >> >> -all of its partitions are also recursively analyzed as also mentioned on >> +all of its partitions are als

Re: tiny documentation fix

On Mon, Feb 17, 2020 at 10:43 AM Michael Paquier wrote: > > On Mon, Feb 17, 2020 at 03:55:46PM +0900, Amit Langote wrote: > > I propose this small fix for 27.4. Progress Reporting: > > > > -all of its partitions are also recursively analyzed as also mentioned > > on > > +all of its partit

Re: Orphaned relation files after crash recovery

On Mon, 17 Feb 2020 at 20:05, Thomas Munro wrote: > > On Mon, Feb 17, 2020 at 11:20 PM Masahiko Sawada > wrote: > > Is this a bug? Has this ever been discussed? > > Hi Sawada-san, > > There was this thread: > > https://www.postgresql.org/message-id/flat/CAEepm%3D0ULqYgM2aFeOnrx6YrtBg3xUdxALoyCG%2

Re: Parallel copy

On Sun, Feb 16, 2020 at 12:21 PM Andrew Dunstan wrote: > On 2/15/20 7:32 AM, Amit Kapila wrote: > > On Sat, Feb 15, 2020 at 4:08 PM Alastair Turner wrote: > >>> > >> The problem case that I see is the chunk boundary falling in the > >> middle of a quoted field where > >> - The quote opens in chu

Re: Orphaned relation files after crash recovery

On Mon, Feb 17, 2020 at 11:20 PM Masahiko Sawada wrote: > Is this a bug? Has this ever been discussed? Hi Sawada-san, There was this thread: https://www.postgresql.org/message-id/flat/CAEepm%3D0ULqYgM2aFeOnrx6YrtBg3xUdxALoyCG%2BXpssKqmezug%40mail.gmail.com We chose that as a sort of simple tes

Orphaned relation files after crash recovery

Hi all, During testing recovery, I realized that it's possible that a relation file is orphaned (probably) forever if postgres crashes during executing a transaction that creates a new relation and loads data. After postgres crashing, the relation is recovered during crash recovery and the transa

Re: Wait event that should be reported while waiting for WAL archiving to finish

On Mon, Feb 17, 2020 at 04:30:00PM +0900, Fujii Masao wrote: > On 2020/02/14 23:43, Robert Haas wrote: >> On Thu, Feb 13, 2020 at 10:47 PM Fujii Masao >> wrote: >>> Fixed. Thanks for the review! >> >> I think it would be safer to just report the wait event during >> pg_usleep(100L) rather tha

Re: tiny documentation fix

On Mon, Feb 17, 2020 at 03:55:46PM +0900, Amit Langote wrote: > I propose this small fix for 27.4. Progress Reporting: > > -all of its partitions are also recursively analyzed as also mentioned on > +all of its partitions are also recursively analyzed as also mentioned in > . > > Not

Re: small improvement of the elapsed time for truncating heap in vacuum

On 2020/02/17 14:28, Kasahara Tatsuhito wrote: Hi, On Mon, Feb 17, 2020 at 1:07 PM Masahiko Sawada wrote: For the patch, we can put also the declaration of ru0 into the loop. Thanks for your reply. Hmm, certainly that it may be better. Fix the v2 patch and attached. Thanks for updating

Re: Fix compiler warnings on 64-bit Windows

On 2020-02-14 15:52, Tom Lane wrote: Yeah, I think that the C99 requirement has obsoleted a number of configure tests and related hackery in c.h. We just haven't got round to cleaning that up yet. BTW: I'm still concerned about the possibility of the C library being less than C99. The model th

Re: WIP/PoC for parallel backup

Thanks Jeevan. Here is the documentation patch. On Mon, Feb 10, 2020 at 6:49 PM Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > Hi Asif, > > On Thu, Jan 30, 2020 at 7:10 PM Asif Rehman > wrote: > >> >> Here are the the updated patches, taking care of the issues pointed >> earlier. This

Re: [PoC] Non-volatile WAL buffer

Hello, On Mon, Feb 17, 2020 at 4:16 PM Takashi Menjo wrote: > Hello Amit, > > > I apologize for not having any opinion on the patches themselves, but let > > me point out that it's better to base these > > patches on HEAD (master branch) than REL_12_0, because all new code is > > committed to t

Re: table partitioning and access privileges

On Mon, Feb 17, 2020 at 4:59 PM Fujii Masao wrote: > On 2020/02/14 10:28, Amit Langote wrote: > > On Thu, Feb 13, 2020 at 8:39 PM Fujii Masao > > wrote: > >> We can verify that even "LOCK TABLE ONLY" command works > >> expectedly on the inherited tables by keeping those SQLs in the > >> regress

Re: Conflict handling for COPY FROM

On Mon, Feb 17, 2020 at 10:00 AM Tatsuo Ishii wrote: > >> test=# copy t1 from '/tmp/a' with (error_limit 1); > >> ERROR: duplicate key value violates unique constraint "t1_pkey" > >> DETAIL: Key (i)=(2) already exists. > >> CONTEXT: COPY t1, line 2: "2 2" > >> > >> So if the number of errors

Re: table partitioning and access privileges

On 2020/02/14 10:28, Amit Langote wrote: On Thu, Feb 13, 2020 at 8:39 PM Fujii Masao wrote: On 2020/02/07 10:39, Amit Langote wrote: On Fri, Feb 7, 2020 at 1:16 AM Fujii Masao wrote: Yes, so I will review your patch getting rid of LOCK TABLE exception. Attached updated patch. Thanks!