On 2018/01/23 15:55, Ashutosh Sharma wrote:
>> However, we don't make it fail because the table has a constraint that
>> contradicts the partition constraint. Attach succeeds in the absence of
>> any violating rows and the end result is that the table/partition has
>> contradictory constraints (th
On Tue, Jan 16, 2018 at 5:56 PM, Haribabu Kommi
wrote:
>
> On Tue, Jan 16, 2018 at 2:55 PM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>>
>> Note that I still find this API confusing, it seems to me that just
>> sorting out the confusion problems with PQhost and then use it would be
On Tue, Jan 23, 2018 at 8:56 AM, Tom Lane wrote:
> I wrote:
> > Specifically, I see failures like this on machines where the prevailing
> > locale isn't C or US:
>
> > pg_restore: [archiver (db)] Error while PROCESSING TOC:
> > pg_restore: [archiver (db)] Error from TOC entry 4871; 2618 34337 RUL
Hello, I returned to this.
I thouroughly checked the translator's behavior against the XPath
specifications and checkd out the documentation and regression
test. Almost everything is fine for me and this would be the last
comment from me.
At Fri, 24 Nov 2017 18:32:43 +0100, Pavel Stehule
wrote
On Tue, Jan 23, 2018 at 11:49 AM, Amit Langote
wrote:
> On 2018/01/23 14:35, Ashutosh Sharma wrote:
>> I have created a regular table with CHECK constraint on the partition
>> key column and it conflicts with the partition constraint but, still,
>> i could attach the table with the partitioned tab
Hi Amit
,
On 19 January 2018 at 04:03, David Rowley wrote:
> On 18 January 2018 at 23:56, Amit Langote
> wrote:
>> So, I've been assuming that the planner changes in the run-time pruning
>> patch have to do with selecting clauses (restriction clauses not
>> containing Consts and/or join clauses)
On 2018/01/23 14:35, Ashutosh Sharma wrote:
> I have created a regular table with CHECK constraint on the partition
> key column and it conflicts with the partition constraint but, still,
> i could attach the table with the partitioned table. Here is what i am
> trying to do,
>
> postgres[76308]=#
Hi all,
While reading the code, I realized that the requesting an autovacuum
work-item could fail in silence if work-item array is full. So the
users cannot realize that work-item is never performed.
AutoVacuumRequestWork() seems to behave so from the initial
implementation but is there any reason
Hi All,
I have created a regular table with CHECK constraint on the partition
key column and it conflicts with the partition constraint but, still,
i could attach the table with the partitioned table. Here is what i am
trying to do,
postgres[76308]=# create table part_tab (b int, a int) partition
On Fri, Jan 19, 2018 at 2:07 AM, Simon Riggs wrote:
> err... that isn't correct. An empty range matches nothing, so can be
> ignored in joins.
>
> So probably best to explain some more, please.
The semantics of R1 @> R2 will return true if R1 is a non-NULL range
and R2 is empty.
It's set semanti
On Mon, Jan 22, 2018 at 12:48:45PM +0100, Daniel Gustafsson wrote:
> Gotcha. Iâve added some tests to the patch. The test for CREATE
> FUNCTION was omitted for now awaiting the outcome of the discussion
> around isStrict and isCachable.
That makes sense.
> Not sure how much theyâre worth in
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> > On Monday, January 22, 2018, Stephen Frost wrote:
> >> In the end, I feel like this patch has actually been through the ringer
> >> and back because it was brought up in the context of solving a problem
> >> that we'd all like to fix in a better way
Hi,
Attached a patch for $subject. The implementation of autovacuum
work-item has been changed by commit
31ae1638ce35c23979f9bcbb92c6bb51744dbccb but the loading of dsa.h
header file is remained.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Cent
On Mon, Jan 22, 2018 at 7:16 PM, Robert Haas wrote:
> On Fri, Jan 19, 2018 at 10:59 PM, Amit Kapila wrote:
>> The patch doesn't apply cleanly on the head, but after rebasing it, I
>> have reviewed and tested it and it seems to be working fine. Apart
>> from this specific issue, I think we should
On Tue, Jan 23, 2018 at 8:43 AM, Peter Geoghegan wrote:
> On Mon, Jan 22, 2018 at 6:45 PM, Amit Kapila wrote:
>>> FWIW, I don't think that that's really much of a difference.
>>>
>>> ExecParallelFinish() calls WaitForParallelWorkersToFinish(), which is
>>> similar to how _bt_end_parallel() calls
Greetings,
* Юрий Соколов (funny.fal...@gmail.com) wrote:
> On Wed, Nov 29, 2017 at 8:00 AM, Peter Geoghegan wrote:
> > On Tue, Nov 28, 2017 at 2:41 PM, Andres Freund wrote:
> >> Maybe it's a stupid question. But would we still want to have this after
> >> the change? These should be just specia
> On Monday, January 22, 2018, Stephen Frost wrote:
>> In the end, I feel like this patch has actually been through the ringer
>> and back because it was brought up in the context of solving a problem
>> that we'd all like to fix in a better way. Had it been simply dropped
>> on us as a "I'd like
On Mon, Jan 22, 2018 at 6:45 PM, Amit Kapila wrote:
>> FWIW, I don't think that that's really much of a difference.
>>
>> ExecParallelFinish() calls WaitForParallelWorkersToFinish(), which is
>> similar to how _bt_end_parallel() calls
>> WaitForParallelWorkersToFinish() in the patch. The
>> _bt_le
Greetings!
* chenhj (chjis...@163.com) wrote:
> Rebased and removed the whitespace.
Thanks for working on this, I agree that it seems like a pretty cool
optimization for pg_rewind.
I've only read through the thread to try and understand what's going on
and the first thing that comes to mind is
On Tue, Jan 23, 2018 at 1:45 AM, Peter Geoghegan wrote:
> On Mon, Jan 22, 2018 at 3:52 AM, Amit Kapila wrote:
>> The difference is that nodeGather.c doesn't have any logic like the
>> one you have in _bt_leader_heapscan where the patch waits for each
>> worker to increment nparticipantsdone. For
On 1/18/18 12:41, Tom Lane wrote:
> Peter Eisentraut writes:
>> So I'm proposing the attached alternative patch, which creates
>> constraint triggers to be TRIGGER_FIRES_ALWAYS by default.
>> Thoughts?
>
> Hm, the general idea seems attractive, but I'm not sure we want
> this behavioral change fo
On 1/19/18 05:31, Simon Riggs wrote:
>> I'm not aware of an explanation why it currently works the way it does,
>> other than that FKs happen to be implemented by triggers and triggers
>> happen to work that way. But I think it's pretty bogus that logical
>> replication subscriptions can insert da
On 23 January 2018 at 15:21, Stephen Frost wrote:
> Alexey,
>
> * Alexey Kondratov (kondratov.alek...@gmail.com) wrote:
> > On Fri, Dec 1, 2017 at 1:58 AM, Alvaro Herrera
> wrote:
> > > On a *very* quick look, please use an enum to return from NextCopyFrom
> > > rather than 'int'. The chunks th
On Mon, Jan 22, 2018 at 04:52:11PM +0100, Daniel Gustafsson wrote:
> Not really, but IIUC a bug in this code could lead to channel binding
> not being used for a connection even if the user wanted it (and may
> miss that ixt didn’t happen due to not looking at logs etc)?
Possible, if an implementa
Alexey,
* Alexey Kondratov (kondratov.alek...@gmail.com) wrote:
> On Fri, Dec 1, 2017 at 1:58 AM, Alvaro Herrera
> wrote:
> > On a *very* quick look, please use an enum to return from NextCopyFrom
> > rather than 'int'. The chunks that change bool to int are very
> > odd-looking. This would mo
On Mon, Jan 22, 2018 at 03:22:05PM -0800, Peter Geoghegan wrote:
> Michael said he'd do more review. I generally feel this is close, though.
Yep. I have provided the feedback I wanted for 0001 (no API change in
the bloom facility by the way :( ), but I still wanted to look at 0002
in depths.
--
Mi
On Monday, January 22, 2018, Stephen Frost wrote:
>
> In the end, I feel like this patch has actually been through the ringer
> and back because it was brought up in the context of solving a problem
> that we'd all like to fix in a better way. Had it been simply dropped
> on us as a "I'd like to
On Mon, Jan 22, 2018 at 04:23:55PM -0500, Tom Lane wrote:
> Robert Haas writes:
>> I agree with Noah. It's true that having unfixed bugs isn't
>> particularly good, but it doesn't justify activating a CommitFest
>> entry under someone else's name.
>
> Agreed. The CF app is not a bug tracker.
O
On 2018/01/23 8:57, Thomas Munro wrote:
> On Tue, Jan 23, 2018 at 12:41 PM, Thomas Munro
> wrote:
>> On Mon, Jan 15, 2018 at 2:32 PM, Stephen Frost wrote:
>>> If someone else would like to review it, that'd be great, otherwise I'll
>>> probably get it committed soon.
>>
>> FYI the v2 doesn't buil
Robert, all,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Aug 7, 2017 at 11:14 AM, Fabrízio de Royes Mello
> wrote:
> > I also test against all current supported versions (9.2 ... 9.6) and didn't
> > find any issue.
> >
> > Changed status to "ready for commiter".
>
> On a very fast rea
On Thu, Jan 18, 2018 at 9:22 AM, Robert Haas wrote:
> But, hang on a minute. Why do the workers need to wait for the leader
> anyway? Can't they just exit once they're done sorting? I think the
> original reason why this ended up in the patch is that we needed the
> leader to assume ownership o
On 01/23/2018 03:19 AM, Peter Eisentraut wrote:
On 1/9/18 15:36, Peter Eisentraut wrote:
On 12/7/17 19:54, Tatsuo Ishii wrote:
On Wed, Dec 6, 2017 at 9:19 PM, Ian Barwick wrote:
Note this substitution sends a "pg_is_in_recovery()" query to the server
each time it's encountered; unless there's
On Tue, Jan 23, 2018 at 12:41 PM, Thomas Munro
wrote:
> On Mon, Jan 15, 2018 at 2:32 PM, Stephen Frost wrote:
>> If someone else would like to review it, that'd be great, otherwise I'll
>> probably get it committed soon.
>
> FYI the v2 doesn't build:
>
> ref/alter_table.sgml:135: parser error : O
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> Unless somebody can prove convincingly that this argument is wrong and
> that there are no other possible problems either, and memorialize that
> argument in the form of a detailed comment, I think we should reject
> this patch.
> http://
On Mon, Jan 15, 2018 at 2:32 PM, Stephen Frost wrote:
> If someone else would like to review it, that'd be great, otherwise I'll
> probably get it committed soon.
FYI the v2 doesn't build:
ref/alter_table.sgml:135: parser error : Opening and ending tag
mismatch: refentry line 6 and synopsis
Greetings,
* Marko Tiikkaja (ma...@joh.to) wrote:
> On Thu, Nov 30, 2017 at 6:39 AM, Peter Geoghegan wrote:
> > On Wed, Nov 29, 2017 at 8:34 PM, Michael Paquier
> > wrote:
> > > The patch does not currently apply. I am noticing as well that Peter
> > > Geoghegan has registered himself as a revie
Hi,
On Fri, Jan 12, 2018 at 1:41 AM, Andrey Borodin wrote:
> I've looked into the code and here's my review.
>
> The new functionality works and is useful right now. I believe it should be
> shipped in the Postgres box (currently, I install it with packet managers).
> The code is nice and well d
Greetings Ivan,
* Ivan Kartyshov (i.kartys...@postgrespro.ru) wrote:
> Ants Aasma писал 2017-10-26 17:29:
> >On Mon, Oct 23, 2017 at 12:29 PM, Ivan Kartyshov
> > wrote:
> >>Ants Aasma писал 2017-09-26 13:00:
> >>>
> >>>Exposing this interface as WAITLSN will encode that visibility order
> >>>match
Greetings,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Aug 18, 2017 at 2:09 PM, Masahiko Sawada
> wrote:
> > On Thu, Aug 17, 2017 at 8:17 PM, Masahiko Sawada
> > wrote:
> >> On Thu, Aug 17, 2017 at 9:10 AM, Peter Eisentraut
> >> wrote:
> >>> On 8/8/17 05:58, Masahiko Sawada
Alvaro Herrera wrote:
> Version 4 of this patch, rebased on today's master.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 1a02e7f359c94e5db0bb069666b950775cd3e2af Mon Sep 17 00:00:00 2001
From: Alvaro Her
Version 4 of this patch, rebased on today's master.
The main change is in dependency handling for the constraints: you now
can't drop a constraint from a partition, if it's attached to a
constraint in the parent (you can't drop indexes from under the
constraints either, but that was true in previo
Greetings,
* Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> On Wed, Jun 28, 2017 at 1:11 PM, Thomas Munro
> wrote:
> > On Sat, Mar 25, 2017 at 7:27 AM, Thomas Munro
> > wrote:
> >> On Sat, Mar 25, 2017 at 3:11 AM, Anastasia Lubennikova
> >> wrote:
> >>> You claim that SLRUs now support f
On 01/17/2018 04:01 PM, Andrew Dunstan wrote:
>
> On 01/15/2018 07:24 PM, Andrew Dunstan wrote:
>> On 01/10/2018 05:42 PM, Nikita Glukhov wrote:
>>> Attached new 8th version of jsonpath related patches. Complete
>>> documentation is still missing.
>>>
>>> The first 4 small patches are necessary d
On 22/01/18 19:45, Petr Jelinek wrote:
> On 19/01/18 12:37, Marco Nenciarini wrote:
>> Hi All,
> + /* logicalrep_rel_close call not needed, because ExecuteTruncateGuts
> + * already closes the relations. Setting localrel to NULL in the
> map entry
> + * is still neede
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> here is a GUC based patch for plancache controlling. Looks so this code is
> working.
This really could use a new thread, imv. This thread is a year old and
about a completely different feature than what you've implemented here.
> It is
On Thu, Jan 11, 2018 at 2:14 AM, Andrey Borodin wrote:
> I like heapam verification functionality and use it right now. So, I'm
> planning to provide review for this patch, probably, this week.
Great!
> Seems like new check is working 4 orders of magnitudes faster then
> bt_index_parent_check(
I wrote:
> Specifically, I see failures like this on machines where the prevailing
> locale isn't C or US:
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 4871; 2618 34337 RULE
> rtest_emp rtest_emp_del pgbf
> pg_restore: [archiver (db)
Oleg,
I'm not really sure why this is still in Needs Review as a review was
posted and I don't see any follow-up. I've changed this to be Waiting
for Author.
* Antonin Houska (a...@cybertec.at) wrote:
> Oleg Ivanov wrote:
>
> > In order to overcome that issue, I would like to propose the patch
On 01/22/2018 08:52 PM, Robert Haas wrote:
> On Sat, Jan 20, 2018 at 7:51 AM, Magnus Hagander wrote:
>> Finally found myself back at this one, because I still think this is a
>> problem we definitely need to adress (whether with this file or not).
>>
>> The funneling into a single process is def
Robert Haas writes:
> I agree with Noah. It's true that having unfixed bugs isn't
> particularly good, but it doesn't justify activating a CommitFest
> entry under someone else's name.
Agreed. The CF app is not a bug tracker.
> If nobody is willing to put in the effort to keep AIX supported un
Greetings,
* Sokolov Yura (funny.fal...@postgrespro.ru) wrote:
> diff --git a/src/backend/utils/time/snapmgr.c
> b/src/backend/utils/time/snapmgr.c
> index 08a08c8e8f..7c3fe7563e 100644
> --- a/src/backend/utils/time/snapmgr.c
> +++ b/src/backend/utils/time/snapmgr.c
> @@ -662,13 +662,16 @@ CopyS
On 12/14/2006 01:17 PM, Peter Eisentraut wrote:
> Tom Lane wrote:
>> Peter Eisentraut writes:
>>> By extrapolation of the SQL standard, I'd say we'd need to check
>>> the EXECUTE privilege of the function at run time.
>>
>> Certainly EXECUTE privilege is what to check, but whose privilege?
>
> ..
I wrote:
> Commit 4bd371f6f's hack to emit "SET default_transaction_read_only = off"
> is gone: we now dodge that problem by the expedient of not issuing ALTER
> DATABASE SET commands until after reconnecting to the target database.
> Therefore, such settings won't apply during the restore session.
On Sat, Jan 20, 2018 at 6:16 PM, Michael Paquier
wrote:
>> The most recent patch version is Returned with Feedback. As a matter of
>> procedure, I discourage creating commitfest entries as a tool to solicit new
>> patch versions. If I were the author of a RwF patch, I would dislike finding
>> a
Hello Ildus,
15/01/2018 00:49, Ildus Kurbangaliev пишет:
> Attached a new version of the patch. Main changes:
>
> * compression as an access method
> * pglz as default compression access method.
> * PRESERVE syntax for tables rewrite control.
> * pg_upgrade fixes
> * support partitioned tables.
>
On Mon, Jan 22, 2018 at 3:52 AM, Amit Kapila wrote:
> The difference is that nodeGather.c doesn't have any logic like the
> one you have in _bt_leader_heapscan where the patch waits for each
> worker to increment nparticipantsdone. For Gather node, we do such a
> thing (wait for all workers to fi
Chris,
* Chris Travers (chris.trav...@adjust.com) wrote:
> Attached is the patch as submitted for commitfest.
This has been stuck in Waiting for Author since before the commitfest
started. I'll try to kick-start it but it seems like it's stuck because
there's a fundamental disagreement about if
В письме от 29 октября 2017 17:08:29 пользователь Nikolay Shaplov написал:
> While merging this commit to my branch, I found two issues that as I think
> needs fixing. Hope this does not require creating new commit request...
To draw more attention to this issue, I've filed it as a new thread
ht
On 22/01/18 20:21, Robert Haas wrote:
> On Mon, Jan 22, 2018 at 10:40 AM, Petr Jelinek
> wrote:
>> I think this is the only real problem from your list for logical
>> decoding catalog snapshots. But it's indeed quite a bad one. Is there
>> something preventing us to remove the assumption that the
I have a small fixes for already committed reloption test patch
(https://www.postgresql.org/message-id/2615372.orqtEn8VGB@x200m)
First one is missing tab symbol where it should be.
The second is a comment. "The OIDS option is not stored" is not quite correct.
They are stored, but not as reloptio
On Sat, Jan 20, 2018 at 7:51 AM, Magnus Hagander wrote:
> Finally found myself back at this one, because I still think this is a
> problem we definitely need to adress (whether with this file or not).
>
> The funneling into a single process is definitely an issue.
>
> But we don't really solve tha
Robert Haas writes:
> On Mon, Jan 22, 2018 at 2:09 PM, Tom Lane wrote:
>> pg_dumpall with --clean will now drop and recreate the "postgres" and
>> "template1" databases in the target cluster, allowing their locale and
>> encoding settings to be changed if necessary, and providing a cleaner
>> way
Jing Wang writes:
> [ support_CURRENT_DATABASE_keyword_v4.6.patch ]
Not surprisingly, this patch no longer applies in the wake of commit
b3f840120. Rather than rebasing the pg_dump portions, I would suggest
you just drop them. It is no longer necessary for pg_dump to worry about
this, because i
On Mon, Jan 22, 2018 at 2:09 PM, Tom Lane wrote:
> pg_dumpall with --clean will now drop and recreate the "postgres" and
> "template1" databases in the target cluster, allowing their locale and
> encoding settings to be changed if necessary, and providing a cleaner
> way to set nondefault tablespa
On Mon, Jan 22, 2018 at 10:40 AM, Petr Jelinek
wrote:
> I think this is the only real problem from your list for logical
> decoding catalog snapshots. But it's indeed quite a bad one. Is there
> something preventing us to remove the assumption that the CTID of T1 is
> garbage nobody cares about? I
On 19/01/18 12:37, Marco Nenciarini wrote:
> Hi All,
>
> Il 18/01/18 17:48, Simon Riggs ha scritto:
>> On 17 January 2018 at 17:07, Petr Jelinek
>> wrote:
>>
>>> Things I am less convinced about:
>>>
>>> The patch will cascade truncation on downstream if cascade was specified
>>> on the upstream
On 19/01/18 12:41, Marco Nenciarini wrote:
> Hi Peter,
>
> Il 18/01/18 17:30, Peter Eisentraut ha scritto:
>> On 1/17/18 11:33, Petr Jelinek wrote:
P.S: I'm struggling to understand why we have two possible values of
session_replication_role settings that behave identically (origin and
>
On 01/12/2018 06:59 AM, Edmund Horner wrote:
> Hi, here's a new patch.
>
> This one makes some changes to the criteria for which functions to
> include; namely filtering out trigger functions and those that take or
> return values of type "internal"; and including aggregate and window
> functions.
On 1/9/18 15:36, Peter Eisentraut wrote:
> On 12/7/17 19:54, Tatsuo Ishii wrote:
>>> On Wed, Dec 6, 2017 at 9:19 PM, Ian Barwick
>>> wrote:
Note this substitution sends a "pg_is_in_recovery()" query to the server
each time it's encountered; unless there's something I'm overlooking I
>>>
On 01/22/2018 05:05 PM, Konstantin Knizhnik wrote:
>
>
> On 19.01.2018 20:28, Tomas Vondra wrote:
>>>
>>> With pgbouncer you will never be able to use prepared statements which
>>> slows down simple queries almost twice (unless my patch with
>>> autoprepared statements is committed).
>>>
>> I d
On 1/21/18 15:43, Andres Freund wrote:
> We've still some support for building the backend with PARTIAL_LINKING /
> SUBSYS.o instead of the current objfiles.txt approach.
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9956ddc19164b02dc1925fb389a1af77472eba5e
>
> Any objections to
On 19.01.2018 20:28, Tomas Vondra wrote:
With pgbouncer you will never be able to use prepared statements which
slows down simple queries almost twice (unless my patch with
autoprepared statements is committed).
I don't see why that wouldn't be possible? Perhaps not for prepared
statements w
> On 22 Jan 2018, at 14:05, Michael Paquier wrote:
>
> On Mon, Jan 22, 2018 at 11:07:55AM +0100, Daniel Gustafsson wrote:
>> An extensible API makes more sense than on/off (or one on/off call per
>> binding). Perhaps a way to validate the contents of the list is
>> required though? Or an assert
Hi,
On 20/01/18 00:52, Robert Haas wrote:
> On Fri, Jan 19, 2018 at 5:19 PM, Tomas Vondra
> wrote:
>> Regarding the HOT issue - I have to admit I don't quite see why A2
>> wouldn't be reachable through the index, but that's likely due to my
>> limited knowledge of the HOT internals.
>
> The inde
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I can confirm that these patches don't break anything; the co
Robert Haas writes:
> Tom, do you want to double-check that this fixes it for you?
I can confirm that a valgrind run succeeded for me with the patch
in place.
regards, tom lane
On 01/22/2018 04:16 AM, Magnus Hagander wrote:
>
>
>
>
> I'll be quite happy to retire the XP machine running brolga, currawong
> and frogmouth, if that's the consensus. XP is now long out of support.
> OTOH I have personal experience of it running in many potentially
> critical s
On 1/16/18 15:24, Andrew Dunstan wrote:
> Looks good. Marking ready for committer.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Jan 21, 2018 at 9:02 AM, Amit Kapila wrote:
> How about adding a project to support Unique capability for the Hash
> Index?
Hmm, that seems pretty hard.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Fri, Jan 19, 2018 at 10:59 PM, Amit Kapila wrote:
> The patch doesn't apply cleanly on the head, but after rebasing it, I
> have reviewed and tested it and it seems to be working fine. Apart
> from this specific issue, I think we should consider making
> nworkers_launched reliable (at the very
On Mon, Jan 22, 2018 at 11:07:55AM +0100, Daniel Gustafsson wrote:
> An extensible API makes more sense than on/off (or one on/off call per
> binding). Perhaps a way to validate the contents of the list is
> required though? Or an assertion on the contents to catch errors
> during testing.
Do yo
On Mon, Jan 22, 2018 at 2:44 AM, Amit Khandekar wrote:
> Yes, right, that's what is happening. It is not happening on an Assert
> though (there is no assert in that function). It is happening when we
> try to access the array here :
>
> if (proute->subplan_partition_offsets &&
>
On Sun, Jan 21, 2018 at 5:41 PM, Craig Ringer wrote:
> If we'd done server_version_num in 9.5, for example, less stuff would've
> broken with pg10.
Yeah, and if Tom hadn't forced it to be reverted from *8.2*, then
every version anyone still cares about would now have support for it.
--
Robert H
On Thu, Jan 18, 2018 at 12:59 AM, Robert Haas wrote:
> On Wed, Jan 17, 2018 at 8:53 AM, Simon Riggs wrote:
>
> Or we could go the other way and try to keep the workers running. I
> don't really like that because it ties down those workers for
> potentially a long period of time, but that might b
On Mon, Jan 22, 2018 at 10:36 AM, Peter Geoghegan wrote:
> On Sun, Jan 21, 2018 at 6:34 PM, Amit Kapila wrote:
>>> Why is this okay for Gather nodes, though? nodeGather.c looks at
>>> pcxt->nworkers_launched during initialization, and appears to at least
>>> trust it to indicate that more than ze
> On 15 Jan 2018, at 02:33, Michael Paquier wrote:
> On Fri, Jan 12, 2018 at 11:35:48PM +0100, Daniel Gustafsson wrote:
>> On 11 Jan 2018, at 09:01, Michael Paquier wrote:
One open question from this excercise is how to write a good test for
this. It can either be made part of the alr
Hello!
On 11.01.2018 18:53, Arthur Zakirov wrote:
The relationship between custom signals and
assigned handlers (function addresses) is replicated from postmaster to
child processes including working backends.
I think this happens only if a custom signal registered during initializing
shared_
On 12.01.2018 18:51, Teodor Sigaev wrote:
In perspective, this mechanism provides the low-level instrument to
define remote procedure call on extension side. The simple RPC that
defines effective userid on remote backend (remote_effective_user
function) is attached for example.
Suppose, it's
> On 22 Jan 2018, at 08:29, Michael Paquier wrote:
> Attached is a patch which is an attempt to make this choice cleaner for
> new SSL implementations. As we are (rightly!) calling the APIs to fetch
> the channel binding data only when necessary, I think that we need an
> extra API for SSL implem
On 22 January 2018 at 08:07, John Naylor wrote:
> On 1/21/18, Dean Rasheed wrote:
>> It occurs to me that maybe a better test to exclude a value from the
>> MCV list would be to demand that its relative standard error not be
>> too high. Such a test, in addition to the existing tests, might be
>>
2018-01-22 10:45 GMT+01:00 Fabien COELHO :
>
> few scripting features doesn't mean scripting language. \if in psql is nice
>> feature that reduce duplicate code, unreadable code, and helps with
>> deployment and test scripts. pgbench and psql should to have similar
>> environment - and I am thinki
few scripting features doesn't mean scripting language. \if in psql is nice
feature that reduce duplicate code, unreadable code, and helps with
deployment and test scripts. pgbench and psql should to have similar
environment - and I am thinking so \if should be there.
Using Lua is not bad idea
On Mon, Jan 22, 2018 at 4:24 AM, Thomas Munro wrote:
> On Mon, Jan 22, 2018 at 3:45 AM, Magnus Hagander
> wrote:
> > I got myself a working build env now so I can at least verify it builds,
> > which it does.
> >
> > With that, I'm pushing this. Let's see what the buildfarm thinks of it.
> And
>
On Mon, Jan 22, 2018 at 12:13 AM, Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
>
> On 01/21/2018 01:02 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-01-21 13:42:13 +0200, Magnus Hagander wrote:
> >> To add some more notes on this. Again, the API appears in Vista/2003.
> >> Windows
On Thu, Dec 14, 2017 at 11:58 PM, Robert Haas wrote:
> On Tue, Dec 12, 2017 at 8:48 PM, Stephen Frost wrote:
>> If the persistence is changed then the table will be written into the
>> WAL, no? All of the WAL generated during a backup (which is what we're
>> talking about here) has to be replaye
(Starting a new thread so as not to distract review)
On 1/21/18, Dean Rasheed wrote:
> On 21 January 2018 at 07:26, John Naylor wrote:
>> I spent a few hours hacking on this, and it turns out calculating the
>> right number of MCVs taking into account both uniform and highly
>> non-uniform distr
96 matches
Mail list logo
