Re: [HACKERS] 10.0

On 06/20/2016 10:14 PM, Robert Haas wrote: On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston wrote: 10.x is the desired output. 10.x is the output that some people desire. (explicitly skipped up-thread to add this -- please forgive my jumping in) Since we are

Re: [HACKERS] Protocol buffer support for Postgres

On 04/26/2016 08:06 AM, 陈天舟 wrote: I am interested in adding Protocol Buffer support for Postgres. Protocol Buffer occupies less space than JSON. More importantly, it has schema and is forward/backward compatible. All these make it a very good format for persistency. Have you investigated

Re: [HACKERS] Parser extensions (maybe for 10?)

On 04/13/2016 04:43 PM, Craig Ringer wrote: On 13 April 2016 at 22:11, José Luis Tallón <jltal...@adv-solutions.net <mailto:jltal...@adv-solutions.net>> wrote: [snip] I can certainly prepare a small patch for the first commitfest of 9.7 if this sounds viable. I'd

Re: [HACKERS] Parser extensions (maybe for 10?)

On 04/12/2016 06:45 AM, Craig Ringer wrote: On 12 April 2016 at 12:36, Arcadiy Ivanov > wrote: Is there any interest and/or tips to allow a pluggable parser or at least allow some syntactical pluggability by extensions? I think this may

Re: [HACKERS] Default Roles

On 04/07/2016 09:50 PM, Stephen Frost wrote: Robert, José, I've rebased this on top of master and added a few additional checks and regression tests. Applies and compiles cleanly, of course. Passes all 164 tests, too. - make installcheck-world ok - interdiff checked, nothing very surprising

[HACKERS] [CommitFest App] Feature request -- review e-mail additions

Hello, Just wanted to suggest two minor mods to the review e-mails auto-generated by the app: * Prepend a [review] tag to the e-mail subject ... so that e-mails sent to -hackers will read " [HACKERS] [review] " * Auto-CC the patch author on this e-mail I guess this should

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 03/30/2016 06:14 PM, Robert Haas wrote: So basically the use of the ENCRYPTED keyword means "if it does already seem to be the sort of MD5 blob we're expecting, turn it into that". If it does NOT already seem to be... I guess? And we just rely on the format to distinguish between an MD5

Re: [HACKERS] Default Roles

If this gets into 9.6, we give users another full release cycle to ensure there are no reserved rolenames in use. Then, I reckon that the additional roles/system-role-based fine-grained authorization could go in for 9.7 without much trouble -- this is badly needed, IMHO Thank you, Stephen and

Re: [HACKERS] How can we expand PostgreSQL ecosystem?

On 03/07/2016 07:30 AM, Tsunakawa, Takayuki wrote: From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mark Kirkwood For cloud - in particular Openstack (which I am working with ATM), the biggest thing would be: - multi-master replication or

Re: [HACKERS] PostgreSQL Auditing

On 02/02/2016 02:05 AM, Curtis Ruck wrote: [snip] P.S., do you know what sucks, having a highly performant PostGIS database that works great, and being told to move to Oracle or SQL Server (because they have auditing). Even though they charge extra for Geospatial support (seriously?) or

Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

On 12/30/2015 06:46 AM, Simon Riggs wrote: On 30 December 2015 at 00:17, Joe Conway > wrote: On 12/29/2015 07:15 AM, Tom Lane wrote: > Yeah. Use of the same x/y notation with two different bases seems like > a recipe for

Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

On 12/29/2015 01:18 PM, Heikki Linnakangas wrote: On 29/12/15 07:14, Joe Conway wrote: I wonder why "Latest checkpoint's NextXID" is formated like this: 8<- printf(_("Latest checkpoint's NextXID: %u/%u\n"),

Re: [HACKERS] New email address

On 11/26/2015 09:12 PM, Greg Stark wrote: On Wed, Nov 25, 2015 at 6:55 PM, Tom Lane wrote: But my point was that while the RFC says what to put there there's absolutely no reference anywhere for when the information should cause any MUA or MTA to behave differently.

Re: [HACKERS] New email address

On 11/24/2015 07:55 PM, Tom Lane wrote: [snip] The clearly critical thing, though, is that when forwarding a message from a person at a DMARC-using domain, we would have to replace the From: line with something @postgresql.org. This is what gets it out from under the original domain's DMARC

Re: [HACKERS] Note about comparation PL/SQL packages and our schema/extensions

On 11/05/2015 01:31 PM, Craig Ringer wrote: On 5 November 2015 at 14:36, Pavel Stehule wrote: [snip] 2. The schema variables - a server side session (can be emulated now) and server side local schema session variables (doesn't exist) is pretty useful for storing some

Re: [HACKERS] Patent warning about the Greenplum source code

On 11/02/2015 02:41 PM, Simon Riggs wrote: On 1 November 2015 at 07:47, Bruce Momjian > wrote: On Sun, Nov 1, 2015 at 01:27:13AM -0500, Bruce Momjian wrote: > On Fri, Oct 30, 2015 at 04:47:35AM -0400, Bruce Momjian wrote: > > Therefore, I

Re: [HACKERS] pg_basebackup and replication slots

On 10/26/2015 12:58 PM, Joshua D. Drake wrote: Hello, The fact that pg_basebackup doesn't use replicaiton slots, is that a technical limitation or just a, "we need a patch"? Given the rest of the thread any possibility whatsoever that it'd be backpatched into 9.5 before release?

Re: [HACKERS] questions about PG update performance

On 10/26/2015 05:49 AM, Amit Kapila wrote: On Mon, Oct 26, 2015 at 9:03 AM, Любен Каравелов > wrote: > > > - Цитат от Kisung Kim (ks...@bitnine.co.kr ), на 26.10.2015 в 04:36 - > > > However, what I want to know

Re: [HACKERS] Duplicated assignment of slot_name in walsender.c

On 10/22/2015 12:36 AM, Alvaro Herrera wrote: Andres Freund wrote: That seems fairly insignificant. For one this is a rather infrequent and expensive operation, for another every decent compiler can optimize those away. Note that those duplicate strlen() calls are there in a lot of places in

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On 09/15/2015 06:57 PM, Anastasia Lubennikova wrote: Proposal Clarification. I see that discussion become too complicated. So, I'd like to clarify what we are talking about. [snip] What are we doing now: CREATE UNIQUE INDEX on tbl(f1,f2); CREATE INDEX on tbl(f1, f2, f3, f4); [snip]

[HACKERS] Proposal: backend niceness / session_priority

Hackers, I have found myself needing to run some maintenance routines (VACUUM, REINDEX, REFRESH MATERIALIZED VIEW mostly) at a lower priority so as not to disturb concurrent *highly transactional* connections. This issue is also noted within the TODO[0] list in the Wiki . * There was

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 05/19/2015 09:00 PM, Simon Riggs wrote: [snip] I think the idea of having SET SESSION AUTH pass a cookie, and only let RESET SESSION AUTH work when the same cookie is supplied, is pretty reasonable. As long as the cookie is randomly generated for each use, then I don't

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 05/13/2015 06:03 AM, Alvaro Herrera wrote: Craig Ringer wrote: For some time I've wanted a way to SET SESSION AUTHORISATION or SET ROLE in a way that cannot simply be RESET, so that a connection may be handed to a less-trusted service or application to do some work with. Some years back, I

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 05/17/2015 07:39 PM, Tom Lane wrote: =?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= jltal...@adv-solutions.net writes: On the other hand, ISTM that what we all intend to achieve is some Postgres equivalent of the SUID bit... so why not just do something equivalent? --- LOGIN-- as user

Re: [HACKERS] multixacts woes

On 05/08/2015 09:57 PM, Josh Berkus wrote: [snip] It's certainly possible to have workloads triggering that, but I think it's relatively uncommon. I in most cases I've checked the multixact consumption rate is much lower than the xid consumption. There are some exceptions, but often that's

Re: [HACKERS] Fwd: [GENERAL] 4B row limit for CLOB tables

On 04/27/2015 08:49 AM, Jim Nasby wrote: On 4/25/15 1:19 PM, Bruce Momjian wrote: Note if you are storing a table with rows that exceed 2KB in size (aggregate size of each row) then the Maximum number of rows in a table may be limited to 4 Billion, see TOAST. That's not accurate

Re: [HACKERS] reducing our reliance on MD5

On 02/11/2015 03:55 PM, Claudio Freire wrote: On 02/11/2015 03:39 PM, Claudio Freire wrote: [snip] Seems the risk of someone either lifting pg_authid from disk or by hacking the system and being postgres, thereby accessing passwords stored somewhere else, is actually the bigger problem. But

Re: [HACKERS] reducing our reliance on MD5

On 02/11/2015 03:39 PM, Claudio Freire wrote: [snip] Seems the risk of someone either lifting pg_authid from disk or by hacking the system and being postgres, thereby accessing passwords stored somewhere else, is actually the bigger problem. But also one that should be reasonably easy (TM) to

Re: [HACKERS] reducing our reliance on MD5

On 02/11/2015 03:14 PM, Magnus Hagander wrote: [snip] The hash value in pg_authid already contains md5 as a prefix. No need for another column. Yes, but for variable length mechanism names (i.e. not just 3 chars) it would become increasingly difficult to differentiate between the algo name

Re: [HACKERS] reducing our reliance on MD5

On 02/11/2015 04:40 PM, Tom Lane wrote: =?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= jltal...@adv-solutions.net writes: In any case, just storing the password BLOB(text or base64 encoded) along with a mechanism identifier would go a long way towards making this part pluggable... just like we do with

Re: [HACKERS] Fwd: [GENERAL] 4B row limit for CLOB tables

On 02/03/2015 03:44 AM, Jim Nasby wrote: [snip] The alternative could be some long LOB (HugeOBject?) using the equivalent to serial8 whereas regular LOBs would use serial4. Well, it depends on how we did this. We could (for example) add a field to pg_class that determines what type to use

Re: [HACKERS] Fwd: [GENERAL] 4B row limit for CLOB tables

On 02/02/2015 09:36 PM, Roger Pack wrote: On 2/2/15, José Luis Tallón jltal...@adv-solutions.net wrote: On 01/31/2015 12:25 AM, Jim Nasby wrote: [snip] It's a bit more complex than that. First, toast isn't limited to bytea; it holds for ALL varlena fields in a table that are allowed to store

Re: [HACKERS] Fwd: [GENERAL] 4B row limit for CLOB tables

On 01/31/2015 12:25 AM, Jim Nasby wrote: [snip] It's a bit more complex than that. First, toast isn't limited to bytea; it holds for ALL varlena fields in a table that are allowed to store externally. Second, the limit is actually per-table: every table gets it's own toast table, and each

Re: [HACKERS] Additional role attributes superuser review

On 12/30/2014 04:16 PM, Stephen Frost wrote: [snip] The approach I was thinking was to document and implement this as impliciting granting exactly USAGE and SELECT rights, no more (not BYPASSRLS) and no less (yes, the role could execute functions). I agree that doing so would be strictly more

Re: [HACKERS] [COMMITTERS] pgsql: Use a bitmask to represent role attributes

On 12/23/2014 04:46 PM, Andres Freund wrote: [snip] I find Tom's concern about needing more than 64 attributes to be ill-founded; I can't really see that happening on any timescale that matters. Hmm... most probably, not (or so I hope)... Unless we begin to add many differerent capabilities,

[HACKERS] Proposal: two new role attributes and/or capabilities?

Hello, I've found myself needing two role capabilities? as of lately, when thinking about restricting some roles to the barely minimum allowed permissions needed to perform their duties ... as opposed to having a superuser role devoted to these task. The capabilities would be: *

Re: [HACKERS] Proposal: two new role attributes and/or capabilities?

On 12/23/2014 05:29 PM, Stephen Frost wrote: * José Luis Tallón (jltal...@adv-solutions.net) wrote: I've found myself needing two role capabilities? as of lately, when thinking about restricting some roles to the barely minimum allowed permissions needed to perform their duties

Re: [HACKERS] [COMMITTERS] pgsql: Use a bitmask to represent role attributes

On 12/23/2014 06:06 PM, Bruce Momjian wrote: On Tue, Dec 23, 2014 at 11:34:09AM -0500, Tom Lane wrote: Stephen Frost sfr...@snowman.net writes: If that's the only consideration for this, well, that's certainly quite straight-forward to change in the other direction too. The new function

Re: [HACKERS] Proposal: two new role attributes and/or capabilities?

On 12/23/2014 07:01 PM, David G Johnston wrote: Hmm the current documentation states that: The specified role_name must be a role that the current session user is a member of. I can see use cases where making the login role a member of every other used role quickly becomes a burden, and

Re: [HACKERS] Proposal: two new role attributes and/or capabilities?

On 12/23/2014 07:01 PM, David G Johnston wrote: [snip] So you want to say: GRANT IMPERSONATE TO bouncer; --covers the ALL requirement instead of GRANT victim1 TO bouncer; GRANT victim2 TO bouncer; etc... -- these would still be used to cover the limited users requirement ? |GRANT

Re: [HACKERS] Proposal: two new role attributes and/or capabilities?

On 12/23/2014 07:52 PM, Stephen Frost wrote: [snip] Manually performing VACUUM / VACUUM ANALYZE on the (few) affected tables every 12h or so fixes the performance problem for the particular queries without impacting the other users too much --- the tables and indexes in question have been moved

Re: [HACKERS] Proposal VACUUM SCHEMA

On 12/21/2014 10:30 PM, Fabrízio de Royes Mello wrote: [snip] I do agree that vacuum schema might very well be useful (I'll probably use it myself from time to time, too). ANALYZE SCHEMA (specially coupled with some transaction-wide SET statistics_target could be beneficial) And why

Re: [HACKERS] On partitioning

On 12/15/2014 07:42 AM, Claudio Freire wrote: [snip] If you do that, you start with empty partitions, and each insert updates the BRIN tuple. Avoiding concurrency loss in this case would be tricky, but in theory this could allow very general partition exclusion. In fact it could even work

Re: [HACKERS] On partitioning

On 12/12/2014 05:43 AM, Amit Langote wrote: [snip] In case of what we would have called a 'LIST' partition, this could look like ... FOR VALUES (val1, val2, val3, ...) Assuming we only support partition key to contain only one column in such a case. Hmmm…. [...] PARTITION BY LIST(col1 [,

Re: [HACKERS] On partitioning

On 12/13/2014 03:09 AM, Alvaro Herrera wrote: [snip] Arbitrary SQL expressions (including functions) are not the thing to use for partitioning -- at least that's how I understand this whole discussion. I don't think you want to do proofs as such -- they are expensive. Yup. Plus, it looks like

Re: [HACKERS] On partitioning

On 12/13/2014 05:57 PM, José Luis Tallón wrote: On 12/13/2014 03:09 AM, Alvaro Herrera wrote: [snip] Arbitrary SQL expressions (including functions) are not the thing to use for partitioning -- at least that's how I understand this whole discussion. I don't think you want to do proofs

Re: [HACKERS] Sequence Access Method WIP

On 12/02/2014 08:21 PM, Andres Freund wrote: [snip] 2. Instead of the single amdata field, make it possible for the implementation to define any number of fields with any datatype in the tuple. That would make debugging, monitoring etc. easier. My main problem with that approach is that it

Re: [HACKERS] Sequence Access Method WIP

On 12/03/2014 11:24 AM, Andres Freund wrote: On 2014-12-03 10:59:50 +0100, José Luis Tallón wrote: snip] I don't think the WAL logging would need to change much in comparison to the current solution. We'd just add the page number to the WAL record. The biggest advantage would be to require

Re: [HACKERS] PITR failing to stop before DROP DATABASE

On 11/25/2014 11:01 PM, Tomas Vondra wrote: [snip] So you could see the same after crash recovery, but it's a lot easier to reproduce with PITR. So we remove the files, and if there happens to be a crash at the right moment, it results in a database with a record in pg_database, but no

Re: [HACKERS] Additional role attributes superuser review

On 11/06/2014 03:31 AM, Robert Haas wrote: [snip] We haven't reached consensus on this one yet and I didn't want it to fall too far off the radar. Here is what I summarize as the current state of the discussion: 1. Syntax: ALTER ROLE role { ADD | DROP } CAPABILITY capability Though a bit

Re: [HACKERS] PageRepairFragmentation performance

On 11/18/2014 07:03 PM, Heikki Linnakangas wrote: When profiling replay the WAL generated by pgbench, I noticed the PageRepairFragmentation consumes a large fraction of the CPU time: [snip] 1. Replace the qsort with something cheaper. The itemid arrays being sorted are small, a few hundred

Re: [HACKERS] DDL Damage Assessment

On 10/03/2014 11:02 AM, Dimitri Fontaine wrote: Jim Nasby jim.na...@bluetreble.com writes: EXPLAIN ALTER TABLE I'm thinking it would be better to have something you could set at a session level, so you don't have to stick EXPLAIN in front of all your DDL. We were considering the

Re: [HACKERS] DDL Damage Assessment

to have it (the common answer) available in the next PostgreSQL release. Sounds very good, indeed. Count on me as tester :) -- José Luis Tallón -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] Changing the concept of a DATABASE

On 22/05/12 11:46, Simon Riggs wrote: On 21 May 2012 20:40, Stephen Frostsfr...@snowman.net wrote: This is important. I like the idea of breaking down the barriers between databases to allow it to be an option for one backend to access tables in multiple databases. The current mechanism

Re: [HACKERS] Changing the concept of a DATABASE

On 22/05/12 13:24, Simon Riggs wrote: On 22 May 2012 12:05, José Luis Tallónjltal...@nosys.es wrote: IMVHO: s/database/schema/g does resolve many of the problems that you were referring to... and 'dblink' should solve the rest, right? Please, feel free to point out what I am (most probably)

Re: [HACKERS] Changing the concept of a DATABASE

On 22/05/12 13:47, Simon Riggs wrote: On 22 May 2012 12:35, Florian Pflugf...@phlo.org wrote: * Allow users to access tables in1 database easily, with appropriate rights. That one I'm very sceptical about. In the long run, I think we want better separation of databases, not less, and this