Re: [HACKERS] SERIALIZABLE with parallel query

On Thu, Sep 21, 2017 at 4:13 PM, Thomas Munro wrote: > On Tue, Sep 19, 2017 at 1:47 PM, Haribabu Kommi > wrote: > > During testing of this patch, I found some behavior difference > > with the support of parallel query, while experimenting with the provided > > test case in the patch. > > > > But

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On 2017/09/25 12:10, Michael Paquier wrote: > On Sat, Sep 23, 2017 at 4:13 AM, Tom Lane wrote: >> Somebody inserted this into vacuum.c's get_rel_oids(): >> >> tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid)); >> if (!HeapTupleIsValid(tuple)) >> elog(ERROR, "cach

[HACKERS] Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Tue, Sep 19, 2017 at 07:01:47PM -0700, Peter Geoghegan wrote: > On Tue, Sep 19, 2017 at 5:52 PM, Peter Eisentraut > wrote: > > On 9/18/17 18:46, Peter Geoghegan wrote: > >> As I pointed out a couple of times already [1], we don't currently > >> sanitize ICU's BCP 47 language tags within CREATE

Re: [HACKERS] SERIALIZABLE with parallel query

On Mon, Sep 25, 2017 at 8:37 PM, Haribabu Kommi wrote: > After I tune the GUC to go with sequence scan, still I am not getting the > error > in the session-2 for update operation like it used to generate an error for > parallel > sequential scan, and also it even takes some many commands until unl

Re: [HACKERS] Effect of changing the value for PARALLEL_TUPLE_QUEUE_SIZE

On Thu, Sep 21, 2017 at 10:34 PM, Dilip Kumar wrote: > On Thu, Sep 21, 2017 at 4:50 PM, Rafia Sabih > wrote: >> On Sun, Sep 17, 2017 at 9:10 PM, Dilip Kumar wrote: >>> On Wed, Sep 6, 2017 at 4:14 PM, Rafia Sabih >>> wrote: >>> >> >> Please find the attached file for the revised version. > > Tha

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On Mon, Sep 25, 2017 at 4:42 PM, Amit Langote wrote: > On 2017/09/25 12:10, Michael Paquier wrote: > Hmm, I'm not sure if we need to lock the partitions, too. Locks taken by > find_all_inheritors() will be gone once the already-running transaction is > ended by the caller (vacuum()). get_rel_oid

Re: [HACKERS] path toward faster partition pruning

Hi Dilip. Thanks for looking at the patches and the comments. On 2017/09/16 18:43, Dilip Kumar wrote: > On Fri, Sep 15, 2017 at 2:20 PM, Amit Langote > wrote: >> On 2017/09/15 11:16, Amit Langote wrote: > > Thanks for the updated patch. I was going through the logic of > get_rel_partitions in

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Sep 22, 2017 at 5:31 PM, Kyotaro HORIGUCHI wrote: > At Fri, 22 Sep 2017 17:21:04 +0900, Masahiko Sawada > wrote in >> On Fri, Sep 22, 2017 at 4:16 PM, Kyotaro HORIGUCHI >> wrote: >> > At Fri, 22 Sep 2017 15:00:20 +0900, Masahiko Sawada >> > wrote in >> > >> >> On Tue, Sep 19, 2017

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On Mon, Sep 25, 2017 at 12:10 PM, Michael Paquier wrote: > On Sat, Sep 23, 2017 at 4:13 AM, Tom Lane wrote: >> Somebody inserted this into vacuum.c's get_rel_oids(): >> >> tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid)); >> if (!HeapTupleIsValid(tuple)) >> elo

Re: [HACKERS] comments improvements

On Mon, Sep 25, 2017 at 5:36 AM, Erik Rijkers wrote: > comments improvements > For triggers.sql.20170924.diff file, you need to update expected/triggers.out file as well. -- Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pg

Re: [HACKERS] logical replication and statistics

On Mon, Sep 25, 2017 at 12:58 AM, Pavel Stehule wrote: > Hi > > I did trivial example of logical replication (one table, one publication, > one subscription) > > I am little bit surprised so after some work - the replication is working, > the statistics are empty > > #master > postgres=# select *

Re: [HACKERS] path toward faster partition pruning

On Mon, Sep 25, 2017 at 3:34 PM, Amit Langote wrote: > Thanks for looking at the patches and the comments. > It's not clear to me whether get_rel_partitions() itself, as it is, is > callable from outside the planner, because its signature contains > RelOptInfo. We have the RelOptInfo in the sig

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On Mon, Sep 25, 2017 at 7:57 PM, Masahiko Sawada wrote: > FWIW, the same thing can happen when specifying an invalid replication > origin name to pg_replication_origin_advance() and > pg_replication_origin_progress(). These probably should fixed as well. I have spawned a thread about that stuff t

Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hello, this patch have been ignored for a long time since its proposal... At Sat, 11 Mar 2017 20:44:31 +0100, Pavel Stehule wrote in > Hi > > This proposal is followup of implementation of XMLTABLE. > > Lot of XML documents has assigned document namespace. > > http://x.y";>10 > > For these

Re: [HACKERS] logical replication and statistics

2017-09-25 13:12 GMT+02:00 Masahiko Sawada : > On Mon, Sep 25, 2017 at 12:58 AM, Pavel Stehule > wrote: > > Hi > > > > I did trivial example of logical replication (one table, one publication, > > one subscription) > > > > I am little bit surprised so after some work - the replication is > workin

Re: [HACKERS] GUC for cleanup indexes threshold.

At Mon, 25 Sep 2017 19:20:07 +0900, Masahiko Sawada wrote in > >> * we stash an XID when a btree page is deleted, which is used to > >> determine when it's finally safe to recycle the page > > > > Is it a "problem" of this proposal? > > > > As Peter explained before[1], the problem is that ther

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On Mon, Sep 25, 2017 at 8:22 PM, Michael Paquier wrote: > On Mon, Sep 25, 2017 at 7:57 PM, Masahiko Sawada > wrote: >> FWIW, the same thing can happen when specifying an invalid replication >> origin name to pg_replication_origin_advance() and >> pg_replication_origin_progress(). These probably

Re: [HACKERS] visual studio 2017 build support

On 09/25/2017 12:25 AM, Haribabu Kommi wrote: > > > > > Thanks for pointing it out, I missed to check the Build tools support > section. > Here I attached the updated patch with the change in documentation to  > include the 2008 R2 SP1 operating system also. > > Thanks, committed and backpatched

Re: [HACKERS] GUC for cleanup indexes threshold.

At Fri, 22 Sep 2017 17:15:08 +0300, Sokolov Yura wrote in > On 2017-09-22 16:22, Sokolov Yura wrote: > > On 2017-09-22 11:21, Masahiko Sawada wrote: > >> On Fri, Sep 22, 2017 at 4:16 PM, Kyotaro HORIGUCHI > >> wrote: > >>> At Fri, 22 Sep 2017 15:00:20 +0900, Masahiko Sawada > >>> wrote in > >>

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Hi Andres, Another idea would be to have an array of FmgrBuiltin*, that we index by > oid. That'd not be super small though, given that the space for function > oids is sparse. > > I totally agree here, as the oids are very much scattered having an array is not feasible here. > Thus what I've in

Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patch for hash index

Hi Thomas, I have attached the rebased version of patch here. Kind Regards, Shubham On 8 September 2017 at 06:37, Thomas Munro wrote: > Hi Shubham, > > On Tue, Jun 27, 2017 at 9:21 PM, Shubham Barai > wrote: > > If these two hash keys (78988658 and 546789888) mapped to the same > bucket, thi

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

Andrew Dunstan writes: > On 09/24/2017 07:06 PM, Tom Lane wrote: >> So I think we should just stop with the blacklist test for v10, >> and then see if we still get complaints (and exactly what they're >> about) so that we can judge how much more work the problem deserves. >> It's still ahead of wh

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On 9/10/17 22:37, Michael Paquier wrote: >>> With the tests directly in the patch, things are easy to run. WIth >>> PG10 stabilization work, of course I don't expect much feedback :) >>> But this set of patches looks like the direction we want to go so as >>> JDBC and libpq users can take advantage

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

Thomas Munro writes: > So, do we want this patch? I think we don't really have a lot of choice. I propose applying this as far back as 9.6 --- anyone think differently? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make cha

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/25/2017 10:14 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 09/24/2017 07:06 PM, Tom Lane wrote: >>> So I think we should just stop with the blacklist test for v10, >>> and then see if we still get complaints (and exactly what they're >>> about) so that we can judge how much more work

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

Amit Langote writes: > On 2017/09/25 12:10, Michael Paquier wrote: >> As long as I don't forget... Another thing currently on HEAD and >> REL_10_STABLE is that OIDs of partitioned tables are used, but the >> RangeVar of the parent is used for error reports. This leads to >> incorrect reports if a

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

Andrew Dunstan writes: > On 09/25/2017 10:14 AM, Tom Lane wrote: >> Oh ... I did not think we were on the same page, because your patch >> didn't include removal of the same-transaction heuristic. It'd be >> sensible to do that as a separate patch, though, to make it easier >> to put back if we d

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On 8/31/17 23:22, Michael Paquier wrote: >> One open question is how to treat a missing (empty) bgw_type. I >> currently fill in bgw_name as a fallback. We could also treat it as an >> error or a warning as a transition measure. > > Hm. Why not reporting an empty type string as NULL at SQL level

Re: [HACKERS] Small improvement to compactify_tuples

On Sat, Sep 23, 2017 at 5:56 AM, Sokolov Yura wrote: > Hello, Claudio. > > Thank you for review and confirm of improvement. > > > On 2017-09-23 01:12, Claudio Freire wrote: >> >> >> Patch 1 applies cleanly, builds, and make check runs fine. >> >> The code looks similar in style to surrounding code

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/25/2017 10:42 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 09/25/2017 10:14 AM, Tom Lane wrote: >>> Oh ... I did not think we were on the same page, because your patch >>> didn't include removal of the same-transaction heuristic. It'd be >>> sensible to do that as a separate patch,

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On 2017-09-23 01:59:0, "Alexander Korotkov" wrote: On Fri, Sep 22, 2017 at 7:16 PM, chenhj wrote: This is the new pacth with TAP test and use Macro XLOGDIR. Good. I took a quick look over the patch. Why do you need master_query(), standby_query() and run_query() in RewindTest.pm? You can do

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Fri, Sep 22, 2017 at 11:56 PM, Tom Lane wrote: > FWIW, the release is a week from Monday, not Monday. (Or if it is > Monday, somebody else is wrapping it.) Oops. > We have some other embarrassingly critical things to fix, like bug #14825, > so I can certainly sympathize with an argument that

[HACKERS] psql \d sequence display

In PostgreSQL 10, the sequence metadata moved from the sequence "relation" to a system catalog. The psql \d sequence command was not updated for that. (It just did SELECT * FROM seq and there were no tests, so this was missed.) Attached is a patch that fixes that up, taking the opportunity to de

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

On Mon, Sep 25, 2017 at 10:22 AM, Tom Lane wrote: > Thomas Munro writes: >> So, do we want this patch? > > I think we don't really have a lot of choice. I propose applying this > as far back as 9.6 --- anyone think differently? +1. If applies to 9.5 and 9.4 without a lot of work, I think we sh

Re: [HACKERS] logical replication and statistics

On 25/09/17 13:33, Pavel Stehule wrote: > > > 2017-09-25 13:12 GMT+02:00 Masahiko Sawada >: > > On Mon, Sep 25, 2017 at 12:58 AM, Pavel Stehule > mailto:pavel.steh...@gmail.com>> wrote: > > Hi > > > > I did trivial example of logical replication

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On 25/09/17 16:45, Peter Eisentraut wrote: > On 8/31/17 23:22, Michael Paquier wrote: >>> One open question is how to treat a missing (empty) bgw_type. I >>> currently fill in bgw_name as a fallback. We could also treat it as an >>> error or a warning as a transition measure. >> >> Hm. Why not re

Re: [HACKERS] logical replication and statistics

2017-09-25 18:30 GMT+02:00 Petr Jelinek : > On 25/09/17 13:33, Pavel Stehule wrote: > > > > > > 2017-09-25 13:12 GMT+02:00 Masahiko Sawada > >: > > > > On Mon, Sep 25, 2017 at 12:58 AM, Pavel Stehule > > mailto:pavel.steh...@gmail.com>> wrote: > > > Hi >

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Mon, Sep 25, 2017 at 9:06 AM, Robert Haas wrote: >> The big concern I have here is that this feels a lot like something that >> we'll regret at leisure, if it's not right in the first release. I'd >> much rather be restrictive in v10 and then loosen the rules later, than >> be lax in v10 and t

Re: [HACKERS] Built-in plugin for logical decoding output

On 23/09/17 19:01, Alvaro Hernandez wro> On 23/09/17 18:42, Euler Taveira wrote: >> 2017-09-22 19:28 GMT-03:00 Gregory Brail : >>> We have been working on a project that makes extensive use of logical >>> replication for use inside Apigee (which is a very small part of >>> Google): >>> >>> https://

Re: [HACKERS] Built-in plugin for logical decoding output

On 25/09/17 19:39, Petr Jelinek wrote: Well, test_decoding is not meant for production use anyway, no need for middleware to support it. The pgoutput is primarily used for internal replication purposes, which is why we need something with more interoperability in mind in the first place. The n

Re: [HACKERS] Built-in plugin for logical decoding output

On 09/25/2017 12:48 PM, Alvaro Hernandez wrote: > > > On 25/09/17 19:39, Petr Jelinek wrote: >> >> Well, test_decoding is not meant for production use anyway, no need for >> middleware to support it. The pgoutput is primarily used for internal >> replication purposes, which is why we need somethi

Re: [HACKERS] Built-in plugin for logical decoding output

I'm encouraged that pgoutput exists and I'm sorry that I missed it before. I think it's fine as a binary-only format. If someone can write a client for the Postgres wire protocol as documented in Chapter 52 of the docs, then they should have no trouble consuming the output from pgoutput. However,

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On 9/24/17, 10:12 PM, "Michael Paquier" wrote: > Attached is a proposal of patch. The patch seems reasonable to me, and I haven't encountered any issues in my tests, even after applying the vacuum-multiple-relations patch on top of it. +* Take a lock here for the relation lookup.

Re: [HACKERS] Built-in plugin for logical decoding output

On 09/25/2017 09:59 AM, Gregory Brail wrote: However, I can't find any docs for the output format of pgoutput, which is going to make it less likely for people to be able to consume it. Is anyone working on docs? I know that it's a painful process. I also think that a JSON-format (or configur

Re: [HACKERS] Built-in plugin for logical decoding output

On 25/09/17 19:56, Andrew Dunstan wrote: On 09/25/2017 12:48 PM, Alvaro Hernandez wrote: On 25/09/17 19:39, Petr Jelinek wrote: Well, test_decoding is not meant for production use anyway, no need for middleware to support it. The pgoutput is primarily used for internal replication purposes,

Re: [HACKERS] Built-in plugin for logical decoding output

Yes. I'm advocating something "built-in" to Postgres. Any or all of those are likely a great starting point. As for protobuf, I'm a big advocate -- it is easy to use, fast, extensible, runs on lots of platforms, and produces very compact output. However it introduces a few dependencies to the buil

Re: [HACKERS] Built-in plugin for logical decoding output

On 2017-09-24 13:36:56 +0300, Alvaro Hernandez wrote: >     However, if DMS uses it for what I'd call production use, I assume it is > actually production quality. I bet they do enough testing, and don't ship > software to potentially millions of customers if it doesn't work well. So... > first, I'

Re: [HACKERS] logical replication and statistics

Pavel Stehule writes: > I had two instances on one server with different port. I am sure, so > replication was functional. Only one issue is statistics > Master: > CREATE TABLE foo(id int primary key, a int); > CREATE PUBLICATION test_pub FOR TABLE foo; > INSERT INTO foo VALUES(1, 200); > slave

Re: [HACKERS] Built-in plugin for logical decoding output

Hi, On 2017-09-25 12:56:00 -0400, Andrew Dunstan wrote: > A general purpose lower bandwidth plugin might one supporting Protocol > Buffers. The downside is that unlike json it's not self-contained, you > need the message definitions to interpret the stream, AIUI. I think that makes it a non-start

Re: [HACKERS] Built-in plugin for logical decoding output

On 25/09/17 18:48, Alvaro Hernandez wrote: > > > On 25/09/17 19:39, Petr Jelinek wrote: >> >> Well, test_decoding is not meant for production use anyway, no need for >> middleware to support it. The pgoutput is primarily used for internal >> replication purposes, which is why we need something wi

Re: [HACKERS] logical replication and statistics

On 25/09/17 19:19, Tom Lane wrote: > Pavel Stehule writes: >> I had two instances on one server with different port. I am sure, so >> replication was functional. Only one issue is statistics > >> Master: > >> CREATE TABLE foo(id int primary key, a int); >> CREATE PUBLICATION test_pub FOR TABLE f

Re: [HACKERS] Built-in plugin for logical decoding output

On 09/25/2017 10:15 AM, Gregory Brail wrote: Yes. I'm advocating something "built-in" to Postgres. Any or all of those are likely a great starting point. I don't see a benefit to having this "in postgres". The whole reason we have built out a mature and extensible product is so that not everyt

Re: [HACKERS] Built-in plugin for logical decoding output

Alvaro Hernandez writes: > In my opinion, logical decoding plugins that don't come with core > are close to worthless (don't get me wrong): > - They very unlikely will be installed in managed environments (an area > growing significantly). > - As anything that is not in core, raises concerns by

Re: [HACKERS] Built-in plugin for logical decoding output

On 09/25/2017 10:19 AM, Petr Jelinek wrote: On 25/09/17 18:48, Alvaro Hernandez wrote:     In my opinion, logical decoding plugins that don't come with core are close to worthless (don't get me wrong): I respectfully disagree. As do I. - They very unlikely will be installed in mana

Re: [HACKERS] Built-in plugin for logical decoding output

On 25/09/17 19:26, Tom Lane wrote: > Alvaro Hernandez writes: >> In my opinion, logical decoding plugins that don't come with core >> are close to worthless (don't get me wrong): > >> - They very unlikely will be installed in managed environments (an area >> growing significantly). >> - As anyt

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

> On Sep 25, 2017, at 07:55, Andrew Dunstan > wrote: > Let's ask a couple of users who I think are or have been actually > hurting on this point. Christophe and David, any opinions? Since about 90% of what I encounter in this area are automatically-generated migrations, having a clear set of (

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On Sep 25, 2017, at 10:55, Andrew Dunstan wrote: > Let's ask a couple of users who I think are or have been actually > hurting on this point. Christophe and David, any opinions? If I understand the issue correctly, I think I’d be fine with requiring ALTER TYPE ADD LABEL to be disallowed in a t

[HACKERS] Reading backup label file for checkpoint and redo location during crash recovery

Hi there, During crash recovery, last checkpoint record information is obtained from the backup label if present, instead of getting it from the control file. This behavior is causing PostgreSQL database cluster not to come up until the backup label file is deleted (as the error message says).

Re: [HACKERS] Built-in plugin for logical decoding output

On 09/25/2017 10:32 AM, Petr Jelinek wrote: On 25/09/17 19:26, Tom Lane wrote: Alvaro Hernandez writes: There is already about 3 million output plugins out there so I think we did reasonable job there. The fact that vast majority of that are various json ones gives reasonable hint that we s

Re: [HACKERS] Built-in plugin for logical decoding output

On 2017-09-25 10:38:52 -0700, Joshua D. Drake wrote: > On 09/25/2017 10:32 AM, Petr Jelinek wrote: > > On 25/09/17 19:26, Tom Lane wrote: > > > Alvaro Hernandez writes: > > > > > There is already about 3 million output plugins out there so I think we > > did reasonable job there. The fact that v

Re: [HACKERS] Reading backup label file for checkpoint and redo location during crash recovery

Greetings Satya, * Satyanarayana Narlapuram (satyanarayana.narlapu...@microsoft.com) wrote: > During crash recovery, last checkpoint record information is obtained from > the backup label if present, instead of getting it from the control file. > This behavior is causing PostgreSQL database clus

Re: [HACKERS] Built-in plugin for logical decoding output

On 2017-09-25 19:32:29 +0200, Petr Jelinek wrote: > On 25/09/17 19:26, Tom Lane wrote: > > Alvaro Hernandez writes: > >> In my opinion, logical decoding plugins that don't come with core > >> are close to worthless (don't get me wrong): > > > >> - They very unlikely will be installed in managed

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

Robert Haas writes: > On Mon, Sep 25, 2017 at 10:22 AM, Tom Lane wrote: >> Thomas Munro writes: >>> So, do we want this patch? >> I think we don't really have a lot of choice. I propose applying this >> as far back as 9.6 --- anyone think differently? > +1. If applies to 9.5 and 9.4 without

Re: [HACKERS] Built-in plugin for logical decoding output

On 09/25/2017 10:43 AM, Andres Freund wrote: On 2017-09-25 10:38:52 -0700, Joshua D. Drake wrote: On 09/25/2017 10:32 AM, Petr Jelinek wrote: On 25/09/17 19:26, Tom Lane wrote: Alvaro Hernandez writes: There is already about 3 million output plugins out there so I think we did reasonable

Re: [HACKERS] Reading backup label file for checkpoint and redo location during crash recovery

On 2017-09-25 13:43:32 -0400, Stephen Frost wrote: > Greetings Satya, > > * Satyanarayana Narlapuram (satyanarayana.narlapu...@microsoft.com) wrote: > > During crash recovery, last checkpoint record information is obtained from > > the backup label if present, instead of getting it from the contr

Re: [HACKERS] Built-in plugin for logical decoding output

Andres Freund writes: >> On 25/09/17 19:26, Tom Lane wrote: >>> The problem with this type of argument is that it leads directly to the >>> conclusion that every feature users want must be in core. > ... I don't think that should mean that there's no possible output > plugin that could/should be

[HACKERS][BUG] Cache invalidation for queries that contains const of temporary composite type

Hello everyone! I have found out the problem when try to sequentially call the function that casts constant to composite type of temporary table that is deleted ateach transaction termination (i.e. at each function call completion). For example, we have the following function 'test': CREAT

Re: [HACKERS] logical replication and statistics

2017-09-25 19:23 GMT+02:00 Petr Jelinek : > On 25/09/17 19:19, Tom Lane wrote: > > Pavel Stehule writes: > >> I had two instances on one server with different port. I am sure, so > >> replication was functional. Only one issue is statistics > > > >> Master: > > > >> CREATE TABLE foo(id int primar

Re: [HACKERS] Reading backup label file for checkpoint and redo location during crash recovery

On Mon, Sep 25, 2017 at 7:43 PM, Stephen Frost wrote: > Greetings Satya, > > * Satyanarayana Narlapuram (satyanarayana.narlapu...@microsoft.com) wrote: > > During crash recovery, last checkpoint record information is obtained > from the backup label if present, instead of getting it from the cont

Re: [HACKERS] psql \d sequence display

Hello, This should be fixed for PG10, so if you have any feedback on the design, please let me know soon. Works for me on head against a 9.6 server, which is good. My 0.02 €: \d+ does not show more. Maybe Type, Min, Max, Inc & Cycles are enough for \d? The next/future or last/previous val

Re: [HACKERS] Built-in plugin for logical decoding output

On 2017-09-25 13:50:29 -0400, Tom Lane wrote: > Andres Freund writes: > >> On 25/09/17 19:26, Tom Lane wrote: > >>> The problem with this type of argument is that it leads directly to the > >>> conclusion that every feature users want must be in core. > > > ... I don't think that should mean that

Re: [HACKERS] Built-in plugin for logical decoding output

Andres, all, * Andres Freund (and...@anarazel.de) wrote: > On 2017-09-25 19:32:29 +0200, Petr Jelinek wrote: > > On 25/09/17 19:26, Tom Lane wrote: > > > Alvaro Hernandez writes: > > >> In my opinion, logical decoding plugins that don't come with core > > >> are close to worthless (don't get me

Re: [HACKERS] Reading backup label file for checkpoint and redo location during crash recovery

* Magnus Hagander (mag...@hagander.net) wrote: > On Mon, Sep 25, 2017 at 7:43 PM, Stephen Frost wrote: > > * Satyanarayana Narlapuram (satyanarayana.narlapu...@microsoft.com) wrote: > > > During crash recovery, last checkpoint record information is obtained > > from the backup label if present, in

[HACKERS] Enhancements to passwordcheck

Hi hackers, Currently, the passwordcheck module provides a few basic checks to strengthen passwords. However, any configuration must be ready at compile time, and many common password requirements cannot be enforced without creating a custom version of this module. I think there are a number of

Re: [HACKERS] PATCH: pgbench - break out timing data for initialization phases

Hello Doug, total time: 316.03 s (insert 161.60 s, commit 0.64 s, vacuum 60.77 s, index 93.01 s) Definitely interesting. There is a "ready for committers" patch in the CF which extensively rework the initialization: it becomes customizable, and this approach may not work as is after that.

Re: [HACKERS] PATCH: pgbench - option to build using ppoll() for larger connection counts

On 2017-09-25 18:01:40 +, Rady, Doug wrote: > This patch enables building pgbench to use ppoll() instead of select() > to allow for more than (FD_SETSIZE - 10) connections. As implemented, > when using ppoll(), the only connection limitation is system resources. Hm, is there any need of using

Re: [HACKERS] PATCH: pgbench - option to build using ppoll() for larger connection counts

Hello Again, Two patches attached. One based on REL9_6_STABLE. I'd be surprise that there would be a backport unless there is a bug, so this one might not be useful. One based on 'master' which can also apply to REL_10_STABLE. Could you add your patches to the next CF? -- Fabien. --

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/25/2017 01:34 PM, David E. Wheeler wrote: > On Sep 25, 2017, at 10:55, Andrew Dunstan > wrote: > >> Let's ask a couple of users who I think are or have been actually >> hurting on this point. Christophe and David, any opinions? > If I understand the issue correctly, I think I’d be fine wi

Re: [HACKERS] Built-in plugin for logical decoding output

On 25/09/17 20:18, Andres Freund wrote: On 2017-09-24 13:36:56 +0300, Alvaro Hernandez wrote:     However, if DMS uses it for what I'd call production use, I assume it is actually production quality. I bet they do enough testing, and don't ship software to potentially millions of customers if

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

Robert Haas writes: > On Mon, Sep 25, 2017 at 10:22 AM, Tom Lane wrote: >> I think we don't really have a lot of choice. I propose applying this >> as far back as 9.6 --- anyone think differently? > +1. If applies to 9.5 and 9.4 without a lot of work, I think we > should apply it there as well

Re: [HACKERS] Built-in plugin for logical decoding output

On 25/09/17 20:31, Joshua D. Drake wrote: On 09/25/2017 10:19 AM, Petr Jelinek wrote: On 25/09/17 18:48, Alvaro Hernandez wrote: In my opinion, logical decoding plugins that don't come with core are close to worthless (don't get me wrong): I respectfully disagree. As do I.    

Re: [HACKERS] Built-in plugin for logical decoding output

On 09/25/2017 11:31 AM, Alvaro Hernandez wrote: Whether or not they are included in a managed environment is generally based on two things: 1. Safety (why RDS doesn't allow certain C extensions) 2. Community/Popularity (Exactly why RDS has PostGIS)     A. Demand with a prerequis

Re: [HACKERS] Built-in plugin for logical decoding output

On 2017-09-25 21:31:11 +0300, Alvaro Hernandez wrote: > > > > - Distribution and testing are non-trivial: many OS/archs combinations. > > > > > > > > Yes, it is. Why would we want to increase that burden to this community? > > >     That's a different story, and one I cannot argue against. If e

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 9/22/17 16:46, Peter Geoghegan wrote: > But you are *already* canonicalizing ICU collation names as BCP 47. My > point here is: Why not finish the job off, and *also* canonicalize > colcollate in the same way? This won't break ucol_open() if we take > appropriate precautions when we go to use th

Re: [HACKERS] Patch to address concerns about ICU collcollate stability in v10 (Was: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?)

On 9/25/17 00:24, Peter Geoghegan wrote: > * Creates root collation as root-x-icu (collcollate "root"), not > und-x-icu. "und" means undefined language. I'm curious about this point. "und" is defined in BCP 47. I don't see "root" defined anywhere. ICU converts the root collation to "und", AFAIK

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

Andrew Dunstan writes: > OK, that seems to be the consensus. So let's apply the blacklist patch > and then separately remove the 'created in the same transaction' test. > We'll need to adjust the regression tests and docs accordingly. Agreed. I'll work on that in a little bit.

Re: [HACKERS] [PATCH] Generic type subscripting

On Fri, Sep 22, 2017 at 3:51 PM, Peter Eisentraut wrote: > On 9/21/17 11:24, Dmitry Dolgov wrote: >> One last thing that I need to clarify. Initially there was an idea to >> minimize changes in `pg_type` > > I see, but there is no value in that if it makes everything else more > complicated. +1

Re: [HACKERS] Fix number skipping in to_number

On Monday, 25 September 2017, Nathan Wagner wrote: > On Thu, Aug 17, 2017 at 12:33:02PM +0100, Oliver Ford wrote: > > > Ok I've made that change in the attached v3. I'm not sure as I'm on > > en_US.UTF-8 locale too. Maybe something Windows specific? > > This patch applies against master (8485a25a

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

I wrote: > Hmm, so I tested this patch on my RHEL6 box (kernel 2.6.32) and it > immediately fell over with > 2017-09-25 14:23:48.410 EDT [325] FATAL: could not resize shared memory > segment "/PostgreSQL.1682054886" to 6928 bytes: Operation not supported > during startup. I wonder whether we nee

Re: [HACKERS] Built-in plugin for logical decoding output

On Mon, Sep 25, 2017 at 11:37 AM, Joshua D. Drake wrote: > On 09/25/2017 11:31 AM, Alvaro Hernandez wrote: > >> >> > Whether or not they are included in a managed environment is generally >>> based on two things: >>> >>> 1. Safety (why RDS doesn't allow certain C extensions) >>> 2. Commun

Re: [HACKERS] Built-in plugin for logical decoding output

On Mon, Sep 25, 2017 at 8:20 PM, Alvaro Hernandez wrote: > > > On 25/09/17 20:18, Andres Freund wrote: > >> On 2017-09-24 13:36:56 +0300, Alvaro Hernandez wrote: >> >>> However, if DMS uses it for what I'd call production use, I assume >>> it is >>> actually production quality. I bet they do

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Mon, Sep 25, 2017 at 11:40 AM, Peter Eisentraut wrote: > On 9/22/17 16:46, Peter Geoghegan wrote: >> But you are *already* canonicalizing ICU collation names as BCP 47. My >> point here is: Why not finish the job off, and *also* canonicalize >> colcollate in the same way? This won't break ucol_

Re: [HACKERS] Reading backup label file for checkpoint and redo location during crash recovery

Thank you! Got it. -Original Message- From: Stephen Frost [mailto:sfr...@snowman.net] Sent: Monday, September 25, 2017 10:57 AM To: Magnus Hagander Cc: Satyanarayana Narlapuram ; PostgreSQL-development Subject: Re: [HACKERS] Reading backup label file for checkpoint and redo location

Re: [HACKERS] Built-in plugin for logical decoding output

On Sep 25, 2017 1:39 PM, "Joshua D. Drake" wrote: > On 09/25/2017 10:32 AM, Petr Jelinek wrote: > >> On 25/09/17 19:26, Tom Lane wrote: >> >>> Alvaro Hernandez writes: >>> >> > >> There is already about 3 million output plugins out there so I think we >> did reasonable job there. The fact that v

Re: [HACKERS] Patch to address concerns about ICU collcollate stability in v10 (Was: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?)

On Mon, Sep 25, 2017 at 11:42 AM, Peter Eisentraut wrote: > On 9/25/17 00:24, Peter Geoghegan wrote: >> * Creates root collation as root-x-icu (collcollate "root"), not >> und-x-icu. "und" means undefined language. > > I'm curious about this point. "und" is defined in BCP 47. I don't see > "root

Re: [HACKERS] Row Level Security Documentation

On 5 August 2017 at 10:03, Fabien COELHO wrote: > Patch applies cleanly, make html ok, new table looks good to me. > So I started looking at this patch, but before even considering the new table proposed, I think there are multiple issues that need to be resolved with the current docs: Firstly,

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Mon, Sep 25, 2017 at 12:14 PM, Peter Geoghegan wrote: > But then our users categorically have to know about both formats, > without any practical benefit to make up for it. You will also get > people that don't realize that only one format is supported on some > versions if go this way. Oh, an

Re: [HACKERS] Built-in plugin for logical decoding output

On 25/09/17 19:48, Joshua D. Drake wrote: > On 09/25/2017 10:43 AM, Andres Freund wrote: >> On 2017-09-25 10:38:52 -0700, Joshua D. Drake wrote: >>> On 09/25/2017 10:32 AM, Petr Jelinek wrote: On 25/09/17 19:26, Tom Lane wrote: > Alvaro Hernandez writes: >>> There is already abo

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

I wrote: > Rather than dig into the guts of glibc to find that out, though, I think > we should just s/fallocate/posix_fallocate/g on this patch. The argument > for using the former seemed pretty thin to begin with. Pushed with that change; we'll soon see what the buildfarm thinks. I suspect tha

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

On Tue, Sep 26, 2017 at 7:56 AM, Tom Lane wrote: > I wrote: >> Hmm, so I tested this patch on my RHEL6 box (kernel 2.6.32) and it >> immediately fell over with >> 2017-09-25 14:23:48.410 EDT [325] FATAL: could not resize shared memory >> segment "/PostgreSQL.1682054886" to 6928 bytes: Operation

  1   2   >