son you think that these would all work
together nicely?
I don't know the specifics, but I understand there are numerous perils
to linking complex C++ code into complex C code, particularly around
exception handling. Look in the archives for previous discussions around
C++.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
here
> and it executed without any problems (I wrote/deleted 100 files).
> That's why I'm doubting that it's something related to postgreSQL.
>
>
> Any ideas on what's going wrong?
What code, exactly, did you change in md.c, and anywhere else in
postgres? Are
On Wed, 2012-03-14 at 10:26 +0100, Andres Freund wrote:
> On Wednesday, March 14, 2012 05:23:03 AM Jeff Davis wrote:
> > On Tue, 2012-03-13 at 09:42 +0100, Andres Freund wrote:
> > > for recursively everything in dir:
> > >posix_fadvise(fd, POSIX_FADV_DONTNEED);
&
se+sync: ~ 1.3s
Patch attached.
Now I feel much better about it. Most people will either have fadvise, a
write cache (rightly or wrongly), or actually need the sync. Those that
have none of those can use -N.
Regards,
Jeff Davis
initdb-fsync-20120313.patch.gz
Description: GNU Zip
#x27;s pretty inefficient considering that
initdb -D data --nosync && sync
only takes a couple seconds. Clearly batching the operation is a big
help. Maybe there's some more efficient way to fsync a lot of
files/directories? Or maybe I can mitigate it by avoiding files that
don&#
ransaction due to
> serialization failure involving a prepared transaction, we might want
> to include the prepared transaction's gid in the errdetail.
I like this idea.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
evelopers can
set. Or maybe developers don't care about 0.3s?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
se with fsync
> calls.
It looks like there are only a few places, so I don't think clutter is
really the problem with the simple patch at this point (unless there is
a portability problem with just calling fsync).
Regards,
Jeff Davis
initdb-fsync.patch.gz
Description: GNU Zip com
Marking "ready for committer", but please apply my comment fixes at your
discretion.
Regards,
Jeff Davis
PS: the test was run on my workstation (Intel(R) Core(TM) i7-2600 CPU @
3.40GHz) with work_mem=512MB, shared_buffers=512MB, and
checkpoint_segments=32. The rest of the setti
ink there would be a surprise factor if
sometimes initdb had a long pause at the end and caused 10GB of data to
be written out.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
olved
the problem, and I think it was only observed once (though I could
probably reproduce it if I tried). The symptom was a log message
indicating that PG_VERSION was missing or corrupt on a system that was
previously started and online (albeit briefly for a test).
Regards,
Jeff Davis
a platform-independent fsync be available at initdb time?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, 2011-12-27 at 16:43 -0600, Merlin Moncure wrote:
> On Tue, Dec 27, 2011 at 1:24 PM, Jeff Davis wrote:
> > 3. Attack hint bits problem.
>
> A large number of problems would go away if the current hint bit
> system could be replaced with something that did not requir
out).
3. Attack hint bits problem.
If (1) and (2) were complete, we would catch many common types of
corruption, and we'd be in a much better position to think clearly about
hint bits, double writes, etc.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
eue depth if there's some weird i/o scheduling going on.
That would also depend on how many disks you have and what configuration
they're in, right?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
s that support CRCs are more like ZFS than ext3. They do
all writes to a new location, thus fragmenting the files. That may be a
good trade-off for some people, but it's not free.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
overwrite your
previous (good) backup with a bad one. The more complicated we make the
verification process, the less workable that becomes.
I vote for a simple way to calculate the checksum -- fixed offsets of
each page (of course, it would need to know the page size), and a
standard checksum algor
g room for the future?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
lly dealing with widely varying range sizes, etc. My approach
really only tackled the simple (and hopefully common) case when the
ranges are about the same size.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ng the common entries does seem like a smaller
version of the original problem. Thoughts?
Thank you for the helpful comments! It took me a while to work through
the logic, but I would have been lost completely without the comments
around the double sorting split.
Regards,
Jeff Davis
*
sidered. Should it be?
* You defined get/set_range_contain_empty, but didn't use them. I think
this was a merge error, but I removed them. So now there are no changes
in rangetypes.c.
Regards,
Jeff Davis
range_gist_cleanup.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers
A built-in textrange type would have to have collation "C", right? Do
you think that would be useful to enough people?
One that I'd like to see is an IP address type, but that's complicated
because inet and cidr support netmasks.
Regards,
Jeff Davis
--
Sent via
that you've committed the flag for
"contains empty ranges".
However, it still sounds like a useful improvement to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
h conceptually, though I'm still working through the
details.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t be a constraint hierarchy; e.g. a step size 100 is based on a
step size of 10 which is based on numeric?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n either direction, just an
observation.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nvolve generating values that might overflow.
I think we had that discussion before, and Florian brought up some good
points (both then and in a reply now). Also, Robert wasn't convinced
that '[]' is necessarily better for discrete ranges:
http://archives.postgresql.org/p
don't seem to cause problems, but the utility is also very
minor.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to work. Seeing it as useful in the context of
range_adjacent might mean that it's useful elsewhere, too, so now I'm
leaning toward supporting [3,3) as an empty range.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On Fri, 2011-11-18 at 13:32 +0100, Florian Pflug wrote:
> That information, however, *is* already contained in the canonical
> functions, because those function know that (2,3) are empty as an integer
> range, but non-empty as a float range.
Very good point. Thank you.
Regards,
y a
mistake, and the user should be informed.
By the way, what does this have to do with canonical functions? This
seems more like a constructor issue, and there is already a
zero-argument constructor to make empty ranges.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsq
u want range_adjacent to work.
Thoughts?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ed to work out fairly well for most of the
operators, and it was the best that I came up with. The nice thing about
it is that it can compare a lower bound to another lower bound, or to an
upper bound. Then again, perhaps I tried to hard to unify those
concepts, and it just led to complexity?
I&#x
ypes within
> type categories...
>
> Thoughts?
That sounds reasonable to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
And to your original question, it seems that << and >> should be
commutators. Perhaps I had a reason earlier, but it is escaping me now.
What edge cases did you have in mind?
Regards,
Jeff Davis
cmp-bounds-2017.gz
Description: GNU Zip compressed data
--
Sent vi
Good point. That makes sense to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to confusion between NULL and the empty range, but it might be
better than marking it VOLATILE.
Thoughts, other ideas?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, 2011-11-07 at 10:18 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > I'm looking for known problem areas in btree_gist. I see:
> > http://archives.postgresql.org/message-id/8973.1286841...@sss.pgh.pa.us
>
> > With Range Types, I'm anticipatin
ome to mind? Or does btree_gist just need a good
review? Or have the problems been fixed?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nge" or "overlaps with another range".
Right now I don't have a very good answer, and even for the "contains a
point" case I'll have to think about the representation in pg_statistic.
Regards,
Jeff Davis
--
Sent via pgsql-hackers ma
hat before
> committing.
Thank you. The only change I found strange was the test that used \c to
reconnect; but I can't say that my solution was any better.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
el very intuitive to me, anyway. I'll just leave the empty(x)
> function.
That's fine with me. At best, they were only marginally useful.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t to be fairly consistent, and it was suggested that I model the
input parsing after the record parsing.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
at the time I was
slightly confused by it. I guess I just haven't seen that idiom before.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
omething simple?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a major concern a while ago:
http://archives.postgresql.org/message-id/28107.1291264...@sss.pgh.pa.us
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
loating around the code? I
know the single-xid cache is potentially vulnerable to xid wraparound
for the same reason.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 2011-10-19 at 10:10 -0700, Jeff Davis wrote:
> > dpkg-reconfigure locales
I had to manually do
# locale-gen tr_TR
to make it generate tr_TR.ISO-8859-9, and now it works.
I'm not sure what we should do, exactly, but I expect that others who
attempt to run the test on ubuntu
On Wed, 2011-10-19 at 11:44 +0300, Peter Eisentraut wrote:
> On tis, 2011-10-18 at 21:47 -0700, Jeff Davis wrote:
> > On Tue, 2011-10-18 at 22:25 +0300, Peter Eisentraut wrote:
> > > Presumably because Jeff doesn't have that particular locale installed.
> > &
ferent -- do you happen to know what package I need for just plain
tr_TR?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
/indexing.h:18:
../../../../src/include/access/htup.h:153:9: note: array 't_bits'
declared here
bits8 t_bits[1]; /* bitmap of NULLs --
VARIABLE LENGTH */
======
Regards,
Jeff Davis
--
Sent via pgsq
On Sun, 2011-10-16 at 16:00 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On master, I see a minor test error (at least on my machine) as well as
> > a diff. Patch attached.
>
> Hmm, yeah, I forgot to fix this regression test when I added that DETAIL
> line. However,
On Sun, 2011-10-16 at 14:43 -0700, Jeff Davis wrote:
> On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote:
>
> > The first thing caught my eye in existing GiST code is idea of
> > subtype_float. float8 has limited precision and can't respresent, for
> >
ave any other ideas to make that cleaner, please let me know.
Otherwise I'll just finish implementing subtype_diff.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On master, I see a minor test error (at least on my machine) as well as
a diff. Patch attached.
Regards,
Jeff Davis
*** a/src/test/regress/expected/collate.linux.utf8.out
--- b/src/test/regress/expected/collate.linux.utf8.out
***
*** 395,401 SELECT relname FROM pg_class
ight allow it to be more up-to-date.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
' thowing an error because
canonicalization would try to increment INT_MAX. But I'm not
particularly disturbed by it. If you want a bigger range, use int8range
or numrange -- the same advice we give to people who want unsigned
types. Or, for people who really need the entire range of signed int4
exac
nge. I could see how if the former
excluded the endpoint and the latter included it, it could be confusing.
We could go back to having different constructor names for different
inclusivity; e.g. int4range_cc(1,10). That at least removes the
awkwardness of typing (and seeing) '[]'.
Regard
objections to using '[]' as the default or
having the default vary between types. So, the only real option
remaining, if we do have a default, is '[)'.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
t seems like every idea I had was just short of practical. Maybe a few
extra characters at the end aren't so bad.
I'd like to hear from some potential users though to see if anyone
recoils at the common case.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
common use-case
for range types are for continuous ranges like timestamps. And (as I
pointed out in reply to Florian) there are good reasons to use the '[)'
convention for those cases.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
the constructor (hopefully in a convenient way).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
u suggesting that I canonicalize to '[]' then? That seems
reasonable to me, but there's still some slight awkwardness because
int4range(1,10) would be '[1,9]'.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gs" parameter that could
also be specified at type creation time that would control the default
third parameter (the parameter that controls inclusivity) of the
constructor. However, I removed the "default_flags" parameter because,
as Florian pointed out, it's better to have a c
ot exist
>
> Is this a problem? e.g. will it break the build-farm?
>
> "make check LANG=en_US" does pass
Thank you for pointing that out. I think I need to remove those before
commit, but I just wanted them in there now to exercise that part of the
code.
Is there a better
e limitation. I don't think my solution
handles it any better.
Regards,
Jeff Davis
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to make sure that unbounded ranges
are a part of the consideration.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;s not much sense reviewing/testing
it.
You may need to consider unbounded and empty ranges specially. I made an
attempt to do so in the current GiST code, and you might want to take a
look at that first. I'm not particularly attached to my approach, but we
should do something reasonable wi
functions produce, and stick with it.
That sounds reasonable to me. Unless someone objects, I'll make the
change in the next patch.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
SYMMETRIC keyword, so there is
> a precedent for this.
And I don't see it as valuable enough to justify changing the grammar.
Also, that still leaves confusion about inclusivity when applied to
range types.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hacke
, it's computed using "i". But that branch being followed is
dependent on a comparison with q->num_items. Maybe that's the dependency
that's not respected?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the reader prefetch the contents of the items array, without
knowing how big it is?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
special
<> : visually looks empty
- : also looks empty
{} : mathematical notation, but doesn't quite fit ranges
I don't have a strong opinion. I'd be OK with any of those.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
27;)
>
> are the same thing or not.
The unbounded side of a range is never equal to a value in the data
type's domain, so no, it's not the same.
I think that we pretty much settled on just using an empty string for
infinity in the other thread, right? So that makes this a non-is
since it'd be
> ambiguous whether '(X)' means range(X, NULL, '()') or range(NULL, X, '()').)
>
> One nice property is that, apart from the different brackets used, this
> representation is identical to the one used by records while still avoiding
> the
lcome.
> (I am also vaguely wondering what happens if if you have a text
> range is (nubile, null) ambiguous?)
There are a few ways to handle that. I would lean toward parsing the
NULL as a special keyword, and then rejecting it (does it matter if it's
upper case?).
Regards,
J
)')::text
>
> return
>
> '[0,Infinity)'?
I'm open to that, if you think it's an improvement I'll do it (but we
should probably pick one identifiable string and stick with it). What
I'd like to avoid is adding to the NULL/infinity confusion.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e constructors.
Underneath though, we don't use NULL semantics (because they don't make
sense for ranges -- in fact, avoiding the need to constantly
special-case NULLs is one of the reasons to use range types). So, we
want to avoid confusion where possible.
Regards,
Jeff
ne function to parse everything.
What about binary formats?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ly that you miss an error as save a
few keystrokes.
I'll add that it would also cause a little confusion with inclusivity.
What if you do: '[5,2)'::int4range? Is that really '[2,5)' or '(2,5]'?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ected by their internal collation, but don't take
part in the logic that passes collation through the type system.
Comments?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
orried about having the same column in pg_type mean two different
things -- every caller of get_typcollation would need to be careful.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ected by their internal collation, but don't take
part in the logic that passes collation through the type system.
Comments?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
On Wed, 2011-08-31 at 09:20 +0300, Heikki Linnakangas wrote:
> On 31.08.2011 09:14, Jeff Davis wrote:
> > First, a range is really a set. So if we take '[1,10)'::int4range and
> > cast that to numrange, we end up moving from a set of exactly 9 elements
> > to
of
values, which doesn't sound like a cast to me at all.
So, I'm leaning toward just not providing any casts from one range type
to another.
Thoughts?
Regards
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Fri, 2011-08-26 at 12:46 -0400, Robert Haas wrote:
> --sections='predata data'
> --sections='postdata'
> --sections='index'
Agreed. After command line options reach a certain level of complexity,
I think it's worth looking for a more general way t
ral declarative option like "BULKLOAD". We might then use that
information for a number of optimizations that make sense for large
loads.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
best idea after significant discussion:
http://archives.postgresql.org/pgsql-hackers/2011-06/msg02046.php
http://archives.postgresql.org/pgsql-hackers/2011-07/msg00210.php
* Send/recv functions
* cleanup
* documentation updates
Regards,
Jeff Davis
rangetypes-20110822.gz
Description: GNU Zip compre
would we call it?
"SET TRANSACTION SNAPSHOT" perhaps?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the user's standpoint what
kind of errors they might expect, and whether the session will remain in
a transaction block.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ething in-between.
Agreed.
Perhaps we need a new utility command to set the snapshot to make the
error handling a little more obvious?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
as a
> back-branch only doc patch.
Fine with me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
we could add the 9.0-specific note to 9.0 and 9.1 docs, but leave it
out of 'master'. That way it sticks around for a while but we don't have
to remember to remove it later.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Tue, 2011-08-09 at 14:52 -0400, Brian Pitts wrote:
> Attached is a patch against master which will cause a directory that
> contains only lost+found to still be treated as empty.
Please add this to the September commitfest at:
https://commitfest.postgresql.org/
Regards,
Jeff
e referenced discussion (10 years ago), Tom seemed OK with it and
Peter did not seem to like it much.
I think I agree with Peter here that it's not a very good idea, and I
don't see a big upside. With tablespaces it seems to make a little bit
more sense, but I'd still lean away fr
so perhaps this was
already discussed. ]
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ansaction can still write to many tables that way, and that could
mean many fsyncs.
Also, there may be a bunch of other transactions trying to write to the
WAL that have to wait as your transaction has to seek out to fsync the
data file and then seek back to the WAL.
Regards,
Jeff Davis
hat we want to avoid in every case we can.
But in the data load case (where many checkpoints may happen during a
single transaction anyway), it happens that avoiding WAL is a
performance win, because the seeks are not the dominant cost.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mai
d frozenxid during
the load.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
is a relation variable".
It's all a bit loose anyway, because SQL tables aren't really relations
or relation variables (for instance, they can contain duplicates).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
501 - 600 of 1617 matches
Mail list logo
