Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On Fri, Feb 17, 2017 at 2:17 PM, Prabakaran, Vaishnavi wrote: > On 22 November 2016 at 18:32, Craig Ringer wrote: > I am interested in this patch and addressed various below comments from > reviewers. And, I have separated out code and test

Re: [HACKERS] dropping partitioned tables without CASCADE

On 2017/02/21 15:35, Amit Langote wrote: >> drop table list_parted cascade; >> -NOTICE: drop cascades to 3 other objects >> -DETAIL: drop cascades to table part_ab_cd >> probably we should remove cascade from there, unless you are testing CASCADE >> functionality. Similarly for other blocks

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Tue, Feb 21, 2017 at 12:48 AM, Stephen Frost wrote: > * Fujii Masao (masao.fu...@gmail.com) wrote: >> On Fri, Feb 17, 2017 at 11:17 PM, Peter Eisentraut >> 1) Expose all the columns except subconninfo in pg_subscription to >> non-superusers. In this idea, the

Re: [HACKERS] dropping partitioned tables without CASCADE

Hi Ashutosh, Thanks for taking a look at the patch. On 2017/02/20 21:49, Ashutosh Bapat wrote: > Thanks for working on all the follow on work for partitioning feature. > > May be you should add all those patches in the next commitfest, so > that we don't forget those. I think adding these as

[HACKERS] [doc fix] Really trivial fix for BRIN documentation

Hello, This is just a correction from "index" to "table". I was a bit confused when I first read this part. Regards Takayuki Tsunakawa brin_trivial_doc_fix.patch Description: brin_trivial_doc_fix.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Feb 20, 2017 at 11:18 PM, Robert Haas wrote: > On Mon, Feb 20, 2017 at 5:55 AM, Thomas Munro > wrote: >> On Sun, Feb 19, 2017 at 9:59 PM, Dilip Kumar wrote: >>> So basically, what I want to propose is that Only

Re: [HACKERS] Documentation improvements for partitioning

On Tue, Feb 21, 2017 at 9:57 AM, Amit Langote wrote: > On 2017/02/21 12:10, Ashutosh Bapat wrote: >> I think, that's a limitation till we implement global indexes. But >> nothing in the current implementation stops us from implementing it. >> In fact, I remember, a

Re: [HACKERS] Documentation improvements for partitioning

On 2017/02/21 12:10, Ashutosh Bapat wrote: > I think, that's a limitation till we implement global indexes. But > nothing in the current implementation stops us from implementing it. > In fact, I remember, a reply from Robert to another thread on > partitioning started in parallel to Amit's thread

Re: [HACKERS] Passing query string to workers

On Mon, Feb 20, 2017 at 8:35 PM, Kuntal Ghosh wrote: > > + char *query_data; > + query_data = estate->es_sourceText; > estate->es_sourceText is a const char* variable. Assigning this const > pointer to a non-const pointer violates the rules >

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Feb 21, 2017 at 7:14 AM, Thomas Munro wrote: > On Fri, Jan 20, 2017 at 2:49 AM, Kevin Grittner wrote: >> Attached is v9 which fixes bitrot from v8. No other changes. >> >> Still needs review. Based on a suggestion from Robert off-list I

Re: [HACKERS] Documentation improvements for partitioning

On Tue, Feb 21, 2017 at 2:03 AM, Bruce Momjian wrote: > On Mon, Feb 20, 2017 at 02:37:44PM +0530, Robert Haas wrote: >> On Mon, Feb 20, 2017 at 2:09 AM, Simon Riggs wrote: >> > On 15 February 2017 at 15:46, Robert Haas wrote: >>

Re: [HACKERS] Documentation improvements for partitioning

On 2017/02/16 10:45, Amit Langote wrote: > Also attaching 0002 (unchanged) for tab-completion support for the new > partitioning syntax. Robert already spawned a new thread titled "tab completion for partitioning" for this [0]. > 0003 changes how ExecFindPartition() shows the row for which >

[HACKERS] error detail when partition not found

Simon pointed out in a nearby thread [0] that the detail part of partition-not-found error should show just the partition keys. I posted a patch on that thread [1], but to avoid confusion being caused by multitude of patches over there I'm re-posting it here. * What the patch does: Currently we

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Jan 20, 2017 at 2:49 AM, Kevin Grittner wrote: > Attached is v9 which fixes bitrot from v8. No other changes. > > Still needs review. This patch still applies, builds cleanly after a small modification, includes regression tests and the tests past. The modification I

Re: [HACKERS] SCRAM authentication, take three

On Mon, Feb 20, 2017 at 9:41 PM, Aleksander Alekseev wrote: >> Speaking about flaws, it looks like there is a memory leak in >> array_to_utf procedure - result is allocated twice. Pushed a fix for this one on my branch. > And a few more things I've noticed after a

Re: [HACKERS] Multivariate statistics and expression indexes

On Tue, Feb 21, 2017 at 01:27:53AM +0100, Tomas Vondra wrote: > On 02/21/2017 12:13 AM, Bruce Momjian wrote: > >At the risk of asking a stupid question, we already have optimizer > >statistics on expression indexes. In what sense are we using this for > >multi-variate statistics, and in what

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, Attached is v9 of this patch series. This addresses most of the points raised in the review, namely: 1) change most 'debug' stuff to 'static inline' in memdebug.h 2) fixed and reworded a bunch of comments 3) get rid of the block-level bitmap tracking free chunks Instead of the bitmap,

Re: [HACKERS] Multivariate statistics and expression indexes

On 02/21/2017 12:13 AM, Bruce Momjian wrote: At the risk of asking a stupid question, we already have optimizer statistics on expression indexes. In what sense are we using this for multi-variate statistics, and in what sense can't we. We're not using that at all, because those are really

Re: [HACKERS] ICU integration

On Mon, Feb 20, 2017 at 3:51 PM, Bruce Momjian wrote: > So we don't have any other cases where we warn about possible corruption > except this? I'm not sure that I understand the distinction you're making. > Also, I will go back to my previous concern, that while I like the

Re: [HACKERS] ICU integration

On Mon, Feb 20, 2017 at 03:29:07PM -0800, Peter Geoghegan wrote: > Marking all indexes as invalid would be an enormous overkill. We don't > even know for sure that the values the user has indexed happens to be > affected. In order for there to have been a bug in ICU in the first > place, the

Re: [HACKERS] ICU integration

On Mon, Feb 20, 2017 at 3:19 PM, Bruce Momjian wrote: > Well, the release notes are a clear-enough communication for a need to > reindex. I don't see a LOG message as similar. Don't we have other > cases where we have to warn administrators? We can mark the indexes as >

Re: [HACKERS] ICU integration

On Mon, Feb 20, 2017 at 02:54:22PM -0800, Peter Geoghegan wrote: > On Mon, Feb 20, 2017 at 2:38 PM, Bruce Momjian wrote: > > I can't think of any cases where we warn of possible corruption only in > > the server logs. > > It's just like any case where there was a bug in

[HACKERS] Multivariate statistics and expression indexes

At the risk of asking a stupid question, we already have optimizer statistics on expression indexes. In what sense are we using this for multi-variate statistics, and in what sense can't we. FYI, I just wrote a blog post about expression index statistics:

Re: [HACKERS] ICU integration

On Mon, Feb 20, 2017 at 2:38 PM, Bruce Momjian wrote: > I can't think of any cases where we warn of possible corruption only in > the server logs. It's just like any case where there was a bug in Postgres that could have subtly broken index builds. We don't make the next point

Re: [HACKERS] ICU integration

On Wed, Feb 15, 2017 at 10:35:34PM -0800, Peter Geoghegan wrote: > On Wed, Feb 15, 2017 at 9:17 PM, Peter Eisentraut > wrote: > > Stable operating systems shouldn't do major library upgrades, so I feel > > pretty confident about this. > > There is one case where

[HACKERS] SUBSCRIPTION command hangs up, segfault occurs in the server process and to cancel the execution.

Hi. While verifying the logical replication of PostgreSQL 10-devel, I found the following problem. * When you run the SUBSCRIPTION command against a table in the same PostgreSQL server, hang up. * Canceling the hung SUBSCRIPTION command with CTRL + C causes a server process occurs Segfault, and

Re: [HACKERS] Documentation improvements for partitioning

On Mon, Feb 20, 2017 at 02:37:44PM +0530, Robert Haas wrote: > On Mon, Feb 20, 2017 at 2:09 AM, Simon Riggs wrote: > > On 15 February 2017 at 15:46, Robert Haas wrote: > >>> It leaves me asking what else is missing. > >> > >> There is certainly a lot

Re: [HACKERS] Documentation improvements for partitioning

On Wed, Feb 15, 2017 at 12:08:19PM -0500, Robert Haas wrote: > On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera > wrote: > > I think new-style partitioning is supposed to consider each partition as > > an implementation detail of the table; the fact that you can

Re: [HACKERS] GUC for cleanup indexes threshold.

On Thu, Feb 16, 2017 at 10:41 AM, Robert Haas wrote: >> 2. The current btree vacuum code requires 2 vacuums to fully reuse >> half-dead pages. So skipping an index vacuum might mean that second >> index scan never happens at all, which would be bad. > > Maybe. If there are

Re: [HACKERS] GUC for cleanup indexes threshold.

On 20 February 2017 at 10:27, Amit Kapila wrote: > On Mon, Feb 20, 2017 at 3:01 PM, Simon Riggs wrote: >> On 20 February 2017 at 09:15, Amit Kapila wrote: >>> On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada

Re: [HACKERS] SERIALIZABLE with parallel query

On Thu, Feb 16, 2017 at 6:19 PM, Thomas Munro wrote: > Specifically, DeleteChildTargetLocks() assumes it can walk > MySerializableXact->predicateLocks and throw away locks that are > covered by a new lock (ie throw away tuple locks because a covering > page lock has

Re: [HACKERS] Replication vs. float timestamps is a disaster

Robert Haas writes: > On Mon, Feb 20, 2017 at 7:37 PM, Tom Lane wrote: >> The question to be asked is whether there is still anybody out there >> using float timestamps. I'm starting to get dubious about it myself. > I'm wondering if it has any effect

Re: [HACKERS] Parallel bitmap heap scan

Robert Haas writes: > On Mon, Feb 20, 2017 at 6:19 AM, Tom Lane wrote: >> The thing that you really have to worry about for this kind of proposal >> is "what if the query errors out and we never get to ExecEndNode"? >> It's particularly nasty if you're

Re: [HACKERS] fd,c just Assert()s that lseek() succeeds

I wrote: > I noticed while researching bug #14555 that fd.c contains two separate > cases like > vfdP->seekPos = lseek(vfdP->fd, (off_t) 0, SEEK_CUR); > Assert(vfdP->seekPos != (off_t) -1); > This seems, um, unwise. It might somehow fail to fail in production > builds, because

[HACKERS] possible encoding issues with libxml2 functions

Hi Today I played with xml_recv function and with xml processing functions. xml_recv function ensures correct encoding from document encoding to server encoding. But the decl section holds original encoding info - that should be obsolete after encoding. Sometimes we solve this issue by removing

Re: [HACKERS] DROP SUBSCRIPTION and ROLLBACK

On Thu, Feb 16, 2017 at 11:40 AM, Masahiko Sawada wrote: > On Thu, Feb 16, 2017 at 7:52 AM, Petr Jelinek > wrote: >> On 15/02/17 06:43, Masahiko Sawada wrote: >>> On Tue, Feb 14, 2017 at 1:13 AM, Fujii Masao wrote:

Re: [HACKERS] GUC for cleanup indexes threshold.

On Mon, Feb 20, 2017 at 6:15 PM, Amit Kapila wrote: > On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada > wrote: >> On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas wrote: >>> On Thu, Feb 16, 2017 at 6:17 AM, Simon Riggs

Re: [HACKERS] Should we cacheline align PGXACT?

On 20 February 2017 at 17:32, Robert Haas wrote: >>> Have you checked whether this >>> patch makes any noticeable performance difference? >> >> No, but then we're reducing the number of calls to PgXact directly; >> there is no heuristic involved, its just a pure saving. >

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Feb 20, 2017 at 6:19 AM, Tom Lane wrote: > Thomas Munro writes: >> One practical problem that came up was the need for executor nodes to >> get a chance to do that kind of cleanup before the DSM segment is >> detached. In my patch

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Feb 20, 2017 at 5:55 AM, Thomas Munro wrote: > On Sun, Feb 19, 2017 at 9:59 PM, Dilip Kumar wrote: >> So basically, what I want to propose is that Only during >> ExecReScanBitmapHeapScan we can free all the DSA pointers because at >>

Re: [HACKERS] Should we cacheline align PGXACT?

On Mon, Feb 20, 2017 at 10:49 PM, Simon Riggs wrote: >> Regarding reduce_pgxact_access_AtEOXact.v1.patch, it took me a few >> minutes to figure out that the comment was referring to >> ProcArrayEndTransaction(), so it might be good to be more explicit >> about that if we go

Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

> On Feb 19, 2017, at 8:14 PM, Jim Nasby wrote: > > On 2/19/17 11:02 AM, David Christensen wrote: >> My design notes for the patch were submitted to the list with little >> comment; see: >>

Re: [HACKERS] Should we cacheline align PGXACT?

On 20 February 2017 at 16:53, Robert Haas wrote: > On Mon, Feb 20, 2017 at 6:02 PM, Simon Riggs wrote: >> On 15 February 2017 at 19:15, Andres Freund wrote: >> >>> I think I previously >>> mentioned, even just removing the

Re: [HACKERS] Replication vs. float timestamps is a disaster

On Mon, Feb 20, 2017 at 7:37 PM, Tom Lane wrote: > The question to be asked is whether there is still anybody out there > using float timestamps. I'm starting to get dubious about it myself. > Certainly, no packager that I'm aware of has shipped a float-timestamp > build

Re: [HACKERS] Should we cacheline align PGXACT?

On Mon, Feb 20, 2017 at 6:02 PM, Simon Riggs wrote: > On 15 February 2017 at 19:15, Andres Freund wrote: > >> I think I previously >> mentioned, even just removing the MyPgXact->xmin assignment in >> SnapshotResetXmin() is measurable performance wise

Re: [HACKERS] Checksums by default?

On 02/11/2017 01:38 AM, Tomas Vondra wrote: Incidentally, I've been dealing with a checksum failure reported by a customer last week, and based on the experience I tend to agree that we don't have the tools needed to deal with checksum failures. I think such tooling should be a 'must have' for

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Wed, Feb 15, 2017 at 9:33 PM, David G. Johnston wrote: > On Wed, Feb 15, 2017 at 12:24 PM, Robert Haas wrote: >> >> So it seems like an ALIGN or NORMALIZE option is kind of like a JOIN, >> except apparently there's no join type and the

Re: [HACKERS] [POC] A better way to expand hash indexes.

On Fri, Feb 17, 2017 at 7:21 PM, Mithun Cy wrote: > > To implement such an incremental addition of bucket blocks I have to > increase the size of array hashm_spares in meta page by four times. > Also, mapping methods which map a total number of buckets to a >

Re: [HACKERS] powerpc(32) point/polygon regression failures on Debian Jessie

Re: Tom Lane 2017-02-20 <13825.1487607...@sss.pgh.pa.us> > Still, it'd be worth comparing the assembly code for your test program. I was compiling the program on jessie and on sid, and running the jessie binary on sid made it output the same as the sid binary, so the difference isn't in the

[HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

Hi, while investigating some checksum-related issues, I needed to perform some forensics on a copy of a btree page (taken from another instance using 'dd'). But I've ran into two pageinspect limitations, hopefully addressed by this patch: 1) bt_page_items(bytea) not defined We have

Re: [HACKERS] powerpc(32) point/polygon regression failures on Debian Jessie

Christoph Berg writes: > Re: Tom Lane 2017-02-20 <30737.1487598...@sss.pgh.pa.us> >> Hmph. We haven't touched that code in awhile, and certainly not in the >> 9.4.x branch. I'd have to agree that this must be a toolchain change. > FYI, in the meantime we could

Re: [HACKERS] powerpc(32) point/polygon regression failures on Debian Jessie

Re: Tom Lane 2017-02-20 <30737.1487598...@sss.pgh.pa.us> > Hmph. We haven't touched that code in awhile, and certainly not in the > 9.4.x branch. I'd have to agree that this must be a toolchain change. FYI, in the meantime we could indeed trace it back to an libc issue on Jessie: $ cat sqrt.c

Re: [HACKERS] [PATCH] Suppress Clang 3.9 warnings

Tomas Vondra writes: > On 02/20/2017 04:37 PM, Tom Lane wrote: >> But that's using gcc. Perhaps clang behaves differently? > AFAIK it happens because clang treats missing declarations as warnings, > which confuses configure: >

Re: [HACKERS] [PATCH] Suppress Clang 3.9 warnings

On 02/20/2017 04:37 PM, Tom Lane wrote: Aleksander Alekseev writes: In theory - could we just always use our internal strl* implementations? Hmm, maybe configure's test to see if a declaration has been provided is going wrong? I notice that anchovy, which is

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

Greetings, * Fujii Masao (masao.fu...@gmail.com) wrote: > On Fri, Feb 17, 2017 at 11:17 PM, Peter Eisentraut > wrote: > > On 2/13/17 12:07, Fujii Masao wrote: > >> Anyway IMO that we can expose all the > >> columns except the sensitive information (i.e.,

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Fri, Feb 17, 2017 at 11:17 PM, Peter Eisentraut wrote: > On 2/13/17 12:07, Fujii Masao wrote: >> Anyway IMO that we can expose all the >> columns except the sensitive information (i.e., subconninfo field) >> in pg_subscription to even non-superusers. > > You

Re: [HACKERS] [PATCH] Suppress Clang 3.9 warnings

Aleksander Alekseev writes: > In theory - could we just always use our internal strl* implementations? Hmm, maybe configure's test to see if a declaration has been provided is going wrong? I notice that anchovy, which is supposedly current Arch Linux, doesn't think

[HACKERS] mat views stats

I've come across a number of times where the statistics on materialized views become stale producing bad plans. It turns out that autovacuum only touches a materialized view when it is first created and ignores it on a refresh. When you have a materialized view like yesterdays_sales the data in

Re: [HACKERS] Passing query string to workers

On Mon, Feb 20, 2017 at 10:11 AM, Rafia Sabih wrote: > On Sun, Feb 19, 2017 at 10:11 PM, Robert Haas wrote: >> + query_data = (char *) palloc0(strlen(estate->es_queryString) + 1); >> + strcpy(query_data, estate->es_queryString); >>

[HACKERS] "may be unused" warnings for gcc

Hi, When building with a new-ish gcc (6.3.0 right now, but I've seen this for a while) with optimization I get a number of warnings: In file included from /home/andres/src/postgresql/src/include/postgres.h:48:0, from

Re: [HACKERS] [PATCH] Suppress Clang 3.9 warnings

In theory - could we just always use our internal strl* implementations? On Mon, Feb 20, 2017 at 09:26:44AM -0500, Tom Lane wrote: > Aleksander Alekseev writes: > > I've just tried to build PostgreSQL with Clang 3.9.1 (default version > > currently available in Arch

Re: [HACKERS] [PATCH] Suppress Clang 3.9 warnings

Aleksander Alekseev writes: > I've just tried to build PostgreSQL with Clang 3.9.1 (default version > currently available in Arch Linux) and noticed that it outputs lots of > warning messages. Most of them are result of a bug in Clang itself: > > postinit.c:846:3:

[HACKERS] [PATCH] Suppress Clang 3.9 warnings

Hello. I've just tried to build PostgreSQL with Clang 3.9.1 (default version currently available in Arch Linux) and noticed that it outputs lots of warning messages. Most of them are result of a bug in Clang itself: ``` postinit.c:846:3: note: include the header or explicitly provide a

Re: [HACKERS] Replication vs. float timestamps is a disaster

Petr Jelinek writes: > It's definitely not hard, we already have > IntegerTimestampToTimestampTz() which does the opposite conversion anyway. It's not the functions that are hard, it's making sure that you have used them in the correct places, and declared relevant

Re: [HACKERS] Replication vs. float timestamps is a disaster

Andres Freund writes: > On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote: >> That being said, I did wonder myself if we should just deprecate float >> timestamps as well. > I think we need a proper deprecation period for that, given that the > conversion away will be painful

Re: [HACKERS] powerpc(32) point/polygon regression failures on Debian Jessie

Christoph Berg writes: > The point/polygon regression tests have started to fail on 32-bit > powerpc on Debian Jessie. So far I could reproduce the problem with > PostgreSQL 9.4.10+11 and 9.6.1, on several different machines. Debian > unstable is unaffected. Hmph. We

[HACKERS] Error in XML recv function

Hi When I did tests of own XML import functions I found a strange error. I successfully imported XML to PostgreSQL. This document is readable without any visual defects. But when I tested this document against any libxml2 function I found a error - ERROR: could not parse XML document DETAIL:

Re: [HACKERS] How to read a value when it is VARATT EXTERNAL ONDISK from logical replication decoder

Hi, On 2017-02-20 11:44:58 +0100, Adam Dratwiński wrote: > Hello everyone, > > I am writing a custom logical replication decoder, and I took test decoder > from Postgres sources as an example. > > Could anyone tell me how to read "unchanged toast datum" in case it is > VARTT_IS_EXTERNAL_ONDISK.

[HACKERS] How to read a value when it is VARATT EXTERNAL ONDISK from logical replication decoder

Hello everyone, I am writing a custom logical replication decoder, and I took test decoder from Postgres sources as an example. Could anyone tell me how to read "unchanged toast datum" in case it is VARTT_IS_EXTERNAL_ONDISK. In the test decoder it is ignored:

[HACKERS] powerpc(32) point/polygon regression failures on Debian Jessie

The point/polygon regression tests have started to fail on 32-bit powerpc on Debian Jessie. So far I could reproduce the problem with PostgreSQL 9.4.10+11 and 9.6.1, on several different machines. Debian unstable is unaffected. The failure looks like this:

Re: [HACKERS] dropping partitioned tables without CASCADE

Thanks for working on all the follow on work for partitioning feature. May be you should add all those patches in the next commitfest, so that we don't forget those. On Mon, Feb 20, 2017 at 7:46 AM, Amit Langote wrote: > Re-posting the patch I posted in a nearby

Re: [HACKERS] SCRAM authentication, take three

And a few more things I've noticed after a closer look: * build_client_first_message does not free `state->client_nonce` if second malloc (for `buf`) fails * same for `state->client_first_message_bare` * ... and most other procedures declared in fe-auth-scram.c file (see malloc and strdup

Re: [HACKERS] 答复: [HACKERS] Adding new output parameter of pg_stat_statements toidentify operation of the query.(Internet mail)

=?gb2312?B?amFzb255c2xpKMDu1L7JrSk=?= writes: > Yes, it seems the pg_stat_sql function can fit the individual need of > collecting tags of query. However the new function can not return other > values of query at the same time, such as block number info, run time and so

Re: [HACKERS] Should we cacheline align PGXACT?

On 15 February 2017 at 19:15, Andres Freund wrote: > I think I previously > mentioned, even just removing the MyPgXact->xmin assignment in > SnapshotResetXmin() is measurable performance wise and cache-hit ratio > wise. Currently, we issue SnapshotResetXmin() pointlessly at

Re: [HACKERS] SCRAM authentication, take three

Speaking about flaws, it looks like there is a memory leak in array_to_utf procedure - result is allocated twice. On Mon, Feb 20, 2017 at 02:51:13PM +0300, Aleksander Alekseev wrote: > Hi! > > Currently I don't see any significant flaws in these patches. However I > would like to verify that

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 20/02/17 12:04, Andres Freund wrote: > On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote: >> That being said, I did wonder myself if we should just deprecate float >> timestamps as well. > > I think we need a proper deprecation period for that, given that the > conversion away will be painful

Re: [HACKERS] SCRAM authentication, take three

Hi! Currently I don't see any significant flaws in these patches. However I would like to verify that implemented algorithms are compatible with algorithms implemented by third party. For instance, for user 'eax' and password 'pass' I got the following record in pg_authid: ``` scram-sha-256:

[HACKERS] pg_monitor role

Further to the patch I just submitted (https://www.postgresql.org/message-id/CA%2BOCxow-X%3DD2fWdKy%2BHP%2BvQ1LtrgbsYQ%3DCshzZBqyFT5jOYrFw%40mail.gmail.com) I'd like to propose the addition of a default role, pg_monitor. The intent is to make it easy for users to setup a role for fully monitoring

[HACKERS] pg_ls_waldir() & pg_ls_logdir()

Hi Following various conversations on list and in person, including the developer meeting in Brussels earlier this month, here is a patch that implements pg_ls_logdir() and pg_ls_waldir() functions. The ultimate aim of this (and followup work I'll be doing) is to provide functionality to enable

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote: > That being said, I did wonder myself if we should just deprecate float > timestamps as well. I think we need a proper deprecation period for that, given that the conversion away will be painful for pg_upgrade using people with big clusters. So

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 20/02/17 08:03, Andres Freund wrote: > On 2017-02-19 10:49:29 -0500, Tom Lane wrote: >> Robert Haas writes: >>> On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote: Thoughts? Should we double down on trying to make this work according to the

Re: [HACKERS] wait events for disk I/O

My colleague Rahila reported compilation issue with the patch. Issue was only coming with we do the clean build on the branch. Fixed the same into latest version of patch. Thanks, On Tue, Jan 31, 2017 at 11:09 AM, Rushabh Lathia wrote: > > > On Tue, Jan 31, 2017 at

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/19 18:53, Robert Haas wrote: > On Fri, Feb 17, 2017 at 1:12 PM, Amit Langote wrote: >> Do you mean that if database-wide analyze is to be run, we should also >> exclude those RELKIND_RELATION relations that are partitions? >> >> So the only way to update a partition's statistics is to

Re: [HACKERS] GUC for cleanup indexes threshold.

On Mon, Feb 20, 2017 at 3:01 PM, Simon Riggs wrote: > On 20 February 2017 at 09:15, Amit Kapila wrote: >> On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada >> wrote: >>> On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas

Re: [HACKERS] Should we cacheline align PGXACT?

Hi, >> On Thu, Feb 16, 2017 at 5:07 AM, Alexander Korotkov > >> wrote: > >> > On Wed, Feb 15, 2017 at 8:49 PM, Alvaro Herrera > >> > > >> > wrote: > >> >> Alexander Korotkov wrote: > >> >> > >> >> > Difference between master, pgxact-align-2

Re: [HACKERS] UPDATE of partition key

On Mon, Feb 20, 2017 at 3:36 PM, Thomas Munro wrote: > On Thu, Feb 16, 2017 at 8:53 PM, Robert Haas wrote: >> Generally speaking, we don't throw >> serialization errors today at READ COMMITTED, so if we do so here, >> that's going to be a

Re: [HACKERS] UPDATE of partition key

On Thu, Feb 16, 2017 at 8:53 PM, Robert Haas wrote: > Generally speaking, we don't throw > serialization errors today at READ COMMITTED, so if we do so here, > that's going to be a noticeable and perhaps unwelcome change. Yes we do:

Re: [HACKERS] case_preservation_and_insensitivity = on

On Mon, Feb 20, 2017 at 1:45 AM, Tom Lane wrote: > The versions of autocommit that have actually stood the test of time were > implemented on the client side (in psql and JDBC, and I think ODBC as > well), where the scope of affected code was lots smaller. I wonder > whether

Re: [HACKERS] GUC for cleanup indexes threshold.

On 20 February 2017 at 09:15, Amit Kapila wrote: > On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada > wrote: >> On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas wrote: >>> On Thu, Feb 16, 2017 at 6:17 AM, Simon Riggs

Re: [HACKERS] case_preservation_and_insensitivity = on

On Mon, Feb 20, 2017 at 2:40 AM, Jim Nasby wrote: > Even if the project decided that "Users" and users is stupid and that we > should deprecate it, I think the odds of also deciding to tell existing > users to re-write their apps are zero. But if the feature can't be

Re: [HACKERS] UPDATE of partition key

On 16 February 2017 at 20:53, Robert Haas wrote: > On Thu, Feb 16, 2017 at 5:47 AM, Greg Stark wrote: >> On 13 February 2017 at 12:01, Amit Khandekar wrote: >>> There are a few things that can be discussed about : >> >> If you do a

Re: [HACKERS] Gather Merge

On Mon, Feb 20, 2017 at 1:58 PM, Dilip Kumar wrote: > On Mon, Feb 20, 2017 at 12:05 PM, Rushabh Lathia > wrote: >> Thanks Amit for raising this point. I was not at all aware of mark/restore. >> I tried to come up with the case, but haven't found

Re: [HACKERS] increasing the default WAL segment size

Hello, On Thu, Feb 16, 2017 at 3:37 PM, Kuntal Ghosh wrote: > On Mon, Feb 6, 2017 at 11:09 PM, Beena Emerson > wrote: > > > > Hello, > > PFA the updated patches. > I've started reviewing the patches. > 01-add-XLogSegmentOffset-macro.patch

Re: [HACKERS] GUC for cleanup indexes threshold.

On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada wrote: > On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas wrote: >> On Thu, Feb 16, 2017 at 6:17 AM, Simon Riggs wrote: >>> On 15 February 2017 at 08:07, Masahiko Sawada

Re: [HACKERS] Documentation improvements for partitioning

On Mon, Feb 20, 2017 at 2:09 AM, Simon Riggs wrote: > On 15 February 2017 at 15:46, Robert Haas wrote: >>> It leaves me asking what else is missing. >> >> There is certainly a lot of room for improvement here but I don't >> understand your persistent

Re: [HACKERS] Gather Merge

On Mon, Feb 20, 2017 at 12:05 PM, Rushabh Lathia wrote: > Thanks Amit for raising this point. I was not at all aware of mark/restore. > I tried to come up with the case, but haven't found such case. > > For now here is the patch with comment update. I think for

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

On 2017/02/13 18:24, Rushabh Lathia wrote: I started reviewing the patch again. Patch applied cleanly on latest source as well as regression pass through with the patch. I also performed few manual testing and haven't found any regression. Patch look much cleaner the earlier version, and don't