On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
> On 2015-05-23 21:36:50 -0400, Bruce Momjian wrote:
> > pgindent run on HEAD and committed.
>
> - if (IsA(node, Aggref) || IsA(node, GroupingFunc))
> + if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
>
On Sat, May 23, 2015 at 12:32:34PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Are we ready for a pgindent run? Back branches?
>
> I think we could do it in HEAD, but it doesn't seem like we have consensus
> about whether to touch the back branches. Suggest jus
the I' commit.
I have always added the typedef list I used as part of pgindent commit
runs.
Are we ready for a pgindent run? Back branches?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god.
On Sat, May 23, 2015 at 03:46:33PM +0200, Nils Goroll wrote:
> Hi,
>
> as many before, I ran into the issue of a postgresql database (8.4.1)
Uh, did you mean 9.4.1 as 8.4.1 is end-of-lifed.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Mon, May 18, 2015 at 07:10:00PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
> >> (BTW, one practical issue is where would we get typedef lists relevant
> >> to the back branches. I'm not sure if
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian wrote:
> >> There was talk last time of pgindent-ing head and all back branches,
> >> because a patch applied to head and back bra
On Mon, May 18, 2015 at 05:52:22PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I have processed all the open email items I can through mid-March,
> > though I do have two pg_upgrade fixes pending application today. I will
> > continue processing doc fixes and ma
On Mon, May 18, 2015 at 05:00:41PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote:
>
> > > But I like the more general approach proposed by Alvaro, so in case this
> > > patch
> > > wo
t least one
> reasonably secure way for password recovery is available. For Unix systems
> "peer" authentication seems to be a good candidate.
Likely to be rejected.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
On Sun, May 17, 2015 at 08:35:49PM -0700, Josh Berkus wrote:
> On 05/15/2015 05:58 AM, Bruce Momjian wrote:
> > I have processed all the open email items I can through mid-March,
> > though I do have two pg_upgrade fixes pending application today. I will
> > continue pro
ause a patch applied to head and back branches was historically only
pgindented in head, meaning that any future patches in that area could
not be easily backpatched.
Do we want to do this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterpris
to block this.
> Or we would need to invent another (this time, privileged) verb in
> order to restore authz.
What if you put the SQL in a function then call the function? I don't
see how the pooler could block this.
--
Bruce Momjian http://momjian.us
EnterpriseDB
reased with
pg_resetxlog. Only in 9.4 was the timeline properly restored, leading
to the missing history file error.
This confirms that setting the timeline to 1 unconditionally, as I did
on Friday, is the right fix, and I have added a C comment so we will
remember _why_ this has to be the case
On Sat, May 16, 2015 at 02:49:08PM -0400, Bruce Momjian wrote:
> On Sat, May 16, 2015 at 12:21:12PM -0400, Noah Misch wrote:
> > On Thu, May 14, 2015 at 10:06:11PM -0400, Bruce Momjian wrote:
> > > On Thu, May 14, 2015 at 09:56:53PM -0400, Bruce Momjian wrote:
> > > &g
On Sat, May 16, 2015 at 12:21:12PM -0400, Noah Misch wrote:
> On Thu, May 14, 2015 at 10:06:11PM -0400, Bruce Momjian wrote:
> > On Thu, May 14, 2015 at 09:56:53PM -0400, Bruce Momjian wrote:
> > > This patch makes pg_upgrade controldata checks more consistent, and adds
> &g
On Fri, May 15, 2015 at 08:15:51AM -0700, Joshua Drake wrote:
>
> On 05/15/2015 07:42 AM, Bruce Momjian wrote:
>
> >>3. Push the rsync paragraph (and edit where appropriate) within the
> >>continuous archiving section.
> >>
> >>3a. Add informa
ump.
> Perhaps change time to Online Backup.
Uh, I don't like Online Backup because pg_dump is an "online" backup,
no?
> 4a. I want to do some general rewording, there are some places
> where the documentation is not clear. I can just do this and then
> let the re
I have processed all the open email items I can through mid-March,
though I do have two pg_upgrade fixes pending application today. I will
continue processing doc fixes and major bug fixes for 9.5, but
everything else I do will be for 9.6.
--
Bruce Momjian http://momjian.us
here you go.
> >
> >
> >Looks good for me.
>
> Ok, pushed after some further minor cleanup.
Great! That PostGIS workaround they had to use for accurate distances
with CTEs and LIMIT 100 was an ugly hack.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Thu, May 14, 2015 at 09:56:53PM -0400, Bruce Momjian wrote:
> This patch makes pg_upgrade controldata checks more consistent, and adds
> a missing check for float8_pass_by_value.
Sorry, I should have mentioned I applied this patch to head. It isn't
significant enough t
This patch makes pg_upgrade controldata checks more consistent, and adds
a missing check for float8_pass_by_value.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/bin/pg_upgrade
On Thu, May 14, 2015 at 06:57:24PM -0400, Tom Lane wrote:
> Stephen Frost writes:
> > * Bruce Momjian (br...@momjian.us) wrote:
> >> I will call for a vote that the freeze deadline be changed if this patch
> >> is rejected to due to time. I might lose the vote, but I a
On Thu, May 14, 2015 at 05:37:07PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, May 14, 2015 at 05:10:29PM -0400, Tom Lane wrote:
> >> The good news on this front is that Salesforce has recently taken an
> >> interest in having GROUPING SETS capabil
ed to due to time. I might lose the vote, but I am going to
try because if we lose our reputation for fairness, we have lost a lot
more than a week/month of release time.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone
rage others to work on it, and a day before the
freeze you say it is too late to apply? And now, all of a sudden, you
are interested in working on this because your employer is interested?
How do I measure the amount of unfairness here?
--
Bruce Momjian http://momjian.us
Enterprise
wrote:
> Hi,
> I am using Debian Jessie and install pgAdmin4 Required modules.
> after I clone pgAdmin4 from
> http://git.postgresql.org/gitweb/?p=pgadmin4.git;a=summary ,
>
> First of, ıf I want run setup.py, I must fix bug .
> after I want run pgadmin4.py, I must fix gravatar
On Wed, May 13, 2015 at 11:52:40AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Let me put a finer point on this --- whatever gets pushed to 9.6
> > unreasonably will be a feature we don't have in 9.5 and will discourage
> > future development. I know we can'
On Wed, May 13, 2015 at 11:19:29AM -0400, Bruce Momjian wrote:
> On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote:
> > We also need to start thinking about what happens after feature
> > freeze. The CommitFest application currently lists a 2015-06
> > CommitFes
k we need committers to devote serious
time, if possible, to helping us resolve as much as we can. If we start
thinking about this on Friday, it is too late.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their ow
ouple of days before feature freeze,
> and this patch has changed massively since it was first submitted.
> There isn't time now for people who want to have an opinion on this to
> form an educated one.
Yeah, pretty much any patch that needs significant redesign at this
point sh
orking, these mistakes will be
repeated. Our existing plan had worked so well for so many years that
it took very long for us to recognize we needed a new approach in this
case.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
ting observation --- are we too focused on patches
and features to realize when we need to seriously revisit an issue?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing l
On Tue, May 12, 2015 at 12:29:56AM +0300, Heikki Linnakangas wrote:
> On 05/12/2015 12:00 AM, Bruce Momjian wrote:
> >Multi-xacts were made durable in Postgres 9.3 (released 2013-09-09) to
> >allow primary-key-column-only locks. 1.7 years later, we are still
> >dealing with
On Mon, May 11, 2015 at 02:11:48PM -0700, Joshua Drake wrote:
>
> On 05/11/2015 02:00 PM, Bruce Momjian wrote:
>
> >I think we now know that our inaction didn't serve us well. The
> >question is how can we identify chronic problems and get resources
> >invol
on is how can we identify chronic problems and get resources
involved sooner. I feel we have been "asleep at the wheel" to some
extent on this.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own go
On Wed, Apr 29, 2015 at 10:52:45PM -0400, Bruce Momjian wrote:
> On Mon, Feb 16, 2015 at 05:03:45PM -0500, Bruce Momjian wrote:
> > > All of our makefiles use single quotes, so effectively the only
> > > character we don't support in directory paths is the single quote i
On Fri, May 1, 2015 at 10:14:13AM -0400, Bruce Momjian wrote:
> Currently initdb outputs suggested text on starting the server:
>
> Success. You can now start the database server using:
>
> /u/pgsql/bin/postgres -D /u/pgsql/data
> or
>
ility into core, but I suspect those increments will largely be in
> the infrastructure until we reach the point where we're able to provide
> the user-facing bits, which is quite likely to go in all at once and
> allow us a clear upgrade path from one to the other. Perhaps that'
On Thu, May 7, 2015 at 04:19:52PM -0400, Bruce Momjian wrote:
> On Tue, May 5, 2015 at 02:07:08PM -0300, Alvaro Herrera wrote:
> > Tom Lane wrote:
> >
> > > * We can't use CREATE OR REPLACE FUNCTION in the upgrade script because
> > > that intentionally doe
hem, then retry the extension update and re-create their views. This
> is necessarily a manual procedure -- I don't think we can re-create
> views using the function automatically. CASCADE seems pretty dangerous.
Just a reality check but this will break a pg_upgrade, and will not be
de
> I don't necessarily agree with the patch as proposed. I would rather
> have a comma-separated list of methods, as in:
>
> --disable-auth=ident,peer
Why don't they just apply a source code patch before compiling?
Configure seems like an odd place for thi
s and only then they will
use it and give us feedback? How motivated can they be if they can't
use the PGXN version?
The bottom line is that for the _years_ we ship pg_audit in /contrib, we
will have some logging stuff in postgresql.conf and some in
contrib/pg_audit and that distinction is
On Thu, May 7, 2015 at 10:17:18AM -0400, Andrew Dunstan wrote:
>
> On 05/07/2015 09:58 AM, Bruce Momjian wrote:
>
> >
> >Frankly, I am not sure how they are starting the server as the
> >/etc/init.d startup files don't handle multiple clusters well, and I
> &
uctions on how multi-cluster users are supposed to
set things up. I assume they are copying the existing init.d file with
a new name and modifying PGDATA and maybe the port number, then doing
'service ... start' or something like that. I doubt we want initdb to
recommend that.
--
Bruce
east, needs a big caveat in the documentation
> of the resume function. But a different API would probably be
> better. I'd actually argue that for now pg_xlog_replay_resume() should
> refuse to work if paused due to a recovery target. Promotion should be
> done via the nor
at. If postgres tells me what to change to
> achieve what I want, I have a much higher chance of getting
> there. Especially if it just does something else otherwise.
Where are we on this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://en
ea.
>
> > I consider this a bug fix, and suggest back patching to 9.4.
>
> I agree on backpatching it. Arguably we could additionally avoid
> emitting the ALTER TABLE ... REPLICA IDENTITY for views that have
> already been created with identity set
be recommended first. At the time this
text was written pg_ctl was new.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Fri, May 1, 2015 at 10:03:01AM -0400, Robert Haas wrote:
> On Fri, May 1, 2015 at 10:01 AM, Bruce Momjian wrote:
> >> Andrew did the research to support a higher value, but even 10 should
> >> be an improvement over what we have now.
> >
> > Yes, I saw that,
On Fri, May 1, 2015 at 09:39:43AM -0400, Robert Haas wrote:
> On Fri, May 1, 2015 at 9:13 AM, Bruce Momjian wrote:
> > On Fri, May 1, 2015 at 07:57:27AM -0400, Robert Haas wrote:
> >> On Thu, Apr 30, 2015 at 9:34 PM, Bruce Momjian wrote:
> >> > On Wed, Mar 11, 20
On Fri, May 1, 2015 at 03:13:28PM +0200, Petr Jelinek wrote:
> On 01/05/15 15:01, Bruce Momjian wrote:
> >On Fri, May 1, 2015 at 05:25:53AM +0200, Pavel Stehule wrote:
> >>It is done
> >
> >Uh, I am not sure why you say that as I don't see any commit relat
On Fri, May 1, 2015 at 07:57:27AM -0400, Robert Haas wrote:
> On Thu, Apr 30, 2015 at 9:34 PM, Bruce Momjian wrote:
> > On Wed, Mar 11, 2015 at 02:40:16PM +, Andrew Gierth wrote:
> >> An issue that comes up regularly on IRC is that text search queries,
> >> espe
15 3:11 napsal uživatel "Bruce Momjian" :
>
> On Tue, Mar 10, 2015 at 02:51:30PM -0400, Robert Haas wrote:
> > On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule
> wrote:
> > > 1. funcname_signature_string
> > > 2. get_rule_expr
> >
e order of 100.
> (With the default cpu_operator_cost that would make each to_tsvector
> call cost 0.25.)
>
> (The guy I was just helping on IRC was seeing a slowdown of 100x from a
> seqscan in a query that selected about 50 rows from about 500.)
Where are we on setting increasing procost f
, are you going to apply this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Apr 30, 2015 at 08:16:09AM -0700, Tom Lane wrote:
> Bruce Momjian writes:
> >>>> On 2015-02-25 12:08:32 -0500, Tom Lane wrote:
> >>>>> The most obvious fix is to change "provider" to a NAME column.
>
> > Where are we on this?
>
On Wed, Apr 29, 2015 at 11:59:26PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I have developed the attached patch to use platform-specific quoting of
> > path names.
>
> Part of me wonders about initdb's existing DIR_SEP and QUOTE_PATH
> definit
x27;re screwed if you've got different collations in different
> > databases and you put anything into pg_shseclabel ...
>
> Hrmpf.
Where are we on this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone
s a company large enough to have in-house counsel
> >(EnterpriseDB?) could get a quick legal opinion on the license
> >before we start pursuing other things? Perhaps this is just a
> >non-issue...
>
>
> The first para above was written by Dave Page, who works for EDB .
n come back to the precedence issues.
>
> > IIRC that's exactly what the earlier patch for this did.
>
> Right, see d809fd0008a2e26de463f47b7aba0365264078f3
Where are we on this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://
not to do this.
>
> The patch is weird, though. If I open it with "less", I get binary
> garbage. My Mac's TextEdit app opens it OK though.
The patch is encoded as utf-16le, and has MSDOS newlines, ^M.
--
Bruce Momjian http://momjian.us
Enterprise
be the same logic as in the other path, then how
> is it that !have_record_arg has anything to do with whether the JSON
> object is empty? Either the code is broken, or the comment is.
Where are we on this?
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Mon, Feb 16, 2015 at 05:03:45PM -0500, Bruce Momjian wrote:
> > All of our makefiles use single quotes, so effectively the only
> > character we don't support in directory paths is the single quote itself.
>
> This seems to say that Windows batch files don't ha
On Tue, Apr 28, 2015 at 09:15:49AM -0400, Bruce Momjian wrote:
> > It seems to me that waiting for 9.6 for what's arguably a bug fix is too
> > much. It's not like this is a new feature. Why don't we just make sure
> > it is as correct as possible and get i
gt;
> I noticed that one after hitting send. I think we should change them both.
Any news on this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list
ce-mapping
> > option:
> >
> > ibarwick:postgresql (master)$ mkdir /tmp//foo-old
> [...]
> > The attached patch adds the missing canonicalization; I can't see any
> > reason not to do this. Thoughts?
>
> Seems OK to me. Anyone think differently
On Fri, Apr 24, 2015 at 01:05:03PM -0400, Bruce Momjian wrote:
> This way, both pg_dump and pg_upgrade will issue warnings, though, of
> course, those warnings can be ignored. I am hopeful these two warnings
> will be sufficient and we will not need make these errors, with the
&
On Tue, Apr 28, 2015 at 12:46:22PM -0700, Tom Lane wrote:
> Bruce Momjian writes:
> > I know COPY doesn't support importing files with fixed column widths,
> > i.e. we can't say field1 is the first 30 characters, and field2 is the
> > rest of the line. We need
s to create a single-column foreign table that reads the
entire line as one field, then a view on top of that the parses the line
into fields, but that seems kind of complex.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyo
On Tue, Apr 28, 2015 at 12:24:50AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Agreed. Here is an attached patch for 9.6 which works for multiple
> > LIKE'ed tables with multiple inheritance and index creation. I figured
> > out why Tom's OID pri
d patch for 9.6 which works for multiple
LIKE'ed tables with multiple inheritance and index creation. I figured
out why Tom's OID primary key test was failing so I now process the
columns and LIKE first, then the constraints. There is also no longer a
dependency on default_with_oids.
es in the grammar.
> >
> > Yeah, having the WHERE outside the parens seems much nicer. What is
> > the ambiguity?
>
> I like having it outside the parens also.
Agreed, and I like the DO [ UPDATE | NOTHING ] too.
--
Bruce Momjian http://momjian.us
EnterpriseDB
sure there's any guarantee that
> default_with_oids can't change between parsing and execution of a CREATE
> TABLE command.
I have changed the default value back to the function call as it should
have been all along; patch attached. I will revisit this for 9.6
unless I hear other
are storing a table with rows that exceed 2KB in size
(aggregate size of each row) then the "Maximum number of rows in a
table" may be limited to 4 Billion, see TOAST.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprised
On Wed, Apr 22, 2015 at 10:41:02PM -0400, Bruce Momjian wrote:
> > josh=# create tablespace tbl2 location '/home/josh/pg94/data/pg_xlog/';
> > CREATE TABLESPACE
> >
> > It really seems like we ought to block *THAT*. Of course, if we block
> > tablespace c
for a field? 1 GB
Maximum number of rows in a table? unlimited
Maximum number of columns in a table? 250-1600 depending on column types
Maximum number of indexes on a table? unlimited
We don't report the maximum number of tables per database, or the
maximum number of
ge
> format updates in pg_upgrade before, and I don't want to get into
> that discussion here, but it's not trivial.
OK, good to know, thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own
e email on the same
topic. My only guess is that I normally say "attached" in that case so
"applied" just looked too similar. I will try to mix it up in the
future.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.
be so tiny as not to be worth caring about.
Agreed, no extra file, and the same write volume as currently. It would
also match pg_clog, which uses two bits per transaction --- maybe we can
reuse some of that code.
--
Bruce Momjian http://momjian.us
EnterpriseDB
use the space for anything else, or compress them
> or anything like that.
Also SELECT FOR UPDATE uses the per-row xmax too.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsq
dd 0.1% to the
> disk size. No doubt it would be nice to reduce our disk footprint,
> but the page header is not the elephant in the room.
Agreed. Are you saying we can't find a way to fit an 8-byte value into
the existing page in a backward-compatible way?
--
Bruce Momjian htt
OTHING is a good alternative. And I do like we're adding one
> keyword less (which is also good for the parser's
> size/performance).
No question that DO IGNORE sounds awkward. DO NOTHING also matches
CREATE RULE --- another plus.
--
Bruce Momjian http://momjian.us
Enterp
On Thu, Apr 23, 2015 at 05:05:14PM +0200, Andres Freund wrote:
> On 2015-04-23 11:00:43 -0400, Bruce Momjian wrote:
> > On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote:
> > > I think this is a good thing to do, but I sure wish we could go
> > > further and
On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote:
> On Wed, Apr 22, 2015 at 10:41 PM, Bruce Momjian wrote:
> >> What is a real problem is that we don't block creating tablespaces
> >> anywhere at all, including in obviously problematic places like the
>
that points to the same directory. We can't make it an
error so people can use pg_upgrade these setups. This would be for 9.5
only.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git
On Tue, Apr 21, 2015 at 05:36:41PM -0400, Robert Haas wrote:
> On Mon, Apr 20, 2015 at 5:41 PM, Bruce Momjian wrote:
> > On Mon, Apr 20, 2015 at 05:04:14PM -0400, Robert Haas wrote:
> >> On Mon, Apr 20, 2015 at 4:11 PM, Bruce Momjian wrote:
> >> > Slightly improved
On Wed, Apr 22, 2015 at 06:36:23PM -0500, Jim Nasby wrote:
> On 4/22/15 6:12 PM, Bruce Momjian wrote:
> >My point is that for the life of 200M transactions, you would have the
> >overhead of an additional file per table in the file system, and updates
> >of that. I just don&#
On Tue, Apr 21, 2015 at 08:39:37AM +0200, Andres Freund wrote:
> On 2015-04-20 17:13:29 -0400, Bruce Momjian wrote:
> > Didn't you think any of the TODO threads had workable solutions? And
> > don't expect adding an additional file per relation will be zero cost
> >
er adjustments to default number of autovac
> workers, I/O allocation, etc.
Do we really want to make vacuum more complex for this? vacuum does
have the delay settings we would need though.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterp
On Wed, Apr 22, 2015 at 04:36:17PM +0100, Greg Stark wrote:
> On Mon, Apr 20, 2015 at 8:48 PM, Bruce Momjian wrote:
> > Well, we have to assume there are many misconfigured configurations ---
> > autovacuum isn't super-easy to configure, so we can't just blame the
>
parts of a table. That would require a lot more sophisticated
> job management than we currently have for, say, autovacuum.
Well, the visibility map tells us where _not_ to clean up, so using
another map to tell use _where_ to cleanup might make sense. However,
the density of the map might
t; Well, for a big sequential scan, we use a ring buffer, so we will
> typically be evicting the pages that we ourselves read in moments
> before. So in this case we would do a lot of sequential writes of
> dirty pages.
Ah, yes, this again supports the prune-then-skip approach, rather tha
On Wed, Apr 22, 2015 at 09:18:40AM +0200, Andres Freund wrote:
> Peter, Michael,
>
> On 2015-04-22 16:13:15 +0900, Michael Paquier wrote:
> > All the patches have been committed, finishing the work on this thread.
>
> Many thanks for that effort!
And pg_upgrade thanks y
tive_*, that makes the correlation to active
> clear. active_pid then?
Let's call it active_procpid. (Runs for cover!)
(For background, see 9.2 release note item:
Rename pg_stat_activity.procpid to pid, to match other system tables
(Magnus
Hagander)
On Mon, Apr 20, 2015 at 07:13:38PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > >
> > > This seems simple to implement: keep two counters, where the
autovacuum would
> have kicked in instead of right after if finished?
>
>
> +1
You can +1 all you want, but if you ignore the specific workloads I
mentioned, you are not going to get much traction.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I think the limit has to be in terms of a percentage of the table size.
> > For example, if we do one SELECT on a table with all non-dirty pages, it
> > would be good to know t
On Mon, Apr 20, 2015 at 05:04:14PM -0400, Robert Haas wrote:
> On Mon, Apr 20, 2015 at 4:11 PM, Bruce Momjian wrote:
> > Slightly improved patch applied.
>
> Is it?
The patch has a slightly modified 'if' statement to check a constant
before calling a
on how to
> avoid freezing, and I think it's a safe bet that any ideas people do
> come up with there will be a lot more invasive than a FrozenMap is.
Didn't you think any of the TODO threads had workable solutions? And
don't expect adding an additional file per relat
On Thu, Apr 9, 2015 at 05:33:20PM -0400, Bruce Momjian wrote:
> On Thu, Apr 9, 2015 at 12:32:23PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > Should this be listed in the release notes as a backward-incompatibility?
> >
> > Isn't
901 - 1000 of 17339 matches
Mail list logo
