On 2017-04-05 00:58:07 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Apr 4, 2017 at 6:56 PM, Joe Conway wrote:
> >> Any objections?
>
> > I'm guessing Tom's going to have a strong feeling about whether 0001a
> > is the right way to address the stdbool issue,
>
> I will? [ looks ...
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii
> Since pgproto is a dumb protocol machine, it does not start a transaction
> automatically (user needs to explicitly send a start transaction command
> via either simple or extended que
On Tue, Apr 4, 2017 at 11:22 PM, Tomas Vondra
wrote:
> On 04/04/2017 06:52 PM, Robert Haas wrote:
>>
>> On Mon, Apr 3, 2017 at 6:08 AM, Kuntal Ghosh
>> wrote:
>>>
>>> On Fri, Mar 31, 2017 at 6:50 PM, Robert Haas
>>> wrote:
On Thu, Mar 30, 2017 at 4:35 PM, Kuntal Ghosh
wrote:
On 2017-04-05 00:39:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-05 10:05:19 +0900, Tatsuo Ishii wrote:
> >> What's your point of the question? What kind of problem do you expect
> >> if the timeout starts only once at the first parse meesage out of
> >> bunch of parse messages
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Andres Freund
> As I asked before, why can't we delete all privs and add the explicitly
> needed once back (using AdjustTokenPrivileges)?
I tried it with pg_ctl.c attached to an earlier mail today,
On 2017-04-05 02:47:55 -0400, Noah Misch wrote:
> On Fri, Mar 10, 2017 at 11:49:46AM -0800, Andres Freund wrote:
> > On 2017-03-09 13:34:22 -0500, Robert Haas wrote:
> > > On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote:
> > > > Andres Freund writes:
> > > >> Wonder if we there's an argument to b
> Then, the following sequence should have occurred. The test result is valid.
Yes, I remembered that and was about to make a posting :-)
> # Execute statement which takes 2 seconds.
> 'P' "S1""SELECT pg_sleep(2)"0
> -> start transaction T1
> 'B' "S2""S1"0 0 0
Hi,
>However, running your original example, I'm getting this error
Thank you for testing. Please find attached an updated patch which fixes
the above.
Thank you,
Rahila Syed
default_partition_v5.patch
Description: application/download
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Tue, Apr 4, 2017 at 12:16 PM, Neha Khatri wrote:
> I feel there should be an assert if
> (BackgroundWorkerData->parallel_register_count -
> BackgroundWorkerData->parallel_terminate_count) > max_parallel_workers)
>
Backend 1 > SET max_parallel_worker = 8;
Backend 1 > Execute a long running
On 2017/04/05 14:41, Rushabh Lathia wrote:
> I agree about the future plan about the row movement, how that is I am
> not quite sure at this stage.
>
> I was thinking that CREATE new partition is the DDL command, so even
> if row-movement works with holding the lock on the new partition table,
> t
On 04/05/2017 04:05 AM, Andres Freund wrote:
PostgresMain() has the following blurb for fastpath functions:
/*
* Note: we may at this point be inside an
aborted
* transaction. We can't throw error
On Thu, Mar 30, 2017 at 3:50 AM, Robert Haas wrote:
> On Wed, Mar 29, 2017 at 1:31 AM, Thomas Munro
> wrote:
>> I considered whether the error message could be improved but it
>> matches the message for an existing similar case (where you try to
>> attach to an unknown handle).
>
> Ugh, OK. I co
The promised new version of my patch is here:
https://www.postgresql.org/message-id/9666.1491295317%40localhost
Jeevan Chalke wrote:
> On Tue, Mar 21, 2017 at 1:47 PM, Antonin Houska wrote:
>
> Jeevan Chalke wrote:
>
> IIUC, it seems that you are trying to push down the aggregation into th
Antonin Houska wrote:
>
> Jeevan Chalke wrote:
>
> > Our work will overlap when we are pushing down the aggregate on partitioned
> > base relation to its children/partitions.
> >
> > I think you should continue working on pushing down aggregate onto the
> > joins/scans where as I will continue
On 2017/04/04 21:28, Ashutosh Bapat wrote:
On Tue, Apr 4, 2017 at 2:31 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
I rebased the patch also. Please find attached an updated version
of the patch.
Thanks, marking this as "ready for committer".
Thanks!
Best regards,
On 5 April 2017 at 04:19, Andres Freund wrote:
> On 2017-04-04 22:32:40 +0800, Craig Ringer wrote:
>> I'm much happier with this. I'm still fixing some issues in the tests
>> for 03 and tidying them up, but 03 should allow 01 and 02 to be
>> reviewed in their proper context now.
>
> To me this ver
On 5 April 2017 at 01:43, Andres Freund wrote:
> On 2017-04-04 08:01:32 -0400, Robert Haas wrote:
>> On Tue, Apr 4, 2017 at 12:47 AM, Andres Freund wrote:
>> > I don't think the parallel seqscan is comparable in complexity with the
>> > parallel append case. Each worker there does the same kind
Hi Arthur,
On 2017/04/05 0:55, Arthur Zakirov wrote:
On 23.03.2017 15:45, Etsuro Fujita wrote:
I have a few comments.
Thank you for the review!
* innersortkeys are the sort pathkeys for the inner side of the
mergejoin
+ * req_outer_list is a list of sensible parameterizations for the
On 04/05/2017 09:05 AM, Kuntal Ghosh wrote:
On Tue, Apr 4, 2017 at 11:22 PM, Tomas Vondra
wrote:
On 04/04/2017 06:52 PM, Robert Haas wrote:
On Mon, Apr 3, 2017 at 6:08 AM, Kuntal Ghosh
wrote:
On Fri, Mar 31, 2017 at 6:50 PM, Robert Haas
wrote:
On Thu, Mar 30, 2017 at 4:35 PM, Kuntal G
On 04/05/2017 08:41 AM, Sven R. Kunze wrote:
Thanks Tomas and David for hacking on this patch.
On 04.04.2017 20:19, Tomas Vondra wrote:
I'm not sure we still need the min_group_size, when evaluating
dependencies. It was meant to deal with 'noisy' data, but I think it
after switching to the '
Hi Amit,
On 2017/04/04 20:11, Amit Khandekar wrote:
> On 3 April 2017 at 17:13, Amit Langote wrote:
On 31 March 2017 at 14:04, Amit Langote wrote:
>> How about something like:
>> For an UPDATE that causes a row to move from one partition to
>> another due the partition key being updated, the
Hello Amit,
>Could you briefly elaborate why you think the lack global index support
>would be a problem in this regard?
I think following can happen if we allow rows satisfying the new partition
to lie around in the
default partition until background process moves it.
Consider a scenario where pa
Hello,
On Wed, Apr 5, 2017 at 9:29 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 4/4/17 22:47, Amit Kapila wrote:
> >> Committed first part to allow internal representation change (only).
> >>
> >> No commitment yet to increasing wal-segsize in the way this patch has
> it.
Hi Rahila,
On 2017/04/05 18:57, Rahila Syed wrote:
> Hello Amit,
>
>> Could you briefly elaborate why you think the lack global index support
>> would be a problem in this regard?
> I think following can happen if we allow rows satisfying the new partition
> to lie around in the
> default partiti
On Wed, Apr 5, 2017 at 3:07 PM, Tomas Vondra
wrote:
>
>
> On 04/05/2017 09:05 AM, Kuntal Ghosh wrote:
>>
>> AFAICU, during crash recovery, we wait for all non-syslogger children
>> to exit, then reset shmem(call BackgroundWorkerShmemInit) and perform
>> StartupDataBase. While starting the startup
On 04/05/2017 12:36 PM, Kuntal Ghosh wrote:
On Wed, Apr 5, 2017 at 3:07 PM, Tomas Vondra
wrote:
On 04/05/2017 09:05 AM, Kuntal Ghosh wrote:
AFAICU, during crash recovery, we wait for all non-syslogger children
to exit, then reset shmem(call BackgroundWorkerShmemInit) and perform
StartupDa
On Wed, Apr 5, 2017 at 4:13 PM, Tomas Vondra
wrote:
>>>
>>> The comment says that the counters are allowed to overflow, i.e. after a
>>> long uptime you might get these values
>>>
>>> parallel_register_count = UINT_MAX + 1 = 1
>>> parallel_terminate_count = UINT_MAX
>>>
>>> which is fine
On 4 April 2017 at 22:47, Amit Kapila wrote:
> On Wed, Apr 5, 2017 at 3:36 AM, Simon Riggs wrote:
>> On 27 March 2017 at 15:36, Beena Emerson wrote:
>>
>>> 02-increase-max-wal-segsize.patch - Increases the wal-segsize and changes
>>> the internal representation of max_wal_size and min_wal_size t
On 5 April 2017 at 06:04, Beena Emerson wrote:
>> >> No commitment yet to increasing wal-segsize in the way this patch has
>> >> it.
>> >>
>> >
>> > What part of patch you don't like and do you have any suggestions to
>> > improve the same?
>>
>> I think there are still some questions and disagre
On vendredi 24 mars 2017 08:14:03 CEST Ashutosh Bapat wrote:
> On Mon, Mar 20, 2017 at 8:33 PM, Ronan Dunklau
wrote:
> > On lundi 20 mars 2017 15:52:03 CET Robert Haas wrote:
> >> On Mon, Mar 20, 2017 at 6:31 AM, Ronan Dunklau
> >
> > wrote:
> >> > With range partitioning, we guarantee that eac
Noah Misch wrote:
> The above-described topic is currently a PostgreSQL 10 open item. Álvaro,
> since you committed the patch believed to have created it, you own this open
> item.
I'll commit a fix for this problem no later than Friday 14th.
--
Álvaro Herrerahttps://www.2ndQua
After thinking about it some more, I think the behavior we want would be
that changes to inheritance would reflect in the publication membership.
So if you have a partitioned table, adding more partitions over time
would automatically add them to the publication.
We could implement this either by
On 4/4/17, Vitaly Burovoy wrote:
> On 4/3/17, Peter Eisentraut wrote:
>> On 3/30/17 22:57, Vitaly Burovoy wrote:
>>> Why do you still want to leave "ADD IF NOT EXISTS" instead of using
>>> "SET IF NOT EXISTS"?
>>> If someone wants to follow the standard he can simply not to use "IF
>>> NOT EXISTS
On 4/5/17 06:04, Beena Emerson wrote:
> I suggest the next step is to dial up the allowed segment size in
> configure and run some tests about what a reasonable maximum value could
> be. I did a little bit of that, but somewhere around 256 MB, things got
> really slow.
>
>
> Woul
On 04/05/2017 01:09 PM, Kuntal Ghosh wrote:
On Wed, Apr 5, 2017 at 4:13 PM, Tomas Vondra
wrote:
The comment says that the counters are allowed to overflow, i.e. after a
long uptime you might get these values
parallel_register_count = UINT_MAX + 1 = 1
parallel_terminate_count = U
On 11/24/16 18:13, Robert Haas wrote:
>> I'm finding hard to imagine a reason why these might be unsafe, but
>> failed. I do notice they're all only used in information_schema.
>>
>> Could it just perhaps be that these just missed the verification
>> process the other functions went through to dete
On 04.04.2017 15:41, Dmitry Dolgov wrote:
Sorry for late reply. Here is a new version of the patch, I rebased it and
fixed those issues you've mentioned (pretty nasty problems, thank you for
noticing).
Thank you!
I've looked at the patch again.
I'd like to focus on "refevalfunc" and "refneste
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
The patch looks fine to me. Changes are clear and all functions are c
On Wed, Apr 5, 2017 at 12:35 PM, Kuntal Ghosh
wrote:
> On Tue, Apr 4, 2017 at 11:22 PM, Tomas Vondra
> wrote:
>> On 04/04/2017 06:52 PM, Robert Haas wrote:
>>>
>>> On Mon, Apr 3, 2017 at 6:08 AM, Kuntal Ghosh
>>> wrote:
On Fri, Mar 31, 2017 at 6:50 PM, Robert Haas
wrote:
>
>>
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Apr 4, 2017 at 9:30 PM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> On Tue, Apr 4, 2017 at 7:38 AM, Stephen Frost wrote:
> >> The patch presented here does lower the coverage we have no
On Tue, Apr 4, 2017 at 11:43 PM, Pavan Deolasee
wrote:
> Well, better than causing a deadlock ;-)
Yep.
> Lets see if we want to go down the path of blocking WARM when tuples have
> toasted attributes. I submitted a patch yesterday, but having slept over it,
> I think I made mistakes there. It mi
On Tue, Apr 4, 2017 at 1:52 PM, Tomas Vondra
wrote:
> In any case, the comment right before BackgroundWorkerArray says this:
>
> * These counters can of course overflow, but it's not important here
> * since the subtraction will still give the right number.
>
> which means that this assert
>
> +
Andres Freund writes:
> On 2017-04-05 02:47:55 -0400, Noah Misch wrote:
>> [Action required within three days. This is a generic notification.]
> I've a very preliminary patch. I'd like to only start polishing it up
> once the code freeze is over, so I can work on getting some patches in -
> no
Andres Freund writes:
> I argued before that we should migrate to stdbool.h by default, because
> it's only going to get more common. We already do so in a way for c++
> compilers...
Yeah, I was just thinking about that. The core problem though is that
we need the "bool" fields in the system ca
Andres Freund writes:
> On 2017-04-05 00:39:51 -0400, Tom Lane wrote:
>> but
>> if that's what we're doing, let's make sure we do it consistently.
>> I haven't read the patch, but the comments in this thread make me fear
>> that it's introducing some ad-hoc, inconsistent behavior.
> I'm a bit wor
On Wed, Apr 5, 2017 at 12:58 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 4, 2017 at 6:56 PM, Joe Conway wrote:
>>> Any objections?
>
>> I'm guessing Tom's going to have a strong feeling about whether 0001a
>> is the right way to address the stdbool issue,
>
> I will? [ looks ... ]
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Apr 4, 2017 at 10:52 PM, Peter Eisentraut
> wrote:
> > On 4/3/17 11:32, Andres Freund wrote:
> >> That doesn't strike as particularly future proof. We intentionally
> >> leave objects behind pg_regress runs, but that only wo
On Wed, Apr 5, 2017 at 8:57 AM, Peter Eisentraut
wrote:
> On 11/24/16 18:13, Robert Haas wrote:
>>> I'm finding hard to imagine a reason why these might be unsafe, but
>>> failed. I do notice they're all only used in information_schema.
>>>
>>> Could it just perhaps be that these just missed the v
On Wed, Apr 5, 2017 at 6:36 AM, Kuntal Ghosh wrote:
> Yes. But, as Robert suggested up in the thread, we should not use
> (parallel_register_count = 0) as an alternative to define a bgworker
> crash. Hence, I've added an argument named 'wasCrashed' in
> ForgetBackgroundWorker to indicate a bgworke
> On 27 Mar 2017, at 18:59, Robert Haas wrote:
>
> On Mon, Mar 27, 2017 at 11:14 AM, Fujii Masao wrote:
>> Logical replication worker should call pgstat_report_stat()?
>> Currently it doesn't seem to do that and no statistics about
>> table accesses by logical replication workers are collected.
On Wed, Apr 5, 2017 at 7:31 PM, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 6:36 AM, Kuntal Ghosh
> wrote:
>> Yes. But, as Robert suggested up in the thread, we should not use
>> (parallel_register_count = 0) as an alternative to define a bgworker
>> crash. Hence, I've added an argument named 'w
On Tue, Apr 4, 2017 at 2:08 PM, Petr Jelinek
wrote:
> So this is what I came up with on plane. Generalized the loading
> functionality into load_library_function which that can load either
> known postgres functions or call load_external_function.
>
> I am not quite sure if fmgr.c is best place to
Stephen Frost writes:
> I believe that what Peter was getting at is that the pg_dump TAP tests
> create a whole slew of objects in just a few seconds and are able to
> then exercise those code-paths in pg_dump, without needing to run the
> entire serial regression test run.
Right. But there's a
On Wed, Apr 5, 2017 at 10:09 AM, Kuntal Ghosh
wrote:
>> Did you intend to attach that patch to this email?
>>
> Actually, I'm confused how we should ensure (register_count >
> terminate_count) invariant. I think there can be a system crash what
> Tomas has suggested up in the thread.
>
> Assert(pa
On Wed, Apr 5, 2017 at 3:59 AM, Thomas Munro
wrote:
> On Thu, Mar 30, 2017 at 3:50 AM, Robert Haas wrote:
>> On Wed, Mar 29, 2017 at 1:31 AM, Thomas Munro
>> wrote:
>>> I considered whether the error message could be improved but it
>>> matches the message for an existing similar case (where you
On 04/05/2017 04:09 PM, Kuntal Ghosh wrote:
On Wed, Apr 5, 2017 at 7:31 PM, Robert Haas wrote:
On Wed, Apr 5, 2017 at 6:36 AM, Kuntal Ghosh wrote:
Yes. But, as Robert suggested up in the thread, we should not use
(parallel_register_count = 0) as an alternative to define a bgworker
crash. Henc
On Wed, Apr 5, 2017 at 7:45 PM, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 10:09 AM, Kuntal Ghosh
> wrote:
>>> Did you intend to attach that patch to this email?
>>>
>> Actually, I'm confused how we should ensure (register_count >
>> terminate_count) invariant. I think there can be a system cras
On 04/05/2017 04:15 PM, Robert Haas wrote:
On Wed, Apr 5, 2017 at 10:09 AM, Kuntal Ghosh
wrote:
Did you intend to attach that patch to this email?
Actually, I'm confused how we should ensure (register_count >
terminate_count) invariant. I think there can be a system crash what
Tomas has sugge
On 2017-04-05 09:43:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I argued before that we should migrate to stdbool.h by default, because
> > it's only going to get more common. We already do so in a way for c++
> > compilers...
>
> Yeah, I was just thinking about that. The core problem
On 2017-03-31 20:23:39 -0400, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 2:14 PM, Mike Palmiotto
> wrote:
> > Attached you will find two patches, which were rebased on master as of
> > 156d388 (applied with `git am --revert [patch file]`). The first gets
> > rid of some pesky compiler warnings a
On 2017-04-05 17:18:24 +0800, Craig Ringer wrote:
> On 5 April 2017 at 04:19, Andres Freund wrote:
> > On 2017-04-04 22:32:40 +0800, Craig Ringer wrote:
> >> I'm much happier with this. I'm still fixing some issues in the tests
> >> for 03 and tidying them up, but 03 should allow 01 and 02 to be
>
On 2017-04-05 09:46:31 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-05 00:39:51 -0400, Tom Lane wrote:
> >> but
> >> if that's what we're doing, let's make sure we do it consistently.
> >> I haven't read the patch, but the comments in this thread make me fear
> >> that it's introd
On 05.04.2017 16:06, Arthur Zakirov wrote:
On 04.04.2017 15:41, Dmitry Dolgov wrote:
Sorry for late reply. Here is a new version of the patch, I rebased it
and
fixed those issues you've mentioned (pretty nasty problems, thank you for
noticing).
Thank you!
I've looked at the patch again.
So
Robert Haas writes:
> On Wed, Apr 5, 2017 at 8:57 AM, Peter Eisentraut
> wrote:
>> - Maybe add a check to opr_sanity to make sure the default set of
>> functions is configured the way we want?
> That seems like a good idea.
+1 for that. We could adopt the strategy already used in opr_sanity of
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I believe that what Peter was getting at is that the pg_dump TAP tests
> > create a whole slew of objects in just a few seconds and are able to
> > then exercise those code-paths in pg_dump, without needing to run the
> > ent
On Tue, Apr 4, 2017 at 4:13 PM, Andres Freund wrote:
> I'm quite unconvinced that just throwing a log() in there is the best
> way to combat that. Modeling the issue of starting more workers through
> tuple transfer, locking, startup overhead costing seems a better to me.
Knock yourself out. Th
Hi,
On 2017-04-05 10:40:41 -0400, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > I believe that what Peter was getting at is that the pg_dump TAP tests
> > > create a whole slew of objects in just a few seconds and are able to
> > > then exercise tho
Andres Freund writes:
> On 2017-04-05 09:43:53 -0400, Tom Lane wrote:
>> Yeah, I was just thinking about that. The core problem though is that
>> we need the "bool" fields in the system catalog structs (or anyplace
>> else that it represents an on-disk bool datum) to be understood as
>> being 1 b
On 5 April 2017 at 14:53, Kyotaro HORIGUCHI
wrote:
> At Tue, 4 Apr 2017 20:19:39 +0200, Tomas Vondra
> wrote in
> <56f40b20-c464-fad2-ff39-06b668fac...@2ndquadrant.com>
>> Two minor comments:
>>
>> 1) DEPENDENCY_MIN_GROUP_SIZE
>>
>> I'm not sure we still need the min_group_size, when evaluating
Andres Freund writes:
> On 2017-03-31 20:23:39 -0400, Robert Haas wrote:
>> 0001 has the problem that we have a firm rule against putting any
>> #includes whatsoever before "postgres.h". This stdbool issue has come
>> up before, though, and I fear we're going to need to do something
>> about it.
On 04/05/2017 04:26 PM, Kuntal Ghosh wrote:
On Wed, Apr 5, 2017 at 7:45 PM, Robert Haas wrote:
On Wed, Apr 5, 2017 at 10:09 AM, Kuntal Ghosh
wrote:
Did you intend to attach that patch to this email?
Actually, I'm confused how we should ensure (register_count >
terminate_count) invariant. I
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-04-05 10:40:41 -0400, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > Stephen Frost writes:
> > > > I believe that what Peter was getting at is that the pg_dump TAP tests
> > > > create a whole slew of objects in
On 2017-04-05 10:45:06 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-05 09:43:53 -0400, Tom Lane wrote:
> >> Yeah, I was just thinking about that. The core problem though is that
> >> we need the "bool" fields in the system catalog structs (or anyplace
> >> else that it represents
On 2017-04-05 10:48:27 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-03-31 20:23:39 -0400, Robert Haas wrote:
> >> 0001 has the problem that we have a firm rule against putting any
> >> #includes whatsoever before "postgres.h". This stdbool issue has come
> >> up before, though, and
On 2017-04-05 10:50:19 -0400, Stephen Frost wrote:
> Andres,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2017-04-05 10:40:41 -0400, Stephen Frost wrote:
> > > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > > Stephen Frost writes:
> > > > > I believe that what Peter was getting at is that
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Right. But there's a certain amount of serendipity involved in using the
>> core regression tests' final results. For example, I don't know how long
>> it would've taken us to understand the problems around dumping and
>> reloadin
Andres Freund writes:
> On 2017-04-05 10:48:27 -0400, Tom Lane wrote:
>> I'd really rather not. It might be safe here, because this code
>> only works on Linux anyway, but it's still a dangerous precedent.
> Well, what's the alternative for v10? There's already precedent btw.,
> cf plperl.h und
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-04-05 10:50:19 -0400, Stephen Frost wrote:
> > Probably because the point was brought up that the regression tests for
> > pg_upgrade spend a bunch of time doing something which, ultimately,
> > don't actually add any real value. Yes,
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm all for adding tests into pg_dump which do things like drop columns
> > and change column names and other cases which could impact if the
> > pg_dump is correct or not, and there's nothing preventing those tests
> > from
On Wed, Apr 5, 2017 at 5:57 AM, Rahila Syed wrote:
>>Could you briefly elaborate why you think the lack global index support
>>would be a problem in this regard?
> I think following can happen if we allow rows satisfying the new partition
> to lie around in the
> default partition until background
Andres Freund writes:
> On 2017-04-05 10:45:06 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> I wonder if there's any compiler that has _Bool/stdbool.h where it's not
>>> 1 byte sized. It's definitely not guaranteed by the standard.
>> Hm. I'd supposed that it'd be pretty common to make _B
On Wed, Apr 5, 2017 at 10:32 AM, Andres Freund wrote:
> On 2017-04-05 17:18:24 +0800, Craig Ringer wrote:
>> On 5 April 2017 at 04:19, Andres Freund wrote:
>> > On 2017-04-04 22:32:40 +0800, Craig Ringer wrote:
>> >> I'm much happier with this. I'm still fixing some issues in the tests
>> >> for
On 04/04/2017 09:58 PM, Tom Lane wrote:
> I doubt that works at all, TBH. What I'd expect to happen with a
> typical compiler is a complaint about redefinition of typedef bool,
> because c.h already declared it and here this fragment is doing
> so again. It'd make sense to me to do
>
> + #ifdef
After further thinking, I prefer the alternative approach of using
pq_sendcountedtext() as is and sticking the trailing zero byte on on the
receiving side. This is a more localized change, and keeps the logical
replication protocol consistent with the main FE/BE protocol. (Also, we
don't need to
On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch wrote:
> On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote:
>> Regarding this feature, there are some loose ends. We should work on
>> and complete them until the release.
>>
>> (1)
>> Which synchronous replication method, priority or quorum, sh
On Thu, Mar 30, 2017 at 4:25 AM, Ashutosh Sharma wrote:
> After debugging the hash index code for deletion, I could find that
> while registering data for xlog record 'XLOG_HASH_UPDATE_META_PAGE' we
> are not passing the correct length of data being registered and
> therefore, data (xl_hash_update
On Sat, Mar 25, 2017 at 1:10 AM, Michael Paquier
wrote:
> On Fri, Mar 24, 2017 at 10:12 PM, Heikki Linnakangas wrote:
>> On 03/24/2017 03:02 PM, Michael Paquier wrote:
>>>
>>> In order to close this thread, I propose to reuse the patches I sent
>>> here to make scram_build_verifier() available to
On 4/5/17 01:20, Tom Lane wrote:
>> The complaint about bool is also just a warning.
>
> Really?
>
> $ cat test.c
> typedef char bool;
> typedef char bool;
> $ gcc -c test.c
> test.c:2: error: redefinition of typedef 'bool'
> test.c:1: note: previous declaration of 'bool' was here
>
> This is wi
Joe Conway writes:
> On 04/04/2017 09:58 PM, Tom Lane wrote:
>> Another issue is whether you won't get compiler complaints about
>> redefinition of the "true" and "false" macros. But those would
>> likely only be warnings, not flat-out errors.
> I have not been able to generate warnings or error
On Fri, Mar 31, 2017 at 10:10 AM, Aleksander Alekseev
wrote:
> Turned out that there is an unused argument `isroot` in
> `btree_xlog_split` procedure. Suggested patch fixes it.
>
> This issue was discovered by Anastasia Lubennikova, coding is done by me.
Hmm. I don't see anything wrong with that
On April 5, 2017 9:04:00 AM PDT, Tom Lane wrote:
>Joe Conway writes:
>> On 04/04/2017 09:58 PM, Tom Lane wrote:
>>> Another issue is whether you won't get compiler complaints about
>>> redefinition of the "true" and "false" macros. But those would
>>> likely only be warnings, not flat-out erro
On Wed, Mar 29, 2017 at 11:54 PM, Tom Lane wrote:
> Andres Freund writes:
>> we have a good number of '(GISTENTRY *) PG_GETARG_POINTER(n)' in our
>> code - looks a bit better & shorter to have PG_GETARG_GISTENTRY(n).
>
> Should be PG_GETARG_GISTENTRY_P to match existing conventions,
> otherwise +
Peter Eisentraut writes:
> On 4/5/17 01:20, Tom Lane wrote:
>> $ cat test.c
>> typedef char bool;
>> typedef char bool;
>> $ gcc -c test.c
>> test.c:2: error: redefinition of typedef 'bool'
>> test.c:1: note: previous declaration of 'bool' was here
> But the above is not how the current code look
On 4/5/17 09:58, Robert Haas wrote:
>> - Maybe add a check to opr_sanity to make sure the default set of
>> functions is configured the way we want?
> That seems like a good idea.
patch
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
On Thu, Mar 23, 2017 at 4:50 AM, Magnus Hagander wrote:
> One thing we might want to consider around this -- in 10 we have
> target_session_attrs=read-write (since
> 721f7bd3cbccaf8c07cad2707826b83f84694832), which will issue a SHOW
> transaction_read_only on the connection.
>
> We should probably
Robert Haas writes:
> On Wed, Mar 29, 2017 at 11:54 PM, Tom Lane wrote:
>> Andres Freund writes:
>>> we have a good number of '(GISTENTRY *) PG_GETARG_POINTER(n)' in our
>>> code - looks a bit better & shorter to have PG_GETARG_GISTENTRY(n).
>> Should be PG_GETARG_GISTENTRY_P to match existing
Andres Freund writes:
> GCC generally doesn't warn about macro redefinitions, if both
> definitions are equivalent.
But they're *not* equivalent. c.h has
#define true((bool) 1)
whereas so far as I can see the definition is just
#define true1
And if you put those two definitions toge
On Wed, Apr 5, 2017 at 12:18 PM, Peter Eisentraut
wrote:
> On 4/5/17 09:58, Robert Haas wrote:
>>> - Maybe add a check to opr_sanity to make sure the default set of
>>> functions is configured the way we want?
>> That seems like a good idea.
>
> patch
LGTM
--
Robert Haas
EnterpriseDB: http://ww
Peter Eisentraut writes:
> On 4/5/17 09:58, Robert Haas wrote:
>>> - Maybe add a check to opr_sanity to make sure the default set of
>>> functions is configured the way we want?
>> That seems like a good idea.
> patch
Looks sane to me, although I wonder if opr_sanity ought to be looking
for any
On 04/05/2017 07:23 AM, Michael Paquier wrote:
fore
On Wed, Apr 5, 2017 at 7:05 AM, Heikki Linnakangas wrote:
I will continue tomorrow, but I wanted to report on what I've done so far.
Attached is a new patch version, quite heavily modified. Notable changes so
far:
Great, thanks!
* Use Uni
1 - 100 of 204 matches
Mail list logo
