Re: SyncRepLock acquired exclusively in default configuration

On Wed, 12 Aug 2020 at 14:06, Asim Praveen wrote: > > > > > On 11-Aug-2020, at 8:57 PM, Robert Haas wrote: > > > > I think this gets to the root of the issue. If we check the flag > > without a lock, we might see a slightly stale value. But, considering > > that there's no particular amount of ti

Re: Handing off SLRU fsyncs to the checkpointer

On Sat, Aug 8, 2020 at 2:44 AM Robert Haas wrote: > On Wed, Aug 5, 2020 at 2:01 AM Thomas Munro wrote: > > * Master is around 11% faster than last week before commit c5315f4f > > "Cache smgrnblocks() results in recovery." > > * This patch gives a similar speedup, bringing the total to around 25%

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

Thanks for helping with this. On Wed, Aug 12, 2020 at 01:54:38PM +0900, Michael Paquier wrote: > +++ b/src/backend/catalog/index.c > @@ -3661,20 +3662,12 @@ reindex_relation(Oid relid, int flags, int options) > + elog(ERROR, "unsupported relation kind for relation \"%s\"", > +

Re: SyncRepLock acquired exclusively in default configuration

> On 11-Aug-2020, at 8:57 PM, Robert Haas wrote: > > I think this gets to the root of the issue. If we check the flag > without a lock, we might see a slightly stale value. But, considering > that there's no particular amount of time within which configuration > changes are guaranteed to take e

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

On Sun, Aug 09, 2020 at 06:44:23PM -0500, Justin Pryzby wrote: > On Sun, Aug 09, 2020 at 02:00:09PM +0900, Michael Paquier wrote: >> For now, I would recommend to focus first on 0001 to add support for >> partitioned tables and indexes to REINDEX. CIC is much more >> complicated btw, but I am not

Re: Parallel copy

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, failed Hi, I don't claim to yet understand all of the Postgres inte

RE: Can I test Extended Query in core test framework

Tatsuo Ishii san, a committer, proposed this to test extended query protocol. Can it be included in Postgres core? A toool to test programs by issuing frontend/backend protocol messages https://github.com/tatsuo-ishii/pgproto Regards Takayuki Tsunakawa

Re: Can I test Extended Query in core test framework

On Tue, Aug 11, 2020 at 11:22 PM Tom Lane wrote: > Andy Fan writes: > > I want to write some test cases with extended query in core test system. > > Why? (That is, what is it you need to test exactly?) > > Thanks for your attention. The background is I hacked exec_bind_message[1], then I want

Re: Allows Extend Protocol support CURSOR_OPT_HOLD with prepared stmt.

On Mon, Jul 27, 2020 at 11:57 AM Andy Fan wrote: > >> 2. Currently I want to add a new GUC parameter, if set it to true, server >> will >> create a holdable portal, or else nothing changed. Then let the user set >> it to true in the above case and reset it to false afterward. Is there >> any is

Re: public schema default ACL

On Mon, Aug 10, 2020 at 10:21:06AM +0200, Magnus Hagander wrote: > On Thu, Aug 6, 2020 at 3:34 PM Stephen Frost wrote: > > Not sure how much it happens in these days of docker and containers, but > > certainly it was common at one point to have home directories > > automatically created on login.

Re: Can I test Extended Query in core test framework

Thank you Ashutosh for your reply. On Tue, Aug 11, 2020 at 9:06 PM Ashutosh Bapat wrote: > You could run PREPARE and EXECUTE as SQL commands from psql. Please > take a look at the documentation of those two commands. I haven't > looked at TAP infrastructure, but you could open a psql session to

Re: Improving connection scalability: GetSnapshotData()

On Wed, Aug 12, 2020 at 12:19 PM Andres Freund wrote: > On 2020-07-29 19:20:04 +1200, Thomas Munro wrote: > > On Wed, Jul 29, 2020 at 6:15 PM Thomas Munro wrote: > > > +static inline FullTransactionId > > > +FullXidViaRelative(FullTransactionId rel, TransactionId xid) > > > > > > I'm struggling t

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-07-29 19:20:04 +1200, Thomas Munro wrote: > On Wed, Jul 29, 2020 at 6:15 PM Thomas Munro wrote: > > +static inline FullTransactionId > > +FullXidViaRelative(FullTransactionId rel, TransactionId xid) > > > > I'm struggling to find a better word for this than "relative". > > The best I

Re: [BUG] Error in BRIN summarization

On 2020-Jul-23, Anastasia Lubennikova wrote: > This error is caused by the problem with root_offsets array bounds. It > occurs if a new HOT tuple was inserted after we've collected root_offsets, > and thus we don't have root_offset for tuple's offnum. Concurrent insertions > are possible, because

Re: [BUG] Error in BRIN summarization

On 2020-Jul-30, Anastasia Lubennikova wrote: > While testing this fix, Alexander Lakhin spotted another problem. I > simplified  the test case to this: Ah, good catch. I think a cleaner way to fix this problem is to just consider the range as not summarized and return NULL from there, as in the

Re: Inconsistent behavior of smart shutdown handling for queries with and without parallel workers

Bharath Rupireddy writes: > In case of smart shutdown postmaster receives SIGTERM from the pg_ctl, > it "disallows new connections, but lets existing sessions end their > work normally". Which means that it doesn't abort any ongoing txns in > any of the sessions and it lets the sessions to exit(on

Re: doc examples for pghandler

On Mon, Jun 15, 2020 at 04:47:01PM +0900, Michael Paquier wrote: > On Sun, Jun 14, 2020 at 08:45:17PM -0700, Mark Wong wrote: > > Sounds good to me. Something more like the attached patch? > > That's the idea. I have not gone in details into what you have here, > but perhaps it would make sense

Re: [PATCH] Covering SPGiST index

вт, 11 авг. 2020 г. в 12:11, Pavel Borisov : > I added changes in documentation into the patch. > > > -- > Best regards, > Pavel Borisov > > Postgres Professional: http://postgrespro.com > v5-0001-Covering-SP-GiST-index-support-for-INCLUDE-column.patch Description: B

Re: EDB builds Postgres 13 with an obsolete ICU version

Jaime Casanova schrieb am 11.08.2020 um 20:39: As a follow-up to bug #16570 [1] and other previous discussions on the mailing-lists, I'm checking out PG13 beta for Windows from: https://www.enterprisedb.com/postgresql-early-experience and it ships with the same obsolete ICU 53 that was used for

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On Tue, Aug 11, 2020 at 11:14 AM Tom Lane wrote: > > James Coleman writes: > > Why is a CIC in active index-building something we need to wait for? > > Wouldn't it fall under a similar kind of logic to the other snapshot > > types we can explicitly ignore? CIC can't be run in a manual > > transac

Re: EDB builds Postgres 13 with an obsolete ICU version

On Mon, 3 Aug 2020 at 13:56, Daniel Verite wrote: > > Hi, > > As a follow-up to bug #16570 [1] and other previous discussions > on the mailing-lists, I'm checking out PG13 beta for Windows > from: > https://www.enterprisedb.com/postgresql-early-experience > and it ships with the same obsolete IC

Re: autovac issue with large number of tables

Jim Nasby writes: > Without reading the 100+ emails or the 260k patch, I'm guessing that it > won't help because the problem I observed was spending most of it's time in >   42.62% postgres  [.] hash_search_with_hash_value > I don't see how moving things to shared memory would help that

Re: massive FPI_FOR_HINT load after promote

On 2020-Aug-11, Masahiko Sawada wrote: > On Tue, 11 Aug 2020 at 07:56, Alvaro Herrera wrote: > > So if you have some table where tuples gain hint bits in bulk, and > > rarely modify the pages afterwards, and promote before those pages are > > frozen, then you may end up with a massive amount of

Re: massive FPI_FOR_HINT load after promote

On Tue, Aug 11, 2020 at 2:55 AM Masahiko Sawada wrote: > > On Tue, 11 Aug 2020 at 07:56, Alvaro Herrera wrote: > > > > Last week, James reported to us that after promoting a replica, some > > seqscan was taking a huge amount of time; on investigation he saw that > > there was a high rate of FPI_F

Re: Can I test Extended Query in core test framework

Hi, On 2020-08-11 11:22:49 -0400, Tom Lane wrote: > I recall someone (Andres, possibly) speculating about building a tool > specifically to exercise low-level protocol issues, but that hasn't > been done either. Yea, I mentioned the possibility, but didn't plan to work on it. I am not a perl pers

Re: Make contrib modules' installation scripts more secure.

Christoph Berg writes: > I think this change neglected to add plpgsql to the extension > dependencies in the .control file: Adding plpgsql to the extension's dependencies would be a cure worse than the disease: it'd mean that you could not remove plpgsql from the system after installing cube, eit

Re: SyncRepLock acquired exclusively in default configuration

On Tue, Aug 11, 2020 at 7:55 AM Asim Praveen wrote: > There is no out-of-order execution hazard in the scenario you are describing, > memory barriers don’t seem to fit. Using locks to synchronise checkpointer > process and a committing backend process is the right way. We have made a > consci

Re: Can I test Extended Query in core test framework

Andy Fan writes: > I want to write some test cases with extended query in core test system. Why? (That is, what is it you need to test exactly?) psql has no ability to issue extended queries AFAIR, so the normal regression test scripts can't exercise this. We haven't built anything for it in t

Re: remove spurious CREATE INDEX CONCURRENTLY wait

James Coleman writes: > Why is a CIC in active index-building something we need to wait for? > Wouldn't it fall under a similar kind of logic to the other snapshot > types we can explicitly ignore? CIC can't be run in a manual > transaction, so the snapshot it holds won't be used to perform > arbi

Re: Switch to multi-inserts for pg_depend

On Tue, Aug 11, 2020 at 1:59 AM Michael Paquier wrote: > On Mon, Aug 10, 2020 at 05:32:21PM -0700, Andres Freund wrote: > > Do we really want to end up with several separate defines for different > > type of catalog batch inserts? That doesn't seem like a good > > thing. Think there should be a si

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

On Tue, Aug 11, 2020 at 7:33 PM Robert Haas wrote: > > On Tue, Aug 11, 2020 at 3:39 AM Ashutosh Sharma wrote: > > The other two messages for reporting unused items and dead items > > remain the same. Hence, with above change, we would be reporting the > > following 4 messages: > > > > NOTICE: sk

Re: Parallel worker hangs while handling errors.

On Fri, Aug 7, 2020 at 1:34 AM Robert Haas wrote: > > On Tue, Jul 28, 2020 at 5:35 AM Bharath Rupireddy > wrote: > > The v4 patch looks good to me. Hang is not seen, make check and make > > check-world passes. I moved this to the committer for further review > > in https://commitfest.postgresql.o

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

On Tue, Aug 11, 2020 at 3:39 AM Ashutosh Sharma wrote: > The other two messages for reporting unused items and dead items > remain the same. Hence, with above change, we would be reporting the > following 4 messages: > > NOTICE: skipping all the tids in block %u for relation "%s" because > the bl

Inconsistent behavior of smart shutdown handling for queries with and without parallel workers

Hi, In case of smart shutdown postmaster receives SIGTERM from the pg_ctl, it "disallows new connections, but lets existing sessions end their work normally". Which means that it doesn't abort any ongoing txns in any of the sessions and it lets the sessions to exit(on their own) and then the postm

Re: Can I test Extended Query in core test framework

You could run PREPARE and EXECUTE as SQL commands from psql. Please take a look at the documentation of those two commands. I haven't looked at TAP infrastructure, but you could open a psql session to a running server and send an arbitrary number of SQL queries through it. Said that a server start

Re: EDB builds Postgres 13 with an obsolete ICU version

On Tue, Aug 4, 2020 at 11:42 AM Dave Page wrote: > > > On Tue, Aug 4, 2020 at 10:29 AM Magnus Hagander > wrote: > >> On Tue, Aug 4, 2020 at 10:07 AM Dave Page wrote: >> >>> >>> >>> On Tue, Aug 4, 2020 at 1:04 AM Bruce Momjian wrote: >>> On Mon, Aug 3, 2020 at 08:56:06PM +0200, Daniel Ver

Re: SyncRepLock acquired exclusively in default configuration

The proposed fix looks good, it resolves the lock contention problem as intended. +1 from my side. > On 09-Jul-2020, at 4:22 PM, Fujii Masao wrote: > > > Regarding how to fix, don't we need memory barrier when reading > sync_standbys_defined? Without that, after SyncRepUpdateSyncStandbysDefine

Re: Make contrib modules' installation scripts more secure.

Re: To PostgreSQL Hackers > I think this change neglected to add plpgsql to the extension > dependencies in the .control file: > > 12:53:51 # Failed test 'psql -qc 'CREATE EXTENSION "cube"'' > 12:53:51 # at t/TestLib.pm line 213. > 12:53:51 not ok 68 - psql -qc 'CREATE EXTENSION "cube"' > 12:5

Re: Add session statistics to pg_stat_database

On Thu, 2020-07-23 at 18:16 +0500, Ahsan Hadi wrote: > On Wed, Jul 8, 2020 at 4:17 PM Laurenz Albe wrote: > > Here is a patch that adds the following to pg_stat_database: > > - number of connections > > Is it expected behaviour to not count idle connections? The connection is > included after it

Re: Make contrib modules' installation scripts more secure.

I think this change neglected to add plpgsql to the extension dependencies in the .control file: 12:53:51 # Failed test 'psql -qc 'CREATE EXTENSION "cube"'' 12:53:51 # at t/TestLib.pm line 213. 12:53:51 not ok 68 - psql -qc 'CREATE EXTENSION "cube"' 12:53:51 # got: '1' 12:53:51 #

Re: psql: add \si, \sm, \st and \sr functions to show CREATE commands for indexes, matviews, triggers and tables

On 2020-07-28 20:46, a.pervush...@postgrespro.ru wrote: I've attached a patch that implements \si, \sm, \st and \sr functions that show the CREATE command for indexes, matviews, triggers and tables. The functions are implemented similarly to the existing sf/sv functions with some modifications.

Re: Add information to rm_redo_error_callback()

On Tue, 11 Aug 2020 at 15:30, Michael Paquier wrote: > > On Tue, Aug 11, 2020 at 02:45:50PM +0900, Masahiko Sawada wrote: > > Thank you for updating the patch! > > > > The patch looks good to me. I've set this patch as Ready for Committer. > > + for (block_id = 0; block_id <= record->max_blo

Re: [PATCH] Covering SPGiST index

I added changes in documentation into the patch. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com v4-0001-Covering-SP-GiST-index-support-for-INCLUDE-column.patch Description: Binary data

RE: Libpq support to connect to standby server as priority

Hi Greg, I was able to successfully execute all the tests of the v17-0001 patch. But I do have a couple of additional review comments about the test code. COMMENT - missing "any" tests In my earlier code review (previous email) I suggested that "any" should be added as valid option to th

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

On Fri, Aug 7, 2020 at 9:21 PM Robert Haas wrote: > > On Thu, Aug 6, 2020 at 9:23 AM Ashutosh Sharma wrote: > There's a certain inconsistency to these messages: > > rhaas=# create table foo (a int); > CREATE TABLE > rhaas=# insert into foo values (1); > INSERT 0 1 > rhaas=# select heap_force_kill

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Tue, Aug 11, 2020 at 02:39:45PM +0900, Michael Paquier wrote: > so I have removed that part, and applied the patch. Thank you > > The rest of your patch looks fine. In my mind, REINDEX(CONCURRENTLY) was > > the > > "new way" to write things, and it's what's easy to support, so I think I > >