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)
>> https://commitfest.postgresql.org/13/528/
>> Michael
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
>> give up on a merge join in that case. I alre
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 unlikely to be worth the
> backwards-compatibility
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. The other
> option of a
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
> having a BR trigger and AR
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 are envisioning to fix th
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 this one to Heikki,
> wh
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
>>> not do that. The command called can decide by itself what t
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 has gotten. As I see it,
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 "extended",
> particularly in places refe
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.
In
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 now. One process would succeed and the oth
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 in... ;P
Greg Stark and Tom
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 pg_rewind test since
>>> this patch went in. It looks lik
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 about that, too. If you're trying to do logical
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 features should first
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 with the use of ? as an operator.
>>
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 there's some argum
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 least has showed interest.
>
>> so if nobody picks it
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 sensible thing to docum
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 that case I am not
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 time. I'll be submitting an
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
>> purpose?
>
> I've pretty ofte
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 the dynahash code.
>
>
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");
>
> t
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 document describes the only
> correct way
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 looks like it's failing to complete connections
>> fr
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 the argument string.
> Just
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 conte
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 cycle, the pages will be re
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 a
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 with the number of pages the n
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 standby; which suggests
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 reve
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 ...
> >- missing
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:
>> >>> It's weirdly inconsistent now. You need a "replication" line in
>> >>>
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 PM, Kyotaro HORIGUCHI
>> wrote:
>>> Six new syscaches in 665d1fa was conflicted and 3-way merge
>>
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
> >>> pg_hba.conf to connect for logica
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 general, or how
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 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 standby; which suggests that something platform-specific is
missing
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. All such tuples can only e
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 bit
> unset. So I propose th
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 scanned.
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 should have scanned.
>
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 u
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 need for freezing
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 9075-2:2016(E)), which was published
> >
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 require that syntax
> > > (COLUMNS is required), and
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
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 greatl
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
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 for purchase from ISO we
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
post
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 otherwi
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 implementation, so why not
> > provide
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 the meantime, I have a few question
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 thin
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 for freezing. XI
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
> wal_write_flush_af
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 m
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 are not marked as a recy
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
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.
> Perhaps
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 xml.out from xml_2.out when doing this. My impleme
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 SUBSCRIP
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 global
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 this
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 a
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
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, so it was failing for me. I
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:
> H
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 cop
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
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 Geoghegan
--
Sent via
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
da...@pgm
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 subs
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 DBMSes
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 occurs to me right now, unfortunately. However
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
> https://www.postgresql.org/me
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?
>>>
>>> Partly yes. Because memory space for dead TI
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.
>> The first is that this patch is a good
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 the
* 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
> >
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.
> >
> > Att
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, that's the New Way. See 40b449ae
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 before vacuum worker launch
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,
> +"missing space char
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 rebase your patch as it no longer applies clean
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 would probably be just fine
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 of foo with (modulus 8, remainder 1)
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 subpaths. This is called with
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 match
> create table
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 is unavoidable partitions number in modu
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 cheapest
>>> inner path, though it will be of use only for the very first
> 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 is
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 would be the "Sorting algorithms be
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 LWLockRegisterTranche. But
> this i
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 it would count the output
> > > rows, regardless of w
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 with
> > > postgresql compliled with
1 - 100 of 104 matches
Mail list logo
