On Mon, Aug 12, 2013 at 04:58:23PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > We did have someone confused by what we have now, as well as me, so I
> > think there is a reason to clean this up. It would be a
> > backward-compatible change, though.
>
> backward
On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote:
> Attached are docs that add the new syntax, and mention it is
> non-standard; you can see the output here:
>
> http://momjian.us/tmp/pgsql/functions-string.html#FUNCTIONS-STRING-SQL
>
> We do document
PG 9.3; from the release notes:
Allow the psql --single-transaction mode to work when
reading from standard input (Fabien Coelho, Robert Haas)
Previously this option only worked when reading from a file.
--
Bruce Momjian http://momjian.us
EnterpriseD
On Fri, Aug 9, 2013 at 02:15:31PM -0400, Bruce Momjian wrote:
> > Well, it's certainly not immediately obvious why we shouldn't merge them.
> > But I would have expected the function's header comment to now explain
> > that the output is intentionally not sche
ion of Object Manipulation rather than in that of Additional
> Modules. Please find attached a patch.
Agreed, done.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
S
lowing line (on or
> > around line 374)
> > #define HAVE_POSIX_FALLOCATE 1
> >
> > *then* build postgresql and see if the performance hit is still there.
>
> Okay, done that. The TPS increases again:
>
> 2308.807568 / 2554.264572 / 2563.190204
>
> And I did run
On Mon, Aug 12, 2013 at 11:31:38PM -0400, Bruce Momjian wrote:
> On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote:
> > Attached are docs that add the new syntax, and mention it is
> > non-standard; you can see the output here:
> >
> > http://mom
On Mon, Aug 12, 2013 at 04:44:12PM -0400, Bruce Momjian wrote:
> On Mon, Aug 12, 2013 at 10:08:07PM +0200, Pavel Raiskup wrote:
> > > The patch moves the atexit setting up, as you suggested, but only does
> > > that when pg_ctl succeeds (we know we started the server),
&g
p before the usual write-zeroes-in-a-loop
> approach) not only doesn't seem to hurt performance, it seems to help
> or at least have parity, *and* the space is guaranteed to exist on
> disk. At the very least that seems useful.
Is it time to revert this patch until we know more?
--
You could also create a binary in
their home directory and have .profile run it. (I thought this was a
particularly creative exploit.)
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be t
On Mon, Aug 19, 2013 at 01:38:13PM +0900, Etsuro Fujita wrote:
> > From: 'Bruce Momjian' [mailto:br...@momjian.us]
>
> > On Tue, Aug 13, 2013 at 05:59:05PM +0900, Etsuro Fujita wrote:
> > > > Thanks for the many suggestions on improving the 9.3 release notes.
people's scripts for no good reason, if people are
> creating the $PGDATA/promote file themselves without using pg_ctl.
>
> (I raised this back in April, but Simon argued strongly for the
> current situation. I never understood why.
> http://www.postgresql.org/me
On Mon, Aug 19, 2013 at 01:27:29PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Aug 19, 2013 at 11:20:42AM +0300, Heikki Linnakangas wrote:
> >> I think "promote" file should trigger the fast promotion, and the
> >> filename to t
On Mon, Aug 19, 2013 at 11:44:36PM +0200, Dimitri Fontaine wrote:
> Bruce Momjian writes:
> > That's pretty vague. Exactly what does "keys to the kingdom" mean? If
> > it means you can do anything to the database, you are right. If it
> > means executing
should.
>
> Definitely interested in what Ts'o says, but if we can't figure out why
> it's slower *without* writing out the zeros, I'd say we punt on this
> until Linux and the other OS folks improve the situation.
Agreed. Anyone with an affected kernel really
x27;#include'.
Just a heads-up, but a lot of C language folks are going to look at:
#include abc
and think that is enabled.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Wed, Aug 21, 2013 at 12:32:20PM +0200, Vik Fearing wrote:
> On 08/14/2013 11:27 PM, Bruce Momjian wrote:
> > On Mon, Aug 12, 2013 at 11:31:38PM -0400, Bruce Momjian wrote:
> >> On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote:
> >>> Attached are doc
lue equal to 'config_file', which
is normally postgresql.conf. I am not a big fan of looking for special
text in files. This might be complex to check, though, because of path
changes --- we might just disallow the basement from matching the
basename of config_file.
--
Bruce Momjian
tem
identifier. We don't allow cross-major-version replication, so I am
confused why we can't rename it in 9.4.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
for this special case can be costly and moreover the
> specs for this patch were layout from beginning that way.
Agreed. If you are worried about ALTER SYSTEM changing postgresql.conf
settings, you should move the include_auto line to the top of
postgresql.conf, but I don't t
s this way.
>
> Another thing that needs to be taken into account here is Oleg and
> Teodor's in-progress work on extending hstore:
> https://www.pgcon.org/2013/schedule/events/518.en.html
> I'm not sure if this patch would conflict with that at all, but it
> needs to be con
On Wed, Aug 28, 2013 at 02:30:41PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
> > > > I really hate the idea that someone could configure 'X' in
> > > > postgr
On Wed, Aug 28, 2013 at 03:15:14PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > Agreed, but I think this is a much larger issue than ALTER SYSTEM SET.
>
> Yeah, true.
>
> > I think changing behavior to first-seen would only add to confus
s too tied to specific database
implementations, but there are general channels, like insert with a
unique key, that should at least have well-defined solutions.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impos
but here is seems the value of the feature itself, security, is not
attainable. Perhaps reasonable security is attainable.
I am not saying we should reject this feature --- just that the calculus
of how we decide to add this feature doesn't fit our normal analysis.
--
Bruce Momjian
* those reads to steal the cache line containing Curr/PrevBytePos.
> + */
> + charpad[128];
Do we adjust for cache line lengths anywhere else? PGPROC? Should it
be a global define?
--
Bruce Momjian http://momjian.us
EnterpriseDB htt
t; >
>
> This matches my experience as well - people certainly use it, but don't change
> it during runtime.
>
> Not having looked at the code, but doesn't pg_start_backup use at least parts
> of the same code path? That one will definitely still be able to modify it
On Fri, Jul 5, 2013 at 10:21:19AM -0400, Bruce Momjian wrote:
> On Thu, Jul 4, 2013 at 04:29:20PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I developed the attached patch which properly recurses into ROW()
> > > records checking for NULLs; you can see
On Tue, Sep 3, 2013 at 09:43:14PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > This has made me adjust my goal and change it so SELECT ROW(NULL) IS
> > NULL returns true, and any further nesting returns false.
>
> AFAICS, the only good argument for breaking backwar
> ("(""()"")")
> (1 row)
Uh, I see the same output you show for a NULL constant:
SELECT ROW(NULL);
row
-
()
SELECT ROW(ROW(NULL));
row
----
("()")
ocument the behavior we currently have? What I _think_ we have now
is that IS NULL in queries checks two levels deep for nulls, but checks
only one level deep for PL/pgSQL and constraints.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
g used after an ANALYZE, it isn't a bad
allvisibile estimate but something else. This code was in PG 9.2.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent vi
implements an auto-tuned
effective_cache_size which is 4x the size of shared buffers. I had to
set effective_cache_size to its old 128MB default so the EXPLAIN
regression tests would pass unchanged.
I considered a new available_ram variable but that just gives us another
variab
On Tue, Sep 3, 2013 at 09:32:44PM -0400, Bruce Momjian wrote:
> In this test, SELECT NULL (which internally would produce SELECT
> ROW(NULL)), returns TRUE, while SELECT ROW(NULL) and further nesting
> returns false.
>
> This has made me adjust my goal and change it so SELECT ROW(
should give reasonable
results in most cases.
I am fine with rewording and not using -1, but we should change the
wal_buffer default and documentation too then. I am not sure what other
value than -1 to use? 0? I figure if we ever get better auto-tuning,
we would just rem
On Thu, Sep 5, 2013 at 02:14:39PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Sep 4, 2013 at 9:26 PM, Bruce Momjian wrote:
> >> I have not heard any feedback on this patch, so I would like to apply it
> >> to give us a nested ROW/IS NULL API we can
On Thu, Sep 5, 2013 at 12:48:54PM -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Sep 5, 2013 at 3:01 AM, Bruce Momjian wrote:
> >> I have developed the attached patch which implements an auto-tuned
> >> effective_cache_size which is 4x the size o
should.
>
> Definitely interested in what Ts'o says, but if we can't figure out why
> it's slower *without* writing out the zeros, I'd say we punt on this
> until Linux and the other OS folks improve the situation.
FYI, the patch has been reverted.
--
Bruc
On Thu, Sep 5, 2013 at 03:11:53PM -0700, Josh Berkus wrote:
> On 09/05/2013 02:16 PM, Bruce Momjian wrote:
> >> Well, the real problem with this patch is that it documents what the
> >> auto-tuning algorithm is; without that commitment, just saying "-1 means
&g
On Wed, Sep 4, 2013 at 04:56:55PM -0400, Bruce Momjian wrote:
> > "Add a column pg_class.relallvisible to remember the number of pages
> > that were all-visible according to the visibility map as of the last
> > VACUUM
> > (or ANALYZE, or some other operations
On Thu, Sep 5, 2013 at 09:10:06PM -0400, Robert Haas wrote:
> On Thu, Sep 5, 2013 at 8:14 PM, Bruce Momjian wrote:
> > Actually, I now realize it is more complex than that, and worse. There
> > are several questions to study to understand when pg_class.relallvisible
> >
ideal case
(static data) doesn't get vm-bits set, while update/delete has the
vm-bits set, but then cleared as more update/deletes occur.
The more I look at this the worse it appears. How has this gone
unaddressed for over a year?
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Fri, Sep 6, 2013 at 01:01:59PM -0400, Bruce Momjian wrote:
> This December 2012 thread by Andrew Dunstan shows he wasn't aware that a
> manual VACUUM was required for index-only scans. That thread ended with
> us realizing that pg_upgrade's ANALYZE runs will populate
>
. You make a good
point that 5 minutes passing is meaningless --- you really want to know
how many transactions have completed. Unfortunately, our virtual
transactions make that hard to compute.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterpr
On Fri, Sep 6, 2013 at 06:36:47PM +0200, Andres Freund wrote:
> On 2013-09-06 12:30:56 -0400, Bruce Momjian wrote:
> > > I am not sure I understand this though. What would be the point to go
> > > and set all visible and not do the rest of the vacuuming work?
> >
On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> Another possible fix would be to avoid the IS NULL value optimizer
> expansion if a ROW construct is inside a ROW(). I have attached a patch
> that does this for review.
Having received no replies, do people perfer this v
On Fri, Sep 6, 2013 at 11:00:24PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> >> Another possible fix would be to avoid the IS NULL value optimizer
> >> expansion if a ROW construct is inside
On Sat, Sep 7, 2013 at 07:42:55AM +0200, Andres Freund wrote:
> On 2013-09-06 23:07:04 -0400, Bruce Momjian wrote:
> > On Fri, Sep 6, 2013 at 11:00:24PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce M
On Sat, Sep 7, 2013 at 10:59:08AM -0400, Bruce Momjian wrote:
> My original problem report was November, 2012:
>
> http://www.postgresql.org/message-id/50b3d11f.20...@2ndquadrant.com
>
> and my patch to fix this was July 4. Tom gave me a code snipped to test
> PL/p
en the last vacuum, we can even vacuum if inserts happened in that
period because we assume the inserts are on new pages. One problem
there is that the FSM is only updated if an insert will not fit on the
page. We could record the table size and make sure the table size has
increased before we a
view, which seems a
> > tad silly.
>
> I agree it would make sense to change this.
Is this the patch you want applied? The docs are fine?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for
es: first one is at
> http://www.postgresql.org/message-id/510100aa.4050...@gmail.com and you
> can see the others in the dropdown (though since the subjects are not
> shown, only date and author, it's a bit hard to follow. The "flat" URL
> is useful.)
Should these patch
On Sun, Sep 8, 2013 at 12:47:35AM +0200, Andres Freund wrote:
> Hi,
>
> On 2013-09-07 12:50:59 -0400, Bruce Momjian wrote:
> > That seems very complicated. I think it would be enough to record the
> > current xid at the time of the vacuum, and when testing for later
>
On Mon, Sep 9, 2013 at 12:37:25PM -0400, Robert Haas wrote:
> On Sat, Sep 7, 2013 at 10:59 AM, Bruce Momjian wrote:
> >> Why don't you add the proposal to the commitfest?
> >
> > This issue is so much larger than the patch's validity that I don't see
>
er of objects, but never thought to look at memory
usage. It would be a big win to just palloc/pfree the memory, rather
than allocate tones of memory. If you don't get to it, I will in a few
weeks.
--
Bruce Momjian http://momjian.us
EnterpriseDB
rote history to file ".//tmp/history.txt".
pgdevel=# \cd /tmp
pgdevel=# \s /tmp/history.txt
Wrote history to file "/tmp//tmp/history.txt".
Should I revert the suggested patch?
--
Bruce Momjian http://momjian.us
EnterpriseDB http
gestion would be setting their effective_cache_size to 100% of RAM?
If we go with 4x, which I believe was the majority opinion, what shall
we answer to someone who asks about this contradiction?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enter
On Tue, Sep 10, 2013 at 08:45:14AM -0400, Robert Haas wrote:
> On Mon, Sep 9, 2013 at 3:51 PM, Bruce Momjian wrote:
> > The problem is that I don't believe this patch is commit-ready ---
> > someone needs to research the IS NULL tests in all areas of our code to
> > se
; coalesce() does) and document our divergence from the standard. Point
> being: B might actually be the best choice, but it should be
> understood that we are not going in that direction before pushing
> patches that go in the other direction.
I see. So going one-level deep in the
On Tue, Sep 10, 2013 at 10:50:32AM -0400, Bruce Momjian wrote:
> > have to hit all the targets. If not, I'd either A: leave things alone
> > or B: remove the special case logic in IS NULL (so that it behaves as
> > coalesce() does) and document our divergence from the sta
On Tue, Sep 10, 2013 at 12:48:08PM -0700, Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > FYI, I think these queries below prove that NOT NULL constraints do not
> > follow the single-depth ROW NULL inspection rule that PL/pgSQL follows,
> > and that my patch was tryin
, Sync will not close any portals. For an
implicit transaction, I assume Sync will close all portals except FOR
HOLD named portals. Is this not how it behaves?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossibl
el;
ERROR: RESET TRANSACTION can only be used in transaction blocks
test=> set local effective_cache_size = '3MB';
ERROR: SET LOCAL can only be used in transaction blocks
test=> set local effective_cache_size = default;
ERROR: SET LOCAL can onl
would be better to allow for 2). Attached
> is a
> patch.
Modified, attached patch applied. Thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/bin/
id = get_ts_dict_oid(stringToQualifiedNameList("unaccent"), false);
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/contrib/unaccent/unaccent--1.0.sql b/contrib
_1B(PTR)-VARHDRSZ_SHORT : \
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian http://momjian.us
EnterpriseDB
earch for a replacement and came up with this:
> http://drdobbs.com/184401251
>
> If that link points to the same content, we could use it
> instead of the broken one.
Applied, thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://en
ument in favor: this is a default setting, and by default,
> shared_buffers won't be 25% of RAM.
So, are you saying you like 4x now?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Wed, Sep 11, 2013 at 09:18:30AM -0400, Bruce Momjian wrote:
> On Tue, Sep 10, 2013 at 03:08:24PM -0700, Josh Berkus wrote:
> > Merlin,
> >
> > > I vote 4x on the basis that for this setting (unlike almost all the
> > > other memory settings) the rami
On Wed, Sep 11, 2013 at 12:43:07PM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
>
> > > So, are you saying you like 4x now?
> >
> > Here is an arugment for 3x. First, using the documented 25% of RAM, 3x
> > puts our effective_cache_size as 75% of RAM,
might want to create the REINDEX script to allow _optional_
reindexing to shrink the index files.
If we do require the REINDEX, --check will clearly warn the user that
this will be required.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterpris
;3MB';
> > ERROR: SET LOCAL can only be used in transaction blocks
> > test=> set local effective_cache_size = default;
> > ERROR: SET LOCAL can only be used in transaction blocks
>
> Shouldn't we do it for Set Constraints as well?
Oh, very
og lookup - not a reliance on external data.
Sorry, I was wrong. Only unaccent_dict() calls get_ts_dict_oid(), and
we aren't changing the signature of that function.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It&
matching row _before_ adding any data?
Our test-and-set code first checks to see if the lock is free, then if
it it is, it locks the bus and does a test-and-set. Couldn't we easily
check the indexes for matches before doing any locking? It seems that
would avoid bloat in most cases, and allow
On Wed, Sep 25, 2013 at 08:48:11PM -0700, Peter Geoghegan wrote:
> On Wed, Sep 25, 2013 at 8:19 PM, Bruce Momjian wrote:
> > This thread had a lot of discussion about bloating. I wonder, does the
> > code check to see if there is a matching row _before_ adding any data?
>
&g
On Thu, Sep 26, 2013 at 07:43:15AM -0400, Bruce Momjian wrote:
> On Wed, Sep 25, 2013 at 08:48:11PM -0700, Peter Geoghegan wrote:
> > On Wed, Sep 25, 2013 at 8:19 PM, Bruce Momjian wrote:
> > > This thread had a lot of discussion about bloating. I wonder, does the
> >
I assumed the code was going to do the index lookups first without a
lock, and take the appropriate action, insert or update, with fallbacks
for guessing wrong.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible
the ability
to compare rows binarily, e.g. for replication, and adding these
operators would help with that.
I think we need to see a patch from Kevin that shows all the row
comparisons documented and we can see the impact of the user-visibile
part.
One interesting approach would be to only allo
gt; In pg_upgrade, there is a similar case with the pg_log() function.
> Since that isn't a public API, I'm proposing to change it and introduce
> a separate function pg_fatal() for those cases where the calls don't
> return.
Fine with me.
--
Bruce Momjian
On Thu, Sep 26, 2013 at 05:50:08PM -0400, Bruce Momjian wrote:
> I think we need to see a patch from Kevin that shows all the row
> comparisons documented and we can see the impact of the user-visibile
> part.
>
> One interesting approach would be to only allow the operator to b
ionChain(isTopLevel, "SET TRANSACTION");
>
> if (stmt->is_local)
> ereport(ERROR,
> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> errmsg("SET LOCAL TRANSACTION SNAPSHOT is not implemented")));
> ..
> }
> ..
> ..
> }
>
> Wouldn't it be better if
e more of an "internal" operator.
> > It would also be good to know about similar non-default entries
> > in pg_opclass so we can understand the expected impact.
>
> A quick query (lacking schema information and schema qualification)
> shows what is there by default:
OK, the unique list is:
I see a few cases of this code in src/backend/utils/adt/datetime.c:
else if ((fmask & DTK_DATE_M) != DTK_DATE_M)
Wouldn't this be clearer as:
else if (fmask & DTK_DATE_M)
--
Bruce Momjian http://momjian.us
EnterpriseDB http://ent
On Tue, Oct 1, 2013 at 05:17:35PM +0200, Andres Freund wrote:
> On 2013-10-01 11:15:36 -0400, Bruce Momjian wrote:
> > I see a few cases of this code in src/backend/utils/adt/datetime.c:
> >
> > else if ((fmask & DTK_DATE_M) != DTK_DATE_M)
> >
used your date/time test to control the
other cases. I also added a few more regression tests.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/backend/utils/adt/da
positioning our code on a slow decline
in clarity.
What I don't want to do is get into a mode where every code cleanup has
to be verified that it isn't going to excessively burden outside code
users. Cleanup is hard enough, and adding another check to that process
m
On Wed, Oct 2, 2013 at 08:59:42AM -0400, Noah Misch wrote:
> On Tue, Oct 01, 2013 at 10:12:05PM -0400, Bruce Momjian wrote:
> > If we had not made massive cleanup changes years ago, our code would not
> > be as good as it is today. By avoiding cleanup to reduce the burden on
>
On Mon, Sep 23, 2013 at 12:40:06AM +0400, Oleg Bartunov wrote:
> I found in my archives several logos. The oldest one comes from postgres95
> time. I recall that logo with cheetah was made by Bruce (?)
No, I don't remember who did that cheetah.
--
Bruce Momjian http:/
On Wed, Oct 2, 2013 at 11:00:30AM -0400, Robert Haas wrote:
> On Tue, Oct 1, 2013 at 7:52 PM, Bruce Momjian wrote:
> > On Fri, Sep 27, 2013 at 10:42:17AM +, Haribabu kommi wrote:
> >> If the changes are very high to deal all scenarios,
> >>
> >> I feel
it or find out the mechanisms
> ZFS uses for cloning. On btrfs cloning is implemented with a custom
> btrfs-specific ioctl, ZFS probably has something similar which would
> be pretty easy to add on top of this patch.
>
> Added this patch to commitfest as suggested,
> https://commitf
ch shared by you with various test and so far it looks good to
> me.
>
> I would like reviewer to review/test the patch and share his comments.
>
> Attaching the git patch again with this mail.
>
> Assigning to Reviewer.
Oh, great. If everyone likes it I can apply it.
--
> for detection of transaction chain as well.
I am also worried about over-engineering this. I will wait to see if
anyone else would find top-level detection useful, and if not, I will
just apply my version of that patch that does not handle set_config.
--
Bruce Momjian http://mo
On Thu, Oct 3, 2013 at 09:59:03AM -0400, Steve Singer wrote:
> Are there any outstanding issues on this patch preventing it from
> being committed?
I have not received answers to my email of October 1:
http://www.postgresql.org/message-id/20131001024620.gb13...@momjian.us
--
e new GIN indexes will be
smaller so most people would want the new format in the new cluster
anyway.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hac
Ideally any new GIN index should be GIN2 and reindex turns GIN1 into GIN2.
I am not sure I like the complexity of a GIN2, but we should give this
problem some serious thought as it will affect how we deal with other
on-disk index changes in the future.
--
Bruce Momjian h
On Fri, Oct 4, 2013 at 09:40:38AM +0530, Amit Kapila wrote:
> On Thu, Oct 3, 2013 at 8:35 PM, Andres Freund wrote:
> > On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote:
> >> On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
> >> > >> Shouldn&#x
On Fri, Oct 4, 2013 at 10:19:38AM +, Haribabu kommi wrote:
>
> On 03 October 2013 19:30 Bruce Momjian wrote:
> >On Thu, Oct 3, 2013 at 11:54:14AM +0530, Rushabh Lathia wrote:
> >> Thanks Bruce.
> >>
> >> Yes for me main problem was to make assumptio
Does btrfs support file system snapshots? If so, shouldn't people just
take a snapshot of the old data directory before the ugprade, rather
than using cloning?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossi
emcmp), it adds
> ~>~, ~>=~, ~<~, and ~<=~ operators which also use memcmp (ignoring
> character encoding and collation).
OK, my questions have been answered and I am no longer concerned about
this patch causing "equality" confusion for our users.
--
Bruce Momjian
ng an error
on a clear 5-digit year seems odd.
On the other hand, this has never come up before because no one cared
about 5-digit years, so you could argue that 5-digit years require
precise specification, which would favor throwing an error.
--
Bruce Momjian http://momjian.us
Ent
801 - 900 of 17339 matches
Mail list logo
