Re: Physical replication slot advance is not persistent

At Wed, 29 Jan 2020 15:45:56 +0900, Michael Paquier wrote in > On Tue, Jan 28, 2020 at 06:06:06PM +0300, Alexey Kondratov wrote: > > On 28.01.2020 15:14, Kyotaro Horiguchi wrote: > >> But the doc part looks a bit too detailed to me. Couldn't we explain > >> that without the word 'dirty'? .. > >>

Re: [Proposal] Global temporary tables

On 27.01.2020 22:44, Pavel Stehule wrote: I don't think so compatibility with Oracle is valid point in this case. We need GTT, but the mechanism of index building should be designed for Postgres, and for users. Maybe the method proposed by you can be activated by some option like CREATE I

Re: Option to dump foreign data in pg_dump

Thanks for working on the comments. I noticed one behavior is different when --table option is specified. When --table is specified the following are not getting dumped: CREATE SERVER foreign_server I felt the above also should be included as part of the dump when include-foreign-data option is sp

Re: Append with naive multiplexing of FDWs

Thanks! At Wed, 29 Jan 2020 14:41:07 +0800, Movead Li wrote in > >"Parallel scan" at the moment means multiple workers fetch unique > >blocks from *one* table in an arbitrated manner. In this sense > >"parallel FDW scan" means multiple local workers fetch unique bundles > >of tuples from *one

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Sun, 26 Jan 2020 at 01:35, Sehrope Sarkuni wrote: > > Hi, > > I took a look at this patch. With some additions I think the feature > itself is useful but the patch needs more work. It also doesn't have > any of its own automated tests yet so the testing below was done > manually. > > The attach

psqlODBC development

Hello, I am interested in contributing source code changes for psqlODBC. These changes cover (trivial) omissions, corrections, and potential enhancements. How do I go about this?Is there a specific-mailing list (other than this one) for that purpose? Or is there some other mechanism th

Re: Autovacuum on partitioned table

On Wed, Jan 29, 2020 at 11:29 AM yuzuko wrote: > > Besides the complexity of > > getting that infrastructure in place, an important question is whether > > the current system of applying threshold and scale factor to > > changes_since_analyze should be used as-is for inheritance parents > > (parti

Re: Making psql error out on output failures

David Zhang wrote: > > Are you sure? I don't find that redefinition. Besides > > print_aligned_text() also calls putc and puts. > Yes, below is the gdb debug message when psql first time detects the > error "No space left on device". Test case, "postgres=# select > repeat('111', 100)

Re: Append with naive multiplexing of FDWs

Hello, >It is "asynchronous append on async-capable'd postgres-fdw scans". It >could be called as such in the sense that it is intended to be used >with sharding. Yes that's it. >Did you looked at my benchmarking result upthread? Even it gives >significant gain even when gathering large numb

Re: psqlODBC development

## Robert Willis (rwil...@abinitio.com): > How do I go about this?Is there a specific-mailing list (other than > this one) for that purpose? https://odbc.postgresql.org/ "psqlODBC is developed and supported through the pgsql-o...@postgresql.org mailing list." Regards, Christoph -- Spare S

Re: closesocket behavior in different platforms

On Tue, Jan 21, 2020 at 11:22 AM Amit Kapila wrote: > > On Fri, Dec 6, 2019 at 11:24 AM vignesh C wrote: > > > > It is noticed that in all the 4 cases the message "FATAL: terminating > > connection due to administrator command" does not appear in windows. > > > > However the following message i

Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)

Hi. Attached patch solve this problem. This patch adds table_beginscan_tid() and call it in TidListEval() instead of table_beginscan(). table_beginscan_tid() is the same as table_beginscan() but do not set SO_TYPE_SEQSCAN to flags. Although I'm not sure this behavior is really problem or not, it

Re: BUG #16109: Postgres planning time is high across version (Expose buffer usage during planning in EXPLAIN)

On Fri, Jan 24, 2020 at 10:06 PM Julien Rouhaud wrote: > > On Fri, Jan 24, 2020 at 6:55 AM Justin Pryzby wrote: > > > > On Wed, Nov 13, 2019 at 11:39:04AM +0100, Julien Rouhaud wrote: > > > (moved to -hackers) > > > > > > On Tue, Nov 12, 2019 at 9:55 PM Andres Freund wrote: > > > > > > > > This

Re: Autovacuum on partitioned table

On Wed, Jan 29, 2020 at 05:56:40PM +0900, Amit Langote wrote: > Yes, we will need to first support those parameters on partitioned > tables. Currently, you get: > > create table p (a int) partition by list (a) with > (autovacuum_analyze_scale_factor=0); > ERROR: unrecognized parameter "autovacuu

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

Hi Mark, On Tue, Jan 28, 2020 at 1:39 PM Mark Dilger wrote: > There is stray whitespace in v30-0002: > > src/backend/partitioning/partbounds.c:4557: space before tab in indent. > + outer_null_unmerged = true; Good catch! > I have added tests checking correctness and showin

Re: [Proposal] Global temporary tables

> 2020年1月29日 上午1:54，Pavel Stehule 写道： > > > > út 28. 1. 2020 v 18:13 odesílatel Pavel Stehule > napsal: > > > út 28. 1. 2020 v 18:12 odesílatel 曾文旌(义从) > napsal: > > >> 2020年1月29日 上午12:40，Pavel Stehule >

Re: [Proposal] Global temporary tables

On Mon, Jan 27, 2020 at 4:11 AM Konstantin Knizhnik wrote: > I do not see any reasons to allow build local indexes for global table. > Yes,it can happen that some session will have small amount of data in > particular GTT and another - small amount of data in this table. But if > access pattern

Re: standby apply lag on inactive servers

On 2020-Jan-29, Kyotaro Horiguchi wrote: > But as more significant issue, nowadays PostgreSQL doesn't run a > checkpoint if it is really inactive (that is, if no "important" WAL > records have issued.). Yeah, I mentioned this in message <20200127203419.GA15216@alvherre.pgsql>. The solution for m

Re: [Proposal] Global temporary tables

On Tue, Jan 28, 2020 at 12:12 PM 曾文旌(义从) wrote: >> Opinion by Pavel >> + rel->rd_islocaltemp = true; <<< if this is valid, then the name of >> field "rd_islocaltemp" is not probably best >> I renamed rd_islocaltemp > > I don't see any change? > > Rename rd_islocaltemp to rd_istemp in global

Re: [HACKERS] Block level parallel vacuum

On Tue, 28 Jan 2020 at 18:47, Amit Kapila wrote: > > On Tue, Jan 28, 2020 at 12:53 PM Mahendra Singh Thalor > wrote: > > > > > > > > 1. > > > > > > -P, --parallel=PARALLEL_DEGREE do parallel vacuum > > > > > > > > > > > > I think, "do parallel vacuum" should be modified. Without > > > > > > spe

pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

Hi, pg_basebackup reports the backup progress if --progress option is specified, and we can monitor it in the client side. I think that it's useful if we can monitor the progress information also in the server side because, for example, we can easily check that by using SQL. So I'd like to propos

Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)

On 2020/01/29 20:06, Kasahara Tatsuhito wrote: Hi. Attached patch solve this problem. This patch adds table_beginscan_tid() and call it in TidListEval() instead of table_beginscan(). table_beginscan_tid() is the same as table_beginscan() but do not set SO_TYPE_SEQSCAN to flags. Although I'm

Re: [Proposal] Global temporary tables

On Wed, Jan 29, 2020 at 3:13 AM Konstantin Knizhnik wrote: > But I heard only two arguments: > > 1. Concurrent building of indexes by all backends may consume much memory > (n_backends * maintenance_work_mem) and consume a lot of disk/CPU resources. > 2. GTT in one session can contains large amou

Re: closesocket behavior in different platforms

On Wed, Jan 29, 2020 at 4:34 PM vignesh C wrote: > On Tue, Jan 21, 2020 at 11:22 AM Amit Kapila > wrote: > > > > On Fri, Dec 6, 2019 at 11:24 AM vignesh C wrote: > > > [...] > > Thanks for your review and suggestion. I have made a patch based on > similar lines. Attached patch has the doc upd

Re: Enabling B-Tree deduplication by default

On Thu, Jan 16, 2020 at 3:05 PM Peter Geoghegan wrote: > The main reason that I am confident about unique indexes is that we > only do a deduplication pass in a unique index when we observe that > the incoming tuple (the one that might end up splitting the page) is a > duplicate of some existing t

Re: closesocket behavior in different platforms

On Wed, Jan 29, 2020 at 6:04 AM vignesh C wrote: > Thanks for your review and suggestion. I have made a patch based on > similar lines. Attached patch has the doc update with the explanation. > Thoughts? Documenting this doesn't seem very useful to me. If we could fix the code, that would be usef

Re: BufFileRead() error signalling

On Wed, Jan 29, 2020 at 1:26 AM Michael Paquier wrote: > On Tue, Jan 28, 2020 at 03:51:54PM -0500, Robert Haas wrote: > > I quickly reread that thread and I don't see that there's any firm > > consensus there in favor of "read %d of %zu" over "read only %d of %zu > > bytes". Now, if most people pr

Re: pause recovery if pitr target not reached

On 2020-01-28 06:01, Kyotaro Horiguchi wrote: Hello. At Mon, 27 Jan 2020 12:16:02 +0100, Peter Eisentraut wrote in On 2020-01-15 05:02, Kyotaro Horiguchi wrote: FWIW, I restate this (perhaps) more clearly. At Wed, 15 Jan 2020 11:02:24 +0900 (JST), Kyotaro Horiguchi wrote in recvoery_target

Re: making the backend's json parser work in frontend code

On Tue, Jan 28, 2020 at 5:35 PM Mark Dilger wrote: > I merged these a bit. See v7-0001 for details. I jiggered that a bit more and committed this. I couldn't see the point of having both the FRONTEND and non-FRONTEND code include pg_wchar.h. I'll wait to see what you make of Andrew's latest com

Re: [Proposal] Global temporary tables

On 29.01.2020 17:47, Robert Haas wrote: On Wed, Jan 29, 2020 at 3:13 AM Konstantin Knizhnik wrote: But I heard only two arguments: 1. Concurrent building of indexes by all backends may consume much memory (n_backends * maintenance_work_mem) and consume a lot of disk/CPU resources. 2. GTT i

Re: doc: vacuum full, fillfactor, and "extra space"

On 2020-01-20 06:30, Justin Pryzby wrote: Rebased against 40d964ec997f64227bc0ff5e058dc4a5770a70a9 I'm not sure that description of parallel vacuum in the middle of non-full vs. full vacuum is actually that good. I think those sentences should be moved to a separate paragraph. About your p

Re: making the backend's json parser work in frontend code

Robert Haas writes: > On Tue, Jan 28, 2020 at 5:35 PM Mark Dilger > wrote: >> I merged these a bit. See v7-0001 for details. > I jiggered that a bit more and committed this. I couldn't see the > point of having both the FRONTEND and non-FRONTEND code include > pg_wchar.h. First buildfarm repor

Re: making the backend's json parser work in frontend code

On Wed, Jan 29, 2020 at 10:45 AM Tom Lane wrote: > Robert Haas writes: > > On Tue, Jan 28, 2020 at 5:35 PM Mark Dilger > > wrote: > >> I merged these a bit. See v7-0001 for details. > > > I jiggered that a bit more and committed this. I couldn't see the > > point of having both the FRONTEND and

Re: making the backend's json parser work in frontend code

On Wed, Jan 29, 2020 at 10:48 AM Robert Haas wrote: > Hrrm, OK. I think it must need a sprinkling of Windows-specific magic. I see that the patch Andrew posted earlier adjusts Mkvcbuild.pm's @pgcommonallfiles, so I pushed that fix. The other hunks there should go into the patch to add a test_json

Re: Option to dump foreign data in pg_dump

On 2020-01-21 10:36, Luis Carril wrote: Yes we can support --include-foreign-data without parallel option and later add support for parallel option as a different patch. Hi,     I've attached a new version of the patch in which an error is emitted if the parallel backup is used with the --in

Re: [Proposal] Global temporary tables

2. Actually I do not propose some completely new approach. I try to > provide behavior with is compatible with regular tables. > If you create index for regular table, then it can be used in all > sessions, right? > I don't understand to this point. Regular tables shares data, shares files. You ca

Re: [Proposal] Global temporary tables

On 29.01.2020 20:08, Pavel Stehule wrote: 2. Actually I do not propose some completely new approach. I try to provide behavior with is compatible with regular tables. If you create index for regular table, then it can be used in all sessions, right? I don't understand to th

Re: [Proposal] Global temporary tables

st 29. 1. 2020 v 18:21 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 29.01.2020 20:08, Pavel Stehule wrote: > > > > > 2. Actually I do not propose some completely new approach. I try to >> provide behavior with is compatible with regular tables. >> If you create inde

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

So having seen the feedback on this thread, and I tend to agree with most of what has been said here, I also agree that the server core isn't really the ideal place to handle the orphan prepared transactions. Ideally, these must be handled by a transaction manager, however, I do believe that we ca

Re: Enabling B-Tree deduplication by default

On Wed, Jan 29, 2020 at 6:56 AM Robert Haas wrote: > This (and the rest of the explanation) don't really address my > concern. I understand that deduplicating in lieu of splitting a page > in a unique index is highly likely to be a win. What I don't > understand is why it shouldn't just be a win,

Re: [Proposal] Global temporary tables

On Wed, Jan 29, 2020 at 10:30 AM Konstantin Knizhnik wrote: > But please consider two arguments: > > 1. Index for GTT in any case has to be initialized on demand. In case of > regular tables index is initialized at the moment of its creation. In > case of GTT it doesn't work. > So we should someho

Re: Removing pg_pltemplate and creating "trustable" extensions

I wrote: > Stephen Frost writes: >> On Tue, Jan 28, 2020 at 16:17 Tom Lane wrote: >>> On the other hand, there's the point that lots of people have probably >>> given out schema-CREATE privilege to users whom they wouldn't necessarily >>> wish to trust with INSTALL privilege. Schema-CREATE is a

Re: Enabling B-Tree deduplication by default

On Wed, Jan 29, 2020 at 1:15 PM Peter Geoghegan wrote: > The good news is that these extra cycles aren't very noticeable even > with a workload where deduplication doesn't help at all (e.g. with > several indexes an append-only table, and few or no duplicates). The > cycles are generally a fixed c

Re: [HACKERS] kqueue

On Sat, Jan 25, 2020 at 11:29:11AM +1300, Thomas Munro wrote: > On Thu, Jan 23, 2020 at 9:38 AM Rui DeSousa wrote: > > On Jan 22, 2020, at 2:19 PM, Tom Lane wrote: > >> It's certainly possible that to see any benefit you need stress > >> levels above what I can manage on the small box I've got th

Marking some contrib modules as trusted extensions

Now that we're just about there on the patch to invent trusted extensions [1], I'd like to start a discussion about whether to mark anything besides the trusted PLs as trusted. I think generally we ought to mark contrib modules as trusted if it's sane to do so; there's not much point in handing pe

Re: Enabling B-Tree deduplication by default

On Wed, Jan 29, 2020 at 10:41 AM Robert Haas wrote: > Yeah, maybe. I'm tempted to advocate for dropping the GUC and keeping > the reloption. If the worst case is a 3% regression and you expect > that to be rare, I don't think a GUC is really worth it, especially > given that the proposed semantics

parens cleanup

Some ereport calls have excess sets of parentheses. patch 0001 removes the ones I found in a very quick grep. 0002 removes newlines immediately following parens. These were previously useful because pgindent would move arguments further to the left so that the line would fit under 80 chars. How

Re: Marking some contrib modules as trusted extensions

On 2020-Jan-29, Tom Lane wrote: > Not sure what I think about these: > > bloom (are these useful in production?) > btree_gin > btree_gist > pgrowlocks(seems safe, but are there security issues?) > spi/autoinc (I doubt that these four are production grade) > s

Re: Default JIT setting in V12

Hello, Based on this thread, Alexandra and I decided to investigate if we could borrow some passes from -O1 and add on to the default optimization of -O0 and mem2reg. To determine what passes would make most sense, we ran ICW with jit_above_cost set to 0, dumped all the backends and then analyzed

Re: Marking some contrib modules as trusted extensions

Hello, > btree_gin > btree_gist I would even ask btree_gin and btree_gist to be moved to core. btree_gist is shipping opclasses for built in types to be used in gist indexes. btree_* is confusing part in the name pretending there's some magic happening linking btree and gist. gist is the most

Re: Collation versioning

On Tue, Jan 28, 2020 at 1:06 PM Peter Eisentraut wrote: > > On 2019-12-17 14:25, Julien Rouhaud wrote: > > PFA rebased v6, with the following changes: > > Some thoughts on this patch set. Thanks for looking at it! > I think we are all agreed on the general idea. > > 0001-0003 seem pretty much OK

Re: Enabling B-Tree deduplication by default

On Wed, Jan 29, 2020 at 2:50 PM Peter Geoghegan wrote: > It's tempting to try to reason about the state of an index over time > like this, but I don't think that it's ever going to work well. > Imagine a unique index where 50% of all values are NULLs, on an > append-only table. Actually, let's say

Re: making the backend's json parser work in frontend code

On Wed, Jan 29, 2020 at 4:32 PM Andrew Dunstan wrote: > > > On 1/28/20 5:28 PM, Mark Dilger wrote: > > > > > >> +# There doesn't seem to be any easy way to get TestLib to use the > >> binaries from > >> +# our directory, so we hack up a path to our binary and run that > >> directly. This > >> +#

Re: making the backend's json parser work in frontend code

> On Jan 29, 2020, at 1:02 PM, Andrew Dunstan > wrote: > > On Wed, Jan 29, 2020 at 4:32 PM Andrew Dunstan > wrote: >> >> >> On 1/28/20 5:28 PM, Mark Dilger wrote: >>> >>> +# There doesn't seem to be any easy way to get TestLib to use the binaries from +# our directory, so

Re: Marking some contrib modules as trusted extensions

=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= writes: >> btree_gin >> btree_gist > I would even ask btree_gin and btree_gist to be moved to core. That's not in scope here. Our past experience with trying to move extensions into core is that it creates a pretty painful upgrade experience f

Re: Marking some contrib modules as trusted extensions

On Wed, Jan 29, 2020 at 9:46 PM Darafei "Komяpa" Praliaskouski wrote: > > Hello, > >> >> btree_gin >> btree_gist > > > I would even ask btree_gin and btree_gist to be moved to core. Without going that far, I also agree that I relied on those extension quite often, so +1 for marking them as truste

Re: Marking some contrib modules as trusted extensions

Julien Rouhaud writes: >>> Probably NO, if only because you'd need additional privileges >>> to use these anyway: >>> pg_stat_statements > But the additional privileges are global, so assuming the extension > has been properly setup, wouldn't it be sensible to ease the > per-database installation

Re: parens cleanup

Alvaro Herrera writes: > Some ereport calls have excess sets of parentheses. patch 0001 removes > the ones I found in a very quick grep. +1 ... kind of looks like somebody got this wrong long ago, and then various people copied-and-pasted from a bad example. > 0002 removes newlines immediately

Re: standby apply lag on inactive servers

On 2020-Jan-28, Kyotaro Horiguchi wrote: > The aim of the patch seem reasonable. XLOG_END_OF_RECOVERY and > XLOG_XACT_PREPARE also have a timestamp but it doesn't help much. (But > could be included for consistency.) Hmm I think I should definitely include those. > The timestamp of a checkpoint

Re: Memory-Bounded Hash Aggregation

On Fri, 2020-01-24 at 17:16 -0800, Peter Geoghegan wrote: > That sounds weird. Might be pathological in some sense. > > I have a wild guess for you. Maybe this has something to do with the > "test for presorted input" added by commit a3f0b3d68f9. That can > perform very badly when the input is alm

Re: Add %x to PROMPT1 and PROMPT2

On 29/01/2020 08:25, Fabien COELHO wrote: > > Hello Vik, > >>> Isn't there examples in the documentation which use the default prompts? >>> >>> If so, should they be updated accordingly? >> >> Good catch! >> I thought about the documentation but not the examples therein. >> >> Updated patch attac

Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)

Hello. At Wed, 29 Jan 2020 23:24:09 +0900, Fujii Masao wrote in > On 2020/01/29 20:06, Kasahara Tatsuhito wrote: > > Hi. > > Attached patch solve this problem. > > This patch adds table_beginscan_tid() and call it in TidListEval() > > instead of table_beginscan(). > > table_beginscan_tid() is t

Re: Physical replication slot advance is not persistent

On Wed, Jan 29, 2020 at 05:10:20PM +0900, Kyotaro Horiguchi wrote: > Looks perfect. Thanks Horiguchi-san and others. Applied and back-patched down to 11. -- Michael signature.asc Description: PGP signature

Re: standby apply lag on inactive servers

At Wed, 29 Jan 2020 19:11:31 -0300, Alvaro Herrera wrote in > On 2020-Jan-28, Kyotaro Horiguchi wrote: > > > The aim of the patch seem reasonable. XLOG_END_OF_RECOVERY and > > XLOG_XACT_PREPARE also have a timestamp but it doesn't help much. (But > > could be included for consistency.) > > Hmm

Re: parens cleanup

On Wed, Jan 29, 2020 at 04:47:19PM -0500, Tom Lane wrote: > Alvaro Herrera writes: >> 0002 removes newlines immediately following parens. These were >> previously useful because pgindent would move arguments further to the >> left so that the line would fit under 80 chars. However, pgindent no >

Re: [HACKERS] Block level parallel vacuum

On Wed, Jan 29, 2020 at 7:20 PM Masahiko Sawada wrote: > > > > > Okay, thanks for the review. Attached is an updated patch. I have > > additionally run pgindent. I am planning to commit the attached > > tomorrow unless I see more comments. > > Thank you for committing it! > I have marked this p

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

On Thu, 30 Jan 2020 at 02:04, Hamid Akhtar wrote: > > So having seen the feedback on this thread, and I tend to agree with most of > what has been said here, I also agree that the server core isn't really the > ideal place to handle the orphan prepared transactions. > > Ideally, these must be ha

Re: closesocket behavior in different platforms

On Wed, Jan 29, 2020 at 8:29 PM Robert Haas wrote: > > On Wed, Jan 29, 2020 at 6:04 AM vignesh C wrote: > > Thanks for your review and suggestion. I have made a patch based on > > similar lines. Attached patch has the doc update with the explanation. > > Thoughts? > > Documenting this doesn't see

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

At Wed, 29 Jan 2020 23:16:08 +0900, Fujii Masao wrote in > Hi, > > pg_basebackup reports the backup progress if --progress option is > specified, > and we can monitor it in the client side. I think that it's useful if > we can > monitor the progress information also in the server side because,

Re: pause recovery if pitr target not reached

At Wed, 29 Jan 2020 16:01:46 +0100, Peter Eisentraut wrote in > On 2020-01-28 06:01, Kyotaro Horiguchi wrote: > > The code looks fine, renaming reachedStopPoint to > > reachedRecoveryTarget looks very nice. Doc part looks fine, too. > > PostgresNode.pm > > +Is has_restoring is used, standby mode

Re: pg_restore crash when there is a failure before all child process is created

On Wed, Jan 29, 2020 at 6:54 PM Ahsan Hadi wrote: > > Hi Vignesh, > > Can you share a test case or steps that you are using to reproduce this > issue? Are you reproducing this using a debugger? > I could reproduce with the following steps: Make cluster setup. Create few tables. Take a dump in di

Re: Option to dump foreign data in pg_dump

On Wed, Jan 29, 2020 at 2:00 PM Luis Carril wrote: > > Thanks for working on the comments. I noticed one behavior is > different when --table option is specified. When --table is specified > the following are not getting dumped: > CREATE SERVER foreign_server > > I felt the above also should be in

Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)

Hi, On Thu, Jan 30, 2020 at 10:55 AM Kyotaro Horiguchi wrote: > At Wed, 29 Jan 2020 23:24:09 +0900, Fujii Masao > wrote in > > On 2020/01/29 20:06, Kasahara Tatsuhito wrote: > > > Although I'm not sure this behavior is really problem or not, > > > it seems to me that previous behavior is more p

Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)

At Thu, 30 Jan 2020 13:30:56 +0900, Kasahara Tatsuhito wrote in > > TID scan : yes , seq_scan, , > Here is wrong, because TID scan came to have SO_TYPE_SEQSCAN flags > from commit 147e3722f7. It is reflectings the discussion below, which means TID scan doesn't have corres

Re: BufFileRead() error signalling

On Wed, Jan 29, 2020 at 10:01:31AM -0500, Robert Haas wrote: > Your grep misses one instance of 'read only %d of %d bytes' because > you grepped for %zu specifically, but that doesn't really change the > overall picture. Yes, the one in pg_checksums.c. That could actually be changed with a cast t

Prevent pg_basebackup running as root

Hi We encountered an unfortunate case of $SUBJECT the other day where it would have been preferable to catch the error before rather than after pg_basebackup ran. I can't think of any practical reason why pg_basebackup would ever need to be run as root; we disallow that for initdb, pg_ctl and pg_

Re: Prevent pg_basebackup running as root

On Thu, Jan 30, 2020 at 02:29:06PM +0900, Ian Barwick wrote: > I can't think of any practical reason why pg_basebackup would ever need to > be run as root; we disallow that for initdb, pg_ctl and pg_upgrade, so it > seems reasonable to do the same for pg_basebackup. Trivial patch attached, > which

Re: Error message inconsistency

On Tue, 28 Jan 2020 at 18:13, Amit Kapila wrote: > > On Sat, Jan 25, 2020 at 10:16 AM Amit Kapila wrote: > > > > On Fri, Jan 24, 2020 at 9:37 PM Tom Lane wrote: > > > > > > Amit Kapila writes: > > > > LGTM. I have combined them into the single patch. What do we think > > > > about backpatchin

Re: making the backend's json parser work in frontend code

On Thu, Jan 30, 2020 at 7:36 AM Mark Dilger wrote: > > > > > On Jan 29, 2020, at 1:02 PM, Andrew Dunstan > > wrote: > > > > On Wed, Jan 29, 2020 at 4:32 PM Andrew Dunstan > > wrote: > >> > >> > >> On 1/28/20 5:28 PM, Mark Dilger wrote: > >>> > >>> > +# There doesn't seem to be any easy way

Re: Hash join not finding which collation to use for string hashing

Hi Mark, On Wed, Jan 29, 2020 at 1:03 PM Mark Dilger wrote: > > On Jan 28, 2020, at 7:38 PM, Mark Dilger > > wrote: > >> Mark Dilger writes: > >>> While reviewing the partition-wise join patch, I ran into an issue that > >>> exists in master, so rather than responding to that patch, I’m start

Re: Prevent pg_basebackup running as root

2020年1月30日(木) 14:57 Michael Paquier : > > On Thu, Jan 30, 2020 at 02:29:06PM +0900, Ian Barwick wrote: > > I can't think of any practical reason why pg_basebackup would ever need to > > be run as root; we disallow that for initdb, pg_ctl and pg_upgrade, so it > > seems reasonable to do the same for

Re: Enabling B-Tree deduplication by default

On Wed, Jan 29, 2020 at 11:50 AM Peter Geoghegan wrote: > I should stop talking about it for now, and go back to reassessing the > extent of the regression in highly unsympathetic cases. The patch has > become faster in a couple of different ways since I last looked at > this question, and it's en

Re: Prevent pg_basebackup running as root

On Thu, Jan 30, 2020 at 03:38:54PM +0900, Ian Barwick wrote: > 2020年1月30日(木) 14:57 Michael Paquier : I have never noticed that your client was configured in Japanese :) > I think we can skip the second sentence altogether. It'd be theoretically > easy enough to up with some combination of group p

Parallel CREATE INDEX vs DSM starvation

Hello, CreateParallelContext() can return a context with seg == NULL. That causes CREATE INDEX to segfault. Instead, it should fall back to non-parallel build. See attached. This probably explains a segfault reported over on pgsql-general[1]. [1] https://www.postgresql.org/message-id/CA%2BhU

Re: Parallel CREATE INDEX vs DSM starvation

On Wed, Jan 29, 2020 at 11:38 PM Thomas Munro wrote: > CreateParallelContext() can return a context with seg == NULL. That > causes CREATE INDEX to segfault. Instead, it should fall back to > non-parallel build. See attached. I guess we can't call _bt_end_parallel() here. So your patch LGTM.