On Oct 28, 2011 5:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Stephen Frost wrote:
Yes, they would have removed it because they didn't want it. As I
recall, part of the agreement to create an extra database by default
was
that it could be removed if
On Oct 28, 2011 5:19 AM, Bruce Momjian br...@momjian.us wrote:
Stephen Frost wrote:
Regarding pg_dumpall and pg_restore, I'm pretty sure both of those
can
be configured to connect to other databases instead, including for
globals.
Well, please show me the code, because the C
On Thu, Oct 27, 2011 at 11:14 PM, Magnus Hagander mag...@hagander.net wrote:
Here's a version that does this. Turns out this requires a lot less
code than what was previously in there, which is always nice.
We still need to solve the other part which is how to deal with the
partial files on
On Thu, Oct 27, 2011 at 11:57 PM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Oct 27, 2011 at 16:54, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Oct 27, 2011 at 13:19, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 27.10.2011
2011/10/28 Tom Lane t...@sss.pgh.pa.us:
Stephen Frost sfr...@snowman.net writes:
Was just wondering if we might want to include the default socket
directory that was compiled in as part of the pg_config output..?
[ shrug... ] We don't report the compiled-in port number, which is
* Tom Lane (t...@sss.pgh.pa.us) wrote:
[ shrug... ] We don't report the compiled-in port number, which is
considerably more critical. And we don't report changes in any of the
other stuff in pg_config_manual.h.
True.
MHO is that changing the socket directory is only marginally supported,
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
that if you're doing something to the database that someone might
object to, you oughtn't be doing it to the postgres database either.
You should create a database just for pg_upgrade's use and install its
crap in
Magnus Hagander wrote:
On Oct 28, 2011 5:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Stephen Frost wrote:
Yes, they would have removed it because they didn't want it. As I
recall, part of the agreement to create an extra database by default
was
Magnus Hagander wrote:
On Oct 28, 2011 5:19 AM, Bruce Momjian br...@momjian.us wrote:
Stephen Frost wrote:
Regarding pg_dumpall and pg_restore, I'm pretty sure both of those
can
be configured to connect to other databases instead, including for
globals.
Well, please
Tom Lane wrote:
I wonder how trustworthy the measure of the visibilitymap_test call site
as a consumer of cycles really is. I've frequently noticed that
oprofile blames remarkably large fractions of the runtime on individual
statements that appear to be quite trivial. I'm not sure if that
On 10/28/2011 08:01 AM, Stephen Frost wrote:
MHO is that changing the socket directory is only marginally supported,
and we shouldn't encourage it unless we're prepared to fully support it
(which we can't really).
This concerns me a bit, as most distros change it.. What would you
expect
On my Fedora 14 box, make -j3 fails. I think the below is the
relevant portion of the output. This has a passing similarity to bug
5665, but I can't for the life of me see what the problem is here.
parer.o depends on preproc.h, which depends on preproc.c; therefore,
parser.o should not be built
On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian br...@momjian.us wrote:
Yes, that would work, but see my summarization email on this. Using
template1 is not a problem for pg_upgrade, it is the modifications to
pg_dumpall that are an issue.
I just did a bit of testing on this. It appears that
On 28 October 2011 14:28, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian br...@momjian.us wrote:
Yes, that would work, but see my summarization email on this. Using
template1 is not a problem for pg_upgrade, it is the modifications to
pg_dumpall that
Robert Haas wrote:
On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian br...@momjian.us wrote:
Yes, that would work, but see my summarization email on this. ?Using
template1 is not a problem for pg_upgrade, it is the modifications to
pg_dumpall that are an issue.
I just did a bit of testing
On Fri, Oct 28, 2011 at 9:55 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian br...@momjian.us wrote:
Yes, that would work, but see my summarization email on this. ?Using
template1 is not a problem for pg_upgrade, it is the
Robert Haas wrote:
But regardless of which database it uses to *generate* the dump, the
dump itself will *always* contain this, right at the very beginning:
\connect postgres
That line is in fact hard-coded as a literal string in pg_dumpall.c.
It seems like the easiest fix here might
Robert Haas wrote:
action. I understand that failing is probably less code, but IMHO one
of the biggest problems with pg_upgrade is that it's too fragile:
there are too many seemingly innocent things that can make it croak
(which isn't good, when you consider that anyone using pg_upgrade is
Gurjeet Singh wrote:
I have tried reproducing the bug starting from 1 and 2 transactions
before
the one shown in snippet, and I used tab-completion to get the same
screen-output as termonal1.txt and yet it's not reproducible.
I could reproduce it when I typed TAB just after typing
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference to the postgres database in the
new cluster if it doesn't exist in the old one. That would allow
pg_upgrade to
On Fri, Oct 28, 2011 at 10:09 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
action. I understand that failing is probably less code, but IMHO one
of the biggest problems with pg_upgrade is that it's too fragile:
there are too many seemingly innocent things that can make it
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference to the postgres database in the
new cluster if it doesn't exist in the old one. ?That would
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:09 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
action. ?I understand that failing is probably less code, but IMHO one
of the biggest problems with pg_upgrade is that it's too fragile:
there are too many seemingly innocent
Bruce Momjian wrote:
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference to the postgres database in the
new cluster if it doesn't exist in
in Section 13.2.3 of the 9.1 docs [1], the follow sentence fragment can be
found:
using Serializable transactions will allow one transaction to commit and
and will roll the other back
Note the double and towards the end. (Is this the right list for this kind
of report?)
[1]
Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Oct 27, 2011 at 4:41 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
On the docs page for the SELECT statement, there is a caution
which starts with:
| It is possible for a SELECT command using ORDER BY and FOR
| UPDATE/SHARE to return
Vik Reykja vikrey...@gmail.com wrote:
in Section 13.2.3 of the 9.1 docs [1], the follow sentence
fragment can be found:
using Serializable transactions will allow one transaction to
commit and and will roll the other back
Note the double and towards the end. (Is this the right list for
On Fri, Oct 28, 2011 at 10:11 AM, Bruce Momjian br...@momjian.us wrote:
Gurjeet Singh wrote:
I have tried reproducing the bug starting from 1 and 2 transactions
before
the one shown in snippet, and I used tab-completion to get the same
screen-output as termonal1.txt and yet it's
vadym nikolaiev vadym.nikola...@gmail.com wrote:
I would like to ask you which sources are responsible for execute
queries in PostgreSQL?
http://wiki.postgresql.org/wiki/Developer_FAQ#How_is_the_source_code_organized.3F
( i would like to run a simple query and debug it execution on
On Fri, Oct 28, 2011 at 11:01 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Vik Reykja vikrey...@gmail.com wrote:
in Section 13.2.3 of the 9.1 docs [1], the follow sentence
fragment can be found:
using Serializable transactions will allow one transaction to
commit and and will roll
On Fri, Oct 28, 2011 at 10:44 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
OK, doc patch attached.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Andrew Dunstan and...@dunslane.net writes:
Er, which distros other than debian/ubuntu?
Well, any and all derivatives I guess, to begin with.
http://distrowatch.com/dwres.php?resource=independence#debian
Based on Debian GNU/Linux: 129 Distributions
More seriously, I'm not sure how to
Pavel Stehule pavel.steh...@gmail.com writes:
this is just small note about length of this patch. This patch was
significantly smaller then he solved problem with derivate types for
compound types - it should to solve problem described in this thread
Robert Haas robertmh...@gmail.com writes:
On my Fedora 14 box, make -j3 fails. I think the below is the
relevant portion of the output. This has a passing similarity to bug
5665, but I can't for the life of me see what the problem is here.
parer.o depends on preproc.h, which depends on
On Mon, Oct 24, 2011 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 24, 2011 at 3:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wonder how trustworthy the measure of the visibilitymap_test call site
as a consumer of cycles really is.
I'm
On Fri, Oct 28, 2011 at 1:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On my Fedora 14 box, make -j3 fails. I think the below is the
relevant portion of the output. This has a passing similarity to bug
5665, but I can't for the life of me see what the
Robert Haas robertmh...@gmail.com writes:
Wait a minute: I'm confused. What's at issue here, at least AIUI, is
taking a TOAST pointer and fetching the corresponding value. But that
must involve reading from the TOAST table, and our usual paradigm for
reading from system catalogs is (1) take
2011/10/28 pasman pasmański pasma...@gmail.com:
I think, it be useful to include in version() function a hexadecimal
identifier of commit, for fast checkout to it in git.
It's sort of impossible to make this accurate, though. You may have
patched your tree but not created a commit with those
Robert Haas robertmh...@gmail.com writes:
I also tried changing the BufferIsValid() tests in
visibilitymap_test() to use BufferIsInvalid() instead, with the sense
of the tests reversed (see attached vismap-test-invalid.patch). Since
BufferIsInvalid() just checks for InvalidBuffer instead of
On Fri, Oct 28, 2011 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I also tried changing the BufferIsValid() tests in
visibilitymap_test() to use BufferIsInvalid() instead, with the sense
of the tests reversed (see attached vismap-test-invalid.patch).
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 28, 2011 at 1:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I tried to reproduce this on my own Fedora 14 box, and couldn't.
I cd'd to src/interfaces/ecpg/preproc and did several repetitions of
make maintainer-clean
make -j
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 28, 2011 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm. I wonder whether it wouldn't be better to get rid of the range
checks in BufferIsValid, or better convert them into Asserts. It seems
less than intuitive that BufferIsValid and
On Fri, Oct 28, 2011 at 3:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 28, 2011 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm. I wonder whether it wouldn't be better to get rid of the range
checks in BufferIsValid, or better convert them
Hi All,
The lseek patches just got included in Linus tree.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 28, 2011 at 3:33 PM, Andres Freund and...@anarazel.de wrote:
The lseek patches just got included in Linus tree.
Excellent, thanks for the update!
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=ef3d0fd27e90f67e35da516dafc1482c82939a60
So I guess this will be
Excerpts from Tom Lane's message of vie oct 28 15:37:43 -0300 2011:
The main concern I had about detoast before caching is the risk of
circularity, ie, needing detoastable cache entries in order to figure
out how to detoast. But I think it's probably okay. The current list
of catalogs with
Excerpts from Alvaro Herrera's message of vie oct 28 16:47:13 -0300 2011:
BTW we had previous discussions about dropping pg_database's toast
table. Maybe this is a good time to do it, even if there's no risk of
this bug (or the hypothetical circularity detoasting problem) showing up
there.
The September commitfest has been drifting sideways for most of this
month. I think it's about time to put it out of its misery, especially
since the next one is due to start in barely more than 2 weeks.
The remaining open items:
* Allow encoding specific character incrementer
This has
On Fri, Oct 28, 2011 at 10:16 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference to the postgres database
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 28, 2011 at 3:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, I find that unlikely as well. But leaving Asserts in place would
tell us.
OK. Should I go do that, or are you all over it?
Go for it.
regards, tom
On Fri, Oct 28, 2011 at 10:18 AM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference
Tom Lane t...@sss.pgh.pa.us wrote:
The risk factor comes in when we hold a syscache entry across
transactions; then this guarantee is lost. (In both the original
example and the pg_proc case above, the second backend is only at
risk when it starts its transaction after the first one's
Kevin Grittner kevin.gritt...@wicourts.gov writes:
If we made the commit sequence number more generally available,
incrementing it at the point of visibility change under cover of
ProcArrayLock, and including the then-current value in a Snapshot
object when built, would that help with this at
On Fri, Oct 28, 2011 at 3:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Allow encoding specific character incrementer
This has certainly gotten reviewed. I'm unclear on whether it's
committable or not. Let's either commit it or mark it Returned With
Feedback (Robert?).
I think it's
* unite recovery.conf and postgresql.conf
This one also seems to be lacking consensus more than anything else.
What do we do about that?
AFAIR, the only person objecting is Simon. I'm not necessarily saying
that means we should drive it in over his objections, but OTOH there
were quite a
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Alvaro Herrera's message of vie oct 28 16:47:13 -0300 2011:
BTW we had previous discussions about dropping pg_database's toast
table. Maybe this is a good time to do it, even if there's no risk of
this bug (or the hypothetical
Hi,
On Friday, October 28, 2011 09:40:51 PM Robert Haas wrote:
On Fri, Oct 28, 2011 at 3:33 PM, Andres Freund and...@anarazel.de wrote:
The lseek patches just got included in Linus tree.
Excellent, thanks for the update!
Joshua D. Drake j...@commandprompt.com writes:
* unite recovery.conf and postgresql.conf
This one also seems to be lacking consensus more than anything else.
What do we do about that?
AFAIR, the only person objecting is Simon. I'm not necessarily saying
that means we should drive it in
On Fri, Oct 28, 2011 at 4:07 PM, Joshua D. Drake j...@commandprompt.com wrote:
* unite recovery.conf and postgresql.conf
This one also seems to be lacking consensus more than anything else.
What do we do about that?
AFAIR, the only person objecting is Simon. I'm not necessarily saying
that
On Fri, Oct 28, 2011 at 10:33:45PM +0200, aperi2007 wrote:
Seem that postgis try to define it an else condition assigning it a
unknown geometry ?
It's PostgreSQL, not PostGIS.
The same happens with any type, can be reproduced with something like this:
=# CREATE VIEW test1 AS SELECT
CASE
On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Separating bgwriter and checkpointer
Same for this one.
Will commit by end of Monday
* pg_last_xact_insert_timestamp
This one is stuck because we don't have consensus on whether it should
be applied. I suggest
Sandro Santilli s...@keybit.net writes:
The same happens with any type, can be reproduced with something like this:
=# CREATE VIEW test1 AS SELECT
CASE WHEN random() 0.5 THEN 1::numeric(10, 0)
END;
=# \d test1
View test.test1
Column | Type | Modifiers
On Fri, Oct 28, 2011 at 3:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 28, 2011 at 3:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, I find that unlikely as well. But leaving Asserts in place would
tell us.
OK. Should I go do that, or are
On Fri, Oct 28, 2011 at 3:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Alvaro Herrera's message of vie oct 28 16:47:13 -0300 2011:
BTW we had previous discussions about dropping pg_database's toast
table. Maybe this is a good time
This one also seems to be lacking consensus more than anything else.
What do we do about that?
I'll re-read the thread in detail to see if I can break impasse.
When we last left it, I pointed out to you that 100% backwards
compatibility is impossible: we simply can't maintain recovery.conf
On Sat, Oct 29, 2011 at 5:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Separating bgwriter and checkpointer
Same for this one.
Will commit by end of Monday
There are plenty of source comments (and probably documents)
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:16 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian br...@momjian.us wrote:
OK, then the simplest fix, once you modify pg_dumpall, would be to
modify pg_upgrade to remove reference
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 28, 2011 at 3:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Range Types
This has certainly had plenty of work done too. If it's not committable
yet, I think we should mark it Returned With Feedback for now.
I have been thinking about
68 matches
Mail list logo
