Re: [HACKERS] expanding inheritance in partition bound order

On Thu, Aug 17, 2017 at 10:54 AM, Amit Langote wrote: > On 2017/08/17 13:56, Ashutosh Bapat wrote: >> On Thu, Aug 17, 2017 at 8:06 AM, Amit Langote >> wrote: >>> On 2017/08/17 11:22, Robert Haas wrote: On Wed, Aug 16, 2017 at

Re: [HACKERS] expanding inheritance in partition bound order

On 2017/08/17 13:56, Ashutosh Bapat wrote: > On Thu, Aug 17, 2017 at 8:06 AM, Amit Langote > wrote: >> On 2017/08/17 11:22, Robert Haas wrote: >>> On Wed, Aug 16, 2017 at 10:12 PM, Amit Langote >>> wrote: > In the catalogs we are

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

On Thu, Aug 17, 2017 at 2:08 PM, Masahiko Sawada wrote: > On Wed, Aug 16, 2017 at 4:37 PM, Michael Paquier > wrote: >> On Wed, Aug 16, 2017 at 4:24 PM, Masahiko Sawada >> wrote: >>> FWIW, in my opinion if tte current

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

On Wed, Aug 16, 2017 at 7:15 PM, Andres Freund wrote: > > > I think this entirely is the wrong approach. We shouldn't add weird > check commands that require locks on pg_class, we should avoid leaving > the orphaned files in the first place. I've upthread outlined >

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

On Wed, Aug 16, 2017 at 4:37 PM, Michael Paquier wrote: > 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

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

On Thu, Aug 17, 2017 at 4:37 PM, Amit Kapila wrote: > Note - enable_gathermerge is not present in postgresql.conf. I think > we should add it in the postgresql.conf.sample file. +1 See also

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

On Thu, Aug 17, 2017 at 1:28 PM, Tom Lane wrote: > -1 ... every datatype I/O function is entitled to assume it's being > invoked inside a transaction. I do not think we should break that > on a case-by-case basis. So using timestamptz_in directly in xlog.c > was a bad idea,

Re: [HACKERS] expanding inheritance in partition bound order

On Thu, Aug 17, 2017 at 8:06 AM, Amit Langote wrote: > On 2017/08/17 11:22, Robert Haas wrote: >> On Wed, Aug 16, 2017 at 10:12 PM, Amit Langote >> wrote: In the catalogs we are using full "partitioned" e.g. pg_partitioned_table.

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

On Tue, Aug 15, 2017 at 7:16 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Aug 15, 2017 at 7:31 AM, Amit Kapila wrote: >>> Attached patch fixes the issue for me. I have locally verified that >>> the gather merge gets

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

Michael Paquier writes: > On Tue, Aug 15, 2017 at 11:37 PM, Piotr Stefaniak > wrote: >> At the very least, I think timestamptz_in() should either complain about >> being called outside of transaction or return the expected value, >> because

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Wed, Jul 26, 2017 at 10:35 PM, Robert Haas wrote: > On Thu, Jun 8, 2017 at 10:44 AM, Dilip Kumar wrote: >> On Thu, May 18, 2017 at 8:07 PM, Robert Haas wrote: >> Thanks for the feedback. I haven't yet worked on optimizer

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

On Tue, Aug 15, 2017 at 11:37 PM, Piotr Stefaniak wrote: > At the very least, I think timestamptz_in() should either complain about > being called outside of transaction or return the expected value, > because returning year 2000 is unuseful at best. I would also like

Re: [HACKERS] Extra Vietnamese unaccent rules

Michael Paquier writes: > On Thu, Aug 17, 2017 at 6:01 AM, Tom Lane wrote: >> I'm not really qualified to review the Python coding >> style, but I did fix a typo in a comment. > No pythonist here, but a large confusing "if" condition without any >

Re: [HACKERS] SCRAM salt length

On Thu, Aug 17, 2017 at 12:10 AM, Aleksander Alekseev wrote: >> 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

Re: [HACKERS] expanding inheritance in partition bound order

On 2017/08/17 11:22, Robert Haas wrote: > On Wed, Aug 16, 2017 at 10:12 PM, Amit Langote > wrote: >>> In the catalogs we are using full "partitioned" e.g. pg_partitioned_table. >>> May >>> be we should name the column as "inhchildpartitioned". >> >> Sure. > > I

Re: [HACKERS] One-shot expanded output in psql using \gx

Noah, all, On Wed, Aug 16, 2017 at 22:24 Noah Misch wrote: > On Tue, Aug 15, 2017 at 10:24:34PM +0200, Tobias Bussmann wrote: > > I've tested the new \gx against 10beta and current git HEAD. Actually > one of my favourite features of PostgreSQL 10! However in my environment

Re: [HACKERS] taking stdbool.h into use

On Wed, Aug 16, 2017 at 11:20 PM, Tom Lane wrote: > Don't know how far back you need to go to find Windows machines > with 4-byte bool, but we have some pretty long-in-the-tooth > buildfarm critters in that lineage, too. >From VS 2003 and upwards the size has always been 1:

Re: [HACKERS] One-shot expanded output in psql using \gx

On Tue, Aug 15, 2017 at 10:24:34PM +0200, Tobias Bussmann wrote: > I've tested the new \gx against 10beta and current git HEAD. Actually one of > my favourite features of PostgreSQL 10! However in my environment it was > behaving strangely. After some debugging I found that \gx does not work if

Re: [HACKERS] expanding inheritance in partition bound order

On Wed, Aug 16, 2017 at 10:12 PM, Amit Langote wrote: >> In the catalogs we are using full "partitioned" e.g. pg_partitioned_table. >> May >> be we should name the column as "inhchildpartitioned". > > Sure. I suggest inhpartitioned or inhispartition.

Re: [HACKERS] expanding inheritance in partition bound order

Hi Ashutosh, Thanks for the review and the updated patch. On 2017/08/16 21:48, Ashutosh Bapat wrote: > 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

Re: [HACKERS] Supporting huge pages on Windows

On Wed, Apr 12, 2017 at 7:08 PM, Tsunakawa, Takayuki wrote: > Oh, I got it now. Thanks. The revised patch is attached. The only modified > file is pg_ctl.c. The patch worked as expected. > > It is regrettable that I could not make it in time for PG 10, but I'd

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

On 17 August 2017 at 09:33, Andres Freund wrote: > On 2017-08-16 21:25:48 -0400, Robert Haas wrote: > > On Wed, Aug 16, 2017 at 5:55 PM, Andres Freund > wrote: > > > I think we should constrain the API to only allow later LSNs than > > > currently in the

Re: [HACKERS] Extra Vietnamese unaccent rules

On Thu, Aug 17, 2017 at 6:01 AM, Tom Lane wrote: > Pushed into v11. Thanks. > I'm not really qualified to review the Python coding > style, but I did fix a typo in a comment. No pythonist here, but a large confusing "if" condition without any comments is better if split up

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

> On Thu, Aug 17, 2017 at 9:15 AM, Tatsuo Ishii wrote: >>> He meant logical replication, >> >> Oh I could not find he meant logical replication in the original >> report. > > The second message of the thread says so, but the first does not > mention logical replication at

Re: [HACKERS] Broken link to DocBook XSL Stylesheets

On Thu, Aug 17, 2017 at 3:52 AM, Peter Eisentraut wrote: > 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.

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

On 2017-08-16 21:25:48 -0400, Robert Haas wrote: > On Wed, Aug 16, 2017 at 5:55 PM, 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".

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

On Thu, Aug 17, 2017 at 9:15 AM, Tatsuo Ishii wrote: >> He meant logical replication, > > Oh I could not find he meant logical replication in the original > report. The second message of the thread says so, but the first does not mention logical replication at all. >From here

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

On Wed, Aug 16, 2017 at 5:55 PM, 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

Re: [HACKERS] expanding inheritance in partition bound order

Hi Amit, Thanks for the comments. On 2017/08/16 20:30, Amit Khandekar wrote: > 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

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

On Thu, Aug 17, 2017 at 9:19 AM, Craig Ringer wrote: > pg_advance_replication_slot(...) > > ERROR's on logical slot, for now. Physical slots only. > > Forward-only. > > Future work to allow it to use the logical decoding infrastructure to > fast-forward a slot by reading

Re: [HACKERS] Fix number skipping in to_number

On Thu, Aug 10, 2017 at 10:21 PM, Oliver Ford wrote: > Prevents an issue where numbers can be skipped in the to_number() > function when the format mask contains a "G" or a "," but the input > string doesn't contain a separator. This resolves the TODO item "Fix > to_number()

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

On 8/16/17 07:27, Robert Haas wrote: > 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

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

On 16 August 2017 at 23:14, Robert Haas wrote: > 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

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

On 17 August 2017 at 07:30, Michael Paquier wrote: > > Definitely agreed on that. Any move function would need to check if > the WAL position given by caller is already newer than what's > available in the local pg_wal (minimum of all other slots), with a > shared lock

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

> He meant logical replication, Oh I could not find he meant logical replication in the original report. > but the code in question here is the same > for streaming replication, or whatever it's called. Yes. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English:

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 17 August 2017 at 01:20, Heikki Linnakangas wrote: > Looks reasonable. I edited the comments and the variable names a bit, to my > liking, and committed. Thanks! Thanks for committing. I've just been catching up on all that went on while I was sleeping. Thanks for handling

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

> In practice it's largely about architecture, I think. You definitely > need the same endianness and floating-point format, which are hardware, > and you need the same MAXALIGN, which is partly hardware but in principle > could be chosen differently in different ABI conventions for the same >

Re: [HACKERS] Subscription code improvements

On 8/8/17 05:58, Masahiko Sawada wrote: > Are you planning to work on remaining patches 0005 and 0006 that > improve the subscription codes in PG11 cycle? If not, I will take over > them and work on the next CF. Based on your assessment, the remaining patches were not required bug fixes. So I

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

On 8/16/17 19:41, Michael Paquier wrote: > On Thu, Aug 17, 2017 at 8:13 AM, Tatsuo Ishii wrote: >> Do we allow streaming replication among different OS? > > No. WAL is a binary format. > >> I thought it is >> required that primary and standbys are same platform (in my >>

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

Michael Paquier writes: > On Thu, Aug 17, 2017 at 8:13 AM, Tatsuo Ishii wrote: >> Do we allow streaming replication among different OS? > No. WAL is a binary format. >> I thought it is >> required that primary and standbys are same platform (in my

Re: [HACKERS] Re: [COMMITTERS] pgsql: Don't force-assign transaction id when exporting a snapshot.

On 8/14/17 13:57, Andres Freund wrote: > On 2017-08-14 13:55:29 -0400, Peter Eisentraut wrote: >> On 8/12/17 07:32, Petr Jelinek wrote: >>> This commit has side effect that it makes it possible to export >>> snapshots on the standbys. This makes it possible to do pg_dump -j on >>> standby with

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

On Thu, Aug 17, 2017 at 8:13 AM, Tatsuo Ishii wrote: > Do we allow streaming replication among different OS? No. WAL is a binary format. > I thought it is > required that primary and standbys are same platform (in my > understanding this means the same hardware architecture

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

On Thu, Jun 29, 2017 at 12:24 PM, Thomas Munro wrote: > fallocate-v5.patch Added to commitfest so we don't lose track of this. I'm mainly concerned about the fact that we have a way for PostgreSQL to die that looks exactly like a bug, when really it's masking an

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

On Thu, Aug 17, 2017 at 7:14 AM, Tom Lane wrote: > 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() ?

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

> Thank you Tom Lane, > This patch fixes the problem. > > With this patch, streaming replication started working (replication to > Windows) > > (Tested for Linux to Windows replication) Do we allow streaming replication among different OS? I thought it is required that primary and standbys are

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

On 2017-08-16 18:14:45 -0400, Tom Lane wrote: > 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

Re: [HACKERS] Hash Functions

Kenneth Marshall writes: > On Wed, Aug 16, 2017 at 05:58:41PM -0400, Tom Lane wrote: >> ... In fact, on perusing the linked-to page >> http://burtleburtle.net/bob/hash/doobs.html >> Bob says specifically that taking b and c from this hash does not >> produce a fully random 64-bit

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Andres Freund writes: > On August 16, 2017 3:09:27 PM PDT, Tom Lane wrote: >> I wonder whether it's sensible to have --enable-cassert have the effect >> of filling memory allocated by ShmemAlloc or the DSA code with junk (as >> palloc does) instead of

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

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

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

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

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

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

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

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

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(>phs_nallocated, 0); It's not ok to initialize an atomic with pg_atomic_write_u64 - works well enough for "plain" atomics,

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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:

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

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:

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

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.

  1   2   >