ll
the app methods at once and not even bother looking at the application
name?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hacke
criptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
write, fsync, close7626.783 ops/sec 131
usecs/op
write, close, fsync6492.697 ops/sec 154
usecs/op
Non-
docs (which is why I used it).
> Patch below.
I have developed the attached patch to fix this problem. Do I need to
say "invalid user or invalid or expired password"?
---
--
Bruce Momjian http://momjian.us
EnterpriseDB http://e
esql.org/message-id/51b59794.3000...@gmail.com
I think we would have to make Cygwin-specific regression output to
handle the regression failures, but frankly I am not even sure if they
are right.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://
On Thu, Jan 23, 2014 at 10:48:01PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Andrew, should this configuration/code patch be applied to 9.4?
>
> > http://www.postgresql.org/message-id/51b59794.3000...@gmail.com
>
> > I think we would have to make Cygwin
On Thu, Jan 23, 2014 at 10:39:34PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I have developed the attached patch to fix this problem. Do I need to
> > say "invalid user or invalid or expired password"?
>
> I'm not convinced that this improves anythi
On Fri, Jan 24, 2014 at 04:52:55PM -0500, Jaime Casanova wrote:
> On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian wrote:
> >
> > Is everyone else OK with this approach? Updated patch attached.
> >
>
> Hi,
>
> I started to look at this patch and i found that i
On Fri, Jan 24, 2014 at 10:10:00AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Jan 23, 2014 at 10:39:34PM -0500, Tom Lane wrote:
> >> I'm not convinced that this improves anything. The problem might not in
> >> fact be either of the things yo
mment there at all, it should be a
> succinct explanation for why we didn't do this (which passes `make
> check-world`):
Is everyone OK with me applying this patch from Kevin, attached?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://ente
On Sat, Jan 25, 2014 at 10:29:36PM +0100, Andres Freund wrote:
> On 2014-01-25 16:28:09 -0500, Bruce Momjian wrote:
> > On Tue, Jun 18, 2013 at 11:04:25AM -0700, Kevin Grittner wrote:
> > > D'Arcy J.M. Cain
> > >
> > > > Although, the more I think
> it will leak similarly to the original test case, but this time the
> leak is into the RELNAMENSP catcache.
>
> To fix that, I think we'll need to teach the catalog cache about the
> relationships between the caches.
Is this a TODO?
--
Bruce Momjian http://momji
t; dozen checks just like this around. If somebody wants to change the rules
> or improve comment it takes more than picking a random one.
OK, change made.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has thei
ld I be using for the bit map?
>
> Regards,
>
> Atri
>
> --
> Regards,
>
> Atri
> l'apprenant
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/m
On Sat, Jan 25, 2014 at 04:56:37PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sat, Jan 25, 2014 at 10:40:28PM +0100, Andres Freund wrote:
> >> I think this style of pinhole copy editing is pretty pointless. There's
> >> dozen checks just like this aro
IONS:
>
> a) Move the overflow checking just after the conversion of pg_tm -> Interval
> is
> made. This way, you can accurately predict if the result is really not
> store-able.
>
> b) Because of 1), you have to declare tm_hour as int64, if you want to use
> that
> fo
On Sun, Jan 26, 2014 at 02:13:03PM +0100, Florian Pflug wrote:
> On Jan26, 2014, at 03:50 , Bruce Momjian wrote:
> > Patch attached.
>
> > + if ((float)tm->tm_year * MONTHS_PER_YEAR + tm->tm_mon > INT_MAX)
> > + return -1;
>
> Is this bullet-
On Mon, Jan 27, 2014 at 04:47:22PM -0500, Bruce Momjian wrote:
> The updated attached patch has overflow detection for interval
> subtraction, multiply, and negate. There are also some comparison
> cleanups.
Oh, one odd thing about this patch. I found I needed to use INT64_MAX,
but I
On Mon, Jan 27, 2014 at 07:19:21PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Oh, one odd thing about this patch. I found I needed to use INT64_MAX,
> > but I don't see it used anywhere else in our codebase. Is this OK? Is
> > there a better way?
>
&g
we just need to rush out new versions to fix major
breakage and one-off GUCs just don't buy us much, and add confusion.
Does that make sense?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has thei
/*
--> * assume NULL if attnum is out of range according to the tupdesc
*/
if (attnum > tupleDesc->natts)
return true;
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Ev
ter definition was removed but corresponding
> prototype was still there.
>
>
>
> Attached is the patch to fix the same.
Thanks. Applied.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god
far larger problems with
9.3 than backward compatibility, and limited resources.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Tue, Jan 28, 2014 at 11:20:39AM -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-01-28 11:14:49 -0500, Bruce Momjian wrote:
> >> OK, so does anyone object to removing this comment line?
>
> > Let's just not do anything. This is change for changes sake
FATAL: configuration file "/u/pgsql/data/postgresql.conf" contains
errors
so, yeah, it isn't going to require an initdb, but it is going to
require everyone to edit their postgresql.conf. My guess is a lot of
people are going to assume the old postgresql.conf is not compa
On Tue, Jan 28, 2014 at 02:25:51PM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
> > On Tue, Jan 28, 2014 at 11:20:39AM -0500, Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2014-01-28 11:14:49 -0500, Bruce Momjian wrote:
> > > >&g
On Tue, Jan 28, 2014 at 07:30:47PM +0200, Heikki Linnakangas wrote:
> On 01/28/2014 07:26 PM, Bruce Momjian wrote:
> >On Tue, Jan 28, 2014 at 07:21:50PM +0200, Heikki Linnakangas wrote:
> >>>>I have no problem removing the parameter if required to. In that case,
> &g
ace imo. Without ever looking at more than one a few lines up/down
> especially.
I see what you mean that the identical comment appears in the same C
file. :-(
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their o
such as with the relative paths issue this patch is
> trying to address, or a datadir containing embedded quotes.
>
> I am eager to see the relative paths issue fixed, but maybe we need to
> bite the bullet and sort out the escaping of command-line options in
> the rest of pg_ct
to
$entab -t4 -qc -s3
we will no longer place a tab in this string, "friend. Hopefully"
--
even if there is a tab stop before the 'H'. It will use a 3-space
break. Does that help? Other ideas? How about requiring
On Thu, Jun 27, 2013 at 09:54:45PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Should we be using entab -s 3?
>
> IIUC, that wouldn't affect leading whitespace at all. What it would
> affect I think (outside of comment blocks) is whitespace between
On Tue, Jan 28, 2014 at 06:39:43PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > I see I already asked about entab -s 3. Let me see how hard it would be
> > to modify entab.
>
> I cannot tell you what to waste your time on, of course, but I wonder if
&g
On Tue, Jan 28, 2014 at 10:40:10PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I see I already asked about entab -s 3. Let me see how hard it would be
> > to modify entab.
>
> TBH I'm not sure we should be changing pgindent at this late date, even if
> ther
ck branches.
If it goes well, it could prove to be a way to incrementally improve
pgindent. If not, I am afraid we are stuck with our current pgindent
output.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their
On Wed, Jan 29, 2014 at 07:31:29PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I have cleaned up entab.c so I am ready to add a new option that removes
> > tabs from only comments. Would you like me to create that and provide a
> > diff at a URL? It would have to be
On Mon, Jan 27, 2014 at 10:48:16PM -0500, Bruce Momjian wrote:
> On Mon, Jan 27, 2014 at 07:19:21PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Oh, one odd thing about this patch. I found I needed to use INT64_MAX,
> > > but I don't see it used anywher
py_file(const char *fromfile, const char *tofile, bool
force);
...
...
...
#else
static intwin32_pghardlink(const char *src, const char *dst);
...
...
...
#endif
Ideas?
--
Bruce Momjian http://momjia
On Fri, Aug 9, 2013 at 09:12:03AM -0400, Robert Haas wrote:
> On Mon, Aug 5, 2013 at 4:53 PM, Dimitri Fontaine
> wrote:
> > Bruce Momjian writes:
> >> So do we want to keep that "AND" in the 9.3beta and 9.4 documentation?
> >
> > The grammar as in gr
On Thu, Jan 30, 2014 at 01:46:34PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
> >> I assert that we should simply remove both of these bits of code, as
> >> just about every committer on the project i
riods and post the results. I should be done in an hour.
--
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 you
On Thu, Jan 30, 2014 at 01:52:55PM -0500, Bruce Momjian wrote:
> On Thu, Jan 30, 2014 at 01:46:34PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
> > >> I assert that we should simply remove
On Thu, Jan 30, 2014 at 03:36:48PM -0500, Bruce Momjian wrote:
> On Thu, Jan 30, 2014 at 03:32:27PM -0500, Robert Haas wrote:
> > Or this:
> >
> > - mp_int_copy(a, b); /* ok: 0 <= r < b */
> > - mp_int_copy(&q, a); /* ok: q <= a */
>
It represents 3903 lines changed.
>
> That looks loads better.
OK. I have updated entab.c to support this new ability as -m. When
should it be run this against HEAD and supported back branches? Probably
when we run pgindent for 9.4. I will need to modify pgindent too
because thi
On Thu, Jan 30, 2014 at 11:44:31PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, seven hours later, I have fixed pg_bsd_indent to no longer insert
> > blank lines above #elif/#else/#endif, and therefore removed the special
> > case code from pgindent.
>
>
On Fri, Jan 31, 2014 at 11:18:17AM -0500, Bruce Momjian wrote:
> Yes, it is a shame pgindent has removed many proper empty lines in the
> past and there is no way to re-add them without causing backpatching
> problems.
FYI, the original BSD indent code that added the blank lines kin
sec << 12) | (getpid() & 0xfff). This would
> restore the intended ability to reverse-engineer the exact creation time
> from the sysidentifier, and also add a little more uniqueness by way of
> the creating process's PID. (Note tv_usec must fit in 20 bits.)
Can someone make a
already good enough, though maybe we could add a HINT
> suggesting that the DB was incompletely dropped.
>
> To ensure this is replayed properly on slave servers, I'd be inclined to
> mechanize it by (1) changing remove_dbtablespaces to ensure that the
> DB's default tabl
us. I am more
> worried about code that does range checks like java's string conversion
> routines...
>
> I think fixing this for 9.4 is fine, but due to the compat issues I
> think it's to late for 9.3.
Where are we on this? There was a posted patch, attached, but Vik
F
On Fri, Jan 31, 2014 at 11:57:28AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > OK. I have updated entab.c to support this new ability as -m. When
> > should it be run this against HEAD and supported back branches? Probably
> > when we run pgindent for 9.4.
>
>
hing
> like this patch would achieve this goal - it would fix something
> that's tripped a lot of people up over the years.
>
> Comments? If we do this, should it be backported?
Andrew, where are we on this?
--
Bruce Momjian http://momjian.us
EnterpriseDB
ven if there was one, because then I'd have to remember
> which typedef names to add each time I run pgindent.
Easily added, so done with the attached, applied patch. You use it
like this:
pgindent --list-of-typedefs 'abc def'
--
Bruce Momjian http://momjian.
ForeignPath *best_path,
> List *tlist,
> List *scan_clauses);
> is ridiculous. It can't be convinced to add a newline at any helpful
> place afaik.
Uh, not sure how to help here.
fied the list so
> someone else could have taken over.
OK, so that brings up a good question. Can we change the protocol for
this without causing major breakage? Tom seems to indicate that it can
be done for 9.4, but I thought protocol breakage was a major issue. Are
we really changing the wire
ADD to change an option's value.
>
> The "provided more than once" wording would be appropriate if the same
> option is specified more than once in the command text, but I'm not sure
> that it's worth the trouble to detect that case.
Where are on this?
-
mname
FROM pg_opfamily join pg_am ON (pg_opfamily.opfmethod = pg_am.oid)
ORDER BY 2, 1;
and you are right that the ones you mentioned were in the wrong section.
I also reordered a few so the entries in each section were in increasing
order.
Attached patch applied.
--
Bruc
ge-id/51fb6703.9090...@2ndquadrant.com
The patch mentioned in the text above was applied, I think.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers maili
tched, after
> removing
> the part about FOR NO KEY UPDATE and FOR KEY SHARE of course from the patch
> attached for 9.2 and prior versions...
> Regards,
Patch applied. Thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterp
the assert-change per se, an explanatory
> comment, and the test case that Noah devised to cause the current
> assertion to fail.
Is there any plan to commit this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone
On Fri, Jan 31, 2014 at 04:38:21PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote:
> >> Unfortunately, I gave up on it as being over my head when I noticed I
> >> was changing the protocol itself. I shoul
rom
int8_tbl offset 0) i8;
row_to_json
{"q1":123,"q2":456}
{"q1":123,"q2":4567890123456789}
{"q1":4567890123456789,"q2":123}
le by
> using the macro INTEGER_BTREE_FAM_OID.
Is this patch to be applied?
--
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 ch
xisting code failed to enforce that timeout during TCP connect,
> resulting in a hang far longer than two seconds if the LDAP server
> does not respond.
Where are we on this patch?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
t
> will only use that much and not waste 900 MB for useless
> preallocated WAL files.
Where are we on this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing
13-10-11 12:18:26 JST LOG: redo starts at 10/5028
> 2013-10-11 12:18:34 JST LOG: redo done at 10/655AE478
>
> 8s (compress)
> 2013-10-11 12:19:07 JST LOG: redo starts at 10/5028
> 2013-10-11 12:19:15 JST LOG: redo done at 10/655AE478
Fujii, are you still wor
rt where I
> got scared of what I was doing.
>
> It will have to wait until next week though; I am currently at FOSDEM.
OK, thanks. I thought it only required passing the int64 around until
it got into the string passed to the client. The original patch is in
the email archives if you want
ming in a
> >place outside of Makefile.shlib. That doesn't look right.
> >
> >
>
>
> Please suggest an alternative.
Did we ever address this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone
s server restarts. When recovery is
> !performed at server start (e.g. after immediate shutdown, server crash,
> !and point-in-time recovery), all statistics counters are reset.
>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Fri, Jan 31, 2014 at 09:28:06PM -0500, Andrew Dunstan wrote:
>
> On 01/31/2014 09:19 PM, Bruce Momjian wrote:
> >On Thu, Oct 10, 2013 at 11:00:30PM -0400, Andrew Dunstan wrote:
> >>On 10/10/2013 09:35 PM, Peter Eisentraut wrote:
> >>>On Tue, 2013-10-08 at
ata) instead of
>always copying the maximum size.
>
> I'd be nicer to get rid of the mostly copied HeapKeyTestArg, but I don't
> immediately see how.
Where are we on this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enter
e table size.
>
> Thoughts? Let the hurling of rotten tomatoes begin.
Robert, where are we on this? Should I post a patch?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent
, it would be nice to keep 'em consistent.
Agreed. Attached patch applied.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/bin/pg_dump/pg_restore.c b/src/bin/pg_dum
better code coverage if you started by
> inserting some NANs into an empty index.
>
> Also, as a stylistic matter, I thought your previous solution of
> copying float8_cmp_internal was a better idea than manually inlining it
> (sans comments!) in multiple places as this version
On Mon, Sep 9, 2013 at 07:39:00PM -0400, Bruce Momjian wrote:
> > In the case of tablespaces, I should have thought you could keep a
> > hash table of the names and just store an entry id in the table
> > structure. But that's just my speculation without actually looking
&g
And I might even be
> tempted to remove the table-level off switch.
Does this feature relate to compression of WAL page images at all?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
On Tue, Feb 4, 2014 at 08:11:18PM +0100, Andres Freund wrote:
> On 2014-02-04 14:09:57 -0500, Bruce Momjian wrote:
> > On Tue, Feb 4, 2014 at 01:28:38PM -0500, Robert Haas wrote:
> > > Meanwhile, in friendlier cases, like "one short and one long field, no
> >
eap tuple all-visible and the page not
all-visible check the other items on the page to see if the page can be
marked all-visible? Does analyze set pages all-visible?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has
n algorithm. If the compression algorithm issue is
resolved, can we move move forward with the full-page compression patch?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgs
dex-only
page-all-visible WAL overhead acceptable?
Do we want to track the number of inserts in statistics and trigger an
auto-vacuum after a specified number of inserts? The problem there is
that we really don't need to do any index cleanup, which is what vacuum
typically does --- w
On Tue, Feb 11, 2014 at 06:54:10PM +0100, Andres Freund wrote:
> On 2014-02-11 12:12:13 -0500, Bruce Momjian wrote:
> > Yes, that pretty much sums it up. We introduced index-only scans in 9.2
> > (2012) but they still seem to be not usable for insert-only workloads
> > two y
On Tue, Feb 11, 2014 at 07:31:03PM +0100, Andres Freund wrote:
> On 2014-02-11 13:23:19 -0500, Bruce Momjian wrote:
> > On Tue, Feb 11, 2014 at 06:54:10PM +0100, Andres Freund wrote:
> > > On 2014-02-11 12:12:13 -0500, Bruce Momjian wrote:
> > > > Yes, that pretty m
On Tue, Feb 11, 2014 at 01:54:48PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Feb 11, 2014 at 07:31:03PM +0100, Andres Freund wrote:
> >> I am not saying it shouldn't be improved, I just don't see the point of
> >> bringing it up while
ote Node B
> 3. Attach Node A as slave
>
> This is sufficient for my needs (I know it doesn't cover a crash), can anyone
> see any potential problems with this approach?
I know some people have used rsync to get A to match B after a crash of
A and promotion of B.
--
Bruce
/delete,
autovacuum will already trigger.)
We are aggressive in clearing the page-all-visible flag (we have to be),
but I think we need a little more aggressiveness for setting it.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.c
is is not intended to be a small change. However, some solution might be
> possible in post 9.4 gin improvements or in new secret indexing project which
> will be presented at PGCon :-)
Would any of the listed changes cause backward-incompatible changes to
the on-disk fo
e directly used for full-page
> compression, some ideas could be used or may be the algorithm could be
> tweaked a bit to make it usable for full-page compression.
Thanks, I understand that now.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://e
On Wed, Feb 12, 2014 at 10:08:26PM +0900, MauMau wrote:
> From: "Bruce Momjian"
> >On Mon, Dec 2, 2013 at 10:22:47PM +0900, MauMau wrote:
> >>So, my suggestion is to just add the following sentence right after
> >>the above one.
> >>
> >>The
and see if brolga starts failing.
> If it does, I'll be satisfied that we understand the issues here.
Can document the issue in case it comes up again, please?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has
On Mon, Feb 3, 2014 at 09:14:10PM -0500, Bruce Momjian wrote:
> On Mon, Sep 9, 2013 at 07:39:00PM -0400, Bruce Momjian wrote:
> > > In the case of tablespaces, I should have thought you could keep a
> > > hash table of the names and just store an entry id in the table
> &
or have other consequences that we don't
> foresee; thus, I would vote against back-patching it. Indeed, I'm not
> sure it's a good idea to do that even in master. On the other hand,
> tightening the checks in PGSharedMemoryCreate() seems very much worth
> doing, and I t
when
displaying disabled triggers:
Disabled user triggers:
check_update BEFORE UPDATE ON orders FOR EACH ROW EXECUTE PROCEDURE
trigf()
Disabled internal triggers:
"RI_ConstraintTrigger_c_16409" AFTER INSERT ON orders FROM customer
NOT DEF ...
s & PROC_IS_AUTOVACUUM) &&
> > !(autovac_pgxact->vacuumFlags &
> PROC_VACUUM_FOR_WRAPAROUND))
> > {
>
> Hmm, yeah. I remember noticing this some time ago but never got
> around to fixing it. +1 for rearrangi
it gets a lot more attention and
> testing than pg_upgrade.
>
> I'm not in favor of adding filesystem-specific tricks into
> pg_upgrade. It would be nice to list these tricks in the docs,
> though.
I have applied the attached patch which suggests the use of file system
snapshot
ntal, thinking they'd get the pipe, not the directory.
>
> > > Also, if we do that, is this something we should consider
> > > backpatchable? It's not strictly speaking a bugfix, but I'd say it
> > > fixes some seriously annoying behavior.
>
ix test isn't going
to get that either.
As I understand it, the only place prefix/suffix with LZ compression is
a win over prefix/suffix-only is when you change two middle fields, and
there are common fields unchanged between them. If we are looking at
11% CPU overhead for that, it isn
e attached patch which removes many of the pre-8.0
references, and trims some of the 8.1-8.3 references. There are
probably some of these that should be kept, but it is easier to show you
all the possibilities and we can trim down the removal list based on
feedback.
--
Bruce Momjian http://mo
On Fri, Oct 11, 2013 at 03:39:51PM -0700, Kevin Grittner wrote:
> Josh Berkus wrote:
> > On 10/11/2013 01:11 PM, Bruce Momjian wrote:
> >> In summary, I think we need to:
> >>
> >> * decide on new defaults for work_mem and maintenance_work_mem
> >> *
strcmp(buf, "\\.\r\n") == 0)
>
> Doesn't seem particularly friendly.
Yeah, that is ugly, and I was about to add a URL to a C comment myself
today.
I can set the column target width, but there doesn't seem to be any flag
that says
On Wed, Oct 16, 2013 at 02:17:11PM -0400, Bruce Momjian wrote:
> > > You can see the UTF8 case is fine because \n is considered greater
> > > than space, but in the C locale, where \n is less than space, the
> > > false return value shows the problem with
> >
> hba rules common to groupings of clusters.
>
> Anyway, please advise. I don't recall hearing anything like this
> discussed.
>
> Has been proposed, discussed and voted down? Or never mentioned?
I have never heard of anyone request this.
--
Bruce Momjian
7;GetFileAttributesEx' instead of stat, when I tried their
> suggestion, it also gives me same problem as stat.
>
> Still they have not told anything about other API's
> (rmdir, RemoveDirectory) which has same problem.
Where are we on this? Is there a check we should
gresql.conf includes, though
the last match wins there --- not sure if that makes it any easier.
I think one concern is that pg_hba.conf is more security-oriented than
postgresql.conf.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
601 - 700 of 17339 matches
Mail list logo
