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 10:07:58AM +0530, Mahendra Singh wrote: > Yes, you are right that we can drop temporary schema of other sessions. I have mentioned that upthread, and basically we need to use isAnyTempNamespace() here. My mistake. > While applying attached patch on HEAD, I got below warni

Re: [HACKERS] WAL logging problem in 9.4.3?

At Tue, 24 Dec 2019 16:35:35 +0900 (JST), Kyotaro Horiguchi wrote in > I rebased the patch and changed the default value for the GUC variable > wal_skip_threshold to 4096 kilobytes in config.sgml, storage.c and > guc.c. 4096kB is choosed as it is the nice round number of 500 pages * > 8kB = 4000

Re: table partition and column default

On Wed, Dec 25, 2019 at 1:56 PM Amit Langote wrote: > > Fujii-san, > > On Wed, Dec 25, 2019 at 12:19 PM Fujii Masao wrote: > > > > Hi, > > > > As the document explains, column defaults can be specified separately for > > each partition. But I found that INSERT via the partitioned table ignores >

Re: table partition and column default

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 implementing a feature whereby > > partition's default will used for an attribute if it's null even after > > considering the parent table's default,

Re: Disallow cancellation of waiting for synchronous replication

On 21.12.2019 00:19, Tom Lane wrote: Three is still a problem when backend is not canceled, but terminated [2]. Exactly. If you don't have a fix that handles that case, you don't have anything. In fact, you've arguably made things worse, by increasing the temptation to terminate or "kill -9"

Re: Disallow cancellation of waiting for synchronous replication

On 21.12.2019 13:34, Marco Slot wrote: I do agree with the general sentiment that terminating the connection is preferable over sending a response to the client (except when synchronous replication was already disabled). But in this case locally committed data becomes visible to new incoming

Re: Disallow cancellation of waiting for synchronous replication

> 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 client. That's arguably more >

Re: ALTER TABLE support for dropping generation expression

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, failed Spec compliant: not tested Documentation:tested, passed Hello Patch does not apply to master. Could you rebase? Code looks

Re: Disallow cancellation of waiting for synchronous replication

On Wed, Dec 25, 2019, 11:28 Maksim Milyutin wrote: > But in this case locally committed data becomes visible to new incoming > transactions that is bad side-effect of this issue. > Your application should be prepared for that in any case. At the point where synchronous replication waits, the co

Re: Online checksums patch - once again

Hello > Attached is a v15 of the online checksums patchset (minus 0005), rebased on > top > of your v3 ProcSignalBarrier patch rather than Andres' PoC GlobalBarrier > patch. > It does take the, perhaps, controversial approach of replacing the SAMPLE > barrier with the CHECKSUM barrier. The cfbot

Re: [HACKERS] Block level parallel vacuum

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 reviewing other patches and > > > will post comments if there is.

Add pg_file_sync() to adminpack

Hi, I'd like to propose to add pg_file_sync() function into contrib/adminpack. This function fsyncs the specified file or directory named by its argument. IMO this is useful, for example, when you want to fsync the file that pg_file_write() writes out or that COPY TO exports the data into, for dur

How to test GSSAPI based encryption support

Hi, I want to test GSSAPI based encryption support added via commit ID b0b39f72b9904bcb80f97b35837ccff1578aa4b8. I have built source --with-gssapi. After installation I added the following line in pg_hba.conf hostgssenc all all 172.16.214.149/24 trust Next I ran the server and ran psql usin

Re: Physical replication slot advance is not persistent

On 25.12.2019 07:03, Kyotaro Horiguchi wrote: At Tue, 24 Dec 2019 20:12:32 +0300, Alexey Kondratov wrote in I dig into the code and it happens because of this if statement:     /* Update the on disk state when lsn was updated. */     if (XLogRecPtrIsInvalid(endlsn))     {         Replicat

Re: Add pg_file_sync() to adminpack

On Wed, Dec 25, 2019 at 2:01 PM Fujii Masao wrote: > > Hi, > > I'd like to propose to add pg_file_sync() function into contrib/adminpack. > This function fsyncs the specified file or directory named by its argument. > IMO this is useful, for example, when you want to fsync the file that > pg_file_

Re: Disallow cancellation of waiting for synchronous replication

On 25.12.2019 14:27, Marco Slot wrote: On Wed, Dec 25, 2019, 11:28 Maksim Milyutin > wrote: But in this case locally committed data becomes visible to new incoming transactions that is bad side-effect of this issue. Your application should be prepar

Re: Physical replication slot advance is not persistent

On 25.12.2019 16:51, Alexey Kondratov wrote: On 25.12.2019 07:03, Kyotaro Horiguchi wrote: As the result I think what is needed there is just checking if the returned lsn is equal or larger than moveto. Doen't the following change work? -    if (XLogRecPtrIsInvalid(endlsn)) +    if (moveto <= e

Expose lock group leader pid in pg_stat_activity

Hello, 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 was to develop a function in plpgsql to sample a given query wait event, but it's not hard to imagine other useful use cas

Re: unsupportable composite type partition keys

I wrote: > Amit Langote writes: >> On Tue, Dec 24, 2019 at 10:59 AM Amit Langote >> wrote: >>> Btw, does the memory leakage fix in this patch address any of the >>> pending concerns that were discussed on the "hyrax vs. >>> RelationBuildPartitionDesc" thread earlier this year[1]? >>> [1] >>> ht

Re: Expose lock group leader pid in pg_stat_activity

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 was to develop a function in plpgsql > to sample a given query wait

Re: unsupportable composite type partition keys

Amit Langote writes: >> On Sun, Dec 22, 2019 at 6:13 AM Tom Lane wrote: >>> I wonder whether we couldn't also lift >>> the restriction against whole-row Vars in partition expressions. >>> Doesn't seem like there is much difference between such a Var and >>> a row(...)::table_rowtype expression.

Re: proposal: schema variables

a variables > concept, aside the new or the modified statements. > We can finalize documentation little bit later, when will be clear what related functionality is implemented. updated patch attached > K) Coding > > I am not able to appreciate the way the feature has been coded. So I let > this for other reviewers ;-) > > > To conclude, again, thanks a lot for this feature ! > And if I may add this. I dream of an additional feature: adding a SHARED > clause to the CREATE VARIABLE statement in order to be able to create > memory spaces that could be shared by all connections on the database and > accessible in SQL and PL, under the protection of ACL. But that's another > story ;-) > > Best regards. Philippe. > Thank you very much for review > > The new status of this patch is: Waiting on Author > schema-variables-20191225.patch.gz Description: application/gzip

Re: [HACKERS] WAL logging problem in 9.4.3?

By improving AssertPendingSyncs_RelationCache() and by testing with -DRELCACHE_FORCE_RELEASE, I now know of three defects in the attached v30nm. Would you fix these? === Defect 1: Forgets to skip WAL after SAVEPOINT; DROP TABLE; ROLLBACK TO A test in transactions.sql now fails in AssertPendingSy

Re: Implementing Incremental View Maintenance

>> Another use case is a ticket selling system. The system shows how many >> tickets remain in a real time manner. For this purpose it needs to >> count the number of tickets already sold from a log table. By using >> IVM, it could be accomplished in simple and effective way. > > Wouldn't the app

Re: unsupportable composite type partition keys

On Thu, Dec 26, 2019 at 5:45 AM Tom Lane wrote: > Amit Langote writes: > >> On Sun, Dec 22, 2019 at 6:13 AM Tom Lane wrote: > >>> I wonder whether we couldn't also lift > >>> the restriction against whole-row Vars in partition expressions. > >>> Doesn't seem like there is much difference between

Re: Avoid full GIN index scan when possible

On Wed, Dec 25, 2019 at 8:25 AM Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > Patch requires further polishing including comments, minor refactoring > etc. I'm going to continue work on this. > I also run the same performance comparison as Nikita [1] on my laptop. The results are show

Re: Implementing Incremental View Maintenance

Hi, Attached is the latest patch (v11) to add support for Incremental Materialized View Maintenance (IVM). Differences from the previous patch (v10) include: - Prohibit creating matviews including mutable functions Matviews including mutable functions (for example now(),random(), ... etc) cou

Re: Implementing Incremental View Maintenance

On Tue, 24 Dec 2019 07:07:35 + "tsunakawa.ta...@fujitsu.com" wrote: > From: Yugo Nagata > > On Mon, 23 Dec 2019 08:08:53 + > > "tsunakawa.ta...@fujitsu.com" wrote: > > > How about unlogged tables ? I thought the point of using a temp table is > > > to > > avoid WAL overhead. > > > >

Re: [HACKERS] WAL logging problem in 9.4.3?

Thank you for the findings. At Wed, 25 Dec 2019 16:15:21 -0800, Noah Misch wrote in > By improving AssertPendingSyncs_RelationCache() and by testing with > -DRELCACHE_FORCE_RELEASE, I now know of three defects in the attached v30nm. > Would you fix these? I'd like to do that, please give me som

Re: [HACKERS] WAL logging problem in 9.4.3?

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 > > that work no matter what does ereport(ERROR) would be tricky and > > low-value. > >

Re: [HACKERS] WAL logging problem in 9.4.3?

At Thu, 26 Dec 2019 12:46:39 +0900 (JST), Kyotaro Horiguchi wrote in > > - Reverted most post-v24nm changes to swap_relation_files(). Under > > "-DRELCACHE_FORCE_RELEASE", relcache.c quickly discards the > > rel1->rd_node.relNode update. Clearing rel2->rd_createSubid is not right > > if >

Re: unsupportable composite type partition keys

On Thu, Dec 26, 2019 at 3:21 AM Tom Lane wrote: > I wrote: > > Amit Langote writes: > >> On Tue, Dec 24, 2019 at 10:59 AM Amit Langote > >> wrote: > >>> Btw, does the memory leakage fix in this patch address any of the > >>> pending concerns that were discussed on the "hyrax vs. > >>> RelationB

Re: table partition and column default

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 implementing a feature whereby > > > partition's default will used for an attribute

table partitioning and access privileges

Hi, 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 not. But anyway is it bet

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, 24 Dec 2019 at 17:21, Amit Kapila wrote: > > On Tue, Dec 24, 2019 at 11:17 AM Masahiko Sawada > wrote: > > > > On Fri, 20 Dec 2019 at 22:30, Amit Kapila wrote: > > > > > > > > > The main aim of this feature is to reduce apply lag. Because if we > > > send all the changes together it can