On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova
wrote:
@@ -590,7 +622,14 @@ _bt_buildadd(BTWriteState *wstate, BTPageState
*state, IndexTuple itup)
if (last_off == P_HIKEY)
{
Assert(state->btps_minkey == NULL);
- state->btps_minkey = CopyIndexTuple(itup);
+ /*
+ * Truncate the tuple t
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
> crash recovery or on standby
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 you should only perform this kind of masking w
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
th
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.
It is true that nbtree can
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 via
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
>> Header : (pd_lower: 28 pd_upper:
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 amount of trouble we
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.)
> Well, if you're going t
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 wondering also whether a timestamp since the server
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 insta
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.
> Don't think aset.
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
> > those AllocSetContextCr
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. Currently is really
> rather
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 n
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 FHS-like subdirectory structure
The standard calling pattern for AllocSetContextCreate is
cxt = AllocSetContextCreate(parent, name,
ALLOCSET_DEFAULT_MINSIZE,
ALLOCSET_DEFAULT_INITSIZE,
ALLOCSET_DEFAULT_MAXSIZE);
or for some conte
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 pg_xlog,
> >> then tha
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 input), Magnus
> - Rename them,
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 http://www.2ndQuadra
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
>
>
> Ok, sold, let's remove support for OpenSSL < 0.9
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 you are trying to fix [2].
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 for both
>>> check and installcheck. I can't imagine why we'd have it and
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.
S
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
>> it during testing.
>>
>
> The actual consistenc
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 move pg_xlog,
then 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. But if we were to mo
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&dt=2016-08-26%2008%3A37%3A27
>
> TRAP: FailedAssertion("!(vmq->mq_sender == ((void *)0))", File:
> "/home/andrew/bf64/root/REL9_6_STABLE/pgsql.build/../pgsql/
28 matches
Mail list logo
