Re: add types to index storage params on doc

On Mon, Mar 16, 2020 at 11:32 PM Alvaro Herrera wrote: > > > Should I also change it to "enum"? > > Yeah, these were strings until recently (commit 773df883e8f7 Sept 2019). > Thanks! Attached a patch for manuals on create and alter view. check_option is also described in

Re: ALTER tbl rewrite loses CLUSTER ON index

On Mon, Mar 16, 2020 at 11:25:23AM -0300, Alvaro Herrera wrote: > On 2020-Mar-16, Justin Pryzby wrote: > > > Also, should we call it "is_index_clustered", since otherwise it sounds alot > > like "+get_index_clustered" (without "is"), which sounds like it takes a > > table > > and returns which

Re: [PATCH] Btree BackwardScan race condition on Standby during VACUUM

Hi Michail! Very interesting bug. > 16 марта 2020 г., в 19:07, Michail Nikolaev > написал(а): > > So, I think right way is to lock all three pages as it is done on the > primary. As far as I can see it is not causes any real performance > regression. It seems to me that it's exactly the same

Re: error context for vacuum to include block number

On Tue, Mar 17, 2020 at 9:21 AM Justin Pryzby wrote: > > On Tue, Mar 03, 2020 at 10:05:42PM +0900, Masahiko Sawada wrote: > > I was concerned about fsm vacuum; vacuum error context might show heap > > scan while actually doing fsm vacuum. But perhaps we can update > > callback args for that. That

Re: Refactor compile-time assertion checks for C/C++

On Mon, Mar 16, 2020 at 10:35:05PM -0400, Tom Lane wrote: > Michael Paquier writes: >> C++ does not allow defining a struct inside a sizeof() call, so in >> this case StaticAssertExpr() does not work with the previous extension >> in C++. StaticAssertStmt() does the work though. > > [ scratches

Re:Re: Re:Standby got fatal after the crash recovery

Sorry. We are using pg11, and cloned from tag REL_11_BETA2. At 2020-03-17 11:43:51, "Michael Paquier" wrote: >On Tue, Mar 17, 2020 at 11:02:24AM +0800, Thunder wrote: >> The slru error detail is the following. >> DETAIL: Could not read from file "/data/pg_xact/003C" at

Re: error context for vacuum to include block number

On Tue, Mar 03, 2020 at 10:05:42PM +0900, Masahiko Sawada wrote: > I was concerned about fsm vacuum; vacuum error context might show heap > scan while actually doing fsm vacuum. But perhaps we can update > callback args for that. That would be helpful for user to distinguish > that the problem

Re: Re:Standby got fatal after the crash recovery

On Tue, Mar 17, 2020 at 11:02:24AM +0800, Thunder wrote: > The slru error detail is the following. > DETAIL: Could not read from file "/data/pg_xact/003C" at offset 221184: > Success. > > I think read /data/pg_xact/003C from offset 221184 and the return value was 0. What is the version of

Re: Autovacuum on partitioned table

Hello, Thank you for reviewing. > > > + */ > > > + if (IsAutoVacuumWorkerProcess() && > > > + rel->rd_rel->relispartition && > > > + !(rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)) > > > > I'm not sure I understand why we do this only on autovac. Why not

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

On Mon, Mar 16, 2020 at 07:17:36PM -0300, Alvaro Herrera wrote: > I pushed 0001 and 0003 (as a single commit). archive_statusdir didn't > get here until 12, so your commit message was mistaken. Also, pg10 is > slightly different so it didn't apply there, so I left it alone. Thanks, I appreciate

Re: comments on elements of xlogctldata

On 2020/03/16 11:08, Fujii Masao wrote: On 2020/03/16 10:57, Atsushi Torikoshi wrote: Hi, It seems the comments on SharedHotStandbyActive and SharedRecoveryInProgress are the same in XLogCtlData. How about modifying the comment on SharedHotStandbyActive? Attached a patch. Thanks for

Re:Re:Standby got fatal after the crash recovery

The slru error detail is the following. DETAIL: Could not read from file "/data/pg_xact/003C" at offset 221184: Success. I think read /data/pg_xact/003C from offset 221184 and the return value was 0. At 2020-03-17 10:36:03, "Thunder" wrote: Appreciate any suggestion for this

Re: RecoveryWalAll and RecoveryWalStream wait events

On 2020/03/15 0:06, Atsushi Torikoshi wrote: On 2020/02/19 21:46 Fujii Masao mailto:masao.fu...@oss.nttdata.com>>: >> I agree to the former, I think RecoveryWalInterval works well enough. >RecoveryWalInterval sounds confusing to me... IMHO as a user, I prefer RecoveryRetrieveRetryInterval

Re:Standby got fatal after the crash recovery

Appreciate any suggestion for this issue? Is there something i misunderstand? At 2020-03-17 00:33:36, "Thunder" wrote: Hello hackers: Our standby node got fatal after the crash recovery. The fatal error was caused in slru module, i changed log level from ERROR to PANIC and

Re: Refactor compile-time assertion checks for C/C++

Michael Paquier writes: > On Mon, Mar 16, 2020 at 10:32:36AM -0400, Tom Lane wrote: >> Sorry for being unclear --- I just meant that we could use do{} >> in StaticAssertStmt for both C and C++. Although now I notice >> that the code is trying to use StaticAssertStmt for StaticAssertExpr, >>

Re: Add PostgreSQL home page to --help output

On Mon, Mar 16, 2020 at 09:10:25PM -0300, Alvaro Herrera wrote: > On 2020-Mar-16, Bruce Momjian wrote: >> Actually, I prefer: >> >> Report bugs mailto:pgsql-b...@lists.postgresql.org >> PostgreSQL website https://www.postgresql.org/ > > Hmm, pasting mailto into the browser address

Re: Refactor compile-time assertion checks for C/C++

On Mon, Mar 16, 2020 at 10:32:36AM -0400, Tom Lane wrote: > Sorry for being unclear --- I just meant that we could use do{} > in StaticAssertStmt for both C and C++. Although now I notice > that the code is trying to use StaticAssertStmt for StaticAssertExpr, > which you're right isn't going to

Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction

On Mon, Mar 16, 2020 at 09:38:50PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > v2 attached - I will add to next CF in case you want to defer it until > > later. > > Thanks, reviewed and pushed. Since this is a bug fix (at least in part) > I didn't want to wait. Thanks for fixing my

Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction

Justin Pryzby writes: > v2 attached - I will add to next CF in case you want to defer it until later. Thanks, reviewed and pushed. Since this is a bug fix (at least in part) I didn't want to wait. regards, tom lane

Re: Adding missing object access hook invocations

> On Mar 16, 2020, at 5:14 PM, Alvaro Herrera wrote: > > On 2020-Mar-16, Mark Dilger wrote: > >> Hackers, >> >> While working on object access hooks, I noticed several locations where I >> would expect the hook to be invoked, but no actual invocation. I think this >> just barely

Re: Parallel leader process info in EXPLAIN

On Tue, Mar 17, 2020 at 2:39 AM David Steele wrote: > On 1/26/20 7:03 PM, Thomas Munro wrote: > > Fair point. I will look into that. > > Are you still planning on looking at this patch for PG13? > > Based on the current state (002 abandoned, 001 needs total rework) I'd > say it should just be

Re: Berserk Autovacuum (let's save next Mandrill)

On Mon, 2020-03-16 at 14:34 -0700, Andres Freund wrote: > > > In particularl, I think it'd make sense to *not* have a lower freezing > > > horizon for insert vacuums (because it *will* cause problems), but if > > > the page is dirty anyway, then do the freezing even if freeze_min_age > > > etc

Re: Adding missing object access hook invocations

On 2020-Mar-16, Mark Dilger wrote: > Hackers, > > While working on object access hooks, I noticed several locations where I > would expect the hook to be invoked, but no actual invocation. I think this > just barely qualifies as a bug. It's debatable because whether it is a bug > depends on

Re: Add PostgreSQL home page to --help output

On 2020-Mar-16, Bruce Momjian wrote: > On Mon, Mar 16, 2020 at 05:55:26PM -0400, Bruce Momjian wrote: > > Report bugs mailto:pgsql-b...@lists.postgresql.org > > PostgreSQL home page https://www.postgresql.org/ > > > > I kind of prefer the last one since the can both be pasted directly

RE: Planning counters in pg_stat_statements (using pgss_store)

On Mon, Mar 16, 2020 at 9:49 PM, Julien Rouhaud wrote: > On Mon, Mar 16, 2020 at 01:34:11AM +, imai.yoshik...@fujitsu.com > wrote: > > On Sat, Mar 14, 2020 at 5:28 PM, Julien Rouhaud wrote: > > > I don't think that's a correct assumption. I obviously didn't read > > > all of citus extension,

Adding missing object access hook invocations

Hackers, While working on object access hooks, I noticed several locations where I would expect the hook to be invoked, but no actual invocation. I think this just barely qualifies as a bug. It's debatable because whether it is a bug depends on the user's expectations and whether not

Adding test coverage for ALTER SEQUENCE .. SET SCHEMA

Hackers, This is pretty low priority stuff, but I noticed there is no test coverage for this in src/test/regress. There is underwhelming coverage elsewhere. I leave it to others to decide if this is worth committing. v1-0001-Adding-test-coverage-for-ALTER-SEQUENCE-SET-SCHEM.patch

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

I pushed 0001 and 0003 (as a single commit). archive_statusdir didn't get here until 12, so your commit message was mistaken. Also, pg10 is slightly different so it didn't apply there, so I left it alone. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development,

Re: Add PostgreSQL home page to --help output

On Mon, Mar 16, 2020 at 05:55:26PM -0400, Bruce Momjian wrote: > Report bugs mailto:pgsql-b...@lists.postgresql.org > PostgreSQL home page https://www.postgresql.org/ > > I kind of prefer the last one since the can both be pasted directly into > a browser. Actually, I prefer:

Re: Add PostgreSQL home page to --help output

On Fri, Feb 28, 2020 at 02:02:17PM +0100, Peter Eisentraut wrote: > On 2020-02-20 12:09, Daniel Gustafsson wrote: > > > On 20 Feb 2020, at 10:53, Daniel Gustafsson wrote: > > > > > > > On 20 Feb 2020, at 10:15, Peter Eisentraut > > > > wrote: > > > > > > > > On 2020-02-13 14:24, Greg Stark

Re: Planning counters in pg_stat_statements (using pgss_store)

On Mon, Mar 16, 2020 at 01:34:11AM +, imai.yoshik...@fujitsu.com wrote: > On Sat, Mar 14, 2020 at 5:28 PM, Julien Rouhaud wrote: > > I don't think that's a correct assumption. I obviously didn't read all of > > citus extension, but it looks like what's happening is that they get > > generate

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

On Mon, Mar 16, 2020 at 04:20:21PM +0100, Fabien COELHO wrote: > This probably means using lstat instead of (in supplement to?) stat, and > probably tell if something is a link, and if so not recurse in them. On Mon, Mar 16, 2020 at 07:21:06PM +0100, Fabien COELHO wrote: > IMHO, I really think

Re: Portal->commandTag as an enum

On 2020-Mar-04, Mark Dilger wrote: > > > > On Mar 2, 2020, at 1:57 PM, Alvaro Herrera wrote: > > > > I pushed it now. > > Thanks again! While rebasing some other work on top, I noticed one of your > comments is out of date: > > --- a/src/include/tcop/cmdtaglist.h > +++

Re: Berserk Autovacuum (let's save next Mandrill)

Hi, On 2020-03-16 22:25:11 +0100, Laurenz Albe wrote: > On Mon, 2020-03-16 at 13:13 -0700, Andres Freund wrote: > > > Freezing tuples is the point of this patch. > > > > Sure. But not hurting existing installation is also a goal of the > > patch. Since this is introducing potentially significant

Re: Berserk Autovacuum (let's save next Mandrill)

On Mon, 2020-03-16 at 16:07 -0500, Justin Pryzby wrote: > Best practice is to vacuum following bulk load. Yes. > If it's a bulk load, then I think it's okay to assume it was vacuumed, No. This patch is there precisely because too many people don't know that they should vacuum their table after

Re: Berserk Autovacuum (let's save next Mandrill)

On Mon, 2020-03-16 at 13:13 -0700, Andres Freund wrote: > > Freezing tuples is the point of this patch. > > Sure. But not hurting existing installation is also a goal of the > patch. Since this is introducing potentially significant performance > downsides, I think it's good to be a bit

Re: Just for fun: Postgres 20?

On Wed, Feb 12, 2020 at 10:38:19PM +0100, Michael Banck wrote: > Hi, > > On Wed, Feb 12, 2020 at 02:52:53PM +0100, Andreas Karlsson wrote: > > On 2/12/20 12:07 AM, Alvaro Herrera wrote: > > > marcelo zen escribió: > > > > I'd rather have releases being made when the software is ready and > > > >

Re: Berserk Autovacuum (let's save next Mandrill)

On Mon, Mar 16, 2020 at 08:49:43PM +0100, Laurenz Albe wrote: > On Mon, 2020-03-16 at 07:47 -0500, Justin Pryzby wrote: > > It seems to me that the easy thing to do is to implement this initially > > without > > FREEZE (which is controlled by vacuum_freeze_table_age), and defer until > > July/v14

nbtree: Refactor "fastpath" and _bt_search() code

I have another refactoring patch for nbtinsert.c that is a little bigger than the commits I've pushed recently. I thought I should run it by -hackers before proceeding with commit, even though it seems like a very clear improvement to me. Attached patch creates a _bt_search() wrapper that is

Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

> On 16 Mar 2020, at 17:12, Tom Lane wrote: > Still, I think the number of people who'd get bit by that could be > counted without running out of fingers, while it seems quite likely > that many people will soon need to build our back branches on > platforms that won't have xml2-config. I agree

Re: Berserk Autovacuum (let's save next Mandrill)

Hi, On 2020-03-16 20:49:43 +0100, Laurenz Albe wrote: > On Mon, 2020-03-16 at 07:47 -0500, Justin Pryzby wrote: > > It seems to me that the easy thing to do is to implement this initially > > without > > FREEZE (which is controlled by vacuum_freeze_table_age), and defer until > > July/v14

Re: Berserk Autovacuum (let's save next Mandrill)

On Mon, 2020-03-16 at 07:47 -0500, Justin Pryzby wrote: > It seems to me that the easy thing to do is to implement this initially > without > FREEZE (which is controlled by vacuum_freeze_table_age), and defer until > July/v14 further discussion and implementation of another GUC/relopt for >

Re: Planning counters in pg_stat_statements (using pgss_store)

> I'm instead attaching a v7 which removes the assert in pg_plan_query, and > modify pgss_planner_hook to also ignore queries without a query text, as > this > seems the best option. Ok, it was the second solution, go on ! -- Sent from:

Re: pgsql: Unify several ways to tracking backend type

On 2020-Mar-13, Peter Eisentraut wrote: > Unify several ways to tracking backend type > > Add a new global variable MyBackendType that uses the same BackendType > enum that was previously only used by the stats collector. That way > several duplicate ways of checking what type a particular

Re: Berserk Autovacuum (let's save next Mandrill)

Hi, On 2020-03-13 19:10:00 -0500, Justin Pryzby wrote: > On Fri, Mar 13, 2020 at 02:38:51PM -0700, Andres Freund wrote: > > > |One disadvantage of decreasing vacuum_freeze_min_age is that it might > > > cause > > > |VACUUM to do useless work: freezing a row version is a waste of time if > > >

Re: Internal key management system

On Mon, Mar 16, 2020 at 04:13:21PM +0900, Masahiko Sawada wrote: > On Thu, 12 Mar 2020 at 08:13, Bruce Momjian > wrote: > > > > On Fri, Mar 6, 2020 at 03:31:00PM +0900, Masahiko Sawada wrote: > > > On Fri, 6 Mar 2020 at 15:25, Moon, Insung > > > wrote: > > > > > > > > Dear Sawada-san > > > > >

Make MemoryContextMemAllocated() more precise

AllocSet allocates memory for itself in blocks, which double in size up to maxBlockSize. So, the current block (the last one malloc'd) may represent half of the total memory allocated for the context itself. The free space at the end of that block hasn't been touched at all, and doesn't

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

Hello Justin, psql> SELECT * FROM pg_ls_dir_recurse('.'); ERROR: could not stat file

Standby got fatal after the crash recovery

Hello hackers: Our standby node got fatal after the crash recovery. The fatal error was caused in slru module, i changed log level from ERROR to PANIC and got the following stack. (gdb) bt #0 0x7f0cc47a1277 in raise () from /lib64/libc.so.6 #1 0x7f0cc47a2968 in abort () from

Re: Re: A bug when use get_bit() function for a long bytea string

On Fri, 13 Mar 2020 at 08:48, movead...@highgo.ca wrote: > Thanks for the reply. > > >Why have you used size? Shouldn't we use int64? > Yes, thanks for the point, I have changed the patch. > > Thanks for the patch. > >If get_bit()/set_bit() accept the second argument as int32, it can not >

Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

Daniel Gustafsson writes: > On 13 Mar 2020, at 17:14, Tom Lane wrote: >> Yeah, that's the argument *for* back-patching. Question is whether it >> outweighs the risk of silently breaking somebody's build by linking >> to the wrong libxml2 version. > Correct, my argument is that breakage can be

JDBC prepared insert and X00 and SQL_ASCII

Hi, I don't know if this is a bug or the intended mode, but since ODBC works and JDBC does not, I would ask why JDBC prepared insert does not work if ODBC prepared insert works in case some varchar field contains 0x00 and DB is SQL_ASCII? My environment: [root @ vlada-home ~ 16:32:56] $ psql

Re: [PATCH] Connection time for \conninfo

On 3/16/20 10:59 AM, Juan José Santamaría Flecha wrote: On Mon, Mar 16, 2020 at 1:24 PM David Steele > wrote: On 3/14/20 3:16 PM, Rodrigo Ramírez Norambuena wrote: > > I forgot about that ... It passed a little time from my new pushed > changes. So

Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction

On Thu, Mar 12, 2020 at 07:11:56AM -0500, Justin Pryzby wrote: > > Do you want to have a go at that? > > First draft attached. Note that I handled pg_ls_dir, even though I'm > proposing > on the other thread to collapse/merge/meld it with pg_ls_dir_files [0]. > Possibly that's a bad idea with

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

On Mon, Mar 16, 2020 at 04:20:21PM +0100, Fabien COELHO wrote: > > About v11, ISTM that the recursive function should check for symbolic links > and possibly avoid them: > > sh> cd data/base > sh> ln -s .. foo > > psql> SELECT * FROM pg_ls_dir_recurse('.'); > ERROR: could not stat file >

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

About v11, ISTM that the recursive function should check for symbolic links and possibly avoid them: sh> cd data/base sh> ln -s .. foo psql> SELECT * FROM pg_ls_dir_recurse('.'); ERROR: could not stat file

Re: [PATCH] Opclass parameters

Hi! I took a look on this patchset. There is a first set of questions. * Patchset badly needs comments. I've to literally reverse engineer to get what's going on. But I still don't understand many things. * I'm curious about what local_relopts.base field means. void

Re: [PATCH] Connection time for \conninfo

On Mon, Mar 16, 2020 at 1:24 PM David Steele wrote: > On 3/14/20 3:16 PM, Rodrigo Ramírez Norambuena wrote: > > > > I forgot about that ... It passed a little time from my new pushed > > changes. So go ahead :) > > This patch has been returned with feedback. Please feel free to resubmit > in a

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Sat, Mar 14, 2020 at 06:53:51PM +0100, Julien Rouhaud wrote: > On Tue, Mar 03, 2020 at 04:24:59PM +0100, Julien Rouhaud wrote: > > > > cfbot reports a failure since 2f9661311b (command completion tag > > change), so here's a rebased v6, no change otherwise. > > > Conflict with 8e8a0becb3 (Unify

Re: Refactor compile-time assertion checks for C/C++

Michael Paquier writes: > On Fri, Mar 13, 2020 at 11:00:33AM -0400, Tom Lane wrote: >> If we do need to change it, I'd be inclined to just use the do{} >> block everywhere, not bothering with the extra #if test. > Not sure what you mean here because we cannot use the do{} flavor > either for the

Re: add types to index storage params on doc

On 2020-Mar-16, Atsushi Torikoshi wrote: > Thanks for your comments! > > On Mon, Mar 16, 2020 at 11:49 AM Fujii Masao > wrote: > > > -buffering > > +buffering (string) > > > > Isn't it better to use "enum" rather than "string"? > > In the docs about enum GUC parameters, "enum" is used

Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

> On 13 Mar 2020, at 17:14, Tom Lane wrote: > Daniel Gustafsson writes: >> I read this is as a preventative patch to stay ahead of future changes to >> packaging. If these changes do materialize, won't they be equally likely to >> hit installations for backbranch minors as v13? > > Yeah,

Re: Online checksums verification in the backend

On Mon, Mar 16, 2020 at 02:15:27PM +0100, Julien Rouhaud wrote: > On Mon, Mar 16, 2020 at 09:42:39AM +0100, Julien Rouhaud wrote: > > On Mon, Mar 16, 2020 at 01:53:35PM +0900, Masahiko Sawada wrote: > > > > > > In addition to comments from Michael-san, here are my comments: > > Thanks both for the

Re: ALTER tbl rewrite loses CLUSTER ON index

On 2020-Mar-16, Justin Pryzby wrote: > Also, should we call it "is_index_clustered", since otherwise it sounds alot > like "+get_index_clustered" (without "is"), which sounds like it takes a table > and returns which index is clustered. That might be just as useful for some > of > these

Re: Option to dump foreign data in pg_dump

Hi Luis, Please don't top post. Also be careful to quote prior text when replying. Your message was pretty hard to work through -- i.e. figuring out what you said vs. what you were replying to. On 3/5/20 8:51 AM, Luis Carril wrote: At this point I would like to leave the patch as is, and

Re: error context for vacuum to include block number

On 2020-Mar-16, Amit Kapila wrote: > 2. > + /* Setup error traceback support for ereport() */ > + update_vacuum_error_cbarg(vacrelstats, VACUUM_ERRCB_PHASE_SCAN_HEAP, > + InvalidBlockNumber, NULL); > + errcallback.callback = vacuum_error_callback; > + errcallback.arg = vacrelstats; > +

[PATCH] Btree BackwardScan race condition on Standby during VACUUM

Hello, hackers. -- ABSTRACT -- There is a race condition between btree_xlog_unlink_page and _bt_walk_left. A lot of versions are affected including 12 and new-coming 13. Happens only on standby. Seems like could not cause invalid query results. -- REMARK -- While working on

Re: row filtering for logical replication

On 3/3/20 12:39 PM, David Steele wrote: Hi Euler, On 1/21/20 2:32 AM, Craig Ringer wrote: On Fri, 17 Jan 2020 at 07:58, Euler Taveira wrote: Em qui., 16 de jan. de 2020 às 18:57, Tomas Vondra escreveu: Euler, this patch is still in "waiting on author" since 11/25. Do you plan to review

Re: Parallel leader process info in EXPLAIN

Hi Thomas, On 1/26/20 7:03 PM, Thomas Munro wrote: Fair point. I will look into that. Are you still planning on looking at this patch for PG13? Based on the current state (002 abandoned, 001 needs total rework) I'd say it should just be Returned with Feedback or Closed for now. Regards,

Re: VACUUM memory management

On 1/28/20 1:36 PM, Ibrar Ahmed wrote: On Wed, Jan 22, 2020 at 11:17 AM k.jami...@fujitsu.com I might have missed something more, but I'll continue reviewing after the rebased patch. Yes, I am working on that. I will send the rebased and updated patch. This patch has not had

Re: ALTER tbl rewrite loses CLUSTER ON index

On Mon, Mar 16, 2020 at 04:01:42PM +0900, Amit Langote wrote: > I came across a commit that recently went in: > > commit 1cc9c2412cc9a2fbe6a381170097d315fd40ccca > Author: Peter Eisentraut > Date: Fri Mar 13 11:28:11 2020 +0100 > > Preserve replica identity index across ALTER TABLE

Re: Libpq support to connect to standby server as priority

On 2/28/20 11:05 AM, Alvaro Herrera wrote: MauMau, Greg, is any of you submitting a new patch for this? This patch has not had any updates in months and now we are halfway through the CF so I have marked it Returned with Feedback. If a patch arrives soon I'll be happy to revive the entry,

Re: [PATCH] kNN for btree

On Wed, Mar 4, 2020 at 2:39 PM Alexander Korotkov wrote: > On Wed, Mar 4, 2020 at 4:58 AM Peter Geoghegan wrote: > > On Mon, Mar 2, 2020 at 1:27 PM Alexander Korotkov > > wrote: > > > I've rebased the patchset to the current master and made some > > > refactoring. I hope it would be possible

Re: Online checksums verification in the backend

On Mon, Mar 16, 2020 at 09:42:39AM +0100, Julien Rouhaud wrote: > On Mon, Mar 16, 2020 at 01:53:35PM +0900, Masahiko Sawada wrote: > > > > In addition to comments from Michael-san, here are my comments: Thanks both for the reviews. I'm attaching a v3 with all comments addressed, except: > It

Re: improve transparency of bitmap-only heap scans

On Tue, Mar 10, 2020 at 12:15 PM David Steele wrote: > > Hi Jeff, > > On 2/7/20 10:22 AM, Alexey Bashtanov wrote: > > I've changed it all to "unfetched" for at least not to call the same > > thing differently > > in the code and in the output, and also rebased it and fit in 80 lines > > width

Re: WIP/PoC for parallel backup

Hi Asif, On testing further, I found when taking backup with -R, pg_basebackup crashed this crash is not consistently reproducible. [edb@localhost bin]$ ./psql postgres -p 5432 -c "create table test (a text);" CREATE TABLE [edb@localhost bin]$ ./psql postgres -p 5432 -c "insert into test values

Re: adding partitioned tables to publications

I was trying to extract some preparatory work from the remaining patches and came up with the attached. This is part of your patch 0003, but also relevant for part 0004. The problem was that COPY (SELECT *) is not sufficient when the table has generated columns, so we need to build the

Re: Berserk Autovacuum (let's save next Mandrill)

On Mon, Mar 16, 2020 at 12:53:43PM +0900, Masahiko Sawada wrote: > There is already a consensus on introducing new 2 parameters, but as > the second idea I'd like to add one (or two) GUC(s) to my suggestion, > say autovacuum_vacuum_freeze_insert_ratio; this parameter is the ratio > of the number

Re: [PATCH] Connection time for \conninfo

On 3/14/20 3:16 PM, Rodrigo Ramírez Norambuena wrote: I forgot about that ... It passed a little time from my new pushed changes. So go ahead :) This patch has been returned with feedback. Please feel free to resubmit in a future CF when you believe the feedback has been addressed.

Re: Replication & recovery_min_apply_delay

A key challenge here is how to determine the starting point for WAL receiver when the startup process starts it while still replaying WAL that's already received. Hao and I wrote a much faster and less intrusive solution to determine the starting point. Scan the first page of each WAL segment

Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

On Sat, 14 Mar 2020 at 03:06, Tom Lane wrote: > Looking again at the generated configure code, I realize I shouldn't have > left off the ACTION-IF-NOT-FOUND argument --- the default is to > throw an error, but we'd rather fall through and try to use xml2-config. > The eventual AC_CHECK_LIB(xml2,

Re: v13 latest snapshot build error

On Wed, 2020-03-11 at 22:52 -0400, Tom Lane wrote: > Artur Zakirov writes: > > I'm not familiar with the patch itself. But I think there is just a lack > > of the comma here, after ", /tmp" :-) > > [ blink... ] There definitely is a comma there in the version of the > patch that's in the

Re: backup manifests

On 3/14/20 2:04 AM, Robert Haas wrote: OK. Done in the attached version Thanks. Verified. -- regards,tushar EnterpriseDB https://www.enterprisedb.com/ The Enterprise PostgreSQL Company

Re: [Proposal] Global temporary tables

> 2020年3月16日 下午5:31，Prabhat Sahu 写道： > > > > On Mon, Mar 16, 2020 at 1:30 PM Konstantin Knizhnik > mailto:k.knizh...@postgrespro.ru>> wrote: > > It seems to be expected behavior: GTT data is private to the session and > postgres_fdw establish its own session where content of the table is

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Mon, Mar 16, 2020 at 11:56 AM Kuntal Ghosh wrote: > > On Mon, Mar 16, 2020 at 9:43 AM Dilip Kumar wrote: > > On Mon, Mar 16, 2020 at 8:57 AM Masahiko Sawada > > wrote: > > > IsRelationExtensionLockHeld and IsPageLockHeld are used only when > > > assertion is enabled. So how about making

Re: [Proposal] Global temporary tables

On Mon, Mar 16, 2020 at 1:30 PM Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > It seems to be expected behavior: GTT data is private to the session and > postgres_fdw establish its own session where content of the table is empty. > But if you insert some data in f_gtt1, then you will

Re: [Proposal] Global temporary tables

> 2020年3月16日 下午5:04，Pavel Stehule 写道： > > > > po 16. 3. 2020 v 9:58 odesílatel tushar > napsal: > Hi Wenjing, > > I have created a global table on X session but i am not able to drop from Y > session ? > > X session - ( connect to psql terminal ) >

Re: [Proposal] Global temporary tables

> 2020年3月16日 下午4:58，tushar 写道： > > Hi Wenjing, > > I have created a global table on X session but i am not able to drop from Y > session ? > > X session - ( connect to psql terminal ) > postgres=# create global temp table foo(n int); > CREATE TABLE > postgres=# select * from foo; > n >

Re: [Proposal] Global temporary tables

po 16. 3. 2020 v 9:58 odesílatel tushar napsal: > Hi Wenjing, > > I have created a global table on X session but i am not able to drop from > Y session ? > > X session - ( connect to psql terminal ) > postgres=# create global temp table foo(n int); > CREATE TABLE > postgres=# select * from foo;

Re: [Proposal] Global temporary tables

Hi Wenjing, I have created a global table on X session but i am not able to drop from Y session ? X session - ( connect to psql terminal ) postgres=# create global temp table foo(n int); CREATE TABLE postgres=# select * from foo;  n --- (0 rows) Y session - ( connect to psql terminal )

Re: WIP/PoC for parallel backup

Hi Asif, > Thanks Rajkumar. I have fixed the above issues and have rebased the patch > to the latest master (b7f64c64). > (V9 of the patches are attached). > I had a further review of the patches and here are my few observations: 1. +/* + * stop_backup() - ends an online backup + * + * The

Re: [HACKERS] [PATCH] Generic type subscripting

st 4. 3. 2020 v 18:04 odesílatel Dmitry Dolgov <9erthali...@gmail.com> napsal: > > On Tue, Mar 03, 2020 at 12:55:38PM -0500, David Steele wrote: > > > > > Yep, I wasn't paying much attention recently to this patch, will post > > > rebased and fixed version soon. > > > > The last CF for PG13 has

Re: Online checksums verification in the backend

On Mon, Mar 16, 2020 at 01:53:35PM +0900, Masahiko Sawada wrote: > > In addition to comments from Michael-san, here are my comments: > > 1. > + if (!is_member_of_role(GetUserId(), DEFAULT_ROLE_READ_SERVER_FILES)) > + ereport(ERROR, > +

Re: Online checksums verification in the backend

Thanks for the review Michael! On Mon, Mar 16, 2020 at 12:29:28PM +0900, Michael Paquier wrote: > On Wed, Mar 11, 2020 at 08:18:23AM +0100, Julien Rouhaud wrote: > > The cfbot reported a build failure, so here's a rebased v2 which also > > contains > > the pg_stat_report_failure() call and extra

Re: [Proposal] Global temporary tables

> 2020年3月16日 下午2:23，Prabhat Sahu 写道： > > Hi Wenjing, > Please check the below scenario, where the Foreign table on GTT not showing > records. > > postgres=# create extension postgres_fdw; > CREATE EXTENSION > postgres=# do $d$ > begin > execute $$create server fdw foreign data

Re: [Proposal] Global temporary tables

On 16.03.2020 9:23, Prabhat Sahu wrote: Hi Wenjing, Please check the below scenario, where the Foreign table on GTT not showing records. postgres=# create extension postgres_fdw; CREATE EXTENSION postgres=# do $d$     begin         execute $$create server fdw foreign data wrapper

Re: Collation versioning

On Thu, Mar 12, 2020 at 03:00:26PM +0100, Julien Rouhaud wrote: > And v15 due to conflict with b08dee24a5 (Add pg_dump support for ALTER obj > DEPENDS ON EXTENSION). I have looked at patches 0001~0003 in the set for now. 0001 looks clean to me. In patch 0002, you have the following addition: @@

Re: Berserk Autovacuum (let's save next Mandrill)

On Mon, 2020-03-16 at 12:53 +0900, Masahiko Sawada wrote: > There is already a consensus on introducing new 2 parameters, but as > the second idea I'd like to add one (or two) GUC(s) to my suggestion, > say autovacuum_vacuum_freeze_insert_ratio; this parameter is the ratio > of the number of

Re: add types to index storage params on doc

Thanks for your comments! On Mon, Mar 16, 2020 at 11:49 AM Fujii Masao wrote: > -buffering > +buffering (string) > > Isn't it better to use "enum" rather than "string"? > In the docs about enum GUC parameters, "enum" is used there. > Agreed. I've fixed it to "enum". But I'm now

Re: Internal key management system

On Thu, 12 Mar 2020 at 08:13, Bruce Momjian wrote: > > On Fri, Mar 6, 2020 at 03:31:00PM +0900, Masahiko Sawada wrote: > > On Fri, 6 Mar 2020 at 15:25, Moon, Insung > > wrote: > > > > > > Dear Sawada-san > > > > > > I don't know if my environment or email system is weird, but the V5 > > >

  1   2   >