Re: [HACKERS] 2017-03 Commitfest In Progress

On Sat, Mar 4, 2017 at 12:45 PM, Michael Paquier wrote: > On Sat, Mar 4, 2017 at 3:43 PM, Robert Haas wrote: >> Fix the optimization to skip WAL-logging on table created in the same >> transaction (originally submitted to CommitFest 2016-03) >>

Re: [HACKERS] Proposal : Parallel Merge Join

On Fri, Mar 3, 2017 at 9:47 PM, Dilip Kumar wrote: > On Fri, Mar 3, 2017 at 3:57 PM, Robert Haas wrote: >> I'm not happy with the way this patch can just happen to latch on to a >> path that's not parallel-safe rather than one that is and then just

Re: [HACKERS] Disallowing multiple queries per PQexec()

On Tue, Feb 28, 2017 at 7:34 PM, Tom Lane wrote: > Surafel Temesgen writes: >> This assignment is on todo list and has a benefit of providing an >> additional defense against SQL-injection attacks. > > This is on the todo list? Really? It seems

Re: [HACKERS] [patch] reorder tablespaces in basebackup tar stream for backup_label

On Sat, Mar 4, 2017 at 1:13 AM, Bernd Helmle wrote: > Ah right, i assumed there must be something, otherwise the comment > won't be there ;) > > We could special case that part to distinguish fetch/stream mode, but i > fear that leads to more confusion than it wants to fix.

Re: [HACKERS] UPDATE of partition key

On Thu, Mar 2, 2017 at 11:53 AM, Amit Khandekar wrote: > I think it does not make sense running after row triggers in case of > row-movement. There is no update happened on that leaf partition. This > reasoning can also apply to BR update triggers. But the reasons for >

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Thu, Mar 2, 2017 at 7:14 PM, Amit Kapila wrote: > So we should move this loading of blocks once the recovery reaches a > consistent state so that we can connect to a database. To allow > worker, to take a lock, we need to dump relation oid as well. Is that > what you

Re: [HACKERS] 2017-03 Commitfest In Progress

On Sat, Mar 4, 2017 at 3:43 PM, Robert Haas wrote: > Fix the optimization to skip WAL-logging on table created in the same > transaction (originally submitted to CommitFest 2016-03) > https://commitfest.postgresql.org/13/528/ > Michael perhaps-unwisely set the committer on

Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

On Sat, Mar 4, 2017 at 1:09 PM, Peter Eisentraut wrote: > On 2/27/17 00:32, Michael Paquier wrote: >> On Sun, Feb 26, 2017 at 8:24 AM, Michael Paquier >> wrote: >>> To be consistent with archive_command and restore_command I'd rather

Re: [HACKERS] 2017-03 Commitfest In Progress

On Fri, Mar 3, 2017 at 10:43 PM, Robert Haas wrote: > Parallel tuplesort (originally submitted to CommitFest 2016-09) > https://commitfest.postgresql.org/13/690/ > Heikki and I have both done a little work to move this forward, but it > needs a lot more attention than it

Re: [HACKERS] multivariate statistics (v24)

On Thu, Mar 2, 2017 at 8:35 AM, Tomas Vondra wrote: > attached is v24 of the patch series, addressing most of the reported issues > and comments (at least I believe so). The main changes are: > > 1) I've mostly abandoned the "multivariate" name in favor of

Re: [pgsql-www] [HACKERS] Small issue in online devel documentation build

Hello Peter, I think what you are looking at is the web site stylesheet. Yep. The whole thing looks fine to me using the default stylesheet. On the web site, it looks wrong to me too. I don't know what the rationale for using 1.3em for is, but apparently it's not working correctly.

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

On Wed, Mar 1, 2017 at 9:07 AM, David Steele wrote: > On 2/28/17 10:22 PM, Robert Haas wrote: >> On Tue, Feb 28, 2017 at 6:22 AM, David Steele wrote: > I'm not sure that's the case. It seems like it should lock just as > multiple backends would

Re: [HACKERS] GSoC 2017

On Thu, Mar 2, 2017 at 3:45 AM, Jim Nasby wrote: > On 2/27/17 4:52 PM, Thomas Munro wrote: >> By the way, that page claims that PostgreSQL runs on Irix and Tru64, >> which hasn't been true for a few years. > > There could be a GSoC project to add support for those back

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

On 04/03/17 05:11, Tom Lane wrote: > Peter Eisentraut writes: >> On 3/3/17 19:16, Tom Lane wrote: >>> Peter Eisentraut writes: Use asynchronous connect API in libpqwalreceiver > >>> Buildfarm member bowerbird has been failing in the

Re: [HACKERS] Logical replication existing data copy

On Sat, Mar 4, 2017 at 11:41 AM, Petr Jelinek wrote: > On 04/03/17 06:46, Robert Haas wrote: >> On Tue, Feb 28, 2017 at 12:08 PM, Erik Rijkers wrote: >>> Would you remind me why synchronous_commit = on was deemed a better default? >> I'm wondering

Re: [HACKERS] 2017-03 Commitfest In Progress

On Thu, Mar 2, 2017 at 6:58 AM, Tom Lane wrote: > Indeed. As usual, a depressingly large number of patches appeared out of > the woodwork in the last few days before the deadline, and more than a > couple of those seem to be clear violations of our rule about "no major > new

Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements

On Wed, Mar 1, 2017 at 8:21 PM, Peter Eisentraut wrote: > On 2/28/17 20:01, Lukas Fittl wrote: >> Currently pg_stat_statements replaces constant values with ? characters. >> I've seen this be a problem on multiple occasions, in particular since >> it conflicts

Re: [HACKERS] Logical replication existing data copy

On 04/03/17 06:46, Robert Haas wrote: > On Tue, Feb 28, 2017 at 12:08 PM, Erik Rijkers wrote: >> Would you remind me why synchronous_commit = on was deemed a better default? > > I'm wondering about that, too. If you're trying to do logical > synchronous replication, then maybe

Re: [HACKERS] pg_dump, pg_dumpall and data durability

On Thu, Mar 2, 2017 at 5:02 AM, Michael Paquier wrote: > On Thu, Mar 2, 2017 at 2:26 AM, David Steele wrote: >> This patch is in need of a committer. Any takers? >> I didn't see a lot of enthusiasm from committers on the thread > > Stephen at

Re: [HACKERS] [BUGS] Seems bug in postgres_fdw?

On Thu, Mar 2, 2017 at 3:28 AM, Rader, David wrote: > Attached is a doc patch that updates the documentation for postgres-fdw to > include the actual values for the 4 session variables that are set. Does > that make sense to clarify? >From my point of view, this would be a

Re: [HACKERS] Logical replication existing data copy

On Tue, Feb 28, 2017 at 12:08 PM, Erik Rijkers wrote: > Would you remind me why synchronous_commit = on was deemed a better default? I'm wondering about that, too. If you're trying to do logical synchronous replication, then maybe there's some argument there, although even in

Re: [HACKERS] Patch: Optimize memory allocation in function 'bringetbitmap'

On Wed, Mar 1, 2017 at 11:28 PM, Alvaro Herrera wrote: > Alvaro Herrera wrote: >> Jinyu Zhang wrote: >> >> > Update the patch_brin_optimze_mem according to your comment. >> >> I have added this patch to the commitfest, which I've been intending to >> get in for a long

Re: [HACKERS] log_autovacuum_min_duration doesn't log VACUUMs

On Wed, Mar 1, 2017 at 11:00 PM, Jeff Janes wrote: >> Because there are already various tools available to log activity of >> session processes, but there are no other ways to log the activity of >> autovacuum. Why are the existing settings not sufficient for this >>

Re: [HACKERS] Performance degradation in TPC-H Q18

On Sat, Mar 4, 2017 at 5:56 AM, Andres Freund wrote: > attached is a patch to address this problem, and the one reported by > Dilip. I ran a lot of TPC-H and other benchmarks, and so far this > addresses all the performance issues, often being noticeably faster than > with

Re: [HACKERS] DROP SUBSCRIPTION and ROLLBACK

On 3/3/17 13:58, Petr Jelinek wrote: > On 23/02/17 08:24, Masahiko Sawada wrote: >> Attached updated version patches. Please review these. >> > > This version looks good to me, I'd only change the > >> +PreventTransactionChain(isTopLevel, "CREATE SUBSCRIPTION CREATE >> SLOT"); > >

Re: [HACKERS] [BUG FIX] Removing NamedLWLockTrancheArray

On Fri, Mar 3, 2017 at 3:49 PM, Kyotaro HORIGUCHI wrote: >> You can read about usage of LWLocks in extensions from below location: >> https://www.postgresql.org/docs/devel/static/xfunc-c.html#idp86986416 > > Thank you for the pointer. I understand that the

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

Peter Eisentraut writes: > On 3/3/17 19:16, Tom Lane wrote: >> Peter Eisentraut writes: >>> Use asynchronous connect API in libpqwalreceiver >> Buildfarm member bowerbird has been failing in the pg_rewind test since >> this patch went in. It

Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

On 2/27/17 00:32, Michael Paquier wrote: > On Sun, Feb 26, 2017 at 8:24 AM, Michael Paquier > wrote: >> To be consistent with archive_command and restore_command I'd rather >> not do that. The command called can decide by itself what to do by >> looking at the shape of

Re: [HACKERS] PATCH: two slab-like memory allocators

On 03/04/2017 02:58 AM, Andres Freund wrote: On 2017-03-01 22:19:30 -0800, Andres Freund wrote: On 2017-03-02 04:36:23 +0100, Tomas Vondra wrote: I've noticed two minor typos: 1) That is solved this by creating ... - extra "this" 2) Given this, routines like pfree their corresponding

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Mar 3, 2017 at 6:58 PM, Amit Kapila wrote: > You are right that we don't want the number of unclaimed-by-FSM > recyclable pages to grow forever, but I think that won't happen with > this patch. As soon as there are more deletions (in heap), in the > next vacuum

Re: [pgsql-www] [HACKERS] Small issue in online devel documentation build

On 3/2/17 05:50, Fabien COELHO wrote: > (2) do use absolute sizes in the CSS, not relative ones like "1.3em" > which accumulate multiplications when code appears in code, > and count on the navigator ctrl-+/- for users to adjust size > consistently to their needs. I think what you

Re: [HACKERS] GUC for cleanup indexes threshold.

On Sat, Mar 4, 2017 at 5:59 AM, Peter Geoghegan wrote: > On Fri, Mar 3, 2017 at 2:41 PM, Peter Geoghegan wrote: >> In other words, the number of B-Tree pages that the last VACUUM >> deleted, and thus made eligible to recycle by the next VACUUM has no >> relationship

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

On 3/3/17 19:16, Tom Lane wrote: > Peter Eisentraut writes: >> Use asynchronous connect API in libpqwalreceiver > > Buildfarm member bowerbird has been failing in the pg_rewind test since > this patch went in. It looks like it's failing to complete connections > from the

Re: [HACKERS] Logical Replication and Character encoding

On 3/3/17 14:51, Petr Jelinek wrote: > On 03/03/17 20:37, Peter Eisentraut wrote: >> On 2/27/17 00:23, Kyotaro HORIGUCHI wrote: >>> Yeah, the patch sends converted string with the length of the >>> orignal length. Usually encoding conversion changes the length of >>> a string. I doubt that the

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-03-01 22:19:30 -0800, Andres Freund wrote: > On 2017-03-02 04:36:23 +0100, Tomas Vondra wrote: > > I've noticed two minor typos: > > > > 1) That is solved this by creating ... > >- extra "this" > > > > 2) Given this, routines like pfree their corresponding context ... > >-

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On Sat, Mar 4, 2017 at 9:47 AM, Magnus Hagander wrote: > On Thursday, March 2, 2017, Peter Eisentraut > wrote: >> >> On 2/3/17 17:47, Michael Paquier wrote: >> > On Fri, Feb 3, 2017 at 4:59 AM, Simon Riggs >> > wrote:

Re: [HACKERS] Protect syscache from bloating with negative cache entries

On 2/1/17 1:25 AM, Kyotaro HORIGUCHI wrote: > Hello, thank you for moving this to the next CF. > > At Wed, 1 Feb 2017 13:09:51 +0900, Michael Paquier > wrote in > >> On Tue, Jan 24, 2017 at 4:58

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On Thursday, March 2, 2017, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2/3/17 17:47, Michael Paquier wrote: > > On Fri, Feb 3, 2017 at 4:59 AM, Simon Riggs > wrote: > >>> It's weirdly inconsistent now. You need a "replication" line in

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Mar 3, 2017 at 2:41 PM, Peter Geoghegan wrote: > In other words, the number of B-Tree pages that the last VACUUM > deleted, and thus made eligible to recycle by the next VACUUM has no > relationship with the number of pages the next VACUUM will itself end > up deleting, in

Re: [HACKERS] Performance degradation in TPC-H Q18

Hi, attached is a patch to address this problem, and the one reported by Dilip. I ran a lot of TPC-H and other benchmarks, and so far this addresses all the performance issues, often being noticeably faster than with the dynahash code. Comments? On 2017-03-03 11:23:00 +0530, Kuntal Ghosh

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

Peter Eisentraut writes: > Use asynchronous connect API in libpqwalreceiver Buildfarm member bowerbird has been failing in the pg_rewind test since this patch went in. It looks like it's failing to complete connections from the standby; which suggests that something

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

On 2017-03-03 15:12:04 -0800, Peter Geoghegan wrote: > On Tue, Feb 28, 2017 at 5:42 AM, Pavan Deolasee > wrote: > > During the second heap scan of CREATE INDEX CONCURRENTLY, we're only > > interested in the tuples which were inserted after the first scan was > > started.

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

On Tue, Feb 28, 2017 at 5:42 AM, Pavan Deolasee wrote: > During the second heap scan of CREATE INDEX CONCURRENTLY, we're only > interested in the tuples which were inserted after the first scan was > started. All such tuples can only exists in pages which have their VM

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote: > > Since VM bits are only set during VACUUM which conflicts with CIC on the > > relation lock, I don't see any risk of incorrectly skipping pages that the > > second scan should have

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

On Fri, Mar 3, 2017 at 2:54 PM, Andres Freund wrote: > On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote: >> Since VM bits are only set during VACUUM which conflicts with CIC on the >> relation lock, I don't see any risk of incorrectly skipping pages that the >> second scan

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

Hi, On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote: > Since VM bits are only set during VACUUM which conflicts with CIC on the > relation lock, I don't see any risk of incorrectly skipping pages that the > second scan should have scanned. I think that's true currently, but it'd also prevent

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Mar 3, 2017 at 11:49 AM, Peter Geoghegan wrote: >> Please verify my understanding of your thought process: We don't have >> to freeze indexes at all, ever, so if we see index bloat as a separate >> problem, we also see that there is no need to *link* index needs to >> the

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-03 21:49 GMT+01:00 David Steele : > Hi Oleg, > > On 2/28/17 2:55 PM, Pavel Stehule wrote: > > 2017-02-28 20:08 GMT+01:00 Oleg Bartunov > > > Attached patch is an implementation of SQL/JSON data model from > > SQL-2016 standard (ISO/IEC

Re: [HACKERS] patch: function xmltable

2017-03-03 21:04 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > 2017-03-03 19:15 GMT+01:00 Alvaro Herrera : > > > > 2. As I've complained many times, I find the way we manage an empty > > > COLUMNS clause pretty bad. The standard doesn't

[HACKERS] adding an immutable variant of to_date

Hello everybody, following up on this thread: https://www.postgresql.org/message-id/flat/d297e048-ac49-9bed-32e3-9dd4e65d0978%40mail.de specifically on this mail: https://www.postgresql.org/message-id/baef819f-acf0-a64d-c1eb-d2c5da1e5030%40mail.de I hope this idea fulfills the requirements. So

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans

Hi Julian, On 1/25/17 12:34 PM, Julian Markwort wrote: > TL:DR; > We extended the functionality of pg_stat_statements so it can track > worst and best case execution plans. pg_stat_statements is an important tool and perhaps one of the most used core extensions. Any improvements would be

Re: [HACKERS] [WIP]Vertical Clustered Index (columnar store extension)

On 2/13/17 8:59 PM, Haribabu Kommi wrote: > The current patch that I shared doesn't contains the plan and executor > changes to show > the performance benefit of the clustered index. we used custom plan to > generate the plan > for the clustered index. Currently I am working on it to rebase it to

Re: [HACKERS] SQL/JSON in PostgreSQL

Hi Oleg, On 2/28/17 2:55 PM, Pavel Stehule wrote: > 2017-02-28 20:08 GMT+01:00 Oleg Bartunov > Attached patch is an implementation of SQL/JSON data model from > SQL-2016 standard (ISO/IEC 9075-2:2016(E)), which was published > 2016-12-15 and is available only

Re: [HACKERS] ANALYZE command progress checker

On 3/1/17 1:25 PM, Andres Freund wrote: > On 2017-03-01 10:20:41 -0800, David Fetter wrote: >> On Wed, Mar 01, 2017 at 09:45:40AM -0500, Peter Eisentraut wrote: >>> On 2/28/17 04:24, vinayak wrote: The view provides the information of analyze command progress details as follows

Re: [HACKERS] patch: function xmltable

Pavel Stehule wrote: > 2017-03-03 19:15 GMT+01:00 Alvaro Herrera : > > 2. As I've complained many times, I find the way we manage an empty > > COLUMNS clause pretty bad. The standard doesn't require that syntax > > (COLUMNS is required), and I don't like the

Re: [HACKERS] Unhelpful typesetting of callouts in example queries in the docs

On 2/27/17 21:49, Thomas Munro wrote: > It turned out that the 'callout' was causing confusion because it > sticks "(1)" into the middle of the query in approximately the same > typeface: > Maybe we should move it over a bit (?) and make it a comment, in case > it gets copied-and-pasted or

Re: [HACKERS] RADIUS fallback servers

On Friday, March 3, 2017, Adam Brightwell wrote: > I've given an initial review of this patch. It applies cleanly and > compiles without issue as of 6da9759. I'm going to continue with > testing it against a set of RADIUS servers in the next few days. But > in

Re: [HACKERS] Logical Replication and Character encoding

On 03/03/17 20:37, Peter Eisentraut wrote: > On 2/27/17 00:23, Kyotaro HORIGUCHI wrote: >> Yeah, the patch sends converted string with the length of the >> orignal length. Usually encoding conversion changes the length of >> a string. I doubt that the reverse case was working correctly. > > I

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Mar 3, 2017 at 11:37 AM, Peter Geoghegan wrote: > Please verify my understanding of your thought process: We don't have > to freeze indexes at all, ever, so if we see index bloat as a separate > problem, we also see that there is no need to *link* index needs to > the need

Re: [HACKERS] Restricting maximum keep segments by repslots

On 3/1/17 19:54, Kyotaro HORIGUCHI wrote: >> Please measure it in size, not in number of segments. > It was difficult to dicide which is reaaonable but I named it > after wal_keep_segments because it has the similar effect. > > In bytes(or LSN) > max_wal_size > min_wal_size >

Re: [HACKERS] Logical Replication and Character encoding

On 2/27/17 00:23, Kyotaro HORIGUCHI wrote: > Yeah, the patch sends converted string with the length of the > orignal length. Usually encoding conversion changes the length of > a string. I doubt that the reverse case was working correctly. I think we shouldn't send the length value at all. This

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Mar 3, 2017 at 8:13 AM, Masahiko Sawada wrote: > Thank you for clarification. Let me check my understanding. IIUC, > skipping second index vacuum path (lazy_cleanup_index) can not be > cause of leaving page as half-dead state but could leave recyclable > pages that

[HACKERS] check failure with -DRELCACHE_FORCE_RELEASE -DCLOBBER_FREED_MEMORY

I have been setting up a buildfarm member with -DRELCACHE_FORCE_RELEASE -DCLOBBER_FREED_MEMORY, settings which Alvaro suggested to me.I got core dumps with these stack traces. The platform is Amazon Linux. == stack trace: pgsql.build/src/test/regress/tmp_check/data/core.4149

Re: [HACKERS] Logical replication and inheritance

On 2/27/17 01:57, Amit Langote wrote: > I see that if the table is a inheritance parent, and ONLY is not > specified, the child tables are also added to the publication. > If the child table is later removed from the inheritance hierarchy, it > continues to be a part of the publication. >

Re: [HACKERS] patch: function xmltable

2017-03-03 19:42 GMT+01:00 Pavel Stehule : > > > 2017-03-03 19:15 GMT+01:00 Alvaro Herrera : > >> Pavel Stehule wrote: >> >> > attached update with fixed tests >> >> Heh, I noticed that you removed the libxml "context" lines that >> differentiate

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On 2/21/17 01:50, Michael Paquier wrote: > So what do you think about the patch attached? This does the following: > - complete subscription list for CREATE/ALTER SUBSCRIPTION > - complete publication list for CREATE/ALTER PUBLICATION > - complete to nothing for PUBLICATION in CREATE/ALTER

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

Christoph Berg wrote: > The new version tests \g and \gx with a new query, and > re-running it on the last query buffer. Thanks, here's a review: The patch compiles and works as expected. The code follows the same pattern as other one-shot command modifiers, setting a flag in the

Re: [HACKERS] Two phase commit in ECPG

Dear Sawada-san, > This cause is that the "begin transaction" is issued automatically > before executing COMMIT PREPARED if we're not in auto commit. The > Commit 816b008eaf1a1ff1069f3bafff363a9a8bf04a21 fixed bug of > incorrect > status calculation but at the same time it became the cause of

Re: [HACKERS] DROP SUBSCRIPTION and ROLLBACK

On 23/02/17 08:24, Masahiko Sawada wrote: > Attached updated version patches. Please review these. > This version looks good to me, I'd only change the > + PreventTransactionChain(isTopLevel, "CREATE SUBSCRIPTION CREATE > SLOT"); to "CREATE SUBSCRIPTION ... CREATE SLOT" as that's

Re: [HACKERS] RADIUS fallback servers

I've given an initial review of this patch. It applies cleanly and compiles without issue as of 6da9759. I'm going to continue with testing it against a set of RADIUS servers in the next few days. But in the meantime, I have a few questions (below). > It supports multiple RADIUS servers. For all

Re: [HACKERS] patch: function xmltable

2017-03-03 19:15 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > > attached update with fixed tests > > Heh, I noticed that you removed the libxml "context" lines that > differentiate xml.out from xml_2.out when doing this. My implementation > emits those lines,

Re: [HACKERS] Logical replication failing when foreign key present

On 1/22/17 18:07, Petr Jelinek wrote: > On 22/01/17 18:50, Thom Brown wrote: >> There's an issue which I haven't seen documented as expected >> behaviour, where replicating data to a table which has a foreign key >> results in a replication failure. This produces the following log >> entries: >

Re: [HACKERS] patch: function xmltable

Pavel Stehule wrote: > attached update with fixed tests Heh, I noticed that you removed the libxml "context" lines that differentiate xml.out from xml_2.out when doing this. My implementation emits those lines, so it was failing for me. I restored them. I also changed a few things to avoid

Re: [HACKERS] Logical Replication WIP

On 2/22/17 07:00, Petr Jelinek wrote: > On 22/02/17 12:24, Petr Jelinek wrote: >> Hi, >> >> I updated these patches for current HEAD and removed the string >> initialization in walsender as Fuji Masao committed similar fix in meantime. >> >> I also found typo/thinko in the first patch which is now

Re: [HACKERS] Statement-level rollback

On Fri, Mar 3, 2017 at 9:01 AM, Andres Freund wrote: > On 2017-03-03 11:54:06 -0500, David Steele wrote: >> Given that this landed on March 28 with no discussion beforehand, I >> recommend that we immediately move this patch to the 2017-07 CF. > > Seconded. +1 -- Peter

Re: [HACKERS] Statement-level rollback

On 3/3/17 12:01 PM, Andres Freund wrote: > On 2017-03-03 11:54:06 -0500, David Steele wrote: >> Given that this landed on March 28 with no discussion beforehand, I >> recommend that we immediately move this patch to the 2017-07 CF. > > Seconded. And of course I meant Feb 28. -- -David

Re: [HACKERS] Statement-level rollback

On 2017-03-03 11:54:06 -0500, David Steele wrote: > Given that this landed on March 28 with no discussion beforehand, I > recommend that we immediately move this patch to the 2017-07 CF. Seconded. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Statement-level rollback

On 3/3/17 2:43 AM, Tsunakawa, Takayuki wrote: > From: Tom Lane [mailto:t...@sss.pgh.pa.us] >> 1. The argument for this is mostly, if not entirely, "application >> compatibility". But it won't succeed at providing that if every BEGIN has >> to be spelled differently than it would be on other

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Mar 3, 2017 at 10:45 PM, David Steele wrote: > On 2/27/17 12:46 PM, Peter Geoghegan wrote: >> On Sat, Feb 25, 2017 at 10:51 PM, Robert Haas wrote: >> >>> Do you have an idea about that, or any ideas for experiments we could try? >> >> Nothing

Re: [HACKERS] Proposal : Parallel Merge Join

On Fri, Mar 3, 2017 at 3:57 PM, Robert Haas wrote: > I'm not happy with the way this patch can just happen to latch on to a > path that's not parallel-safe rather than one that is and then just > give up on a merge join in that case. I already made this argument in >

Re: [HACKERS] Block level parallel vacuum WIP

On Fri, Mar 3, 2017 at 11:01 PM, David Steele wrote: > On 1/10/17 11:23 AM, Claudio Freire wrote: >> On Tue, Jan 10, 2017 at 6:42 AM, Masahiko Sawada >> wrote: Does this work negate the other work to allow VACUUM to use > 1GB memory? >>> >>>

Re: [HACKERS] GUC for cleanup indexes threshold.

On Sat, Feb 25, 2017 at 7:10 AM, Peter Geoghegan wrote: > On Fri, Feb 24, 2017 at 9:26 AM, Robert Haas wrote: >> I think this thread is pretty short on evidence that would let us make >> a smart decision about what to do here. I see three possibilities. >>

Re: [HACKERS] [patch] reorder tablespaces in basebackup tar stream for backup_label

Am Freitag, den 03.03.2017, 15:44 +0900 schrieb Michael Paquier: > So, the main directory is located at the end on purpose. When using > --wal-method=fetch the WAL segments are part of the main tarball, so > if you send the main tarball first you would need to generate a > second > tarball with

Re: [HACKERS] logical replication access control patches

* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 28/02/17 04:10, Stephen Frost wrote: > > Peter, > > > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > >> On 2/18/17 18:06, Stephen Frost wrote: > >>> I'm not convinced that it really makes sense to have PUBLICATION of a >

Re: [HACKERS] pg_upgrade loses security lables and COMMENTs on blobs

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Feb 23, 2017 at 10:36:37AM -0500, Stephen Frost wrote: > > * Stephen Frost (sfr...@snowman.net) wrote: > > > Just wanted to get a note out to -hackers about the issue, I'll see > > > about getting a fix written up for it soon. > > > >

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

On 03/03/2017 05:09 AM, Robert Haas wrote: On Mon, Feb 20, 2017 at 9:43 PM, Tomas Vondra wrote: BTW I've noticed the pageinspect version is 1.6, but we only have pageinspect--1.5.sql (and upgrade script to 1.6). Not sure that's entirely intentional? Actually,

Re: [HACKERS] Block level parallel vacuum WIP

On 1/10/17 11:23 AM, Claudio Freire wrote: > On Tue, Jan 10, 2017 at 6:42 AM, Masahiko Sawada > wrote: >>> Does this work negate the other work to allow VACUUM to use > >>> 1GB memory? >> >> Partly yes. Because memory space for dead TIDs needs to be allocated >> in DSM

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Fri, 3 Mar 2017 15:24:53 +0900 Michael Paquier wrote: > > + /* > +* No space found, file content is corrupted. Return > NULL to the > +* caller and inform him on the situation. > +*/ > + elog(ERROR, > +

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hi Ivan, On 2/27/17 3:52 PM, Thomas Munro wrote: > On Thu, Feb 23, 2017 at 3:08 AM, Thom Brown wrote: >> On 23 January 2017 at 11:56, Ivan Kartyshov >> wrote: >>> >>> Thank you for reading, will be glad to get your feedback. >> >> Could you please

Re: [HACKERS] GUC for cleanup indexes threshold.

On 2/27/17 12:46 PM, Peter Geoghegan wrote: > On Sat, Feb 25, 2017 at 10:51 PM, Robert Haas wrote: > >> Do you have an idea about that, or any ideas for experiments we could try? > > Nothing occurs to me right now, unfortunately. However, my general > sense is that it

Re: [HACKERS] [POC] hash partitioning

On Fri, Mar 3, 2017 at 5:00 PM, Greg Stark wrote: > On 2 March 2017 at 13:03, amul sul wrote: > > create table foo (a integer, b text) partition by hash (a); > > create table foo1 partition of foo with (modulus 4, remainder 0); > > create table foo2 partition

Re: [HACKERS] Questions about MergeAppend

On Thu, Mar 2, 2017 at 8:00 PM, Ronan Dunklau wrote: > Hello, > > Looking into the MergeAppendPath generation, I'm a bit surprised by several > things: > > - When generating the mergeappendpath, we use a dummy path to take the sort > cost into account for non-sorted

Re: [HACKERS] [POC] hash partitioning

On 2 March 2017 at 13:03, amul sul wrote: > create table foo (a integer, b text) partition by hash (a); > create table foo1 partition of foo with (modulus 4, remainder 0); > create table foo2 partition of foo with (modulus 8, remainder 1); -- legal, > modulus doesn't need to

Re: [HACKERS] [POC] hash partitioning

On Thu, 2 Mar 2017 18:33:42 +0530 amul sul wrote: Thank you for the patch. This is very interesting. I'm going to look into your code and write a feedback later. > On Wed, Mar 1, 2017 at 3:50 PM, Yugo Nagata wrote: > > > ​[]​ > > > > I Agree that it

Re: [HACKERS] Proposal : Parallel Merge Join

On Wed, Mar 1, 2017 at 12:01 PM, Amit Kapila wrote: > On Wed, Mar 1, 2017 at 11:24 AM, Dilip Kumar wrote: >> On Wed, Mar 1, 2017 at 11:13 AM, Amit Kapila wrote: >>> I think for now we can keep the parallel safety check for

Re: [HACKERS] [BUG FIX] Removing NamedLWLockTrancheArray

> You can read about usage of LWLocks in extensions from below location: > https://www.postgresql.org/docs/devel/static/xfunc-c.html#idp86986416 Thank you for the pointer. I understand that the document describes the only correct way to use LWLock in extensions and using LWLockRegisterTranche

Re: [HACKERS] [GSoC] Personal presentation and request for clarification

Hi! It's great that you are interested in PostgreSQL! I'll answer the question on the matter of GSoC project proposed by me. I hope someone else will handle questions on your primary objective. 2017-03-03 4:15 GMT+05:00 João Miguel Afonso : > My second choice

Re: [HACKERS] [BUG FIX] Removing NamedLWLockTrancheArray

On Fri, Mar 3, 2017 at 1:43 PM, Kyotaro HORIGUCHI wrote: > Hello, some of my collegues found that orafce crashes with > postgresql compliled with dtrace. > > === The cause > > The immediate cause was I think that it just did > LWLockNewTrancheId and forget to do

Re: [HACKERS] patch: function xmltable

2017-03-02 22:35 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > 2017-03-02 19:32 GMT+01:00 Alvaro Herrera : > > > > > So in the old (non-executor-node) implementation, you could attach WITH > > > ORDINALITY to the xmltable expression and

Re: [HACKERS] [BUG FIX] Removing NamedLWLockTrancheArray

I should be very tired. This is the last mail today. At Fri, 03 Mar 2017 17:26:27 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170303.172627.225604431.horiguchi.kyot...@lab.ntt.co.jp> > > > Hello, some of my collegues found that orafce crashes

  1   2   >