On Sat, May 7, 2016 at 11:08 PM, Masahiko Sawada wrote:
> On Sat, May 7, 2016 at 6:00 AM, Joshua D. Drake
> wrote:
>> On 05/06/2016 01:58 PM, Stephen Frost wrote:
>>>
>>> * Joshua D. Drake (j...@commandprompt.com) wrote:
Yeah I thought about that, it is the word "FORCE" that bothers me
On Saturday, May 7, 2016, Tom Lane wrote:
> Stephen Frost > writes:
> > * Tom Lane (t...@sss.pgh.pa.us ) wrote:
> >> ... but I'm left with a policy question: should initdb disallow
> >> bootstrap superuser names like "pg_xxx"?
>
> > On the whole, I'd vote to treat the bootstrap user as a normal r
Euler Taveira writes:
> While updating translations, I noticed that access/transam/xlog.c:6174
> contains different messages that could be the same.
> "ignoring file \"%s\" because no file \"%s\" exists"
> a few lines above
> "ignoring \"%s\" file because no \"%s\" file exists"
> Attached is a pat
On Friday, May 6, 2016, Tom Lane wrote:
> If you're not tired of reviewing release notes (I'm sure getting a bit
> tired of writing them), see
>
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=eb7de00ac2d282263541ece849ec71e2809e9467
>
> guaibasaurus should have 'em up on th
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> ... but I'm left with a policy question: should initdb disallow
>> bootstrap superuser names like "pg_xxx"?
> On the whole, I'd vote to treat the bootstrap user as a normal role and
> therefore have the same restriction in place fo
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Disable BLOB test in pg_dump TAP tests
>
> > Buildfarm member jacana appears to have an issue with running this
> > test. It's not entirely clear to me why, but rather than try to
> > fight with it, just disable it for now.
My take below is that of a user reading our documentation and our projected
consistency via that document.
All of the other planner GUCs are basically, {on, off, special} with on or
special the default as appropriate for the feature - since most/all
features default to enabled. While I get that t
On 07-05-2016 22:53, Robins Tharakan wrote:
> Should I be looking somewhere else? Parse keywords from Git Source file
> (if so where)? Parse PG Documentation?
>
src/include/parser/kwlist.h
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Des
Hi,
While creating a Syntax Highlighting XML for Notepad++ (something like a
PLSQL one here http://goo.gl/UBbHdt ), I was looking for a list of Keywords
(& separately list of Datatypes) that Postgres uses in a given version (Say
DEVEL branch).
I did find the Reserved Keyword list (
http://www.pos
Hi,
While updating translations, I noticed that access/transam/xlog.c:6174
contains different messages that could be the same.
"ignoring file \"%s\" because no file \"%s\" exists"
a few lines above
"ignoring \"%s\" file because no \"%s\" file exists"
Attached is a patch that turn it into one.
On 2016-05-06 20:28:27 -0500, Kevin Grittner wrote:
> On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote:
> > On 2016-05-06 19:43:24 -0500, Kevin Grittner wrote:
> >> It's disappointing that I am not getting more consistent numbers,
> >> but NUMA can be hard to manage that way.
> >
> > FWIW, in m
On 7 May 2016 at 16:49, Tom Lane wrote:
> Simon Riggs writes:
> > On 3 May 2016 at 18:07, Tom Lane wrote:
> >> Or at least, it did until Simon decided that ALTER TABLE RESET
> >> doesn't require AccessExclusiveLock.
>
> > On reflection, this still seems like a good idea.
>
> Yes, what pg_upgrad
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 5/7/16 9:36 AM, Stephen Frost wrote:
> >Honestly, over the next couple of months between feature-freeze and
> >release, I'd like to add even more tests, and not just to pg_dump but
> >also to other commands that don't have ve
On 5/7/16 9:36 AM, Stephen Frost wrote:
Honestly, over the next couple of months between feature-freeze and
release, I'd like to add even more tests, and not just to pg_dump but
also to other commands that don't have very good testing today (psql, in
particular, but pg_dumpall needs more also, an
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> So this seems like another reason why removing those checks was an
> improvement, but I'm left with a policy question: should initdb disallow
> bootstrap superuser names like "pg_xxx"? This doesn't seem quite
> open-and-shut. On the one hand, if we leave i
I noticed that opossum's latest buildfarm run failed, evidently because
it was set up with the user running the buildfarm named "pg_buildfarmer":
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=opossum&dt=2016-05-03%2018%3A43%3A31
That caused the bootstrap superuser's name to be "pg_buildf
Simon Riggs writes:
> On 3 May 2016 at 18:07, Tom Lane wrote:
>> Or at least, it did until Simon decided that ALTER TABLE RESET
>> doesn't require AccessExclusiveLock.
> On reflection, this still seems like a good idea.
Yes, what pg_upgrade was doing was clearly a hack, and not a very nice one.
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 7 May 2016 at 16:21, Stephen Frost wrote:
> > * Simon Riggs (si...@2ndquadrant.com) wrote:
> > > On 7 May 2016 at 16:14, Stephen Frost wrote:
> > > > > If we don't lock it then we will have a inconsistent dump that will
> > fail
> > > > > later, i
On 7 May 2016 at 16:21, Stephen Frost wrote:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
> > On 7 May 2016 at 16:14, Stephen Frost wrote:
> > > > If we don't lock it then we will have a inconsistent dump that will
> fail
> > > > later, if dumped while an object is being dropped.
> > > > Do we
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 7 May 2016 at 16:14, Stephen Frost wrote:
> > > If we don't lock it then we will have a inconsistent dump that will fail
> > > later, if dumped while an object is being dropped.
> > > Do we want an inconsistent dump?
> >
> > The dump won't be incon
On 7 May 2016 at 16:14, Stephen Frost wrote:
> > If we don't lock it then we will have a inconsistent dump that will fail
> > later, if dumped while an object is being dropped.
> > Do we want an inconsistent dump?
>
> The dump won't be inconsistent, as Tom pointed out. The catalog tables
> are
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 4 May 2016 at 16:45, Tom Lane wrote:
> > Why is it that we need to lock a table at all if we're just going to dump
> > its ACL?
>
> We don't, but surely that's the wrong question.
I tend to agree with this, however...
> If we don't lock
On Sat, May 7, 2016 at 6:00 AM, Joshua D. Drake wrote:
> On 05/06/2016 01:58 PM, Stephen Frost wrote:
>>
>> * Joshua D. Drake (j...@commandprompt.com) wrote:
>>>
>>> Yeah I thought about that, it is the word "FORCE" that bothers me.
>>> When you use FORCE there is an assumption that no matter what
On 4 May 2016 at 16:45, Tom Lane wrote:
> Why is it that we need to lock a table at all if we're just going to dump
> its ACL?
We don't, but surely that's the wrong question.
If we don't lock it then we will have a inconsistent dump that will fail
later, if dumped while an object is being dro
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 5/6/16 3:11 PM, Stephen Frost wrote:
> >These are just new tests..?
>
> This is a matter of degree, but I think there is a difference
> between new test cases and a whole new test suite.
To be clear, I've been calling it a 'test su
On Fri, May 6, 2016 at 8:45 AM, Tom Lane wrote:
>
> Andreas Seltenreich writes:
> > when fuzz testing master as of c1543a8, parallel workers trigger the
> > following assertion in ExecInitSubPlan every couple hours.
> > TRAP: FailedAssertion("!(list != ((List *) ((void *)0)))", File:
"list.c"
On 6 May 2016 at 01:00, Tomas Vondra wrote:
> I think we can further limit the impact by ignoring foreign keys on a
> single column, because the primary goal of the patch is improving estimates
> with multi-column FKs (and matching joins). I'd argue that 99% of the FKs
> in practice is single-co
On 3 May 2016 at 16:10, Tomas Vondra wrote:
> While this in itself is about a two-line fix, after reviewing
>> 137805f89acb3611 I'm pretty unhappy that it got committed at all.
>> I think this obvious bug is a good sign that it wasn't ready.
>> Other unfinished aspects like invention of an undoc
On 3 May 2016 at 18:07, Tom Lane wrote:
> Or at least, it did until Simon decided that ALTER TABLE RESET
> doesn't require AccessExclusiveLock.
On reflection, this still seems like a good idea.
> Now you get a failure.
>
Failure condition as an exception to that.
> I haven't tried to cons
29 matches
Mail list logo
