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 >

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] 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] 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] 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] 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] 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] [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] 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] 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

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

[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

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. >

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] 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] [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] 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] 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] 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] 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] 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] 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] 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] 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] 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

[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] [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. >

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] 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] 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] 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] 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] 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] [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] 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] [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] 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] [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] 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] 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] 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] [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] 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] 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] [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] 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

[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] 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

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

Robert Haas writes: > On Wed, Aug 16, 2017 at 11:56 AM, Tom Lane wrote: >> I can get on board with that statement. Can you draft a better wording? > Here is an attempt. Feel free to edit. I think s/plan/query/ in the last bit would be better. Perhaps +* However, if force_parallel_mo

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

On Wed, Aug 16, 2017 at 12:49 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Aug 16, 2017 at 11:56 AM, Tom Lane wrote: >>> I can get on board with that statement. Can you draft a better wording? > >> Here is an attempt. Feel free to edit. > > I think s/plan/query/ in the last bit would b

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 2017-08-16 11:16:58 -0400, Tom Lane wrote: > 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("(((u

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

Robert Haas writes: > You want to push something, or should I do it? Go for it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On Wed, Aug 16, 2017 at 9:55 AM, Andres Freund wrote: > On 2017-08-16 11:16:58 -0400, Tom Lane wrote: >> 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 is

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Robert, Tom, On 2017-08-16 09:55:15 -0700, Andres Freund wrote: > > Not sure if this is your bug or if it's exposing a pre-existing > > deficiency in the atomics code, viz, failure to ensure that > > pg_atomic_uint64 is actually a 64-bit-aligned type. Andres? > I suspect it's the former. Suspe

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 2017-08-16 09:57:35 -0700, Peter Geoghegan wrote: > On Wed, Aug 16, 2017 at 9:55 AM, Andres Freund wrote: > > On 2017-08-16 11:16:58 -0400, Tom Lane wrote: > >> Heikki Linnakangas writes: > >> > A couple of 32-bit x86 buildfarm members don't seem to be happy with > >> > this. I'll investigate,

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

On 2017-08-16 14:20:02 +0200, Chris Travers wrote: > 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.

Re: [HACKERS] Hash Functions

On Wed, Aug 16, 2017 at 12:38 PM, Tom Lane wrote: > 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 i

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 08/16/2017 08:10 PM, Andres Freund wrote: Afaict shm_create/shm_toc_allocate don't actually guarantee that the end of the toc's memory is suitably aligned. But I didn't yet have any coffee, so ... Robert, I'm not quite sure what the intended behaviour of shm_toc is wrt alignment. I see that

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane wrote: > 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

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On Wed, Aug 16, 2017 at 1:19 PM, Heikki Linnakangas wrote: > Yeah, that's the gist of it. > > The attached patch seems to fix this. I'm not too familiar with this DSM > stuff, but this seems right to me. Unless someone has a better idea soon, > I'll commit this to make the buildfarm happy. Mmm, c

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Hi, On 2017-08-16 20:19:29 +0300, Heikki Linnakangas wrote: > diff --git a/src/backend/storage/ipc/shm_toc.c > b/src/backend/storage/ipc/shm_toc.c > index 9f259441f0..121d5a1ec9 100644 > --- a/src/backend/storage/ipc/shm_toc.c > +++ b/src/backend/storage/ipc/shm_toc.c > @@ -44,7 +44,7 @@ shm_toc_

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Heikki Linnakangas writes: > On 08/16/2017 08:10 PM, Andres Freund wrote: >> Seems like we'd just have to add alignment of the total size to >> shm_toc_estimate()? > Yeah, that's the gist of it. I can confirm that on dromedary, that regression test case is attempting to create a TOC with a not-w

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

I wrote: > I can confirm that on dromedary, that regression test case is attempting > to create a TOC with a not-well-aligned size: 93268 = 0x16c54 bytes. ... although, on closer look, it still seems like we have a fundamental bit of schizophrenia here, because on this machine $ grep ALIGN pg_con

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Andres Freund writes: > Don't think we require BUFFERALIGN - MAXALIGN ought to be > sufficient. Uh, see my other message just now. > The use of BUFFERALIGN presumably is to space out things > into different cachelines, but that doesn't really seem to be important > with this. Then we can just a

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 2017-08-16 13:40:09 -0400, Tom Lane wrote: > I wrote: > > I can confirm that on dromedary, that regression test case is attempting > > to create a TOC with a not-well-aligned size: 93268 = 0x16c54 bytes. > > ... although, on closer look, it still seems like we have a fundamental > bit of schizo

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On Wed, Aug 16, 2017 at 1:40 PM, Tom Lane wrote: > I was wondering why the shm_toc code was using BUFFERALIGN and not > MAXALIGN, and I now suspect that the answer is "it's an entirely > undocumented kluge to make the atomics code not crash on 32-bit > machines, so long as nobody puts a pg_atomic_

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 2017-08-16 13:44:28 -0400, Tom Lane wrote: > Andres Freund writes: > > Don't think we require BUFFERALIGN - MAXALIGN ought to be > > sufficient. > > Uh, see my other message just now. Yup, you're right. > > The use of BUFFERALIGN presumably is to space out things > > into different cachelin

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On Wed, Aug 16, 2017 at 1:44 PM, Tom Lane wrote: > I was feeling a bit uncomfortable with the BUFFERALIGN_DOWN() for a > different reason: if the caller has specified the exact amount of space it > needs, having shm_toc_create discard some could lead to an unexpected > failure. Well, that's why H

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On August 16, 2017 10:47:23 AM PDT, Robert Haas wrote: >On Wed, Aug 16, 2017 at 1:40 PM, Tom Lane wrote: >> I was wondering why the shm_toc code was using BUFFERALIGN and not >> MAXALIGN, and I now suspect that the answer is "it's an entirely >> undocumented kluge to make the atomics code not c

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Robert Haas writes: > On Wed, Aug 16, 2017 at 1:44 PM, Tom Lane wrote: >> I was feeling a bit uncomfortable with the BUFFERALIGN_DOWN() for a >> different reason: if the caller has specified the exact amount of space it >> needs, having shm_toc_create discard some could lead to an unexpected >> f

Re: [HACKERS] 10 beta docs: different replication solutions

On 7/30/17 21:34, Steve Singer wrote: > We don't seem to describe logical replication on > > https://www.postgresql.org/docs/10/static/different-replication-solutions.html > > The attached patch adds a section. Committed with some further tweaking, thanks! -- Peter Eisentraut http

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Andres Freund writes: > On 2017-08-16 13:40:09 -0400, Tom Lane wrote: >> I was wondering why the shm_toc code was using BUFFERALIGN and not >> MAXALIGN, and I now suspect that the answer is "it's an entirely >> undocumented kluge to make the atomics code not crash on 32-bit >> machines, so long as

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

Robert Haas writes: > On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane wrote: >> --> * reconstruct the row for EvalPlanQual(). Find an alternative local path >> Should the marked line simply be deleted? If not, what correction is >> appropriate? > Hmm, wow. My first thought was that it should just

Re: [HACKERS] Logical replication: stuck spinlock at ReplicationSlotRelease

On 6/23/17 20:58, Peter Eisentraut wrote: > On 6/23/17 16:15, Andres Freund wrote: >> On 2017-06-23 13:26:58 -0400, Alvaro Herrera wrote: >>> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have >>> some elog(DEBUG1) calls with the slot spinlock held. That's probably >>> uncool.

Re: [HACKERS] Broken link to DocBook XSL Stylesheets

On 6/20/17 22:20, Masahiko Sawada wrote: > Hi, > > In J.2. Tool Sets section of documentation, there is a link to DocBook > XSL Stylesheets but that link seems no longer available. I got 404 > error. > > J.2. Tool Sets > > > A

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 08/16/2017 09:00 PM, Tom Lane wrote: Robert Haas writes: On Wed, Aug 16, 2017 at 1:44 PM, Tom Lane wrote: I was feeling a bit uncomfortable with the BUFFERALIGN_DOWN() for a different reason: if the caller has specified the exact amount of space it needs, having shm_toc_create discard some

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane wrote: >>> --> * reconstruct the row for EvalPlanQual(). Find an alternative local >>> path >>> Should the marked line simply be deleted? If not, what correction is >>> appropr

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas wrote: > On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Wed, Aug 16, 2017 at 12:31 PM, Tom Lane wrote: --> * reconstruct the row for EvalPlanQual(). Find an alternative local path Should the marked lin

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 2017-08-16 14:09:08 -0400, Tom Lane wrote: > >> I'm not sure that that's good enough, and I'm damn sure that it > >> shouldn't be undocumented. > > > 8 byte alignment would be good enough, so BUFFERALIGN ought to be > > sufficient. But it'd be nicer to have a separate more descriptive knob. >

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 2017-08-16 16:20:28 +0300, 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 wh

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Jeff Janes writes: > This patch still applies, and I think the argument for it is still valid. > So I'm going to make a commit-fest entry for it. Is there additional > evidence we should gather? I think we had consensus to apply this at the start of the next development cycle; I just forgot to d

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Heikki Linnakangas writes: > On 08/16/2017 09:00 PM, Tom Lane wrote: >> I don't buy that argument. A caller might think "Why do I need >> shm_toc_estimate, when I can compute the *exact* size I need?". >> And it would have worked, up till this proposed patch. > Well, no. The size of the shm_toc

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

Robert Haas writes: > On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas wrote: >> On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane wrote: >>> The current text of the comment dates to commit 177c56d60, and looking at >>> that commit makes it pretty clear that the line I'm complaining of >>> belonged to the p

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

On Wed, Aug 16, 2017 at 3:44 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Aug 16, 2017 at 3:02 PM, Robert Haas wrote: >>> On Wed, Aug 16, 2017 at 2:16 PM, Tom Lane wrote: The current text of the comment dates to commit 177c56d60, and looking at that commit makes it pretty clea

Re: [HACKERS] Garbled comment in postgresGetForeignJoinPaths

Robert Haas writes: > On Wed, Aug 16, 2017 at 3:44 PM, Tom Lane wrote: >> Will you fix it, or shall I? > Whichever you like. It's your commit, you can do the honors. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chang

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

On 2017-08-16 12:24:11 -0400, Peter Eisentraut wrote: > 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 k

Re: [HACKERS] Extra Vietnamese unaccent rules

Dang Minh Huong writes: > On 2017/07/05 15:28, Michael Paquier wrote: >> (Surprised to see that generate_unaccent_rules.py is inconsistent on >> MacOS, runs fine on Linux). FWIW, I got identical results from running the script on current macOS (Sierra) and Linux (RHEL6). >> Testing with characte

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

Andres Freund writes: > On 2017-08-16 12:24:11 -0400, Peter Eisentraut wrote: >> 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

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Andres Freund writes: > On 2017-08-16 16:20:28 +0300, Heikki Linnakangas wrote: > + pg_atomic_write_u64(&target->phs_nallocated, 0); > It's not ok to initialize an atomic with pg_atomic_write_u64 - works > well enough for "plain" atomics, but the fallback implementation isn't > ok with it. Yo

Re: [HACKERS] taking stdbool.h into use

I wrote: > gaur/pademelon isn't booted up right now, but it might provide > an example of a system that lacks altogether. > (If it doesn't, I'd be willing to concede that we need not > consider that scenario anymore.) For the record --- pademelon (vendor cc on that box) doesn't have at all. gau

Re: [HACKERS] Hash Functions

On Wed, Aug 16, 2017 at 12:38 PM, Tom Lane wrote: > 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 i

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 08/17/2017 12:20 AM, Tom Lane wrote: Andres Freund writes: On 2017-08-16 16:20:28 +0300, Heikki Linnakangas wrote: + pg_atomic_write_u64(&target->phs_nallocated, 0); It's not ok to initialize an atomic with pg_atomic_write_u64 - works well enough for "plain" atomics, but the fallbac

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

On 2017-08-16 17:06:42 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-08-16 12:24:11 -0400, Peter Eisentraut wrote: > >> 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

Re: [HACKERS] Hash Functions

Robert Haas writes: > Attached is a quick sketch of how this could perhaps be done (ignoring > for the moment the relatively-boring opclass pushups). It introduces > a new function hash_any_extended which differs from hash_any() in that > (a) it combines both b and c into the result and (b) it ac

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Heikki Linnakangas writes: > On 08/17/2017 12:20 AM, Tom Lane wrote: >> Indeed, gaur fails with >> 2017-08-16 17:09:38.315 EDT [13043:11] PANIC: stuck spinlock detected at >> pg_atomic_compare_exchange_u64_impl, atomics.c:196 > I was able to reproduce this locally, with --disable-atomics, but o

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

Andres Freund writes: > On 2017-08-16 17:06:42 -0400, Tom Lane wrote: >> If I understand what this is meant to do, maybe better >> pg_move_replication_slot_lsn() or pg_change_replication_slot_lsn() ? >> The point being that you're adjusting the LSN pointer contained >> in the slot, which is distin

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

Andres Freund wrote: > On 2017-08-16 17:06:42 -0400, Tom Lane wrote: > > If I understand what this is meant to do, maybe better > > pg_move_replication_slot_lsn() or pg_change_replication_slot_lsn() ? > > The point being that you're adjusting the LSN pointer contained > > in the slot, which is dis

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

Alvaro Herrera writes: > Andres Freund wrote: >> I think we should constrain the API to only allow later LSNs than >> currently in the slot, rather than arbitrary ones. That's why I was >> thinking of "forward". I'm not convinced it's a good / safe idea to >> allow arbitrary values to be set. >

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On August 16, 2017 3:09:27 PM PDT, Tom Lane wrote: >Heikki Linnakangas writes: >> On 08/17/2017 12:20 AM, Tom Lane wrote: >>> Indeed, gaur fails with >>> 2017-08-16 17:09:38.315 EDT [13043:11] PANIC: stuck spinlock >detected at pg_atomic_compare_exchange_u64_impl, atomics.c:196 > >> I was able

Re: [HACKERS] Hash Functions

On Wed, Aug 16, 2017 at 05:58:41PM -0400, Tom Lane wrote: > Robert Haas writes: > > Attached is a quick sketch of how this could perhaps be done (ignoring > > for the moment the relatively-boring opclass pushups). It introduces > > a new function hash_any_extended which differs from hash_any() in

  1   2   >