For a documentation patch should this not be back ported to all
relevant versions?
On 8/21/10, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
On further reflection, though: since we put in the BufferAccessStrategy
code, which was in 8.3, the background writer isn't *supposed* to
On Sat, Aug 21, 2010 at 1:00 PM, Greg Stark gsst...@mit.edu wrote:
On Sat, Aug 21, 2010 at 4:29 AM, Sergio A. Kessler
sergiokess...@gmail.com wrote:
on every single planet of the universe, except the one called
postgrearth, whose inhabitants breathe sql and eat messages from
postgresql
I noticed that we were already tracking the information about when an
autovacuum worker was last started in a database, but this information
was not exposed. The attached patch puts this column in
pg_stat_database.
Was there any particular reason why this wasn't exposed before that
I've missed,
(2010/08/22 0:20), Robert Haas wrote:
On Aug 20, 2010, at 8:27 PM, KaiGai Koheikai...@kaigai.gr.jp wrote:
(2010/08/20 23:34), Robert Haas wrote:
2010/8/19 KaiGai Koheikai...@ak.jp.nec.com:
I think our standard criteria for the inclusion of hooks is that you
must demonstrate that the hook can
Sure, I agree.
New patch attached. How about this?
On Fri, 20 Aug 2010 11:21:18 +0200
Magnus Hagander mag...@hagander.net wrote:
On Fri, Aug 20, 2010 at 01:01, Quan Zongliang quanzongli...@gmail.com wrote:
Because Windows's CreateService has serial start-type:
SERVICE_AUTO_START
Rob Wultsch wrote:
For a documentation patch should this not be back ported to all
relevant versions?
It is only a minor adjustment and I normally don't backpatch that.
---
On 8/21/10, Bruce Momjian br...@momjian.us
Magnus Hagander escreveu:
Was there any particular reason why this wasn't exposed before that
I've missed, making this a bad addition? :-)
Not that I know of. Good catch. ;)
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list
Bruce Momjian br...@momjian.us writes:
We often mention that we do vacuum freeze for anti-wraparound vacuum,
but not for pg_clog file removal, which is the primary trigger for
autovacuum vacuum freezing. I have added the attached documentation
patch for autovacuum_freeze_max_age;
On Sun, Aug 22, 2010 at 10:03:32PM +0800, Quan Zongliang wrote:
Sure, I agree.
New patch attached. How about this?
Docs re-added. Please not to leave these out in future patches. :)
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666
Magnus Hagander mag...@hagander.net writes:
I noticed that we were already tracking the information about when an
autovacuum worker was last started in a database, but this information
was not exposed. The attached patch puts this column in
pg_stat_database.
Was there any particular reason
Erik Rijkers e...@xs4all.nl writes:
If only for consistency, this patch adds the path info to that message.
Seems reasonable, but speaking of consistency:
+#ifdef WIN32
+ snprintf(WALFilePath, MAXPGPATH, %s\\%s,
archiveLocation, exclusiveCleanupFileName);
+#else
On lör, 2010-08-21 at 15:30 -0400, Tom Lane wrote:
The only thing that seems like it might need discussion is the name
to give the datatype. My first instinct was pg_expr or pg_expression,
but there are some cases where this doesn't exactly fit. In
particular,
pg_rewrite.ev_action contains
On Sun, Aug 22, 2010 at 17:29, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
I noticed that we were already tracking the information about when an
autovacuum worker was last started in a database, but this information
was not exposed. The attached patch puts
Magnus Hagander mag...@hagander.net writes:
On Sun, Aug 22, 2010 at 17:29, Tom Lane t...@sss.pgh.pa.us wrote:
So I'd like to see a positive argument why this is important for users
to know, rather than merely we should expose every conceivable detail
by default. Why wouldn't a user care more
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
We often mention that we do vacuum freeze for anti-wraparound vacuum,
but not for pg_clog file removal, which is the primary trigger for
autovacuum vacuum freezing. I have added the attached documentation
patch for
On tis, 2010-08-17 at 20:04 -0400, Stephen Frost wrote:
What I'm thinking of is something like a warning if the permissions on
the child don't match those of the parent when the relationship is
created, or maybe forcibly setting the permissions on the child (with
a
NOTICE), so it's at least
On Sun, August 22, 2010 17:54, Tom Lane wrote:
Erik Rijkers e...@xs4all.nl writes:
If only for consistency, this patch adds the path info to that message.
Seems reasonable, but speaking of consistency:
+#ifdef WIN32
+snprintf(WALFilePath, MAXPGPATH, %s\\%s,
I just noticed that we are now advertising the ability to insert UTF16
surrogate pairs in strings and identifiers (see section 4.1.2.2 in
current docs, in particular). Is this really wise? I thought that
surrogate pairs were specifically prohibited in UTF8 strings, because
of the security
* Peter Eisentraut (pete...@gmx.net) wrote:
I think there are perfectly good reasons to have different permissions
on parent and child tables. I don't see any reason to monkey around
with that.
Even though the permissions on the child table aren't invovled at all if
queried through the
On sön, 2010-08-22 at 14:29 -0400, Tom Lane wrote:
I just noticed that we are now advertising the ability to insert UTF16
surrogate pairs in strings and identifiers (see section 4.1.2.2 in
current docs, in particular). Is this really wise? I thought that
surrogate pairs were specifically
Peter Eisentraut pete...@gmx.net writes:
On sön, 2010-08-22 at 14:29 -0400, Tom Lane wrote:
I just noticed that we are now advertising the ability to insert UTF16
surrogate pairs in strings and identifiers (see section 4.1.2.2 in
current docs, in particular). Is this really wise? I thought
On sön, 2010-08-22 at 15:08 -0400, Stephen Frost wrote:
* Peter Eisentraut (pete...@gmx.net) wrote:
I think there are perfectly good reasons to have different permissions
on parent and child tables. I don't see any reason to monkey around
with that.
Even though the permissions on the
* Peter Eisentraut (pete...@gmx.net) wrote:
On sön, 2010-08-22 at 15:08 -0400, Stephen Frost wrote:
Even though the permissions on the child table aren't invovled at all if
queried through the parent..? The parent implicitly adds to the set of
privileges which are granted on the child, but
Erik Rijkers e...@xs4all.nl writes:
yes, I agree that's better; attached is that change.
Looks good, applied to HEAD and 9.0. (I also snuck in a couple of
cosmetic cleanups while I was looking at the file.)
regards, tom lane
--
Sent via pgsql-hackers mailing list
24 matches
Mail list logo
