2011/10/28 Tom Lane :
> Stephen Frost 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
> considerably more critical. And we
* 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 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 t
Magnus Hagander wrote:
> On Oct 28, 2011 5:22 AM, "Tom Lane" wrote:
> >
> > Bruce Momjian 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 c
Magnus Hagander wrote:
> On Oct 28, 2011 5:19 AM, "Bruce Momjian" 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.
> > > >
> > >
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 to
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 u
On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian 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 pg_dumpall, if
On 28 October 2011 14:28, Robert Haas wrote:
> On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian 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 b
Robert Haas wrote:
> On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian 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.
On Fri, Oct 28, 2011 at 9:55 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian 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
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 ea
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 i
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
On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian 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 maintain a 1-1 mat
On Fri, Oct 28, 2011 at 10:09 AM, Bruce Momjian 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 croak
>> (whic
Robert Haas wrote:
> On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian 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_
Robert Haas wrote:
> On Fri, Oct 28, 2011 at 10:09 AM, Bruce Momjian 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 th
Bruce Momjian wrote:
> Robert Haas wrote:
> > On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian 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
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]
http://www.postgr
Simon Riggs wrote:
> On Thu, Oct 27, 2011 at 4:41 PM, Kevin Grittner
> 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 rows out of order. This is because OR
Vik Reykja 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
> this kind
On Fri, Oct 28, 2011 at 10:11 AM, Bruce Momjian 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 no
vadym nikolaiev 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
> PostgreSql server for under
On Fri, Oct 28, 2011 at 11:01 AM, Kevin Grittner
wrote:
> Vik Reykja 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 doubl
On Fri, Oct 28, 2011 at 10:44 AM, Kevin Grittner
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 changes to your subscription:
h
Andrew Dunstan 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 understand why some peopl
Pavel Stehule 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
> http://stackoverflow.com/questions/7634704/declare-variable-of
Robert Haas 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 preproc.c; therefore,
>
On Mon, Oct 24, 2011 at 4:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 24, 2011 at 3:35 PM, Tom Lane wrote:
>>> I wonder how trustworthy the measure of the visibilitymap_test call site
>>> as a consumer of cycles really is.
>
>> I'm not sure either. I guess we could try short-cir
On Fri, Oct 28, 2011 at 1:24 PM, Tom Lane wrote:
> Robert Haas 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 depend
Robert Haas 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 AccessShareLock, (
2011/10/28 pasman pasmański :
> 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 changes before
you
Robert Haas 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 also doing
> the sa
On Fri, Oct 28, 2011 at 2:48 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas writes:
> On Fri, Oct 28, 2011 at 1:24 PM, Tom Lane 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
>>
>> and every time, make care
Robert Haas writes:
> On Fri, Oct 28, 2011 at 2:48 PM, Tom Lane 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 BufferIsInvalid aren't simple
>>
On Fri, Oct 28, 2011 at 3:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Oct 28, 2011 at 2:48 PM, Tom Lane 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
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 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 in Linux 3.2?
--
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 w
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
> ther
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 certainl
On Fri, Oct 28, 2011 at 10:16 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian 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
Robert Haas writes:
> On Fri, Oct 28, 2011 at 3:27 PM, Tom Lane 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 lane
--
Sent via pgsql-hackers mai
On Fri, Oct 28, 2011 at 10:18 AM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Robert Haas wrote:
>> > On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian wrote:
>> > > OK, then the simplest fix, once you modify pg_dumpall, would be to
>> > > modify pg_upgrade to remove reference to the postgres da
Tom Lane 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 commit,
> and in bet
"Kevin Grittner" 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 all?
No, because we n
On Fri, Oct 28, 2011 at 3:50 PM, Tom Lane 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 committable. Let me dr
* 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 fe
Alvaro Herrera 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 circularity detoasting
Hi,
On Friday, October 28, 2011 09:40:51 PM Robert Haas wrote:
> On Fri, Oct 28, 2011 at 3:33 PM, Andres Freund 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=ef3
> d
"Joshua D. Drake" 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 over hi
On Fri, Oct 28, 2011 at 4:07 PM, Joshua D. Drake 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 mean
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 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 pushing it forward
Sandro Santilli 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 wrote:
> Robert Haas writes:
>> On Fri, Oct 28, 2011 at 3:27 PM, Tom Lane 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.
OK, done. An
On Fri, Oct 28, 2011 at 3:11 PM, Tom Lane wrote:
> Alvaro Herrera 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 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.
On Sat, Oct 29, 2011 at 5:50 AM, Simon Riggs wrote:
> On Fri, Oct 28, 2011 at 8:50 PM, Tom Lane wrote:
>
>> * Separating bgwriter and checkpointer
>>
>> Same for this one.
>
> Will commit by end of Monday
There are plenty of source comments (and probably documents) describing that
checkpoint is
Robert Haas wrote:
> On Fri, Oct 28, 2011 at 10:16 AM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Fri, Oct 28, 2011 at 10:07 AM, Bruce Momjian wrote:
> >> > OK, then the simplest fix, once you modify pg_dumpall, would be to
> >> > modify pg_upgrade to remove reference to the postgres dat
Robert Haas writes:
> On Fri, Oct 28, 2011 at 3:50 PM, Tom Lane 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 looking at committing at least pa
64 matches
Mail list logo
