On Wed, 2009-05-27 at 21:09 -0400, Tom Lane wrote:
> So, if we assume that these numbers are real and not artifacts, it seems
> we have to postulate at least four distinct block-size-dependent
> performance effects:
Two performance effects would be sufficient to explain the results.
* Optimal p
On Wed, 2009-05-27 at 17:51 -0700, Mark Wong wrote:
> On Wed, May 27, 2009 at 1:46 AM, Simon Riggs wrote:
> >
> > On Tue, 2009-05-26 at 19:51 -0700, Mark Wong wrote:
> >> It appears for this workload using a 16KB or 32KB gets more than 4%
> >> throughput improvement, but some of that could be noi
Hi,
Quoting "Marc G. Fournier" :
Please repost ...
Peter referred to this message here:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01879.php
However, please be cautious before applying such a patch.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
Hi,
Quoting "Marc G. Fournier" :
Actually, I have done that on at least one of the 8.x tags too, so
if that is it, more then those two tags should be causing issues ...
Not *every* such issue causes problems. An example that's perfectly fine:
cvs commit -m "first commit" fileA
cvs tag TEST
Hi,
Quoting "Robert Haas" :
I think this is a semantic argument. The problem isn't that we don't
understand how CVS behaves; it's that we find that behavior
undesirable
I fully agree to that and find it undesirable as well.
aka broken.
Well, for some it's a feature, for others a bug ;-)
Hi all,
Seems the night has been providing lots of thoughs :)
Josh Berkus writes:
> Sure. I think that having better search path management would be a
> wonderful thing; it would encourage people to use schema more in general.
>
> However, that doesn't mean that I think it should be part of the
Robert Haas writes:
> The contents of a particular schema are more or less analagous to an
> application. In most programming languages, an application informs
> the system of the libraries that it needs and the system goes off and
> loads the symbols in those libraries into the application's nam
Andrew Dunstan writes:
> Dimitri Fontaine wrote:
>> "we all agree that a specific pg_extension schema is a good idea, as
>>soon as user is free not to use it at extension install time".
>
> I don't think we all agree on that at all. ;-)
Ooops, my mistake, as few people where taking that as
Hi,
Tom Lane writes:
> Andrew Gierth writes:
>> Splitting up search_path is something I've been thinking about for a
>> while (and threw out on IRC as a suggestion, which is where Dimitri
>> got it); it was based on actual experience running an app that set the
>> search path in the connection p
I attached another cleanup patch which fixes following warnings reported
by Sun Studio:
"zic.c", line 1534: warning: const object should have initializer: tzh0
"dynloader.c", line 7: warning: empty translation unit
"pgstat.c", line 666: warning: const object should have initializer: all_zeroes
"pg
Kevin Grittner wrote:
>> 1. implementation of the paper's technique sans predicate locking,
>> that would avoid more serialization anomalies but not all?
>
> I saw that as a step along the way to support for fully serializable
> transactions. If covered by a "migration path" GUC which defaulted
Tom Lane wrote:
> > =# SELECT xmlelement(name a, xmlattributes('./qa?a=1&b=2' as href), 'Q&A');
> > xmlelement
> >
> > Q&A
>
> > '&' in xmlattributes seems to be encoded twice.
>
> This was apparently broken by Peter's patch here:
Guillaume Smet wrote:
On Tue, Apr 28, 2009 at 5:35 PM, Guillaume Smet
wrote:
On Tue, Apr 28, 2009 at 5:22 PM, Heikki Linnakangas
wrote:
At a normal startup, the checkpoint record would be there as usual. And an
archive recovery starts at the location indicated by the backup label.
AFAICS cal
On Thu, May 28, 2009 at 11:11:20AM +0200, Zdenek Kotala wrote:
> I attached another cleanup patch which fixes following warnings reported
> by Sun Studio:
> ...
> "preproc.c", line 39569: warning: pointer expression or its operand do not
> point to the same object yyerror_range, result is undefine
Michael Meskes píše v čt 28. 05. 2009 v 13:33 +0200:
> On Thu, May 28, 2009 at 11:11:20AM +0200, Zdenek Kotala wrote:
> > I attached another cleanup patch which fixes following warnings reported
> > by Sun Studio:
> > ...
> > "preproc.c", line 39569: warning: pointer expression or its operand do n
On Thursday 28 May 2009 04:49:19 Tom Lane wrote:
> Yeah. The fundamental problem with all the "practical" approaches I've
> heard of is that they only work for a subset of possible predicates
> (possible WHERE clauses). The idea that you get true serializability
> only if your queries are phrased
* Dimitri Fontaine (dfonta...@hi-media.com) wrote:
> Andrew Dunstan writes:
> > Dimitri Fontaine wrote:
> >> "we all agree that a specific pg_extension schema is a good idea, as
> >>soon as user is free not to use it at extension install time".
> >
> > I don't think we all agree on that at a
Peter Eisentraut wrote:
On Thursday 28 May 2009 04:49:19 Tom Lane wrote:
Yeah. The fundamental problem with all the "practical" approaches I've
heard of is that they only work for a subset of possible predicates
(possible WHERE clauses). The idea that you get true serializability
only if your
* Dimitri Fontaine (dfonta...@hi-media.com) wrote:
> A better way to solve this is to have the database post_search_path (or
> call it search_path_suffix) contain the extensions schemas. Now the
> roles are set up without search_path_suffix, and it's easy to add an
> extension living in its own sch
On Thursday 28 May 2009 03:38:49 Tom Lane wrote:
> * SET TRANSACTION ISOLATION LEVEL something-else should provide our
> current snapshot-driven behavior. I don't have a strong feeling about
> whether "something-else" should be spelled REPEATABLE READ or SNAPSHOT,
> but lean slightly to the latter
On Thursday 28 May 2009 15:24:59 Heikki Linnakangas wrote:
> I don't think you need that for predicate locking. To determine if e.g
> an INSERT and a SELECT conflict, you need to determine if the INSERTed
> tuple matches the predicate in the SELECT. No need to deduce anything
> between two predicat
On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote:
> Problem is with YYLLOC_DEFAULT. When I look on macro definition
>
> #define YYLLOC_DEFAULT(Current, Rhs, N) \
> Current.first_line = Rhs[1].first_line; \
> Current.first_column = Rhs[1].first_column;\
> Cur
* Robert Haas [090527 22:43]:
> On Wed, May 27, 2009 at 10:09 PM, Aidan Van Dyk wrote:
> > * Robert Haas [090527 21:30]:
> >
> >> > And actually looking at the history of the gpo repo, the branches are all
> >> > messed up with "merges" and stuff that I'm not sure where they are coming
> >> > fr
On Thu, 2009-05-28 at 14:04 +0300, Heikki Linnakangas wrote:
> I've committed a patch to do the RequstXLogSwitch() before shutdown
> checkpoint as discussed. It seems safe to me. (sorry for the delay, and
> thanks for the reminder)
Not sure if that is a fix that will work in all cases.
There
Simon Riggs wrote:
On Thu, 2009-05-28 at 14:04 +0300, Heikki Linnakangas wrote:
I've committed a patch to do the RequstXLogSwitch() before shutdown
checkpoint as discussed. It seems safe to me. (sorry for the delay, and
thanks for the reminder)
Not sure if that is a fix that will work in all
On Thu, 2009-05-28 at 16:19 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-05-28 at 14:04 +0300, Heikki Linnakangas wrote:
> >
> >> I've committed a patch to do the RequstXLogSwitch() before shutdown
> >> checkpoint as discussed. It seems safe to me. (sorry for the delay,
On Wed, 2009-05-27 at 12:08 -0400, Bruce Momjian wrote:
> Ideally someone would have
> taken ownership of the issue, summarized the email conclusions, gotten
> a patch together, and submitted it for application.
Just a further comment on this, based upon the patch Heikki recently
committed.
I ra
On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk wrote:
> All that based on the assumption that when the project switches to git,
> they actually want all the CVS history in their official tree. Its
> certainly not necessary, and possibly not even desirable... PostgreSQL
> could just as easily to
Simon Riggs wrote:
On Thu, 2009-05-28 at 16:19 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2009-05-28 at 14:04 +0300, Heikki Linnakangas wrote:
I've committed a patch to do the RequstXLogSwitch() before shutdown
checkpoint as discussed. It seems safe to me. (sorry for the dela
Greg Smith wrote:
On Wed, 27 May 2009, andy wrote:
I have a Sun blade 1000 that's just collecting dust now days...It
weighs a ton.
Bah, I know I picked one of those up myself once, which means it's far
from being what I'd consider a heavy server as Sun hardware goes. Specs
say it's 70 poun
On Thu, 2009-05-28 at 16:52 +0300, Heikki Linnakangas wrote:
> > If the archiver is working, but has fallen behind at the point of
> > shutdown, does the archiver operate for long enough to ensure we are
> > archived up to the point of the log switch prior to checkpoint?
>
> Yes, it archives all
Peter Eisentraut writes:
> On Thursday 28 May 2009 00:54:32 Tom Lane wrote:
>> To wit, the current
>> coding fails to respect the gettext domain when working with pluralized
>> messages.
> The ngettext() calls use the default textdomain that main.c sets up. The PLs
> use dngettext(). Is that no
* Robert Haas [090528 09:49]:
> On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk wrote:
> > All that based on the assumption that when the project switches to git,
> > they actually want all the CVS history in their official tree. Its
> > certainly not necessary, and possibly not even desirable...
Robert Haas wrote:
On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk wrote:
All that based on the assumption that when the project switches to git,
they actually want all the CVS history in their official tree. Its
certainly not necessary, and possibly not even desirable... PostgreSQL
could
Simon Riggs wrote:
On Thu, 2009-05-28 at 16:52 +0300, Heikki Linnakangas wrote:
If the archiver is working, but has fallen behind at the point of
shutdown, does the archiver operate for long enough to ensure we are
archived up to the point of the log switch prior to checkpoint?
Yes, it archive
Michael Meskes píše v čt 28. 05. 2009 v 14:47 +0200:
> On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote:
> > Problem is with YYLLOC_DEFAULT. When I look on macro definition
> >
> > #define YYLLOC_DEFAULT(Current, Rhs, N) \
> > Current.first_line = Rhs[1].first_line;
On Thu, 2009-05-28 at 17:21 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> >
> > I don't think it does, please look again.
>
> Still looks ok to me. pgarch_ArchiverCopyLoop() loops until all ready
> WAL segments have been archived (assuming no errors).
No, it doesn't now, though it d
Heikki Linnakangas wrote:
> 1. Needs to be fully spec-compliant serializable behavior. No
> anomalities.
That is what the paper describes, and where I want to end up.
> 2. No locking that's not absolutely necessary, regardless of the
> WHERE-clause used. No table locks, no page locks. Block
"Albe Laurenz" wrote:
> Every WHERE-clause in a SELECT will add one or more checks for each
> concurrent writer.
That has not been the case in any implementation of predicate locks
I've used so far. It seems that any technique with those performance
characteristics would be one to avoid.
>
Andrew Dunstan writes:
> Robert Haas wrote:
>> That would suck for me. I use git log a lot to see how things have
>> changed over time.
> Indeed. Losing the history is not an acceptable option.
I think the same. If git is not able to maintain our project history
then it is not mature enough to
On Thu, May 28, 2009 at 10:18 AM, Aidan Van Dyk wrote:
> * Robert Haas [090528 09:49]:
>> On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk wrote:
>> > All that based on the assumption that when the project switches to git,
>> > they actually want all the CVS history in their official tree. Its
>>
Peter Eisentraut wrote:
> Could someone describe concisely what behavior "snapshot" isolation
> provides that repeatable read does?
Phantom reads are not possible in snapshot isolation. They are
allowed to occur (though not required to occur) in repeatable read.
Note that in early versions
On Thu, May 28, 2009 at 3:40 PM, Kevin Grittner
wrote:
>> 2. No locking that's not absolutely necessary, regardless of the
>> WHERE-clause used. No table locks, no page locks. Block only on
>> queries/updates that would truly conflict with concurrent updates
>
> If you do a table scan, how do you
Simon Riggs wrote:
On Thu, 2009-05-28 at 17:21 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
I don't think it does, please look again.
Still looks ok to me. pgarch_ArchiverCopyLoop() loops until all ready
WAL segments have been archived (assuming no errors).
No, it doesn't now, though
Simon Riggs wrote:
>>>
>>> No, because as I said, if archive_command has been returning non-zero
>>> then the archive will be incomplete.
>>>
>> Yes. You think that's wrong? How would you like it to behave, then? I
>> don't think you want the shutdown to wait indefinitely until all files
>
On Thu, May 28, 2009 at 3:52 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Robert Haas wrote:
>>> That would suck for me. I use git log a lot to see how things have
>>> changed over time.
>
>> Indeed. Losing the history is not an acceptable option.
>
> I think the same. If git is not able to
On Thu, May 28, 2009 at 5:02 PM, Heikki Linnakangas
wrote:
> So you check. This solves Guillaume's immediate concern. If you have a
> suggestion for further improvements, I'm all ears.
Thanks for applying the patch.
Yes, the problem is that before this change, even with a working
replication and
On 05/27/09 22:00, Josh Berkus wrote:
Andy,
I have a Sun blade 1000 that's just collecting dust now days. I was
wondering if there were any pg-hackers that could find use for it.
Its dual UltraSPARC III 750 (I think) and has two 36? gig fiber channel
scsi disks.
It weighs a ton.
I'd be ha
On Thu, 2009-05-28 at 17:16 +0200, Guillaume Smet wrote:
> On Thu, May 28, 2009 at 5:02 PM, Heikki Linnakangas
> wrote:
> > So you check. This solves Guillaume's immediate concern. If you have a
> > suggestion for further improvements, I'm all ears.
>
> Thanks for applying the patch.
>
> Yes, t
Greg Stark wrote:
> Once again, the type of scan is not relevant. it's quite possible to
> have a table scan and only read some of the records, or to have an
> index scan and read all the records.
>
> You need to store some representation of the qualifiers on the scan,
> regardless of whether t
Hi,
Quoting "Tom Lane" :
I think the same. If git is not able to maintain our project history
then it is not mature enough to be considered as our official VCS.
As Aidan pointed out, the question is not *if* git can represent it.
It's rather *how*. Especially WRT changes of historical infor
On Thu, May 28, 2009 at 8:43 AM, Peter Eisentraut wrote:
> On Thursday 28 May 2009 15:24:59 Heikki Linnakangas wrote:
>> I don't think you need that for predicate locking. To determine if e.g
>> an INSERT and a SELECT conflict, you need to determine if the INSERTed
>> tuple matches the predicate i
Zdenek Kotala writes:
> I attached another cleanup patch which fixes following warnings reported
> by Sun Studio:
I'm not too impressed with any of these. The proposed added
initializers just increase future maintenance effort without solving
any real problem (since the variables are required by
On Thu, May 28, 2009 at 11:04 AM, Greg Stark wrote:
> On Thu, May 28, 2009 at 3:52 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Robert Haas wrote:
That would suck for me. I use git log a lot to see how things have
changed over time.
>>
>>> Indeed. Losing the history is not an acc
On Thu, May 28, 2009 at 11:40 AM, Markus Wanner wrote:
> Quoting "Tom Lane" :
>> I think the same. If git is not able to maintain our project history
>> then it is not mature enough to be considered as our official VCS.
>
> As Aidan pointed out, the question is not *if* git can represent it. It's
On Thu, May 28, 2009 at 5:36 PM, Simon Riggs wrote:
> If you feel we have moved forwards, that's good, but since no part of
> the *safe* maintenance procedure has changed, I don't see that myself.
> Only the unsafe way of doing it got faster.
I disagree with you.
The situation was:
- you stop th
Hi,
Quoting "Robert Haas" :
I don't think that was the idea - Aidan floated the idea of just
checking the current version of each branch into git, rather than
importing the full history from CVS (and letting indivdual cloners fix
their own history if they were so inclined). I think that's a
non
On Thu, May 28, 2009 at 4:33 PM, Kevin Grittner
wrote:
>
> Can you cite anywhere that such techniques have been successfully used
> in a production environment
Well there's a reason our docs say: "Such a locking system is complex
to implement and extremely expensive in execution"
> or are you su
Michael Meskes writes:
> I have to admit that those version look strikingly unsimilar to me. There is
> no
> reference to Rhs[N] in our macro at all. But then I have no idea whether this
> is needed.
The default version of the macro is intended to track both the starting
and ending locations of
Greg Stark wrote:
> I would want any serialization failure to be
> justifiable by simple inspection of the two transactions.
BTW, there are often three (or more) transaction involved in creating
a serialization failure, where any two of them alone would not fail.
You probably knew that, but j
On Thu, 2009-05-28 at 17:50 +0200, Guillaume Smet wrote:
> I think it's a step forward, maybe not sufficient for you but I prefer
> the situation now than before. It's safer because of the principle of
> least surprise: I'm pretty sure a lot of people didn't even think that
> the last WAL file wa
Hi,
Quoting "Robert Haas" :
My understanding is that the histories of some of the branches we have
now are flat-out wrong.
AFAIU only the latest revisions of the branches have been compared.
Keeping history and future in mind, that's not telling much, IMO. In
my experience, there's much mo
>
> Dmitry Koterov writes:
> > No, I meant that in case of the row (1, NULL, NULL, 2, 3, NULL):
> > - the corresponding NULL bitmap is (100110...)
> > - the corresponding tuple is (1, 2, 3)
> > - t_natts=3 (if I am not wrong here)
>
> You are wrong --- t_natts would be six here. In general the le
On Thu, May 28, 2009 at 6:06 PM, Simon Riggs wrote:
> On Thu, 2009-05-28 at 17:50 +0200, Guillaume Smet wrote:
>
>> I think it's a step forward, maybe not sufficient for you but I prefer
>> the situation now than before. It's safer because of the principle of
>> least surprise: I'm pretty sure a l
Robert Haas writes:
> What's hard about that? INSERTs are the hard case, because the rows
> you care about don't exist yet. SELECT, UPDATE, and DELETE are easy
> by comparison; you can lock the actual rows at issue. Unless I'm
> confused?
UPDATE isn't really any easier than INSERT: the update
Robert Haas writes:
> I'm still not sure who is going to take responsibility for fixing the
> git tree we have now. I don't think it's going to work for us to
> leave it broken until we're ready to do "the cutover", and then do one
> monolithic move. If the tools we're using to do the import now
On Thu, May 28, 2009 at 12:10 PM, Markus Wanner wrote:
> Hi,
>
> Quoting "Robert Haas" :
>>
>> My understanding is that the histories of some of the branches we have
>> now are flat-out wrong.
>
> AFAIU only the latest revisions of the branches have been compared. Keeping
> history and future in m
On May 28, 2009, at 1:34 AM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
Dimitri Fontaine wrote:
"we all agree that a specific pg_extension schema is a good idea,
as
soon as user is free not to use it at extension install time".
I don't think we all agree on that at all. ;-)
Ooops
On Thu, May 28, 2009 at 12:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm still not sure who is going to take responsibility for fixing the
>> git tree we have now. I don't think it's going to work for us to
>> leave it broken until we're ready to do "the cutover", and then do one
>> monoli
Greg Stark wrote:
> On Thu, May 28, 2009 at 4:33 PM, Kevin Grittner wrote:
>>
>> Can you cite anywhere that such techniques have been successfully
>> used in a production environment
>
> Well there's a reason our docs say: "Such a locking system is
> complex to implement and extremely expensive i
On May 28, 2009, at 1:13 AM, Dimitri Fontaine wrote:
Having all extensions live in pg_extension schema also solves the
problem in a much easier way, except for people who care about not
messing it all within a single schema (fourre-tout is the french for a
place where you put anything and everyt
Jignesh K. Shah wrote:
On 05/27/09 22:00, Josh Berkus wrote:
Andy,
I have a Sun blade 1000 that's just collecting dust now days. I was
wondering if there were any pg-hackers that could find use for it.
Its dual UltraSPARC III 750 (I think) and has two 36? gig fiber channel
scsi disks.
It
On Thu, 28 May 2009, Robert Haas wrote:
My understanding is that the histories of some of the branches we have
now are flat-out wrong. I don't have a problem keeping those
alongside the corrected history for ease of rebasing and porting
commits, but I don't want to punt the problem of figuring
Robert Haas writes:
> On Thu, May 28, 2009 at 12:19 PM, Tom Lane wrote:
>> I think
>> we will have to make a clean cutover from "CVS is authoritative" to
>> "CVS is dead and git is authoritative", and do a fresh repository
>> conversion at that instant. What we should be doing to get prepared fo
Greg Smith wrote:
On Thu, 28 May 2009, Andy Colson wrote:
Yeah, when it shipped I think it was about 75 pounds. It is a tower,
yes, and an impressively large box (my experience with servers is
limited, this is the first I've ever gotten to play with, so it may
not be out of the ordinary).
On Thu, 2009-05-28 at 18:02 +0300, Heikki Linnakangas wrote:
> postmaster never sends SIGTERM to pgarch, and postmaster is still alive.
Then we have a regression, since we changed the code to make sure the
archiver did shutdown even if there was a backlog. The reason is that if
there is a long b
Robert Haas escribió:
> To me they sound complex and inconvenient. I guess I'm kind of
> mystified by why we can't make this work reliably. Other than the
> "broken tags" issue we've discussed, it seems like the only real issue
> should be how to group changes to different files into a single
>
Greg Smith writes:
> The best way to control the scope creep here is to avoid doing that, and
> instead focus on what you really need from the repo conversion. [...]
> If the goalposts are moved to "every ancient tag/release ever must build
> perfectly and have sane history no matter how nasty
Alvaro Herrera writes:
> There's another issue which is that of the $Id$ and similar tags. We
> have to decide what we want to do with them. If we're not going to have
> them in the Git repository, then they are only causing trouble right now
> and it would be better to get rid of them completel
On Thu, May 28, 2009 at 12:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> What's hard about that? INSERTs are the hard case, because the rows
>> you care about don't exist yet. SELECT, UPDATE, and DELETE are easy
>> by comparison; you can lock the actual rows at issue. Unless I'm
>> confused?
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Right. Shall we try to spec out exactly what our conversion
> requirements are? Here's a shot:
[...]
> Comments? Other considerations?
Certainly sounds reasonable to me. I'd be really suprised if that's
really all that hard to accomplish. I'd be happy
Simon Riggs wrote:
On Thu, 2009-05-28 at 18:02 +0300, Heikki Linnakangas wrote:
postmaster never sends SIGTERM to pgarch, and postmaster is still alive.
Then we have a regression, since we changed the code to make sure the
archiver did shutdown even if there was a backlog.
The commit messag
On Thu, May 28, 2009 at 12:51 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> There's another issue which is that of the $Id$ and similar tags. We
>> have to decide what we want to do with them. If we're not going to have
>> them in the Git repository, then they are only causing trouble right n
Tom Lane escribió:
> Alvaro Herrera writes:
> > There's another issue which is that of the $Id$ and similar tags. We
> > have to decide what we want to do with them. If we're not going to have
> > them in the Git repository, then they are only causing trouble right now
> > and it would be better
Hello
current plpgsql cannot detect early some errors based on unknown
casting. Other problem is IO casting.
The reason is an late casting:
current_code is some like:
val = eval_expr(query, &result_type);
if (result_type != expected_type)
{
str = convert_to_string(val, result_type);
val =
Alvaro Herrera writes:
> Tom Lane escribió:
>> What was in the back of my mind was that we'd go around and mass-remove
>> $PostgreSQL$ (and any other lurking tags), but only from HEAD and only
>> after the repo conversion. Although just before it would be okay too.
> You mean we would remove the
Pavel Stehule writes:
> I propose for types with typmod -1 early casting - etc casting to
> target type on planner level. We cannot use this method for defined
> typmod, because we would to raise exception for following situation:
What existing coding habits will this break? People have long bee
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler wrote:
> Yes, just as long as your extensions schema doesn't turn into a bricolage of
> stuff. I mean, if I use a lot of extensions, it means that I end up with a
> giant collection of functions and types and whatnot in this one namespace.
> PHP pr
Dimitri Fontaine wrote:
"we all agree that a specific pg_extension schema is a good idea, as
soon as user is free not to use it at extension install time".
I don't think we all agree on that at all. ;-)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On 5/28/09 12:36 AM, Dimitri Fontaine wrote:
That really seems exactly to be what we're proposing with pre_ and post_
search_path components: don't change current meaning of search_path,
just give DBAs better ways to manage it. And now that you're leaning
towards a search_path suffix, don't you w
Greg Stark writes:
> I don't understand what storing them in different namespaces and then
> putting them all in your search_path accomplishes. You end up with the
> same mishmash of things in your namespace.
+1 ... naming conflicts between different extensions are going to be a
problem for peopl
Josh Berkus writes:
> On 5/28/09 12:36 AM, Dimitri Fontaine wrote:
>> That really seems exactly to be what we're proposing with pre_ and post_
>> search_path components: don't change current meaning of search_path,
>> just give DBAs better ways to manage it. And now that you're leaning
>> towards
Andy,
Yeah, when it shipped I think it was about 75 pounds. It is a tower,
yes, and an impressively large box (my experience with servers is
limited, this is the first I've ever gotten to play with, so it may not
be out of the ordinary). I think my kill-a-watt said, at idle, it was
near 300W. (T
2009/5/28 Tom Lane :
> Pavel Stehule writes:
>> I propose for types with typmod -1 early casting - etc casting to
>> target type on planner level. We cannot use this method for defined
>> typmod, because we would to raise exception for following situation:
>
> What existing coding habits will this
Pavel Stehule writes:
> for typmod others then -1 we should to use IO cast - but we should to
> check, if it's one from known casts.
I still think it's fundamentally wrong to be treating typmod -1 so
differently from other typmods. If this behavior is sane at all then
it should work in both case
I use pgTAP to make sure my functions produce the correct errors using
throws_ok(). So when I get an error from a plpgsql function, it looks
like this:
ERROR: upper bound of FOR loop cannot be null
CONTEXT: PL/pgSQL function "foo" line 35 at FOR with integer loop
variable
...which I can then t
On Thu, May 28, 2009 at 2:27 PM, Greg Stark wrote:
> On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler
> wrote:
>> Yes, just as long as your extensions schema doesn't turn into a bricolage of
>> stuff. I mean, if I use a lot of extensions, it means that I end up with a
>> giant collection of fun
On Thu, 28 May 2009, Tom Lane wrote:
Each released minor version tag must check out the same as from CVS, at
least back to some specified point (perhaps 7.4.0). I'd really prefer
to insist on that all the way back.
We'd all like to hope that conversion process that works for everything
back
2009/5/28 Tom Lane :
> Pavel Stehule writes:
>> for typmod others then -1 we should to use IO cast - but we should to
>> check, if it's one from known casts.
>
> I still think it's fundamentally wrong to be treating typmod -1 so
> differently from other typmods. If this behavior is sane at all th
Robert Haas writes:
> It also seems to me that we're getting seriously sidetracked from the
> dependency-tracking part of this project which seems to me to be a
> much deeper and more fundamental issue.
I thought that part was a pretty simple problem, actually. Have an
object representing the mo
1 - 100 of 169 matches
Mail list logo
