* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 8/17/16 9:46 PM, Stephen Frost wrote:
> >* Jim Nasby (jim.na...@bluetreble.com) wrote:
> >>> https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial does
> >>> not specify -c for any of the rsync commands. Tha
* Venkata B Nagothi (nag1...@gmail.com) wrote:
> On Wed, Aug 17, 2016 at 11:27 PM, Stephen Frost wrote:
> > * Venkata B Nagothi (nag1...@gmail.com) wrote:
> > > Agreed. Additional option like "pause" would. As long as there is an
> > option
> > > to ensu
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial does
> not specify -c for any of the rsync commands. That's maybe safe for
> WAL, but I don't think it's safe for any of the other uses, right?
> I'd like someone to confirm before I just ch
Venkata,
* Venkata B Nagothi (nag1...@gmail.com) wrote:
> Agreed. Additional option like "pause" would. As long as there is an option
> to ensure following happens if the recovery target is not reached -
>
> a) PG pauses the recovery at the end of the WAL
> b) Generates a warning in the log fil
Greetings,
* Venkata B Nagothi (nag1...@gmail.com) wrote:
> The above said parameters can be configured to pause, shutdown or prevent
> promotion only after reaching the recovery target point.
> To clarify, I am referring to a scenario where recovery target point is not
> reached at all ( i mean,
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 8/15/16 3:06 PM, Tom Lane wrote:
> > That would give us an automatic annual change in the minor version.
> > If we ever made an incompatible change in a shlib, we could advance
> > its SO_MAJOR_VERSION but keep this rule for
David,
* David Steele (da...@pgmasters.net) wrote:
> Recently a hacker proposed a patch to add pg_dynshmem to the list of
> directories whose contents are excluded in pg_basebackup. I wasn't able
> to find the original email despite several attempts.
That would be here:
b4e94836-786b-6020-e1b3-
* Vladimir Sitnikov (sitnikov.vladi...@gmail.com) wrote:
> 3) "suddently get slow the 6th time" is a PostgreSQL bug that both fails to
> estimate cardinality properly, and it does not provide administrator a way
> to disable the feature (generic vs specific plan).
Dropping and recreating the prepa
* Vladimir Sitnikov (sitnikov.vladi...@gmail.com) wrote:
> It works completely transparent to the application, and it does use
> server-prepared statements even though application builds "brand new" sql
> text every time.
And is the source of frequent complaints on various mailing lists along
the
* Joshua D. Drake (j...@commandprompt.com) wrote:
> +1 for Robert here, removing async commit is a non-starter. It is
> PostgreSQL performance 101 that you disable synchronous commit
> unless you have a specific data/business requirement that needs it.
> Specifically because of how much faster Pg i
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Aug 2, 2016 at 3:07 PM, Alfred Perlstein wrote:
> > You are quite technical, my feeling is that you will understand it, however
> > it will need to be a self learned lesson.
>
> I don't know what this is supposed to mean, but I think that Ge
David,
* David Fetter (da...@fetter.org) wrote:
> On Mon, Aug 01, 2016 at 02:52:04PM -0400, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > "David G. Johnston" writes:
> > > > I suspect I'll end up using 10.x somewhat frequen
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "David G. Johnston" writes:
> > I suspect I'll end up using 10.x somewhat frequently though I'm mostly on
> > the lists. I suspect the choice will be dependent on context and channel.
>
> Hmm, that seems like a workable answer as well, and one that's trac
Robbie, all,
* Robbie Harwood (rharw...@redhat.com) wrote:
> Michael Paquier writes:
> > On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood
> > wrote:
> >> Michael Paquier writes:
> >>
> >> So there's a connection setting `sslmode` that we'll want something
> >> similar to here (`gssapimode` or
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Building on the has-property approach Andrew suggested, I wonder if
> >> we need something like pg_index_column_has_property(indexoid, colno,
> >>
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Yeah. I'm not very impressed by the underlying assumption that it's
> >> okay for client-side code to hard-wire knowledge about what indoptio
* Hannu Krosing (hkros...@gmail.com) wrote:
> On 07/27/2016 12:07 AM, Tom Lane wrote:
> >
> >> 4. Now, update that small table 500 times per second.
> >> That's a recipe for runaway table bloat; VACUUM can't do much because
> >> there's always some minutes-old transaction hanging around (and SNAPSH
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sat, Jul 30, 2016 at 5:47 AM, Stephen Frost wrote:
> > What we need to be doing here is combining the set of components that
> > the sequence has been marked with and the set of components that the
> > table
Michael,
(dropping -general, not sure why that list was included...)
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Wed, Jul 27, 2016 at 8:07 AM, Stephen Frost wrote:
> > That'd be great. It's definitely on my list of things to look into, but
> > I'
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Jul 29, 2016 at 10:44:29AM -0400, Stephen Frost wrote:
> > Another thought that was kicking around in my head related to that is if
> > we could have indexes that only provide page-level information (similar
> > to BRIN, b
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 7/28/16 10:05 AM, Alex Ignatov wrote:
> >>Just curious: what if PostgreSQL supported index that stores "primary
> >>key" (or unique key) instead of tids?
> >
> >You mean IOT like Oracle have?
>
> IIRC, IOT either stores the table in index order, w
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > On 7/25/16 3:26 PM, Andrew Gierth wrote:
> >> The issue I ran into was the exact same one as in the JDBC thread I
> >> linked to earlier: correctly interpreting pg_index.indoption (to get the
> >> ASC / DESC and NULLS FIRST/LAST
* Joshua D. Drake (j...@commandprompt.com) wrote:
> Hello,
>
> The following article is a very good look at some of our limitations
> and highlights some of the pains many of us have been working
> "around" since we started using the software.
>
> https://eng.uber.com/mysql-migration/
>
> Specif
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Jul 26, 2016 at 4:50 PM, Noah Misch wrote:
> > [Action required within 72 hours. This is a generic notification.]
> >
> > The above-described topic is currently a PostgreSQL 9.6 open item. Stephen,
> > since you committed t
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "Joshua D. Drake" writes:
> > On 07/25/2016 12:19 PM, Tom Lane wrote:
> >> Andrew still hasn't shown a concrete
> >> example of what he needs to do and why.
>
> > I think that Andrew and other people who have commented on this thread
> > made it pretty ob
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> > "Tom" == Tom Lane writes:
>
> >> With the gutting of pg_am in 9.6, there seems to be no longer any
> >> way for a query of the system catalogs to discover any of the index
> >> capabilities that were formerly columns in pg_am (notabl
* Noah Misch (n...@leadboat.com) wrote:
> On Fri, Jul 15, 2016 at 03:46:17PM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> > > On Sat, Jul 09, 2016 at 12:55:33AM -0400, Stephen Frost wrote:
> > > > * Noah Misch (n...@leadboat.com) wrote:
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sat, Jul 16, 2016 at 4:46 AM, Stephen Frost wrote:
> > Going through and doing testing now. Unfortunately, it doesn't look
> > like adding in testing of tablespaces into the TAP tests would be very
> > easy (th
Noah,
On Monday, July 18, 2016, Noah Misch wrote:
> On Fri, Jul 15, 2016 at 03:46:17PM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com ) wrote:
> > > On Sat, Jul 09, 2016 at 12:55:33AM -0400, Stephen Frost wrote:
> > > > * Noah Misch (n...@leadbo
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> We've talked before about how the regression tests should be circumspect
> about what role names they create/drop, so as to avoid possibly blowing
> up an installation's existing users during "make installcheck". In
> particular I believe there was co
* Noah Misch (n...@leadboat.com) wrote:
> On Sat, Jul 09, 2016 at 12:55:33AM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> > > This PostgreSQL 9.6 open item is past due for your status update. Kindly
> > > send
> > > a status update
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > On 7/13/16 2:06 PM, Corey Huinker wrote:
> >> Time: 3601083.544 ms (1h 0m 1.084s)
>
> > That works for me, except that the abbreviation for minute is "min".
>
> Meh ... if we're using one-letter abbreviations for hour and seco
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Kenan Yao writes:
> > -- mkfifo /tmp/test.dat # bash
> > copy pg_class to '/tmp/test.dat';
> > -- try pg_cancel_backend or pg_terminate_backend from other sessions
>
> This does not seem like a supported case to me. I see few if any reasons
> to want to d
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 7/12/16 7:11 PM, Stephen Frost wrote:
> > I'm curious how it's useful and in what way \sf does not accomplish what
> > you use \df+ for.
>
> One main use is to see multiple related functions next to
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 7/12/16 12:17 PM, Tom Lane wrote:
> > It's sounding to me like we have consensus on this proposal to further
> > change \df+ to replace the "Source code" column with "Internal name",
> > which is prosrc for C and internal-language fu
All,
* Noah Misch (n...@leadboat.com) wrote:
> On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > > Do this:
> > >
> > > CREATE DATABASE test1;
> > > REVOKE CONNECT ON
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Are we satisfied with telling people to use \sf to see the source code
> >> for a PL function? Or should there be another variant of \df that
> >>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Agreed. I don't have any issue with "Language", really, but I agree
> > that "Source code" makes the output pretty ridiculous. I also liked the
> > idea of changing the name to &quo
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
> > wrote:
> >> So prosrc for internal/C and NULL for others? WFM.
>
> > And so we'd remove "Language" at the same time? That does not sound bad to
> > me.
>
> Hm, I wasn't th
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-07-11 11:14:29 -0700, Peter Geoghegan wrote:
> > On Mon, Jul 11, 2016 at 7:25 AM, Stephen Frost wrote:
> > >> Or in short, this may be a fine change to make, but I don't like your
> > >> argument for i
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I agree with removing the source code field, though I did like the
> > suggestion mentioned elsewhere for having it shown when it's just a C
> > symbol but not otherwise. If we can find a way to have t
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane wrote:
> >> (Of course, if we were to get rid of "Source code", the point
> >> would be moot ...)
>
> > I still think that having source code is useful for debugging, so I
> > left it
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836
> > in November 2002 when we didn't have any logging of checkpointing at
> > all. I propose to remove it: surely anyone who cares about analyzing
> > checkp
* Noah Misch (n...@leadboat.com) wrote:
> This PostgreSQL 9.6 open item is past due for your status update. Kindly send
> a status update within 24 hours, and include a date for your subsequent status
> update. Refer to the policy on open item ownership:
> http://www.postgresql.org/message-id/201
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Amit Kapila writes:
> > On Fri, Jul 8, 2016 at 5:27 PM, Michael Paquier
> > wrote:
> >> Okay. Here we go. I named the column for the parallel information
> >> "Parallelism".
>
> > Another option could be to name it as Parallel Mode.
>
> I'd go with just
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Magnus Hagander writes:
> > On Friday, July 8, 2016, Michael Paquier wrote:
> >> Fujii-san has reminded me of the fact that we do not show in \df+ the
> >> parallel status of a function. The output of \df+ is already very
> >> large, so I guess that any pe
All,
* Noah Misch (n...@leadboat.com) wrote:
> On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > > Do this:
> > >
> > > CREATE DATABASE test1;
> > > REVOKE CONNECT ON
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Jul 5, 2016 at 5:50 PM, Magnus Hagander wrote:
> > On Tue, Jul 5, 2016 at 10:06 AM, Michael Paquier
> > wrote:
> > However, is there something that's fundamentally better with the OpenSSL
> > implementation? Or should we just keep *j
All,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Michael Paquier wrote:
> > On Wed, Jul 6, 2016 at 7:34 PM, Fujii Masao wrote:
> > > I have one question; why do we call the column "conn_info" instead of
> > > "conninfo" which is basically used in other places? "conninfo" is better
> > >
Noah, all,
On Saturday, July 2, 2016, Noah Misch wrote:
> On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com )
> wrote:
> > > Do this:
> > >
> > > CREATE DATABASE test1;
> > &
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Tue, Jun 21, 2016 at 4:18 PM, Merlin Moncure wrote:
> >> explain analyze select * from foo where false or exists (select 1 from
> >> bar where good and foo.id = bar.id); -- A
> >> explain analyze select * from foo whe
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> Do this:
>
> CREATE DATABASE test1;
> REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
>
> Run pg_dumpall.
>
> In 9.5, this produces
>
> CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = peter;
> REVOKE ALL ON DATABASE te
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jun 28, 2016 at 11:12 PM, Peter Eisentraut
> wrote:
> > Do this:
> >
> > CREATE DATABASE test1;
> > REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
> >
> > Run pg_dumpall.
> >
> > In 9.5, this produces
> >
> > CREATE DATABASE test1 WITH TEMPLATE
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Tue, Jun 21, 2016 at 11:29 AM, Tom Lane wrote:
> >> What I would want to know is whether this specific change is actually a
> >> good idea. In particular, I'm concerned about the possible security
> >> implications of exposi
* Noah Misch (n...@leadboat.com) wrote:
> Yep, pretty much that. CLOSE_WAIT is for performance defects, race
> conditions, and other defects where a successful fix is difficult to verify
> beyond reasonable doubt. Other things can move directly to "resolved". I
> don't mind if practice diverges
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 6/7/16 11:16 AM, Stephen Frost wrote:
> >Moved to CLOSE_WAIT.
>
> Could you add an explanation on the wiki page about what this section means?
I understood it to simply be a step on the way to being resolved- that
* Noah Misch (n...@leadboat.com) wrote:
> The above-described topic is currently a PostgreSQL 9.6 open item. Stephen,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> 9.6 open item, pleas
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> Stephen, are you working on a patch or should I get one out of my
> pocket? That's something we should get fixed quickly. We need as well
> to be careful with the support for COMMENT with access methods, the
> current consensus on the
Andres, all,
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-06-06 15:16:10 -0400, Robert Haas wrote:
> > On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote:
> > and like you have the right to tell assign me arbitrary work, which I
> > think you don't.
>
> It's not like adding a parameter
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund wrote:
> >> In terms of diagnostic tools, you can get the VM bits and
> >> page-level bits using the pg_visibility extension; I wrote it
> >> precisely because of concerns like the ones you raise here. I
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote:
> > If a database with the bloom extension installed is dumped and restored,
> > there's an error with the access method creation:
> >
> > createdb bloomtest
> > psql -c 'CREATE EXTEN
Rushabh,
* Rushabh Lathia (rushabh.lat...@gmail.com) wrote:
> On Fri, May 13, 2016 at 7:27 PM, Stephen Frost wrote:
>
> > * Rushabh Lathia (rushabh.lat...@gmail.com) wrote:
> > > On master branch when we do pg_dumpall with -c option, I can see that
> > >
All,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andreas Karlsson writes:
> > On 05/25/2016 02:41 AM, Robert Haas wrote:
> >> I'd rather extend see us ALTER AGGREGATE to do this.
>
> > Wouldn't that prevent this from going into 9.6? I do not think changing
> > ALTER AGGREGATE is 9.6 materials.
>
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Mon, May 23, 2016 at 5:05 PM, Tom Lane wrote:
> > Michael Paquier writes:
> >> I just bumped into the following typo for $subject:
> >> - 'role names cannot being with "pg_"');
> >> + 'role names cannot begin with "pg_"');
> >
On Friday, May 13, 2016, Bruce Momjian wrote:
> On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote:
> > * Dave Page (dp...@pgadmin.org ) wrote:
> > > I imagine the bigger issue will be apps that have been written
> > > assuming the first part of the vers
On Friday, May 13, 2016, Dave Page wrote:
> On Fri, May 13, 2016 at 5:08 PM, Bruce Momjian > wrote:
> > On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote:
> >> * Dave Page (dp...@pgadmin.org ) wrote:
> >> > I imagine the bigger issue wi
* Dave Page (dp...@pgadmin.org) wrote:
> I imagine the bigger issue will be apps that have been written
> assuming the first part of the version number is only a single digit.
Let's just go with 2016 instead then.
At least then users would see how old the version they're running is (I
was just re
* Rushabh Lathia (rushabh.lat...@gmail.com) wrote:
> On master branch when we do pg_dumpall with -c option, I can see that
> it also dumping the "DROP ROLE pg_signal_backend", which seems wrong.
> Because when you restore the dump, its throwing an error
> "ERROR: cannot drop role pg_signal_backend
it tomorrow.
Thanks!
Stephen
From e294008daa8e909059c94441643157fddf9af9b6 Mon Sep 17 00:00:00 2001
From: Stephen Frost
Date: Tue, 10 May 2016 12:55:11 -0400
Subject: [PATCH] Qualify table usage in dumpTable() and use regclass
All of the other tables used in the query in dumpTable(), which is
collecting column-level ACLs, are qu
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
>
> > diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
> > index 1267afb..4a9b1bf 100644
> > --- a/src/bin/pg_dump/pg_dump.c
> > +++ b/src/bin/pg_dump/pg_dump.c
> >
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Apr 05, 2016 at 05:50:18PM -0400, Stephen Frost wrote:
> > @@ -14187,18 +14869,65 @@ dumpTable(Archive *fout, TableInfo *tbinfo)
>
> > + "FROM
> &g
Catalin,
* Catalin Iacob (iacobcata...@gmail.com) wrote:
> On 5/9/16, Stephen Frost wrote:
> >> And what if the tests are buggy? New test suites should go through a
> >> CF first I think for proper review. And this is clearly one.
> >
> > They still won'
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sun, May 8, 2016 at 6:44 AM, Stephen Frost wrote:
> > I do think that now is a good time for people to be reviewing what's
> > been committed, which includes writing tests (either automated ones,
> > which can be
* Andrew Dunstan (and...@dunslane.net) wrote:
> TL;DR version: Msys provides a virtualized Unix-like file system
> that is visible to its programs that you use to build, but invisible
> to the programs you build since they are going to run without any
> knowledge of the build environment. So you c
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> If we're going to enforce such a restriction, I think it would be
> >> a good thing for it to be in place in beta1.
>
> > Makes sense.
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> If we're going to enforce such a restriction, I think it would be
> >> a good thing for it to be in place in beta1.
>
> > Makes sense.
>
* Robert Haas (robertmh...@gmail.com) wrote:
> Also, if we say that new tests are not features, that would mean that
> they could be back-patched even after the release is out the door, and
> generally I'm not in favor of that policy, except when we're adding a
> test to a back-branch that is close
* Tom Lane (t...@sss.pgh.pa.us) 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&
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
> > fig
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 othe
* 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
* 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 d
* 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 inconsist
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
* 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
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> If you like, you can try the @contrib_excludes addition that was mentioned
> before and see if that fixes it. But if it doesn't, it's time to cut our
> losses.
Alright, it certainly *appears* to be working. All of the Windows
buildfarm animals
* Josh berkus (j...@agliodbs.com) wrote:
> On 05/06/2016 01:58 PM, Andres Freund wrote:
> > On 2016-05-06 13:54:09 -0700, Joshua D. Drake wrote:
> >> On 05/06/2016 01:50 PM, Andres Freund wrote:
>
> >>> There already is FREEZE - meaning something different - so I doubt it.
> >>
> >> Yeah I thought
* 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, it
> plows through (think rm -f). So if we don't use FROZEN, that's cool
> but FORCE doesn't work either.
Isn't th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Fri, May 6, 2016 at 4:07 PM, Stephen Frost wrote:
> >> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >>> But at this point I think Peter's complaint has some force to it, and that
> >>
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, May 6, 2016 at 4:07 PM, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Stephen Frost writes:
> >> > * Stephen Frost (sfr...@snowman.net) wrote:
> >> >> Looks like the test_pg
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Apr 17, 2016 at 11:05 PM, Noah Misch wrote:
> > On Sun, Apr 17, 2016 at 08:04:03PM -0400, Noah Misch wrote:
> >> On Thu, Apr 07, 2016 at 03:50:47PM -0400, Stephen Frost wrote:
> >> > I'm planning to con
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, May 5, 2016 at 10:41 AM, Stephen Frost wrote:
> > Barring objections or concerns, I'll push this sometime tomorrow
> > (probably after I get back to DC).
>
> It really would have been good to get this stuff done
Robert,
On Friday, May 6, 2016, Robert Haas wrote:
> On Thu, May 5, 2016 at 10:41 AM, Stephen Frost > wrote:
> > Barring objections or concerns, I'll push this sometime tomorrow
> > (probably after I get back to DC).
>
> It really would have been good to get th
* Stephen Frost (sfr...@snowman.net) wrote:
> In any case, as I was saying, that's far closer to 9.5 run-time. I've
> not measured the time added when things like TRANSFORMs were added, but
> it wouldn't surprise me if adding a new query for every database to
> pg_dum
* Stephen Frost (sfr...@snowman.net) wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Tue, Apr 26, 2016 at 7:39 PM, Robert Haas wrote:
> > > On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote:
> > >> Based on our discussion at PGConf.US and the comm
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 5/4/16 11:23 PM, Tom Lane wrote:
> >Actually, I believe it will be dumped. selectDumpableCast believes it
> >should dump casts with OID >= FirstNormalObjectId. That's a kluge no
> >doubt, but reasonably effective; looks like we've
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > On 5/4/16 2:39 PM, Stephen Frost wrote:
> >> These checks are looking for the functions used by the transform in the
> >> list of functions that pg_dump has loaded, but in 9.5, we don't
* Noah Misch (n...@leadboat.com) wrote:
> On Wed, May 04, 2016 at 08:14:55AM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> > > On Mon, Apr 25, 2016 at 12:39:09AM -0400, Stephen Frost wrote:
> > > > * Noah Misch (n...@leadboat.com) wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Attached patch implements this change to not LOCK the table in cases
> > where we don't need to. I'll push this with my other changes to pg_dump
> > tomorrow (and I've included it in an update
atches
sent on the thread where those changes were being discussed already).
Wanted to include it here also for completeness.
Comments welcome, of course.
Thanks!
Stephen
From 32645eac291b546df2acb23685c0a5f123131efa Mon Sep 17 00:00:00 2001
From: Stephen Frost
Date: Wed, 4 May 2016 13:40:36 -0400
701 - 800 of 4446 matches
Mail list logo
