On 2015-08-11 22:34:40 -0400, Noah Misch wrote:
> On Tue, Aug 11, 2015 at 01:04:48PM +0200, Andres Freund wrote:
> > On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
> > > On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
> > > > We might later want to change some of the harder to maintain macro
Am 11.08.2015 um 21:03 schrieb Peter Eisentraut:
On 8/10/15 12:36 PM, Peter Moser wrote:
Can someone tell me, how I can compare two datum fields, when I do not
know the data type in advance inside an executor function?
For example, "x less than y" where x and y are of various types that
form
2015-08-10 18:43 GMT+02:00 Pavel Stehule :
>
>
> 2015-08-10 9:11 GMT+02:00 Heikki Linnakangas :
>
>> On 07/26/2015 08:34 AM, Pavel Stehule wrote:
>>
>>> Hi
>>>
>>> here is complete patch, that introduce context filtering on client side.
>>> The core of this patch is trivial and small - almost all
On 12 August 2015 at 03:10, Noah Misch wrote:
> > On another review I suggested we add a function to core to allow it to be
> > used in regression tests. A long debate ensued, deciding that we must be
> > consistent and put diagnostic functions in contrib. My understanding is
> > that we are not
On 2015-08-08 02:30:44 -0400, Noah Misch wrote:
> On Sat, Aug 08, 2015 at 02:30:47AM +0200, Andres Freund wrote:
> > On 2015-08-07 20:16:20 -0400, Noah Misch wrote:
> > > I agree that lock.h offers little to frontend code. Headers that the
> > > lockdefs.h patch made usable in the frontend, partic
On 3 August 2015 at 01:35, Andreas Karlsson wrote:
> On 07/15/2015 09:30 PM, Robert Haas wrote:
>
>> On Tue, Jul 14, 2015 at 5:57 PM, Jim Nasby
>> wrote:
>>
>>> On 7/7/15 7:07 AM, Andres Freund wrote:
>>>
On 2015-07-03 18:03:58 -0400, Tom Lane wrote:
> I have just looked through th
On 2015-07-01 12:55:48 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Last night my ancient HP compiler spit up on HEAD:
> > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pademelon&dt=2015-07-01%2001%3A30%3A18
> > complaining thus:
> > cpp: "brin_pageops.c", line 626: error 4018: Macro
On 3 August 2015 at 17:18, Jeff Janes wrote:
> That does still leave the prefetch technique, so all is not lost.
>>
>> Can we see a patch with just prefetch, probably with a simple choice of
>> stride? Thanks.
>>
>
> I probably won't get back to it this commit fest, so it can be set to
> returne
Hi,
Forcing our bool to be stdbool.h shows up a bunch of errors and
warnings:
1) gin stores/queries some bools as GinTernaryValue.
Part of this is easy to fix, just adjust GinScanKeyData->entryRes to
be a GinTernaryValue (it's actually is compared against MAYBE).
What I find slightly w
On 8/12/15 9:36 AM, Pavel Stehule wrote:
So, there is common agreement on this version.
There are several instances of double semicolons. Also,
PsqlSettings.show_context doesn't look like a boolean to me. For
SHOW_CONTEXT, it would be good if the documentation mentioned the
default value.
Am 11.08.2015 um 13:41 schrieb Anastasia Lubennikova:
Can someone tell me, how I can compare two datum fields, when I do
not know the data type in advance inside an executor function?
In a nutshell, there is no way to compare Datums.
Datum is an abstact data type. It's the backend int
2015-08-12 11:07 GMT+02:00 Marko Tiikkaja :
> On 8/12/15 9:36 AM, Pavel Stehule wrote:
>
>> So, there is common agreement on this version.
>>
>
> There are several instances of double semicolons. Also,
> PsqlSettings.show_context doesn't look like a boolean to me. For
> SHOW_CONTEXT, it would be
On 2015-08-12 10:43:51 +0200, Andres Freund wrote:
> 3) The 'bypassrls' boolean in AlterUser() is queried strangely. There are two
> complaints:
>
> boolbypassrls = -1;
>
> it's a boolean.
>
> else if (authform->rolbypassrls || bypassrls >= 0)
> {
>
On 2015/08/12 7:21, Robert Haas wrote:
On Fri, Aug 7, 2015 at 3:37 AM, Kouhei Kaigai wrote:
I could have a discussion with Fujita-san about this topic.
Also, let me share with the discussion towards entire solution.
The primitive reason of this problem is, Scan node with scanrelid==0
represe
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> Forcing our bool to be stdbool.h shows up a bunch of errors and
> warnings:
Wow.
> 1) gin stores/queries some bools as GinTernaryValue.
>
>Part of this is easy to fix, just adjust GinScanKeyData->entryRes to
>be a GinTernaryValue (it
On 2015-08-12 08:16:09 -0400, Stephen Frost wrote:
> > 1) gin stores/queries some bools as GinTernaryValue.
> >
> >Part of this is easy to fix, just adjust GinScanKeyData->entryRes to
> >be a GinTernaryValue (it's actually is compared against MAYBE).
> >
> >What I find slightly worrys
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-08-12 08:16:09 -0400, Stephen Frost wrote:
> > > 1) gin stores/queries some bools as GinTernaryValue.
> > >
> > >Part of this is easy to fix, just adjust GinScanKeyData->entryRes to
> > >be a GinTernaryValue (it's actually is compared a
On 08/04/2015 06:30 PM, Robert Haas wrote:
> On Mon, Aug 3, 2015 at 2:17 AM, Michael Paquier
> wrote:
>> On Tue, Jul 7, 2015 at 9:14 PM, Andres Freund wrote:
>>> On 2015-06-19 06:41:19 +, Brendan Jurd wrote:
I'm marking this "Waiting on Author". Once the problems have been
correcte
Andres Freund writes:
> On 2015-07-01 12:55:48 -0300, Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> I'm thinking we really ought to mount a campaign to replace some of these
>>> macros with inlined-if-possible functions.
>> My guess is that changing a very small amount of them will do a large
>> e
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
> Sent: Wednesday, August 12, 2015 8:26 PM
> To: Robert Haas; Kaigai Kouhei(海外 浩平)
> Cc: PostgreSQL-development; 花田茂
> Subject: Re: [HACKERS] Foreign join
... btw, why don't we convert c.h's Max(), Min(), and Abs() to inlines?
They've all got multi-eval hazards.
It might also be interesting to research whether inline would allow
simplifying the MemSetFoo family.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
On 8/11/15 5:18 PM, Robert Haas wrote:
> The thing we're actually debating here is whether enabling SCRAM
> authentication for a role should also mean disabling MD5
> authentication for that same role, or whether you should be able to
> have two password verifiers stored for that role, one for SCRA
What's a good way for me to create a self-contained test case. AFAIU the
only way to make these test cases more self-contained would be to inline
the second table and its index. How do you create an index to an inlined
table of values?
Or perhaps I could send over a dump of a subset of the data?
Hi,
On 2015-08-11 01:15:37 +0200, Andres Freund wrote:
> I'm too tired right now to look at this, but it generally looked sane.
Pushed your fix to master and 9.5, with two very minor changes:
1) I moved the BufferDescriptorGetBuffer() call in PinBuffer_Locked() to
after the spinlock release. I
On Wed, Aug 12, 2015 at 9:22 AM, Vik Fearing wrote:
> Thank you, Brendan, Michael, and Robert for taking care of this while I
> was away.
Thanks for the patch!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (p
On 2015-08-11 13:49:19 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2015-08-11 12:43:03 -0400, Robert Haas wrote:
> > > On Tue, Aug 11, 2015 at 12:40 PM, Tom Lane wrote:
> > > > We do not use !! elsewhere for this purpose, and I for one find it a
> > > > pretty ugly locution.
> > >
On Wed, Aug 12, 2015 at 10:50 AM, Peter Eisentraut wrote:
> I understand this idea, but I think it's not practical for many uses.
> There is no way to find out, on the server, whether all current clients
> would support a switch to SCRAM. Let alone all not-current clients.
> The only way to do su
On Tue, Aug 11, 2015 at 10:34 PM, Noah Misch wrote:
>> In my opinion this drastically increases readability and thus should be
>> applied. Will do so sometime tomorrow unless there's protest.
>
> -1 to introducing more inline functions before committable code replaces what
> you've already pushed
Hi,
I'd like to suggest $SUBJECT for inclusion in Postgres 9.6. I'm sure
everyone would've found it useful at some point in their lives, and the
fact that it can't be properly implemented in any language other than C
I think speaks for the fact that we as a project should provide it.
A quic
I've created a small dump of my database that recreates the problem. I hope
that this will help recreate the problem. It is attached. I'd be happy to
hear if there is an easier way of doing this.
To rebuild the database:
- create a database
- run from the commandline `$ psql database-name < 1000ge
On Wed, Aug 12, 2015 at 6:18 PM, Marko Tiikkaja wrote:
> Will finish this up for the next CF, unless someone wants to tell me how
> stupid this idea is before that.
I'm kind of puzzled what kind of schema would need this.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Greg Stark wrote:
> On Wed, Aug 12, 2015 at 6:18 PM, Marko Tiikkaja wrote:
> > Will finish this up for the next CF, unless someone wants to tell me how
> > stupid this idea is before that.
>
> I'm kind of puzzled what kind of schema would need this.
I've seen cases where you want some entity to
Hi
2015-08-12 19:18 GMT+02:00 Marko Tiikkaja :
> Hi,
>
> I'd like to suggest $SUBJECT for inclusion in Postgres 9.6. I'm sure
> everyone would've found it useful at some point in their lives, and the
> fact that it can't be properly implemented in any language other than C I
> think speaks for t
On Wed, Aug 12, 2015 at 10:30 AM, Alvaro Herrera
wrote:
> The name count_nulls() suggest an aggregate function to me, though.
I thought the same.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
On 2015-08-12 7:23 PM, Greg Stark wrote:
On Wed, Aug 12, 2015 at 6:18 PM, Marko Tiikkaja wrote:
Will finish this up for the next CF, unless someone wants to tell me how
stupid this idea is before that.
I'm kind of puzzled what kind of schema would need this.
The first example I could find f
2015-08-12 19:32 GMT+02:00 Peter Geoghegan :
> On Wed, Aug 12, 2015 at 10:30 AM, Alvaro Herrera
> wrote:
> > The name count_nulls() suggest an aggregate function to me, though.
>
> I thought the same.
>
maybe nulls_count ?
we have regr_count already
Regards
Pavel
>
>
> --
> Peter Geoghegan
On 2015-08-12 7:35 PM, Pavel Stehule wrote:
maybe nulls_count ?
we have regr_count already
But that's an aggregate as well..
.m
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-08-12 19:37 GMT+02:00 Marko Tiikkaja :
> On 2015-08-12 7:35 PM, Pavel Stehule wrote:
>
>> maybe nulls_count ?
>>
>> we have regr_count already
>>
>
> But that's an aggregate as well..
>
my mistake
Pavel
>
>
> .m
>
On Wed, Aug 12, 2015 at 3:10 AM, Noah Misch wrote:
> Committers press authors to delete tests more often than we press them to
> resubmit with more tests. No wonder so many patches have insufficient tests;
> we treat those patches more favorably, on average. I have no objective
> principles for
On Wed, Aug 12, 2015 at 10:46 AM, Greg Stark wrote:
> The only time I've seen pushback against tests is when the test author
> made valiant efforts to test every codepath and the expected output
> embeds the precise behaviour of the current code as "correct". Even
> when patches have extensive tes
One trouble I face when adding tests is that sometimes they require
hooks in the code, to test for race conditions. In BRIN I cannot test
some code paths without resorting to adding breakpoints in GDB, for
instance. If there's no support for such in the core code, it's
essentially impossible to a
All look good to me,
Thank you,
Qingqing
On Wed, Aug 12, 2015 at 8:37 AM, Andres Freund wrote:
> Hi,
>
> On 2015-08-11 01:15:37 +0200, Andres Freund wrote:
>> I'm too tired right now to look at this, but it generally looked sane.
>
> Pushed your fix to master and 9.5, with two very minor changes
Tom Lane wrote:
> However, we did learn something valuable from the fact that all the
> -DCLOBBER_CACHE_ALWAYS critters failed on it: per my earlier message,
> brin_page_items() is unsafe against a relcache flush on the index.
> I'll put that on the 9.5 open items list.
>
> (If I were tasked with
On 2015-08-12 13:00:25 -0400, Robert Haas wrote:
> On Tue, Aug 11, 2015 at 10:34 PM, Noah Misch wrote:
> >> In my opinion this drastically increases readability and thus should be
> >> applied. Will do so sometime tomorrow unless there's protest.
> >
> > -1 to introducing more inline functions bef
On Tue, Aug 11, 2015 at 5:27 PM, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-08-11 15:07:15 -0700, Jeff Janes wrote:
> >> The attached patch adds an else branch to call CHECK_FOR_INTERRUPTS().
> >>
> >> But I think we could instead just call vacuum_delay_point
> unconditionally.
> >> It
Alvaro Herrera wrote:
> Close some holes in BRIN page assignment
buildfarm evidently didn't like this one :-(
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Hi Michael,
I'm currently investigating some of our code cleanliness issues around
booleans. Turns out that ecpg fails if C99's _Bool is used as bool
instead of typedef char bool.
Playing around a bit lead to to find that this is caused by a wrong type
declaration in two places. 'isarray' is decl
On 8/12/15 12:19 PM, Robert Haas wrote:
> On Wed, Aug 12, 2015 at 10:50 AM, Peter Eisentraut wrote:
>> I understand this idea, but I think it's not practical for many uses.
>> There is no way to find out, on the server, whether all current clients
>> would support a switch to SCRAM. Let alone all
All,
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 8/12/15 12:19 PM, Robert Haas wrote:
> > On Wed, Aug 12, 2015 at 10:50 AM, Peter Eisentraut wrote:
> >> I understand this idea, but I think it's not practical for many uses.
> >> There is no way to find out, on the server, whether all current
On Wed, Aug 12, 2015 at 4:09 PM, Stephen Frost wrote:
> As for the notion of dropping md5 from 9.6 or even forcing it to be
> one-or-the-other on a per-role basis, ...
Please don't conflate those two things. They are radically different
in terms of the amount of upgrade pain that they cause. Th
On Wed, Aug 12, 2015 at 2:57 PM, Andres Freund wrote:
> The only actual separate patch since then (fastgetattr as inline
> function) was posted 2015-08-05 and I yesterday suggested to push it
> today. And it's just replacing two existing macros by inline functions.
I'm a little concerned about th
On 08/12/2015 11:25 PM, Robert Haas wrote:
On Wed, Aug 12, 2015 at 2:57 PM, Andres Freund wrote:
The only actual separate patch since then (fastgetattr as inline
function) was posted 2015-08-05 and I yesterday suggested to push it
today. And it's just replacing two existing macros by inline fun
Here is a v8,
I collected a few performance figures with this patch on an old box with 8
cores, 16 GB, RAID 1 HDD, under Ubuntu precise.
postgresql.conf:
shared_buffers = 4GB
checkpoint_timeout = 15min
checkpoint_completion_target = 0.8
max_wal_size = 4GB
init> pgbench
On Wed, Aug 12, 2015 at 1:34 PM, Heikki Linnakangas wrote:
> Andres didn't mention how big the performance benefit he saw with pgbench
> was, but I bet it was barely distinguishible from noise. But that's OK. In
> fact, there's no reason to believe this would make any difference to
> performance.
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Aug 12, 2015 at 4:09 PM, Stephen Frost wrote:
> > As for the notion of dropping md5 from 9.6 or even forcing it to be
> > one-or-the-other on a per-role basis, ...
>
> Please don't conflate those two things. They are radically diffe
On 2015-08-12 16:25:17 -0400, Robert Haas wrote:
> On Wed, Aug 12, 2015 at 2:57 PM, Andres Freund wrote:
> > The only actual separate patch since then (fastgetattr as inline
> > function) was posted 2015-08-05 and I yesterday suggested to push it
> > today. And it's just replacing two existing mac
On Wed, Aug 12, 2015 at 2:04 PM, Peter Geoghegan wrote:
> This resistance to adding tests seems quite short sighted to me,
> especially when the concern is about queries that will each typically
> take less than 1ms to execute. Like Noah, I think that it would be
> very helpful to simply be more i
On 2015-08-12 23:34:38 +0300, Heikki Linnakangas wrote:
> Andres didn't mention how big the performance benefit he saw with pgbench
> was, but I bet it was barely distinguishible from noise.
I think it was discernible (I played around with changing unrelated code
trying to exclude unrelated layout
* Andres Freund (and...@anarazel.de) wrote:
> I find that a somewhat ugly coding pattern, but since the rest of the
> function is written that way...
Agreed, but not going to change it at this point.
Would love feedback on the attached. I included the variable renames
discussed previously with N
On Wed, Aug 12, 2015 at 4:34 PM, Heikki Linnakangas wrote:
> Andres didn't mention how big the performance benefit he saw with pgbench
> was, but I bet it was barely distinguishible from noise. But that's OK. In
> fact, there's no reason to believe this would make any difference to
> performance.
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Aug 12, 2015 at 2:04 PM, Peter Geoghegan wrote:
> > This resistance to adding tests seems quite short sighted to me,
> > especially when the concern is about queries that will each typically
> > take less than 1ms to execute. Like Noah, I thin
On 08/12/2015 01:37 PM, Stephen Frost wrote:
> Would be great to get comments on the other comments, specifically that
> adding SCRAM's password verifier won't seriously change the security of
> a user's account or password based on an attack vector where the
> contents of pg_authid is compromised.
Gideon Dresdner writes:
> I've created a small dump of my database that recreates the problem. I hope
> that this will help recreate the problem. It is attached. I'd be happy to
> hear if there is an easier way of doing this.
Ah. Now that I see the database schema, the problem is here:
regressi
On Wed, Aug 12, 2015 at 4:37 PM, Stephen Frost wrote:
>> Please don't conflate those two things. They are radically different
>> in terms of the amount of upgrade pain that they cause. The first one
>> would be completely insane.
>
> Thanks for the clarification. I had gotten the (apparently mi
Andres Freund writes:
> I went through all headers in src/include and checked for macros
> containing [^&]&[^&] and checked whether they have this hazard. Found a
> fair number.
> That patch also changes !! tests into != 0 style.
Looks OK to me, except I wonder why you did this
#define TRIGGE
On 2015-08-12 18:52:59 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I went through all headers in src/include and checked for macros
> > containing [^&]&[^&] and checked whether they have this hazard. Found a
> > fair number.
>
> > That patch also changes !! tests into != 0 style.
>
> Look
Andres Freund writes:
> On 2015-08-12 18:52:59 -0400, Tom Lane wrote:
>> Looks OK to me, except I wonder why you did this
>>
>> #define TRIGGER_FIRED_FOR_ROW(event) \
>> -((event) & TRIGGER_EVENT_ROW)
>> +(((event) & TRIGGER_EVENT_ROW) == TRIGGER_EVENT_ROW)
>>
>> rather than != 0. That
On 2015-08-12 19:03:50 -0400, Tom Lane wrote:
> The adjacent code is doing something different than a bit-test, though:
> it's checking whether multibit fields have particular values.
Yea, I know, that's why I was on the fence about it. Since you have an
opinion and I couldn't really decide it's p
Peter Geoghegan writes:
> On Wed, Aug 12, 2015 at 10:30 AM, Alvaro Herrera
> wrote:
>> The name count_nulls() suggest an aggregate function to me, though.
> I thought the same.
Ditto. I'd be fine with this if we can come up with a name that
doesn't sound like an aggregate. The best I can do o
I've written a function which allows users to clean up the pending list.
It takes the index name and returns the number of pending list pages
deleted.
# select * from gin_clean_pending_list('foo_text_array_idx');
gin_clean_pending_list
278
(1 row)
Tim
Robert Haas writes:
> On Wed, Aug 12, 2015 at 2:04 PM, Peter Geoghegan wrote:
>> This resistance to adding tests seems quite short sighted to me,
>> especially when the concern is about queries that will each typically
>> take less than 1ms to execute. Like Noah, I think that it would be
>> very
On 2015-08-12 16:08:08 -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Close some holes in BRIN page assignment
>
> buildfarm evidently didn't like this one :-(
clang seems to see a (the?) problem:
/home/andres/src/postgresql/src/backend/access/brin/brin_pageops.c:357:6:
warning: varia
On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane wrote:
> FWIW, I've objected in the past to tests that would significantly
> increase the runtime of "make check", unless I thought they were
> especially valuable (which enumerating every minor behavior of a
> feature patch generally isn't IMO). I still
On 2015-08-12 10:18:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-07-01 12:55:48 -0300, Alvaro Herrera wrote:
> >> Tom Lane wrote:
> >>> I'm thinking we really ought to mount a campaign to replace some of these
> >>> macros with inlined-if-possible functions.
>
> >> My guess is th
On Wed, Aug 12, 2015 at 4:11 PM, Tom Lane wrote:
> Peter Geoghegan writes:
> > On Wed, Aug 12, 2015 at 10:30 AM, Alvaro Herrera
> > wrote:
> >> The name count_nulls() suggest an aggregate function to me, though.
>
> > I thought the same.
>
> Ditto. I'd be fine with this if we can come up with
On Thu, Aug 13, 2015 at 6:21 AM, Josh Berkus wrote:
> The only case where I can see multiple verifiers per role making a real
> difference in migrations is for PGAAS hosting. But the folks from
> Heroku and AWS have been notably silent on this; lemme ping them.
Yes, I would be curious to hear fro
Fujita-san,
The attached patch enhanced the FDW interface according to the direction
below (but not tested yet).
>> In the summary, the following three enhancements are a straightforward
>> way to fix up the problem he reported.
>> 1. Add a special path to call recheckMtd in ExecScanFetch if scan
Andreas Seltenreich writes:
> there's a 1/1e6 chance that a sqlsmith query on the regression db of
> master (c124cef) fails with
> ERROR: failed to build any {4..8}-way joins
Looks like I broke that while trying to fix one of your previous
reports :-(. I think it's all better now, but your
On Thu, Aug 13, 2015 at 5:54 AM, Stephen Frost wrote:
> The regression tests included in pgBackRest (available here:
> https://github.com/pgmasters/backrest) go through a number of different
> recovery tests. There's vagrant configs for a few different VMs too
> (CentOS 6, CentOS 7, Ubuntu 12.04 a
* Josh Berkus (j...@agliodbs.com) wrote:
> On 08/12/2015 01:37 PM, Stephen Frost wrote:
> > Would be great to get comments on the other comments, specifically that
> > adding SCRAM's password verifier won't seriously change the security of
> > a user's account or password based on an attack vector
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Aug 13, 2015 at 5:54 AM, Stephen Frost wrote:
> > The regression tests included in pgBackRest (available here:
> > https://github.com/pgmasters/backrest) go through a number of different
> > recovery tests. There's vagrant configs for
Hello,
I am working on a project which requires going through each field inside a
tuple without using postgresql. I have managed to iterate through each
tuple inside a table by recycling postgres's code. However, for the part of
parsing through each field in the tuple, I am not able to think of an
Andres Freund writes:
> On 2015-08-12 10:18:12 -0400, Tom Lane wrote:
>> Sounds reasonable to me. If you do this, I'll see whether pademelon
>> can be adjusted to build using the minimum macro expansion buffer
>> size specified by the C standard.
> Here's the patch attached.
Looks like you need
On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Thu, Aug 13, 2015 at 5:54 AM, Stephen Frost wrote:
>> > The regression tests included in pgBackRest (available here:
>> > https://github.com/pgmasters/backrest) go through a number of
Vignesh Raghunathan writes:
> I am working on a project which requires going through each field inside a
> tuple without using postgresql. I have managed to iterate through each
> tuple inside a table by recycling postgres's code. However, for the part of
> parsing through each field in the tuple,
On Thu, Aug 13, 2015 at 10:22 AM, Stephen Frost wrote:
>> The only case where I can see multiple verifiers per role making a real
>> difference in migrations is for PGAAS hosting. But the folks from
>> Heroku and AWS have been notably silent on this; lemme ping them.
>
> While their insight is cer
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Aug 12, 2015 at 4:37 PM, Stephen Frost wrote:
> >> Please don't conflate those two things. They are radically different
> >> in terms of the amount of upgrade pain that they cause. The first one
> >> would be completely insane.
> >
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> On Thu, Aug 13, 2015 at 5:54 AM, Stephen Frost wrote:
> >> > The regression tests included in pgBackRest (available here:
> >> > https:
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Aug 13, 2015 at 10:22 AM, Stephen Frost wrote:
> >> The only case where I can see multiple verifiers per role making a real
> >> difference in migrations is for PGAAS hosting. But the folks from
> >> Heroku and AWS have been notably si
(Please read this message on wide display)
Our team recently tries to run TPC-DS benchmark to know capability of
PostgreSQL towards typical analytic queries.
TPC-DS defines about 100 complicated queries. We noticed optimizer made
unreasonable execution plan towards some of queries.
Here is an exa
Andrew Dunstan writes:
> On 08/06/2015 03:36 PM, Tom Lane wrote:
>> Further fixes for degenerate outer join clauses.
> Looks like this might have upset brolga on 9.0 and 9.1 - it's coming up
> with a different plan from what's expected.
I looked into this, and while I can't be certain of the di
On Wed, Aug 12, 2015 at 9:36 PM, Stephen Frost wrote:
>> Yes, the SCRAM implementation could be buggy. But also, OpenSSL has
>> repeatedly had security bugs that were due to forcing servers to
>> downgrade to older protocols. I wouldn't like us to start growing
>> similar vulnerabilities, where
Andres Freund wrote:
> On 2015-08-12 16:08:08 -0300, Alvaro Herrera wrote:
> > Alvaro Herrera wrote:
> > > Close some holes in BRIN page assignment
> >
> > buildfarm evidently didn't like this one :-(
>
> clang seems to see a (the?) problem:
Ahh, right. There's an identical problem in the other
On Thu, Aug 13, 2015 at 2:19 AM, Jeff Janes wrote:
> I've written a function which allows users to clean up the pending list.
> It takes the index name and returns the number of pending list pages
> deleted.
>
> # select * from gin_clean_pending_list('foo_text_array_idx');
> gin_clean_pending_li
Thank you very much for the response.
On Wed, Aug 12, 2015 at 6:31 PM, Tom Lane wrote:
> Vignesh Raghunathan writes:
> > I am working on a project which requires going through each field inside
> a
> > tuple without using postgresql. I have managed to iterate through each
> > tuple inside a tab
FWIW, I've objected in the past to tests that would significantly
increase the runtime of "make check", unless I thought they were
especially valuable (which enumerating every minor behavior of a
feature patch generally isn't IMO). I still think that that's an
important consideration: every sec
On Thu, Aug 13, 2015 at 1:31 AM, Robert Haas wrote:
> On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane wrote:
> > FWIW, I've objected in the past to tests that would significantly
> > increase the runtime of "make check", unless I thought they were
> > especially valuable (which enumerating every minor
Hi
2015-08-12 11:07 GMT+02:00 Marko Tiikkaja :
> On 8/12/15 9:36 AM, Pavel Stehule wrote:
>
>> So, there is common agreement on this version.
>>
>
> There are several instances of double semicolons. Also,
> PsqlSettings.show_context doesn't look like a boolean to me. For
> SHOW_CONTEXT, it woul
On Wed, Aug 12, 2015 at 11:23 PM, Magnus Hagander wrote:
>> The value of a core regression suite that takes less time to run has
>> to be weighed against the possibility that a better core regression
>> suite might cause us to find more bugs before committing. That could
>> easily be worth the pr
99 matches
Mail list logo
