On Sat, Aug 27, 2016 at 9:47 PM, Amit Kapila wrote:
> Right, I think there is no need to mask all the flags. However apart
> from BTP_HAS_GARBAGE, it seems we should mask BTP_SPLIT_END as that is
> just used to save some processing for vaccum and won't be set after
>
On Sun, Aug 28, 2016 at 6:26 AM, Peter Geoghegan wrote:
> On Thu, Aug 25, 2016 at 9:41 AM, Kuntal Ghosh
> wrote:
>> 2. For Btree pages, I've masked BTP_HALF_DEAD, BTP_SPLIT_END,
>> BTP_HAS_GARBAGE and BTP_INCOMPLETE_SPLIT flags.
>
> Why? I think that
On 2016-08-27 14:48:29 -0700, Andres Freund wrote:
> My next steps are to work on cleaning up the code a bit more, and
> increase the regression coverage.
Oh, there's one open item I actually don't really know how to handle
well: A decent way of enforcing the join order between the subquery and
On Thu, Aug 25, 2016 at 9:41 AM, Kuntal Ghosh
wrote:
> 2. For Btree pages, I've masked BTP_HALF_DEAD, BTP_SPLIT_END,
> BTP_HAS_GARBAGE and BTP_INCOMPLETE_SPLIT flags.
Why? I think that you should only perform this kind of masking where
it's clearly strictly necessary.
Hi,
I've noticed the comment in src/include/catalog/pg_foreign_table.h still
talks about genbki.sh, but AFAIK it was replaced with genbki.pl.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent
On Fri, Aug 26, 2016 at 7:24 AM, Alvaro Herrera
wrote:
>> As the block numbers are different, I was getting the following warning:
>> WARNING: Inconsistent page (at byte 8166) found for record
>> 0/127F4A48, rel 1663/16384/16946, forknum 0, blkno 0, Backup Page
>>
Christoph Berg writes:
> I've always been wondering why we don't set a log_line_prefix by
> default.
I think the odds of getting to something that everyone would agree on
are nil, so I'm not excited about getting into that particular
bikeshed-painting discussion. Look at the
Andres Freund writes:
> On 2016-08-27 15:46:26 -0400, Tom Lane wrote:
>> (Or in other words, the fact that "DefaultContextCreate" is spelled
>> "AllocSetContextCreate" is a bit of a historical artifact, but I do
>> not see why changing the spelling is a useful exercise.)
>
Re: Fabien COELHO 2016-08-26
> So I would suggest something like the following, which is also a little bit
> more compact:
>
> log_line_prefix = '%m [%p:%l] %q%a '
>
> If you want to keep something with %a, maybe parentheses?
>
> Finally I'm
On 2016-08-27 15:46:26 -0400, Tom Lane wrote:
> (Or in other words, the fact that "DefaultContextCreate" is spelled
> "AllocSetContextCreate" is a bit of a historical artifact, but I do
> not see why changing the spelling is a useful exercise.)
Well, if you're going through nearly all of the
Andres Freund writes:
> On 2016-08-27 15:36:28 -0400, Tom Lane wrote:
>> What is actually of interest, IMO, is making *some* contexts have a
>> different allocator, and that is going to require case-by-case decisions
>> anyway. A blanket switch seems completely useless to me.
On 2016-08-27 15:36:28 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-08-27 14:08:44 -0400, Tom Lane wrote:
> >> Barring objection, I propose to make these changes in HEAD and 9.6.
>
> > I think we might also / instead want to think about replacing a lot of
> >
Andres Freund writes:
> On 2016-08-27 14:08:44 -0400, Tom Lane wrote:
>> Barring objection, I propose to make these changes in HEAD and 9.6.
> I think we might also / instead want to think about replacing a lot of
> those AllocSetContextCreate with a wrapper function.
Hi,
On 2016-08-27 14:08:44 -0400, Tom Lane wrote:
> The standard calling pattern for AllocSetContextCreate is
> Barring objection, I propose to make these changes in HEAD and 9.6.
> I don't feel a great need to adjust the back branches --- although there
> might be some argument for adding these
Alvaro Herrera writes:
> I'm for renaming too, but I'd go with Peter E's suggestion: move pg_xlog
> to something like $PGDATA/var/wal or $PGDATA/srv/wal or something like that.
I think that would make sense if we were to relocate *everything* under
PGDATA into some
The standard calling pattern for AllocSetContextCreate is
cxt = AllocSetContextCreate(parent, name,
ALLOCSET_DEFAULT_MINSIZE,
ALLOCSET_DEFAULT_INITSIZE,
ALLOCSET_DEFAULT_MAXSIZE);
or for some
Michael Paquier wrote:
> On Sat, Aug 27, 2016 at 6:34 AM, Andres Freund wrote:
> > On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote:
> >> I agree with all that. But the subject line is specifically about
> >> moving pg_xlog. So if your opinion is that we shouldn't move
Michael Paquier writes:
> OK, so let's focus only on the renaming mentioned in $subject. So far
> as I can see on this thread, here are the opinions of people who
> clearly gave one:
> - Rename them, hard break is OK: Michael P, Bruce, Stephen (depends on
> David's
On 8/26/16 9:26 PM, Andreas Karlsson wrote:
> I have attached a patch which removes the < 0.9.8 compatibility code.
> Should we also add a version check to configure? We do not have any such
> check currently.
I think that is not necessary.
--
Peter Eisentraut
On Sat, Aug 27, 2016 at 2:04 AM, Heikki Linnakangas wrote:
> On 08/26/2016 07:44 PM, Tom Lane wrote:
>> Peter Eisentraut writes:
>> Also, I get this on fully-up-to-date OS X (El Capitan):
>>
>> $ openssl version
>> OpenSSL 0.9.8zh 14 Jan 2016
>
On Sat, Aug 27, 2016 at 12:33 AM, Aleksander Alekseev
wrote:
> Your patch [1] was marked as "Needs review" so I decided to take a look.
Thanks for the input!
> It looks good to me. However I found dozens of places in PostgreSQL code
> that seem to have similar problem
On Sat, Aug 27, 2016 at 6:16 PM, Simon Riggs wrote:
> On 27 August 2016 at 07:36, Amit Kapila wrote:
>> On Fri, Aug 26, 2016 at 9:26 PM, Simon Riggs wrote:
>>>
>>> I think you should add this as part of the default testing
Hello Simon,
I'm really sorry for the inconveniences. Next time, I'll attach the
patch with proper documentation, test and comments.
> I think you should add this as part of the default testing for both
> check and installcheck. I can't imagine why we'd have it and not use
> it during testing.
On 27 August 2016 at 07:36, Amit Kapila wrote:
> On Fri, Aug 26, 2016 at 9:26 PM, Simon Riggs wrote:
>>
>> I think you should add this as part of the default testing for both
>> check and installcheck. I can't imagine why we'd have it and not use
On 27/08/16 20:33, Michael Paquier wrote:
On Sat, Aug 27, 2016 at 6:34 AM, Andres Freund wrote:
On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote:
I agree with all that. But the subject line is specifically about
moving pg_xlog. So if your opinion is that we shouldn't
On Sat, Aug 27, 2016 at 6:34 AM, Andres Freund wrote:
> On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote:
>> I agree with all that. But the subject line is specifically about
>> moving pg_xlog. So if your opinion is that we shouldn't move pg_xlog,
>> then that is noted.
On Fri, Aug 26, 2016 at 6:20 PM, Tom Lane wrote:
> Latest from lorikeet:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet=2016-08-26%2008%3A37%3A27
>
> TRAP: FailedAssertion("!(vmq->mq_sender == ((void *)0))", File:
>
27 matches
Mail list logo