On 10 August 2015 at 07:14, Peter Geoghegan wrote:
> On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs
> wrote:
> > If 5) fails to bring a workable solution by the Jan 2016 CF then we
> commit
> > 2) instead.
>
> Is there actually a conflict there? I didn't think so.
>
I didn't explain myself fully,
On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs wrote:
> If 5) fails to bring a workable solution by the Jan 2016 CF then we commit
> 2) instead.
Is there actually a conflict there? I didn't think so.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Freezing is painful for VLDBs and high transaction rate systems. We have a
number of proposals to improve things...
1. Allow parallel cores to be used with vacuumdb (Dilip)
Idea is if we have to get the job done, lets do it as fast as we can using
brute force. Reasonable thinking, but there are mo
On 8 August 2015 at 17:47, Noah Misch wrote:
> We've too often criticized patches for carrying many lines/bytes of test
> case
> additions. Let's continue to demand debuggable, secure tests that fail
> only
> when something is wrong, but let's stop pushing for test minimalism. Such
> objections
On Thu, Aug 6, 2015 at 12:24 PM, Haribabu Kommi
wrote:
>
> On Mon, Jun 30, 2014 at 11:08 PM, Beena Emerson
wrote:
> >
> > I also ran the test script after making the same configuration changes
that
> > you have specified. I found that I was not able to get the same
performance
> > difference that
On Wed, Jul 1, 2015 at 12:30 AM, Tom Lane wrote:
>
> What seems more likely to lead to a usable patch is to arrange for the
> extra information you want to be emitted as error "context", via an error
> context callback that gets installed at the right times. ...
> ...
> with no need for int8in to
Hello,
>Say, 6 bigint counters, 6 float8
>counters, and 3 strings up to 80 characters each. So we have a
>fixed-size chunk of shared memory per backend, and each backend that
>wants to expose progress information can fill in those fields however
>it likes, and we expose the results.
>This would b
On Sun, Aug 09, 2015 at 07:29:40PM +0200, Daniel Verite wrote:
> Hi,
>
> I want to suggest a client-side \pivot command in psql, implemented
> in the attached patch.
>
> \pivot takes the current query in the buffer, execute it and
> display it pivoted by interpreting the result as:
>
> column1
2015-08-10 2:23 GMT+09:00 Tom Lane :
> Robert Haas writes:
>> I'm not too excited about supporting the use case where there are two
>> people using queryId but it just so happens that they always set
>> exactly the same value. That seems like a weird setup. Wouldn't that
>> mean both modules wer
2015-08-10 0:04 GMT+09:00 Robert Haas :
> On Sun, Aug 9, 2015 at 1:36 AM, Satoshi Nagayasu wrote:
>> On 2015/08/08 22:32, Robert Haas wrote:
>>> On Sat, Aug 8, 2015 at 5:00 AM, Satoshi Nagayasu wrote:
I just found that pg_stat_statements causes assert when queryId is
set by other m
On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > In SQL:2008 and SQL:2011 at least, "=", "<" and "BETWEEN" are all in the
> > same
> > boat. They have no precedence relationships to each other; SQL sidesteps
> > the
> > question by requiring parentheses. They
On Mon, Aug 10, 2015 at 6:05 AM, Stephen Frost wrote:
> * Sehrope Sarkuni (sehr...@jackdb.com) wrote:
>> It'd be nice if the new auth mechanism supports multiple passwords in the
>> same format as well (not just one per format).
>>
>> That way you could have two different passwords for a user that
On Mon, Aug 10, 2015 at 3:42 AM, Josh Berkus wrote:
> On 08/09/2015 08:09 AM, Robert Haas wrote:
>> Why do we need to be able to authenticate using more than one
>> mechanism? If you have some clients that can't support SCRAM yet, you
>> might as well continue using MD5 across the board until tha
On Mon, Aug 10, 2015 at 12:39 AM, Robert Haas wrote:
> On Thu, Aug 6, 2015 at 11:33 AM, Jim Nasby wrote:
>> They also provide a level of control over what is and isn't installed in a
>> cluster. Personally, I'd prefer that most users not even be aware of the
>> existence of things like pageinspec
On Sun, Aug 9, 2015 at 11:19 PM, Andrew Dunstan wrote:
>
>
> On 08/09/2015 08:41 AM, Michael Paquier wrote:
>>
>> On Sun, Aug 9, 2015 at 1:40 AM, Andrew Dunstan
>> wrote:
>>>
>>> On 08/08/2015 09:31 AM, Robert Haas wrote:
On Fri, Aug 7, 2015 at 7:17 PM, Andrew Dunstan
wrote:
>
"Daniel Verite" writes:
> Tom Lane wrote:
>> Is there a way to implement pivoting as a set-returning function?
> Not with the same ease of use. We have crosstab functions
> in contrib/tablefunc already, but the killer problem with PIVOT
> is that truly dynamic columns are never reachable directly
Noah Misch writes:
> On Sun, Aug 09, 2015 at 07:16:02PM -0400, Tom Lane wrote:
>> Noah Misch writes:
>>> It does risk that. Same deal with making "=" have the same precedence as
>>> "<"
>>> instead of keeping it slightly lower.
>> Agreed, but in that case I think our hand is forced by the SQL
Tom Lane wrote:
> Is there a way to implement pivoting as a set-returning function?
Not with the same ease of use. We have crosstab functions
in contrib/tablefunc already, but the killer problem with PIVOT
is that truly dynamic columns are never reachable directly.
If we could do this:
On Sun, Aug 09, 2015 at 07:16:02PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Aug 09, 2015 at 06:44:58PM -0400, Tom Lane wrote:
> >> So for our
> >> purposes, it's better to keep BETWEEN and friends as binding slightly
> >> tighter than '<' than to make them the same precedence. Same
Noah Misch writes:
> On Sun, Aug 09, 2015 at 06:44:58PM -0400, Tom Lane wrote:
>> So for our
>> purposes, it's better to keep BETWEEN and friends as binding slightly
>> tighter than '<' than to make them the same precedence. Same precedence
>> risks breaking things that weren't broken before.
>
On Sun, Aug 09, 2015 at 06:44:58PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Aug 09, 2015 at 04:48:22PM -0400, Tom Lane wrote:
> >> I'm curious about your rationale for claiming that has
> >> precedence exactly equal to "<" according to the spec.
>
> > Both and are in the set of
Noah Misch writes:
> On Sun, Aug 09, 2015 at 04:48:22PM -0400, Tom Lane wrote:
>> I'm curious about your rationale for claiming that has
>> precedence exactly equal to "<" according to the spec.
> Both and are in the set of productions
> that take arguments and appear only in .
> Passing a pr
Andrew Dunstan writes:
> Still not quite there. If either 9.0 or 9.1 is upgraded to 9.2 or later,
> they fail like this:
> pg_restore: creating TYPE "public"."myshell"
> pg_restore: setting owner and privileges for TYPE "public"."myshell"
> pg_restore: setting owner and privileges fo
On Sun, Aug 09, 2015 at 04:48:22PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > SQL has two groups of IS tests with different precedence. The > test>
> > productions IS [NOT] {TRUE | FALSE | UNKNOWN} have precedence just lower
> > than
> > "<", and the productions IS [NOT] NULL have precede
I wrote:
> Noah Misch writes:
>> Why in particular the following three precedence groups instead of
>> combining them as in SQL or subdividing further as in PostgreSQL 9.4?
> +%nonassoc'<' '>' '=' LESS_EQUALS GREATER_EQUALS NOT_EQUALS
> +%nonassocBETWEEN IN_P LIKE ILIKE SIMILAR NOT_LA
> %
* Sehrope Sarkuni (sehr...@jackdb.com) wrote:
> It'd be nice if the new auth mechanism supports multiple passwords in the
> same format as well (not just one per format).
>
> That way you could have two different passwords for a user that are active
> at the same time. This would simplify rolling
Noah Misch writes:
> SQL has two groups of IS tests with different precedence. The
> productions IS [NOT] {TRUE | FALSE | UNKNOWN} have precedence just lower than
> "<", and the productions IS [NOT] NULL have precedence equal
> to "<". (An implementation giving them the same precedence can con
I've started to work on path-ification of the upper planner (finally),
and since that's going to be a large patch in any case, I've been looking
for pieces that could be bitten off and done separately. One such piece
is the fact that SS_finalize_plan (computation of extParams/allParams)
currently
On Thu, Feb 19, 2015 at 10:48:34AM -0500, Tom Lane wrote:
> To wit, that the precedence of <= >= and <> is neither sane nor standards
> compliant.
> I claim that this behavior is contrary to spec as well as being
> unintuitive. Following the grammar productions in SQL99:
Between 1999 and 2006, S
On Sun, Aug 9, 2015 at 10:23 AM, Tom Lane wrote:
> If there's actually a use case for that sort of thing, I would vote
> for moving the jumble-calculation code into core
I think that there'd be a good case for doing that for several other
reasons. It would be great to have a per-queryId
log_min_d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/09/2015 10:37 AM, Tom Lane wrote:
> I can see the value of a feature like this, but doing it in psql
> sure seems like the wrong place. It would be unavailable to
> anything except interactive use.
>
> Is there a way to implement pivoting as a
On 08/09/2015 08:09 AM, Robert Haas wrote:
> Why do we need to be able to authenticate using more than one
> mechanism? If you have some clients that can't support SCRAM yet, you
> might as well continue using MD5 across the board until that changes.
> You're not going to get much real security ou
"Daniel Verite" writes:
> I want to suggest a client-side \pivot command in psql, implemented
> in the attached patch.
> \pivot takes the current query in the buffer, execute it and
> display it pivoted by interpreting the result as:
> column1 => row in pivoted output
> column2 => column in pivo
Hi,
I want to suggest a client-side \pivot command in psql, implemented
in the attached patch.
\pivot takes the current query in the buffer, execute it and
display it pivoted by interpreting the result as:
column1 => row in pivoted output
column2 => column in pivoted output
column3 => value at
Robert Haas writes:
> I'm not too excited about supporting the use case where there are two
> people using queryId but it just so happens that they always set
> exactly the same value. That seems like a weird setup. Wouldn't that
> mean both modules were applying the same jumble algorithm, and
>
On Thu, Aug 6, 2015 at 11:33 AM, Jim Nasby wrote:
> They also provide a level of control over what is and isn't installed in a
> cluster. Personally, I'd prefer that most users not even be aware of the
> existence of things like pageinspect.
+1.
If everybody feels that moving extensions currentl
On Thu, Aug 6, 2015 at 2:19 PM, Qingqing Zhou wrote:
> In cache invalidation logic, we have the following comment:
>
> /*
> * Now that we have the lock, check for invalidation messages, so that we
> * will update or flush any stale relcache entry before we try to use it.
> * RangeVarGetRelid() spe
On Sat, Aug 8, 2015 at 11:30 AM, Shay Rojansky wrote:
> the entire row in memory (imagine rows with megabyte-sized columns). This
> makes sense to me; Tom, doesn't the libpq behavior you describe of absorbing
> the result set as fast as possible mean that a lot of memory is wasted on
> the client
On Sat, Aug 8, 2015 at 1:23 PM, Heikki Linnakangas wrote:
> On 08/08/2015 04:27 PM, Robert Haas wrote:
>> I don't see that there's any good reason to allow the same password to
>> be stored in the catalog encrypted more than one way,
>
> Sure there is. If you want to be able to authenticate using
On Sun, Aug 9, 2015 at 1:36 AM, Satoshi Nagayasu wrote:
> On 2015/08/08 22:32, Robert Haas wrote:
>> On Sat, Aug 8, 2015 at 5:00 AM, Satoshi Nagayasu wrote:
>>>
>>> I just found that pg_stat_statements causes assert when queryId is
>>> set by other module, which is loaded prior to pg_stat_stateme
On 08/09/2015 08:41 AM, Michael Paquier wrote:
On Sun, Aug 9, 2015 at 1:40 AM, Andrew Dunstan wrote:
On 08/08/2015 09:31 AM, Robert Haas wrote:
On Fri, Aug 7, 2015 at 7:17 PM, Andrew Dunstan
wrote:
That certainly isn't what happens, and given the way this is done in
TestLib.pm, using the C
On Sun, Aug 9, 2015 at 1:40 AM, Andrew Dunstan wrote:
>
> On 08/08/2015 09:31 AM, Robert Haas wrote:
>>
>> On Fri, Aug 7, 2015 at 7:17 PM, Andrew Dunstan
>> wrote:
>>>
>>> That certainly isn't what happens, and given the way this is done in
>>> TestLib.pm, using the CLEANUP parameter of File::Tem
On Sun, Aug 9, 2015 at 5:00 PM, Vladimir Koković
wrote:
> starting permutation: s2check s1b s2b s1i s2summ s1c s2c s2check
> setup failed: ERROR: could not open extension control file
> "/home/src/postgresql-devel/dev-build/tmp_install/home/src/postgresql-devel/dev-install/share/extension/pageins
Hi,
PostgreSQL build failed with current GIT source.
tail make-out-dev.log
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-g3 -gdwarf-2 isolati
Hello Heikki,
Thanks for having a look at the patch.
* I think we should drop the "flush" part of this for now. It's not as
clearly beneficial as the sorting part, and adds a great deal more code
complexity. And it's orthogonal to the sorting patch, so we can deal with it
separately.
I agr
45 matches
Mail list logo
