Re: [HACKERS] Hash Functions

Robert Haas writes: > After some further thought, I propose the following approach to the > issues raised on this thread: > 1. Allow hash functions to have a second, optional support function, > similar to what we did for btree opclasses in > c6e3ac11b60ac4a8942ab964252d51c1c0bd8845. The second

[HACKERS] Garbled comment in postgresGetForeignJoinPaths

postgres_fdw.c around line 4500: /* * If there is a possibility that EvalPlanQual will be executed, we need * to be able to reconstruct the row using scans of the base relations. * GetExistingLocalJoinPath will find a suitable path for this purpose in * the path list of the

Re: [HACKERS] Function to move the position of a replication slot

On 5/4/17 08:05, Magnus Hagander wrote: > PFA a patch that adds a new function, pg_move_replication_slot, that > makes it possible to move the location of a replication slot without > actually consuming all the WAL on it. The name keeps confusing me. I understand "move" to be "rename" or possibly

Re: [HACKERS] [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.

On Wed, Aug 16, 2017 at 11:56 AM, Tom Lane wrote: >> So I still don't see what's wrong here, other than that the comment is >> evidently not half clear enough. > > I can get on board with that statement. Can you draft a better wording? Here is an attempt. Feel free to edit. -- Robert Haas Ent

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

On Wed, Aug 16, 2017 at 11:51 AM, Tom Lane wrote: > You have a point, but I'm not sure that this is such a bad compatibility > break as to be a reason not to change things to be more consistent. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --

Re: [HACKERS] Hash Functions

On Thu, Aug 3, 2017 at 6:47 PM, Robert Haas wrote: > That seems pretty lame, although it's sufficient to solve the > immediate problem, and I have to admit to a certain predilection for > things that solve the immediate problem without creating lots of > additional work. After some further though

Re: [HACKERS] [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.

Robert Haas writes: > On Wed, Aug 16, 2017 at 11:03 AM, Tom Lane wrote: >> Well, it has subplans, so formally I think it's restricted not unsafe >> --- but the parallel_safe marking on constructed paths/plans is only >> safe/not-safe, not a three-way. > True, but when parallel_safe it not set, t

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

Heikki Linnakangas writes: > This no longer works: > postgres=# CREATE TEXT SEARCH DICTIONARY public.simple_dict ( > TEMPLATE = pg_catalog.simple, > "STOPWORds" = english > ); > ERROR: unrecognized simple dictionary parameter: "STOPWORds" > In hindsight, perhaps we should always have

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

Hi, Hello! Just had a need for this feature, and took this to a short test drive. So some comments: - it'd be useful to display a retry percentage of all transactions, similar to what's displayed for failed transactions. - it'd be useful to also conveniently display the number of retried

Re: [HACKERS] Remove 1MB size limit in tsvector

On Thu, 10 Aug 2017 11:46:55 -0400 Tom Lane wrote: > Alexander Korotkov writes: > > ... > > You have random mix of tabs and spaces here. > > It's worth running pgindent over your code before submitting. It > should be pretty easy to set that up nowadays, see > src/tools/pgindent/README. (If

Re: [HACKERS] [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.

On Wed, Aug 16, 2017 at 11:03 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Aug 15, 2017 at 6:40 PM, Tom Lane wrote: >>> (In fact, a quick look shows a counterexample: if we pick a MinMaxAgg >>> path, that's parallel unsafe, but the original query might've been >>> completely safe.) > >>

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Heikki Linnakangas writes: > A couple of 32-bit x86 buildfarm members don't seem to be happy with > this. I'll investigate, but if anyone has a clue, I'm all ears... dromedary's issue seems to be alignment: TRAP: UnalignedPointer("(((uintptr_t) ((uintptr_t)(ptr)) + ((8) - 1)) & ~((uintptr_t) (

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

On Tue, Aug 15, 2017 at 4:36 PM, Tomas Vondra wrote: > You might say that people investigating issues in this area of code should > be aware of how HEAP_XMIN_FROZEN is defined, and perhaps you're right ... Yes, I think that's what I would say. I mean, if you happen to NOT know that committed|inv

Re: [HACKERS] SCRAM salt length

He Peter, > The SCRAM salt length is currently set as > > /* length of salt when generating new verifiers */ > #define SCRAM_DEFAULT_SALT_LEN 12 > > without further comment. > > I suspect that this length was chosen based on the example in RFC 5802 > (SCRAM-SHA-1) section 5. But the analog

Re: [HACKERS] [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.

Robert Haas writes: > On Tue, Aug 15, 2017 at 6:40 PM, Tom Lane wrote: >> (In fact, a quick look shows a counterexample: if we pick a MinMaxAgg >> path, that's parallel unsafe, but the original query might've been >> completely safe.) > I'm quite confused here. What's parallel-unsafe about a Mi

Re: [HACKERS] Orphaned files in base/[oid]

On Mon, Aug 14, 2017 at 2:56 PM, Andres Freund wrote: > I think there are some possibilities to close the gap here. We could > e.g. have .delete_on_crash marker files that get installed > when creating a new persistent relfilenode. If we set up things so they > get deleted post commit, but inside

Re: [HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

On Tue, Aug 15, 2017 at 10:37 AM, Piotr Stefaniak wrote: > One thing I tried was a combination of recovery_target_action = > 'shutdown' and recovery_target_time = 'now'. The result is surprising, > because then the standby tries to set the target to year 2000. Seems like this is just a plain old

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 08/16/2017 04:20 PM, Heikki Linnakangas wrote: On 05/06/2017 04:57 PM, David Rowley wrote: Andres mentioned in [2] that it might be worth exploring using atomics to do the same job. So I went ahead and did that, and came up with the attached, which is a slight variation on what he mentioned i

Re: [HACKERS] taking stdbool.h into use

Thomas Munro writes: > However my system has sizeof(bool) == 1 and so do all the systems I > have access to (x86 + POWER). Where can we find a computer with > sizeof(bool) == 4? According to the intertubes OSX on POWER and > Windows 32 bit systems had that in ancient prehistory but they don't >

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

On Fri, Aug 11, 2017 at 10:50 PM, Andres Freund wrote: > On 2017-07-21 19:32:02 +0300, Marina Polyakova wrote: > > Here is the third version of the patch for pgbench thanks to Fabien > Coelho > > comments. As in the previous one, transactions with serialization and > > deadlock failures are rolle

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 05/06/2017 04:57 PM, David Rowley wrote: Andres mentioned in [2] that it might be worth exploring using atomics to do the same job. So I went ahead and did that, and came up with the attached, which is a slight variation on what he mentioned in the thread. To keep things a bit more simple, an

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

On Tue, Aug 15, 2017 at 9:46 AM, Tom Lane wrote: > How big a deal do we think test coverage is? It looks like > ExecReScanGatherMerge is identical logic to ExecReScanGather, > which *is* covered according to coverage.postgresql.org, but > it wouldn't be too surprising if they diverge in future. >

[HACKERS] SCRAM salt length

The SCRAM salt length is currently set as /* length of salt when generating new verifiers */ #define SCRAM_DEFAULT_SALT_LEN 12 without further comment. I suspect that this length was chosen based on the example in RFC 5802 (SCRAM-SHA-1) section 5. But the analogous example in RFC 7677 (SCRA

Re: [HACKERS] Parallel Append implementation

Thanks for the benchmarking results! On Tue, Aug 15, 2017 at 11:35 PM, Rafia Sabih wrote: > Q4 | 244 | 12 | PA and PWJ, time by only PWJ - 41 12 seconds instead of 244? Whoa. I find it curious that we picked a Parallel Append with a bunch of non-partial plans when we could've just as easily pi

Re: [HACKERS] expanding inheritance in partition bound order

On Wed, Aug 16, 2017 at 11:06 AM, Amit Langote wrote: > >> This patch series is blocking a bunch of other things, so it would be >> nice if you could press forward with this quickly. > > Attached updated patches. > Review for 0001. The attached patch has some minor changes to the comments and co

Re: [HACKERS] POC: Sharing record typmods between backends

On Tue, Aug 15, 2017 at 8:34 PM, Andres Freund wrote: > On 2017-08-15 20:30:16 -0400, Robert Haas wrote: >> On Tue, Aug 15, 2017 at 6:06 PM, Andres Freund wrote: >> > Interesting. I was apparently thinking slightly differently. I'd have >> > thought we'd have Session struct in statically allocate

Re: [HACKERS] Orphaned files in base/[oid]

So having throught about this a bit more, and having had some real-world experience with the script now, I have an idea that might work and some questions to make it succeed. My thinking is to add a new form of vacuum called VACUUM FSCK. This would: 1. lock pg_class in exclusive mode (or do I nee

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

Hi 2017-08-15 4:37 GMT+02:00 Peter Eisentraut : > On 3/11/17 07:06, Pavel Stehule wrote: > > I am sending a updated version with separated sort direction in special > > variable > > This patch also needs a rebase. > I am sending rebased patch Regards Pavel > > -- > Peter Eisentraut

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

On 04/04/2017 10:13 AM, Daniel Gustafsson wrote: On 04 Apr 2017, at 05:52, Alvaro Herrera wrote: Daniel Gustafsson wrote: Testing DefElem options is done with both strcmp() and pg_strcasecmp() a bit mixed. Since the option defnames are all lowercased, either via IDENT, keyword rules or “by ha

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Wed, Aug 16, 2017 at 3:31 AM, Ashutosh Bapat wrote: > There are two ways we can do this > 1. In expand_inherited_rtentry(), remember (childRTE and childRTIndex) > or just childRTIndex (using this we can fetch childRTE calling > rtfetch()) of intermediate partitioned tables. Once we are done > e

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Aug 16, 2017 at 7:23 AM, Amit Kapila wrote: > On Tue, Aug 15, 2017 at 7:15 PM, Robert Haas wrote: >> On Sat, Aug 12, 2017 at 9:18 AM, Amit Kapila wrote: >>> I think skipping a generation of gather paths for scan node or top >>> level join node generated via standard_join_search seems str

Re: [HACKERS] expanding inheritance in partition bound order

On 16 August 2017 at 11:06, Amit Langote wrote: > Attached updated patches. Thanks Amit for the patches. I too agree with the overall approach taken for keeping the locking order consistent: it's best to do the locking with the existing find_all_inheritors() since it is much cheaper than to loc

Re: [HACKERS] [COMMITTERS] pgsql: Include foreign tables in information_schema.table_privileges

On Tue, Aug 15, 2017 at 7:41 PM, Peter Eisentraut wrote: > Include foreign tables in information_schema.table_privileges > > This appears to have been an omission in the original commit > 0d692a0dc9f. All related information_schema views already include > foreign tables. > > Reported-by: Nicolas

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Aug 15, 2017 at 7:15 PM, Robert Haas wrote: > On Sat, Aug 12, 2017 at 9:18 AM, Amit Kapila wrote: >> I think skipping a generation of gather paths for scan node or top >> level join node generated via standard_join_search seems straight >> forward, but skipping for paths generated via geq

Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken

This patch is fixing similar problem reported in Logical replication also by another user. Message: 20170524173644.1440.53...@wrigleys.postgresql.org Bug reference: 14669 Logged by: Igor Neym

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

2017-08-16 12:47 GMT+02:00 Thomas Munro : > On Wed, Aug 16, 2017 at 9:56 PM, Pavel Stehule > wrote: > > 2017-08-16 6:58 GMT+02:00 Thomas Munro : > >> Stray blank line. > > > > I am not sure if I see last issue well. > > I meant this: > > > + > > > ... but it doesn't really matter. >

[HACKERS] Use PG_DETOAST_DATUM_SLICE in bitlength() (was Re: PG_GETARG_GISTENTRY?)

On 04/25/2017 04:10 AM, Noah Misch wrote: On Mon, Apr 24, 2017 at 09:25:25AM -0700, Mark Dilger wrote: Noah, if you left this case out intentionally, sorry for the noise. I did not immediately see any reason not to follow your lead for this function. This is not following my lead, but that do

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

On Wed, Aug 16, 2017 at 9:56 PM, Pavel Stehule wrote: > 2017-08-16 6:58 GMT+02:00 Thomas Munro : >> Stray blank line. > > I am not sure if I see last issue well. I meant this: + ... but it doesn't really matter. > Sending updated patch Thanks, looks good. New status: ready for

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

Hi, hackers! > 21 июня 2017 г., в 12:52, Shubham Barai написал(а): > > Hi, > ... > I know that. This is the old version of the patch. I had sent updated patch > later. Please have a look at updated patch. > > Regards, > Shubham Here is some information for reviewers. This applies to patches

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

Hi 2017-08-16 6:58 GMT+02:00 Thomas Munro : > On Thu, Jul 27, 2017 at 4:19 AM, Pavel Stehule > wrote: > > here is a patch - it is trivial > > The feature makes sense, follows an existing example (PSQL_EDITOR), > and works nicely. > >is platform-dependent. Use of the pager can be disable

Re: [HACKERS] [PATCH] Remove unused argument in btree_xlog_split

On 04/06/2017 03:21 PM, Aleksander Alekseev wrote: Hi Robert, Hmm. I don't see anything wrong with that, particularly, but it seems we also don't need the distinction between XLOG_BTREE_SPLIT_L and XLOG_BTREE_SPLIT_L_ROOT or likewise between XLOG_BTREE_SPLIT_R and XLOG_BTREE_SPLIT_R_ROOT -- in

Re: [HACKERS] Secondary index access optimizations

On 14.08.2017 19:33, Konstantin Knizhnik wrote: On 14.08.2017 12:37, Konstantin Knizhnik wrote: Hi hackers, I am trying to compare different ways of optimizing work with huge append-only tables in PostgreSQL where primary key is something like timestamp and queries are usually accessing mos

Re: [HACKERS] Stats for triggers on partitioned tables not shown in EXPLAIN ANALYZE

Fujita-san, Thanks for reporting the bugs and patches to fix the same. On 2017/08/15 21:20, Etsuro Fujita wrote: > Hi hackers, > > I noticed that runtime stats for BEFORE ROW INSERT triggers on leaf > partitions of partitioned tables aren't reported in EXPLAIN ANALYZE. Here > is an example: > >

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

Hello Masahiko-san, Yeah, once custom initialization patch get committed we can extend it. Attached updated patch. I've incorporated the all comments from Fabien to it, and changed it to single letter version. Patch applies and works. A few comments and questions about the code and document

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Wed, Aug 16, 2017 at 4:24 PM, Masahiko Sawada wrote: > FWIW, in my opinion if tte current behavior of 'N(a,b)' could confuse > users and we want to break the backward compatibility, I'd rather like > to remove that style in PostgreSQL 10 and to raise an syntax error to > user for more safety. A

Re: [HACKERS] Foreign tables privileges not shown in information_schema.table_privileges

On Tue, 15 Aug 2017 19:41:40 -0400 Peter Eisentraut wrote: > On 8/10/17 09:00, Nicolas Thauvin wrote: > > The information_schema.table_privileges view filters on regular > > tables and views. Foreign tables are not shown in this view but > > they are in other views of the information_schema like

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Aug 15, 2017 at 10:15 PM, Robert Haas wrote: > On Thu, Aug 10, 2017 at 8:00 AM, Ashutosh Bapat > wrote: >> Attached patches with the comments addressed. > > I have committed 0001-0003 as 480f1f4329f1bf8bfbbcda8ed233851e1b110ad4 > and e139f1953f29db245f60a7acb72fccb1e05d2442. Thanks a lot

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Fri, Aug 11, 2017 at 1:40 AM, Josh Berkus wrote: > On 08/09/2017 10:49 PM, Michael Paquier wrote: >> On Fri, Aug 4, 2017 at 8:19 AM, Masahiko Sawada >> wrote: >>> On Fri, Jul 28, 2017 at 2:24 PM, Noah Misch wrote: This item appears under "decisions to recheck mid-beta". If anyone is >

<    1   2