Re: Physical replication slot advance is not persistent

At Wed, 25 Dec 2019 20:28:04 +0300, Alexey Kondratov wrote in > > Yep, it helps with physical replication slot persistence after > > advance, but the whole validation (moveto <= endlsn) does not make > > sense for me. The value of moveto should be >= than minlsn == > > confirmed_flush /

Calling PLpgSQL function with composite type fails with an error: "ERROR: could not open relation with OID ..."

Hi All, When the following test-case is executed on master, it fails with an error: "ERROR: could not open relation with OID ..." -- create a test table: create table tab1(a int, b text); -- create a test function: create or replace function f1() returns void as $$ declare var1 tab1; begin

Re: Expose lock group leader pid in pg_stat_activity

Hello I doubt that "Process ID of the lock group leader" is enough for user documentation. I think we need note: - this field is related to parallel query execution - leader_pid = pid if process is parallel leader - leader_pid would point to pid of the leader if process is parallel worker -

Re: Expose lock group leader pid in pg_stat_activity

On Thu, Dec 26, 2019 at 10:20 AM Guillaume Lelarge wrote: > > Le jeu. 26 déc. 2019 à 09:49, Julien Rouhaud a écrit : >> >> On Thu, Dec 26, 2019 at 9:08 AM Guillaume Lelarge >> wrote: >> > >> > Le mer. 25 déc. 2019 à 19:30, Julien Rouhaud a écrit : >> >> >> >> On Wed, Dec 25, 2019 at 7:03 PM

Re: Calling PLpgSQL function with composite type fails with an error: "ERROR: could not open relation with OID ..."

The issue here is that PLpgSQL_rec structure being updated by revalidate_rectypeid() is actually a local/duplicate copy of the PLpgSQL_rec structure available in plpgsql_HashTable (refer to copy_plpgsql_datums() where you would notice that if datum type is PLPGSQL_DTYPE_REC we actually mempcy()

Re: Expose lock group leader pid in pg_stat_activity

Le jeu. 26 déc. 2019 à 09:49, Julien Rouhaud a écrit : > On Thu, Dec 26, 2019 at 9:08 AM Guillaume Lelarge > wrote: > > > > Le mer. 25 déc. 2019 à 19:30, Julien Rouhaud a > écrit : > >> > >> On Wed, Dec 25, 2019 at 7:03 PM Julien Rouhaud > wrote: > >> > > >> > Guillaume (in Cc) recently

Re: table partition and column default

Fuji-san, On Thu, Dec 26, 2019 at 7:12 AM Fujii Masao wrote: > > On Wed, Dec 25, 2019 at 5:47 PM Amit Langote wrote: > > > > On Wed, Dec 25, 2019 at 5:40 PM Fujii Masao wrote: > > > On Wed, Dec 25, 2019 at 1:56 PM Amit Langote > > > wrote: > > > > IIRC, there was some discussion about

Re: Minimal logical decoding on standbys

On Tue, 24 Dec 2019 at 14:02, Amit Khandekar wrote: > > On Thu, 19 Dec 2019 at 01:02, Rahila Syed wrote: > > > > Hi, > > > >> Hi, do you consistently get this failure on your machine ? I am not > >> able to get this failure, but I am going to analyze when/how this can > >> fail. Thanks > >> > >

Re: [HACKERS] Restricting maximum keep segments by repslots

At Tue, 24 Dec 2019 21:26:14 +0900 (JST), Kyotaro Horiguchi wrote in > The attached v17 patch is changed in the follwing points. > > - Rebased to the current master. > > - Change KeepLogSeg not to emit the message "Slot %s lost %ld > segment(s)" if the slot list is not changed. > > -

Re: Expose lock group leader pid in pg_stat_activity

Le jeu. 26 déc. 2019 à 10:26, Julien Rouhaud a écrit : > On Thu, Dec 26, 2019 at 10:20 AM Guillaume Lelarge > wrote: > > > > Le jeu. 26 déc. 2019 à 09:49, Julien Rouhaud a > écrit : > >> > >> On Thu, Dec 26, 2019 at 9:08 AM Guillaume Lelarge > >> wrote: > >> > > >> > Le mer. 25 déc. 2019 à

Re: Expose lock group leader pid in pg_stat_activity

On Thu, Dec 26, 2019 at 9:08 AM Guillaume Lelarge wrote: > > Le mer. 25 déc. 2019 à 19:30, Julien Rouhaud a écrit : >> >> On Wed, Dec 25, 2019 at 7:03 PM Julien Rouhaud wrote: >> > >> > Guillaume (in Cc) recently pointed out [1] that it's currently not >> > possible to retrieve the list of

Re: [HACKERS] WAL logging problem in 9.4.3?

Hello, Noah. At Wed, 25 Dec 2019 20:22:04 -0800, Noah Misch wrote in > On Thu, Dec 26, 2019 at 12:46:39PM +0900, Kyotaro Horiguchi wrote: > > At Wed, 25 Dec 2019 16:15:21 -0800, Noah Misch wrote in > > > Skip AssertPendingSyncs_RelationCache() at abort, like v24nm did. > > > Making > > >

Re: Expose lock group leader pid in pg_stat_activity

Hello, On Thu, Dec 26, 2019 at 12:18 PM Sergei Kornilov wrote: > > I doubt that "Process ID of the lock group leader" is enough for user > documentation. I think we need note: > - this field is related to parallel query execution > - leader_pid = pid if process is parallel leader > - leader_pid

Fix comment typos.

Hello. I found that confirmed_flush in ReplicationSlot (PersistentData) is pointed with a wrong name in the comments in slotfuncs.c The attaches fixes that. regards. -- Kyotaro Horiguchi NTT Open Source Software Center diff --git a/src/backend/replication/slotfuncs.c

Re: error context for vacuum to include block number

On Tue, Dec 24, 2019 at 01:19:09PM +0900, Michael Paquier wrote: > (Please note that I have not indented yet the patch.) And one indentation later, committed this one after an extra lookup as of 1ab41a3. -- Michael signature.asc Description: PGP signature

Re: Expose lock group leader pid in pg_stat_activity

Le mer. 25 déc. 2019 à 19:30, Julien Rouhaud a écrit : > On Wed, Dec 25, 2019 at 7:03 PM Julien Rouhaud wrote: > > > > Guillaume (in Cc) recently pointed out [1] that it's currently not > > possible to retrieve the list of parallel workers for a given backend > > at the SQL level. His use case

Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema

On Thu, 26 Dec 2019 at 19:23, Michael Paquier wrote: > > On Wed, Dec 25, 2019 at 12:24:10PM +0900, Michael Paquier wrote: > > Arf. Yes, this had better be isAnyTempNamespace() so as we complain > > about all of them. > > Okay, finally coming back to that. Attached is an updated patch with >

Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema

Mahendra Singh writes: > I think, we can add a regression test for this. > postgres=# create temporary table temp(c1 int); > CREATE TABLE > postgres=# drop schema pg_temp_3 cascade ; > ERROR: cannot drop temporary namespace "pg_temp_3" > postgres=# No, we can't, because the particular temp

Re: Add support for automatically updating Unicode derived files

On 2019-12-19 23:48, John Naylor wrote: I gave "make update-unicode" a try. It's unclear to me what the state of the build tree should be when a maintainer runs this, so I'll just report what happens when running naively (on MacOS). Yeah, that wasn't fully thought through, it appears. After

Re: proposal: schema variables

Hi fresh rebase Regards Pavel schema-variables-20191226.patch.gz Description: application/gzip

Re: [HACKERS] Block level parallel vacuum

On Wed, 25 Dec 2019 at 17:47, Masahiko Sawada wrote: > > On Tue, 24 Dec 2019 at 15:46, Masahiko Sawada > wrote: > > > > On Tue, 24 Dec 2019 at 15:44, Amit Kapila wrote: > > > > > > On Tue, Dec 24, 2019 at 12:08 PM Masahiko Sawada > > > wrote: > > > > > > > > > > > > The first patches look good

Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence

24.12.2019 19:08, Alvaro Herrera wrote: @@ -106,6 +106,18 @@ CREATE OPERATOR CLASS name [ DEFAUL + +NOT BITWISE + + + If present, the operator class equality is not the same as equivalence. + For example, two numerics can compare equal but have

Re: table partitioning and access privileges

Fujii Masao writes: > My customer reported me that the queries through a partitioned table > ignore each partition's SELECT, INSERT, UPDATE, and DELETE privileges, > on the other hand, only TRUNCATE privilege specified for each partition > is applied. I'm not sure if this behavior is expected or

Re: Fix comment typos.

On Thu, Dec 26, 2019 at 05:59:19PM +0900, Kyotaro Horiguchi wrote: > I found that confirmed_flush in ReplicationSlot (PersistentData) is > pointed with a wrong name in the comments in slotfuncs.c Committed, thanks! -- Michael signature.asc Description: PGP signature

Re: Physical replication slot advance is not persistent

On 26.12.2019 11:33, Kyotaro Horiguchi wrote: At Wed, 25 Dec 2019 20:28:04 +0300, Alexey Kondratov wrote in Yep, it helps with physical replication slot persistence after advance, but the whole validation (moveto <= endlsn) does not make sense for me. The value of moveto should be >= than

Re: error context for vacuum to include block number

On Tue, Dec 24, 2019 at 01:19:09PM +0900, Michael Paquier wrote: > On Mon, Dec 23, 2019 at 07:24:28PM -0600, Justin Pryzby wrote: > > I renamed. > > Hmm. I have found what was partially itching me for patch 0002, and > that's actually the fact that we don't do the error reporting for heap >

Re: MSYS2 support

On 2019-12-12 22:11, Peter Eisentraut wrote: You can also build natively on MSYS2, using the existing Cygwin support. Except that it won't work because configure doesn't recognize the config.guess output. Attached are a couple of small patches to fix that up. The first patch fixes configure

Re: Disallow cancellation of waiting for synchronous replication

On 25.12.2019 13:45, Andrey Borodin wrote: 25 дек. 2019 г., в 15:28, Maksim Milyutin написал(а): Synchronous replication does not guarantee that a committed write is actually on any replica, but it does in general guarantee that a commit has been replicated before sending a response to the

Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema

On Wed, Dec 25, 2019 at 12:24:10PM +0900, Michael Paquier wrote: > Arf. Yes, this had better be isAnyTempNamespace() so as we complain > about all of them. Okay, finally coming back to that. Attached is an updated patch with polished comments and the fixed logic. -- Michael diff --git

[PATCH] fix a performance issue with multiple logical-decoding walsenders

Hello Our current setup uses logical replication to build a BI replication server along our primary clusters (running PG 10.10 so far). This implies having one logical replication slot per database. After some analysis, we identified two hot spots behind this issue. Fixing them gave us a 10

Re: Rearranging ALTER TABLE to avoid multi-operations bugs

I wrote: >> [ fix-alter-table-order-of-operations-1.patch ] > The cfbot noticed that this failed to apply over a recent commit, > so here's v2. No substantive changes. Another rebase required :-(. Still no code changes from v1, but this time I remembered to add a couple more test cases that I'd

Re: [PATCH] fix a performance issue with multiple logical-decoding walsenders

Hello Pierre, On Thu, Dec 26, 2019 at 5:43 PM Pierre Ducroquet wrote: > > The second one was tested on PG 10 and PG 12 (with 48 lines offset). It has on > PG12 the same effect it has on a PG10+isAlive patch. Instead of calling each > time GetFlushRecPtr, we call it only if we notice we have

Re: [HACKERS] Block level parallel vacuum

Hi, On Wed, Dec 25, 2019 at 09:17:16PM +0900, Masahiko Sawada wrote: On Tue, 24 Dec 2019 at 15:46, Masahiko Sawada wrote: On Tue, 24 Dec 2019 at 15:44, Amit Kapila wrote: > > On Tue, Dec 24, 2019 at 12:08 PM Masahiko Sawada > wrote: > > > > > > The first patches look good to me. I'm

Re: Autovacuum on partitioned table

Hi, As Laurenz commented in this thread, I tried adding option to update parent's statistics during Autovacuum. To do that, I propose supporting 'autovacuum_enabled' option already exists on partitioned tables. In the attached patch, you can use 'autovacuum_enabled' option on partitioned table

Re: Calling PLpgSQL function with composite type fails with an error: "ERROR: could not open relation with OID ..."

Ashutosh Sharma writes: > Okay. Thanks for that fix. You've basically forced > revalidate_rectypeid() to update the PLpgSQL_rec's rectypeid > irrespective of typcache entry requires re-validation or not. Right. The assignment is cheap enough that it hardly seems worth avoiding.

Re: Calling PLpgSQL function with composite type fails with an error: "ERROR: could not open relation with OID ..."

On Fri, Dec 27, 2019 at 1:59 AM Tom Lane wrote: > > Ashutosh Sharma writes: > > The issue here is that PLpgSQL_rec structure being updated by > > revalidate_rectypeid() is actually a local/duplicate copy of the > > PLpgSQL_rec structure available in plpgsql_HashTable (refer to > >

Re: ALTER INDEX fails on partitioned index

On Mon, Jan 07, 2019 at 04:23:30PM -0300, Alvaro Herrera wrote: > On 2019-Jan-05, Justin Pryzby wrote: > > postgres=# CREATE TABLE t(i int)PARTITION BY RANGE(i); > > postgres=# CREATE INDEX ON t(i) WITH(fillfactor=11); > > postgres=# ALTER INDEX t_i_idx SET (fillfactor=12); > > ERROR: 42809:

Re: standby recovery fails (tablespace related) (tentative patch and discussion)

20.09.2019 15:23, Asim R P wrote: On Thu, Sep 19, 2019 at 5:29 PM Asim R P > wrote: > > In order to fix the test failures, we need to distinguish between a missing database directory and a missing tablespace directory.  And also add logic to forget missing

Re: unsupportable composite type partition keys

Amit Langote writes: > Thank you. I noticed that there are comments suggesting that certain > RelationData members are to be accessed using their RelationGet* > functions, but partitioning members do not have such comments. How > about the attached? Good idea, done.

Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema

On Thu, 26 Dec 2019 at 23:21, Tom Lane wrote: > > Mahendra Singh writes: > > I think, we can add a regression test for this. > > postgres=# create temporary table temp(c1 int); > > CREATE TABLE > > postgres=# drop schema pg_temp_3 cascade ; > > ERROR: cannot drop temporary namespace "pg_temp_3"

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

I started writing this patch to avoid the possibly-misleading phrase: "with no extra space" (since it's expected to typically take ~2x space, or 1x "extra" space). But the original phrase "with no extra space" seems to be wrong anyway, since it actually follows fillfactor, so say that. Possibly

Re: Autovacuum on partitioned table

On Fri, 27 Dec 2019 at 12:37, yuzuko wrote: > > Hi, > > As Laurenz commented in this thread, I tried adding option > to update parent's statistics during Autovacuum. To do that, > I propose supporting 'autovacuum_enabled' option already > exists on partitioned tables. > > In the attached patch,

Re: Duplicate Workers entries in some EXPLAIN plans

On Fri, Dec 27, 2019 at 12:31 AM Maciek Sakrejda wrote: > > I wanted to follow up on this patch since I received no feedback. What should > my next steps be (besides rebasing, though I want to confirm there's interest > before I do that)? Given Andres' answer I'd say that there's interest in

Re: Asymmetric partition-wise JOIN

Hello, This crash was reproduced on our environment also. It looks to me adjust_child_relids_multilevel() didn't expect a case when supplied 'relids' (partially) indicate normal and non-partitioned relation. It tries to build a new 'parent_relids' that is a set of appinfo->parent_relid related to

Re: Calling PLpgSQL function with composite type fails with an error: "ERROR: could not open relation with OID ..."

Ashutosh Sharma writes: > The issue here is that PLpgSQL_rec structure being updated by > revalidate_rectypeid() is actually a local/duplicate copy of the > PLpgSQL_rec structure available in plpgsql_HashTable (refer to > copy_plpgsql_datums() where you would notice that if datum type is >

use CLZ instruction in AllocSetFreeIndex()

Hi all, In commit ab5b4e2f9ed, we optimized AllocSetFreeIndex() using a lookup table. At the time, using CLZ was rejected because compiler/platform support was not widespread enough to justify it. For other reasons, we recently added bitutils.h which uses __builtin_clz() where available, so it

Re: Avoid full GIN index scan when possible

On 26.12.2019 4:59, Alexander Korotkov wrote:  I've tried to add patch #4 to comparison, but I've catch assertion failure. TRAP: FailedAssertion("key->includeNonMatching", File: "ginget.c", Line: 1340) There simply should be inverted condition in the assertion:

Re: Libpq support to connect to standby server as priority

On 2019-Oct-01, Greg Nancarrow wrote: > On Wed, Sep 11, 2019 at 10:17 AM Alvaro Herrera from 2ndQuadrant > wrote: > > > > Oh, oops. Here they are then. > > With the permission of the original patch author, Haribabu Kommi, I’ve > rationalized the existing 8 patches into 3 patches, merging

Re: Libpq support to connect to standby server as priority

On 2019-Dec-26, Alvaro Herrera wrote: > The name of the label "consume_checked_write_connection" is not very > descriptive. I propose "conn_succeeded" instead. (I realized later that I should have removed this paragraph -- other goto labels are added in 0002 that would make such renaming more

Re: pgsql: Superuser can permit passwordless connections on postgres_fdw

On Wed, Dec 25, 2019 at 12:56 PM Michael Paquier wrote: > > On Fri, Dec 20, 2019 at 10:17:20PM -0500, Tom Lane wrote: > > Yeah, it's sort of annoying that the buildfarm didn't notice this > > aspect of things. I'm not sure I want to spend cycles on checking > > it in every test run, though. > >

Re: [Patch] Invalid permission check in pg_stats for functional indexes

Awhile back I wrote: > Actually ... maybe we don't need to change the view definition at all, > but instead just make has_column_privilege() do something different > for indexes than it does for other relation types. It's dubious that > applying that function to an index yields anything

Re: planner support functions: handle GROUP BY estimates ?

On Sun, Dec 22, 2019 at 06:16:48PM -0600, Justin Pryzby wrote: > On Tue, Nov 19, 2019 at 01:34:21PM -0600, Justin Pryzby wrote: > > Tom implemented "Planner support functions": > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a391ff3c3d418e404a2c6e4ff0865a107752827b > >

Re: Duplicate Workers entries in some EXPLAIN plans

I wanted to follow up on this patch since I received no feedback. What should my next steps be (besides rebasing, though I want to confirm there's interest before I do that)?

Re: pgsql: Superuser can permit passwordless connections on postgres_fdw

Andrew Dunstan writes: > What's the preferred way to set that? > "configure CPPFLAGS=-DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS"? longfin is doing it via config_env. I have no opinion on whether that's the "preferred" way. regards, tom lane

Re: Libpq support to connect to standby server as priority

On Thu, 26 Dec 2019 at 15:07, Alvaro Herrera wrote: > On 2019-Oct-01, Greg Nancarrow wrote: > > > On Wed, Sep 11, 2019 at 10:17 AM Alvaro Herrera from 2ndQuadrant > > wrote: > > > > > > Oh, oops. Here they are then. > > > > With the permission of the original patch author, Haribabu Kommi, I’ve

Re: Libpq support to connect to standby server as priority

On 2019-Dec-26, Dave Cramer wrote: > On Thu, 26 Dec 2019 at 15:07, Alvaro Herrera > wrote: > > There were other comments that I think went largely unaddressed, > > such as the point that the JDBC driver seems to offer a different > > syntax for the configuration, and should we offer a

RE: Libpq support to connect to standby server as priority

From: Alvaro Herrera > I'm not sure I understand why we end up with "prefer-read" in addition > to "prefer-standby" (and similar seeming redundancy between "primary" > and "read-write"). Do we really need more than one way to identify > hosts' roles? It seems 0001 adds the "prefer-read" modes