On 22.10.2010 06:10, Tom Lane wrote:
Right at the moment I'm not seeing any way that the present
exec_eval_simple_expr approach can be fixed to work safely in the
presence of recursion. What I think we might have to do is give up
on the idea of caching execution state trees across calls, instead
On Fri, Oct 22, 2010 at 11:03 AM, Josh Berkus wrote:
>
>> I think it's pretty well explained in the fine manual.
>>
>> http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-KEEP-SEGMENTS
>
> Nope. No relationship to checkpoint_segments is explained there. Try
> again?
Pl
On Fri, Oct 22, 2010 at 7:33 AM, Bruce Momjian wrote:
> Fujii Masao wrote:
>> Hi,
>>
>> As the result of the discussion, I think that we need the following two
>> parameters for the case where the standby goes down.
>
> Can we have a parameter that calls a operating system command when a
> standby
On Thu, Oct 21, 2010 at 10:24 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Greg Stark wrote:
>>> Did we have a solution for the problem that understanding which
>>> columns are timestamps requires having a tuple descriptor and parsing
>>> the every tuple? That seems like it would a) be slow and
On Thu, Oct 21, 2010 at 7:24 PM, Tom Lane wrote:
> Would we be willing to make such assumptions to
> support in-place upgrade of timestamps?
>
If something like that is true (I'm not sure it is) then we could
consider doing the equivalent of what we were talking about doing for
changes that requ
On Thu, Oct 21, 2010 at 7:13 PM, Tom Lane wrote:
> ... and as I recall, we got rid of it principally because the temp
> tables weren't visible to ordinary catalog lookups, thus breaking
> all sorts of client-side logic.
>
Though that wouldn't be the case if the catalogs held a template.
Anyw
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue oct 21 19:36:07 -0300 2010:
>> I don't believe that it's plancache's fault; the real problem is that
>> plpgsql is keeping "simple expression" execution trees around longer
>> than it should. Your patch masks the problem by forcing
On Fri, Oct 22, 2010 at 1:31 AM, Dimitri Fontaine
wrote:
> Of course, you what that means? Yes, another version of the patch, that
> will build the control file out of the control.in at build time rather
> than install time, and that's back to using EXTVERSION both in the
> Makefile and in the .co
Bruce Momjian writes:
> Greg Stark wrote:
>> Did we have a solution for the problem that understanding which
>> columns are timestamps requires having a tuple descriptor and parsing
>> the every tuple? That seems like it would a) be slow and b) require a
>> lot of high level code in the middle of
On Thu, Oct 21, 2010 at 10:03 PM, Josh Berkus wrote:
>
>> I think it's pretty well explained in the fine manual.
>>
>> http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-KEEP-SEGMENTS
>
> Nope. No relationship to checkpoint_segments is explained there. Try
> again?
We
Bruce Momjian writes:
> Greg Stark wrote:
>> It seems to me simpler and more direct to just nail relcache
>> entries for these objects into memory and manipulate them directly.
>> They can be constructed from the global catalog tables and then
>> tweaked to point to the backend local temporary tab
> I think it's pretty well explained in the fine manual.
>
> http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-KEEP-SEGMENTS
Nope. No relationship to checkpoint_segments is explained there. Try
again?
>> If checkpoint_segments were a hard limit, then we could let a
On Thu, Oct 21, 2010 at 9:09 PM, Josh Berkus wrote:
>
>>> Very true. But the lack of a -1 setting for wal_keep_segments means
>>> that if you would like to take a backup without archiving, you must
>>> set wal_keep_segments to a value greater than or equal to the rate at
>>> which you generate WA
Greg Stark wrote:
> On Thu, Oct 21, 2010 at 4:49 PM, Bruce Momjian wrote:
> > One thing we have talked about is converting the page on read-in from
> > the backend. ?Since the timestamps are the same size as float or
> > integer, that might be possible.
>
> Did we have a solution for the problem
>> Very true. But the lack of a -1 setting for wal_keep_segments means
>> that if you would like to take a backup without archiving, you must
>> set wal_keep_segments to a value greater than or equal to the rate at
>> which you generate WAL segments multiplied by the time it takes you to
>> run a
Bruce Momjian wrote:
>Greg Stark wrote:
>> On Tue, Oct 19, 2010 at 1:12 PM, Stephen R. van den Berg
>> wrote:
>> > In order to simplify recovery at this point (enormously), it would
>> > have been very helpful (at almost negligible cost), to have the name
>> > of the table, the name of the column
Greg Stark wrote:
>On Thu, Oct 21, 2010 at 11:30 AM, Stephen R. van den Berg wrote:
>> For the recovery information I'd like to reserve:
>> identifier: 00: table OID
>> ? ? ? ? ? ?01: table layout
>So here's a proposal for something that could maybe be implemented. I
>think I'm leaning against th
Robert Haas wrote:
> > However the user-unfriendliness isn't the fact that administrators
> > need to determine how much disk they're willing to dedicate to
> > Postgres. The user-unfriendliness is that they then have to specify
> > this in terms of WAL log files and also have to know that we somet
On Thu, Oct 21, 2010 at 8:45 PM, Robert Haas wrote:
> Please add this in the usual spot:
> https://commitfest.postgresql.org/action/commitfest_view/open
Aye sir, added.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
On Thu, Oct 21, 2010 at 8:52 PM, Greg Stark wrote:
> On Thu, Oct 21, 2010 at 5:46 PM, Josh Berkus wrote:
>>
>>> Agreed, but as a reality check: when I proposed that wal_keep_segments
>>> = -1 would keep all WAL segments (for use while the file system was
>>> being backed up), I was told administ
Greg Stark wrote:
> On Tue, Oct 19, 2010 at 1:12 PM, Stephen R. van den Berg wrote:
> > In order to simplify recovery at this point (enormously), it would
> > have been very helpful (at almost negligible cost), to have the name
> > of the table, the name of the columns, and the types of the
> > co
On Thu, Oct 21, 2010 at 5:46 PM, Josh Berkus wrote:
>
>> Agreed, but as a reality check: when I proposed that wal_keep_segments
>> = -1 would keep all WAL segments (for use while the file system was
>> being backed up), I was told administrators shoud compute how much free
>> disk space they had.
> Agreed, but as a reality check: when I proposed that wal_keep_segments
> = -1 would keep all WAL segments (for use while the file system was
> being backed up), I was told administrators shoud compute how much free
> disk space they had. Obviously easy of use is not our #1 priority.
Depends.
On Wed, Oct 20, 2010 at 10:56 PM, Josh Kupershmidt wrote:
> It looks like psql's tab completion for the \z and \dg commands in
> psql are missing. I couldn't see a reason for this, so attached patch
> fixes.
>
> Also, this patch proposes to change psql's "\?" help text to say that
> \dg and \du ar
On Thu, Oct 21, 2010 at 8:22 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> Greg,
>>
>> > The way things stand you *always* need archived logs. Even if you have
>> > streaming set up it might try to use archived logs if it falls too far
>> > behind.
>>
>> Actually, you don't. If you're willing
Robert Haas wrote:
> On Thu, Oct 21, 2010 at 4:21 PM, Josh Berkus wrote:
> > On 10/20/10 6:54 PM, Robert Haas wrote:
> >> I find it impossible to believe that's
> >> a good decision, and IMHO we should be focusing on how to make the
> >> parameters PGC_SIGHUP rather than PGC_POSTMASTER, which woul
Robert Haas wrote:
> On Wed, Oct 20, 2010 at 3:40 PM, Greg Stark wrote:
> > On Wed, Oct 20, 2010 at 6:29 AM, Robert Haas wrote:
> >> Exactly. ?It doesn't take many 3-7% slowdowns to add up to being 50%
> >> or 100% slower, and that sucks. ?In fact, I'm still not convinced that
> >> we were wise t
Excerpts from Tom Lane's message of jue oct 21 19:36:07 -0300 2010:
> I'm not immediately sure why plpgsql_subxact_cb is failing to clean up
> correctly in this example, but that seems to be where to look.
I think the reason is that one econtext is pushed for function
execution, and another one f
Josh Berkus wrote:
> Greg,
>
> > The way things stand you *always* need archived logs. Even if you have
> > streaming set up it might try to use archived logs if it falls too far
> > behind.
>
> Actually, you don't. If you're willing to accept possible
> desynchronization and recloning of the st
Tom Lane wrote:
> Bruce Momjian writes:
> > Currently it isn't possible to create temporary tables on read-only
> > standby servers, and I don't see it listed on the TODO list. Can I add
> > it?
>
> Not unless you have some credible concept for how it might ever be
> implemented. You can't crea
Kevin Grittner wrote:
>Tom Lane wrote:
>> Most of the data-loss reports I've seen appeared to come from
>> people who wouldn't be capable of doing such recovery work even if
>> better tools were available.
>No doubt; but the recovery work often winds up in the hands of
>people with more skills th
Greg Stark wrote:
> On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas wrote:
> > The trick is that it would require us to have two pg_class tables, two
> > pg_attribute tables, two pg_attrdef tables, etc.: in each case, one
> > permanent and one temporary. ?I am not sure how complex that will turn
> >
On Thu, Oct 21, 2010 at 4:49 PM, Bruce Momjian wrote:
> One thing we have talked about is converting the page on read-in from
> the backend. Since the timestamps are the same size as float or
> integer, that might be possible.
Did we have a solution for the problem that understanding which
colum
Robert Haas wrote:
> On Mon, Oct 18, 2010 at 2:29 PM, Jeff Davis wrote:
> > A reasonable conversion path might be to offer integer timestamps using
> > a different type name (e.g. inttimestamp) that always means integer
> > timestamps. Then, they could convert using ALTER TABLE, then do an
> > in-
Jeff Davis wrote:
> When using locks in an unconventional way, it would be helpful to
> describe the invalid schedules that you're preventing. Perhaps an
> example if you think it would be reasonably simple? Also some
> indication of how another process is intended to modify the list
> without w
Excerpts from Tom Lane's message of jue oct 21 19:36:07 -0300 2010:
> Alvaro Herrera writes:
> > A customer was hitting some misbehavior in one of their internal tests and
> > I tracked it down to plancache not behaving properly with
> > subtransactions: in particular, a plan is not being marked "
On Thu, Oct 21, 2010 at 5:21 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> Most of the data-loss reports I've seen appeared to come from
>> people who wouldn't be capable of doing such recovery work even if
>> better tools were available.
>
> No doubt; but the recovery work often winds up in t
On 19/10/10 13:16, Josh Berkus wrote:
Robert asked me to write this up, so here it is.
It is critical that we make replication easier to set up, administrate
and monitor than it currently is. In my conversations with people,
this is more important to our users and the adoption of PostgreSQL
Robert Treat wrote:
> Howdy folks,
>
> Was wondering if there are any docs on which contrib modules don't work with
> pg_upgrade? I seem to remember discussion on this during the 9.0 cycle, but
> couldn't find it in the mail archive, and don't see anything in the wiki.
> What
> brings this up
Alvaro Herrera writes:
> A customer was hitting some misbehavior in one of their internal tests and
> I tracked it down to plancache not behaving properly with
> subtransactions: in particular, a plan is not being marked "dead" when
> the subtransaction on which it is planned rolls back.
I don't
Fujii Masao wrote:
> Hi,
>
> As the result of the discussion, I think that we need the following two
> parameters for the case where the standby goes down.
Can we have a parameter that calls a operating system command when a
standby is declared dead, to notify the administrator?
--
Bruce Momj
Greg Stark wrote:
> On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Should we consider moving pg_filedump into our /contrib?
> >
> > Can't: it's GPL.
> >
>
> I don't particularly see a problem with having GPL'd contrib modules.
> It would mean any users hoping to
On Oct 21, 2010, at 2:17 PM, Tom Lane wrote:
> The oversight here is that we don't use appendrel planning for
> a top-level UNION ALL construct. That didn't use to matter,
> because you always got the same stupid Append plan either way.
> Now it seems like we ought to have some more intelligence
Peter Eisentraut wrote:
> On ons, 2010-10-13 at 14:32 -0400, Bruce Momjian wrote:
> > We have a database specification in .pgpass:
> >
> > hostname:port:database:username:password
> >
> > What is the purpose of 'database' since username/password combinations
> > are global, not per databa
Tom Lane wrote:
> Most of the data-loss reports I've seen appeared to come from
> people who wouldn't be capable of doing such recovery work even if
> better tools were available.
No doubt; but the recovery work often winds up in the hands of
people with more skills than those responsible for
Greg Stark writes:
> On Thu, Oct 21, 2010 at 6:57 AM, Tom Lane wrote:
>>> Thanks. It also explains my another question why Merge Append cannot
>>> be used for UNION ALL plans.
>> Hmm, seems like the example you show ought to work. I wonder if there
>> was an oversight in that patch...
> Huh, t
Excerpts from Tom Lane's message of jue oct 21 17:48:18 -0300 2010:
> buildfarm member koi, having recently been rescued from git purgatory,
> is failing like this:
>
> configure: using CFLAGS=-O -Kinline
> configure: using CPPFLAGS= -I/usr/local/include/libxml2 -I/usr/local/include
> configure:
Hi,
A customer was hitting some misbehavior in one of their internal tests and
I tracked it down to plancache not behaving properly with
subtransactions: in particular, a plan is not being marked "dead" when
the subtransaction on which it is planned rolls back. It was reported
in 8.4, but I can r
"A.M." writes:
> On Oct 21, 2010, at 4:19 PM, Robert Haas wrote:
>> I think adding this to pg_config is sensible. Sure, the user could
>> have moved the socket directory. But it's a place to start looking.
>> So why not?
> Because pg_config is supposed to return the current state of a cluster?
buildfarm member koi, having recently been rescued from git purgatory,
is failing like this:
configure: using CFLAGS=-O -Kinline
configure: using CPPFLAGS= -I/usr/local/include/libxml2 -I/usr/local/include
configure: using LDFLAGS= -L/usr/local/lib -L/usr/local/lib
preparing build tree... UX:fin
> I think that that would probably involve a whole lot more notational
> busywork than just replacing typmod with something more complicated.
> However, we're talking about breaking vast amounts of code in either
> case, so maybe making it even vaster isn't a real consideration.
Gods, yes. Pleas
Robert Haas writes:
> On Thu, Oct 21, 2010 at 4:28 PM, Tom Lane wrote:
>> TypeName per se is completely inappropriate for use beyond the first
>> stage of parsing, because it requires catalog lookups to make any sense
>> of. I think the post-parsing representation should still start with a
>> ty
On Oct 21, 2010, at 4:19 PM, Robert Haas wrote:
> 2010/10/21 Tom Lane :
>> Alvaro Herrera writes:
>>> Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010:
I agree this is interesting information to get, but wonder how
pg_config can know that and it looks to me th
On Thu, Oct 21, 2010 at 4:28 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> We already have TypeName as a structure that contains type and typmod
>> (and collation, in my patch). We could make that a primnode instead of
>> a parsenode, and use it in more places, or we could make a new leaner
Peter Eisentraut writes:
> We already have TypeName as a structure that contains type and typmod
> (and collation, in my patch). We could make that a primnode instead of
> a parsenode, and use it in more places, or we could make a new leaner
> structure that only contains the numeric info.
TypeN
On Thu, Oct 21, 2010 at 4:21 PM, Josh Berkus wrote:
> On 10/20/10 6:54 PM, Robert Haas wrote:
>> I find it impossible to believe that's
>> a good decision, and IMHO we should be focusing on how to make the
>> parameters PGC_SIGHUP rather than PGC_POSTMASTER, which would give us
>> most of the same
"Stephen R. van den Berg" writes:
> Tom Lane wrote:
>> There are way too many scenarios where you'll have no hope of doing
>> any such manual recovery anyway.
> True. It's all a matter of statistics. Judging by the number of reports
> I find by googling net-history, I'd have to conclude that th
On Thu, Oct 21, 2010 at 12:10:22PM -0700, David Gould wrote:
> On Thu, Oct 21, 2010 at 08:16:27AM -0700, Mark Wong wrote:
> > On Tue, Oct 19, 2010 at 8:30 PM, daveg wrote:
> > > On Wed, Oct 20, 2010 at 04:08:37PM +1300, Mark Kirkwood wrote:
> > >> On 20/10/10 16:05, Mark Kirkwood wrote:
> > >> >
>
On 10/20/10 6:54 PM, Robert Haas wrote:
> I find it impossible to believe that's
> a good decision, and IMHO we should be focusing on how to make the
> parameters PGC_SIGHUP rather than PGC_POSTMASTER, which would give us
> most of the same benefits without throwing away hard-won performance.
I'd
2010/10/21 Tom Lane :
> Alvaro Herrera writes:
>> Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010:
>>> I agree this is interesting information to get, but wonder how
>>> pg_config can know that and it looks to me that this information as
>>> nothing to do in pg_config...
Alvaro Herrera writes:
> Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010:
>> I agree this is interesting information to get, but wonder how
>> pg_config can know that and it looks to me that this information as
>> nothing to do in pg_config
>>
>> pg_config is all a
On Thu, Oct 21, 2010 at 11:30 AM, Stephen R. van den Berg wrote:
> For the recovery information I'd like to reserve:
> identifier: 00: table OID
> 01: table layout
>
So here's a proposal for something that could maybe be implemented. I
think I'm leaning against this currently as there
Tom Lane writes:
> One possible response would be to add an item to what pg_config knows
> about, eg "pg_config --socketdir". This doesn't answer every possible
> use-case either, but it would be helpful for some scenarios.
>
> Thoughts?
Following some links one can find out
http://packages.de
Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010:
> I agree this is interesting information to get, but wonder how
> pg_config can know that and it looks to me that this information as
> nothing to do in pg_config
>
> pg_config is all about installation, socket_dir i
On Thu, Oct 21, 2010 at 08:16:27AM -0700, Mark Wong wrote:
> On Tue, Oct 19, 2010 at 8:30 PM, daveg wrote:
> > On Wed, Oct 20, 2010 at 04:08:37PM +1300, Mark Kirkwood wrote:
> >> On 20/10/10 16:05, Mark Kirkwood wrote:
> >> >
> >> >
> >> >shmget and friends are hugetlbpage aware, so it seems it s
On Thu, Oct 21, 2010 at 2:44 PM, Peter Eisentraut wrote:
> On tor, 2010-10-14 at 22:54 -0400, Robert Haas wrote:
>> and maybe not that bad, but I wonder if there is some preparatory
>> refactoring that could be done to trim it down a bit. I notice, for
>> example, that a lot of places that looked
2010/10/21 Tom Lane :
> I just noticed that there doesn't seem to be any good way of finding
> out what a postmaster's default value of unix_socket_directory is.
> If you try to SHOW it you just get an empty string. We could probably
> fix things so that SHOW exposes the actual setting, but (1) th
Excerpts from Alvaro Herrera's message of jue oct 21 15:32:53 -0300 2010:
> Excerpts from Jean-Baptiste Quenot's message of jue oct 21 09:20:16 -0300
> 2010:
>
> > I get this error when calling the function:
> >
> > test=# select foobar();
> > ERROR: error fetching next item from iterator
>
>
On tor, 2010-10-14 at 22:54 -0400, Robert Haas wrote:
> and maybe not that bad, but I wonder if there is some preparatory
> refactoring that could be done to trim it down a bit. I notice, for
> example, that a lot of places that looked at first/last> now look at . In
> particular, all the pathke
Jeff Davis wrote:
> in this case we do clearly have a problem, because the result is
> not equal to the serial execution of the transactions in either
> order.
Yeah, you're right. I misread that example -- newbie with the
PERIOD type.
> So the question is: at what point is the logic wrong?
Robert Haas wrote:
I think the right way to write UPSERT is something
along the lines of:
MERGE INTO Stock t USING (VALUES (10, 1)) s(item_id, balance) ON
s.item_id = t.item_id ...
That led in the right direction, after a bit more fiddling I was finally
able to get something that does what
Tom Lane wrote:
>"Stephen R. van den Berg" writes:
>> If it's inserted in the "special" area, it will not break any
>> compatibility.
>I'll tell you what I really don't like about this proposal: we discuss
>some scheme or other for taking over the "special space" in heap pages
>at least once a ye
Excerpts from Jean-Baptiste Quenot's message of jue oct 21 09:20:16 -0300 2010:
> I get this error when calling the function:
>
> test=# select foobar();
> ERROR: error fetching next item from iterator
I can reproduce this here. The first bug to solve is, I think, getting
a more meaningful err
On Thu, Oct 21, 2010 at 6:57 AM, Tom Lane wrote:
>> Thanks. It also explains my another question why Merge Append cannot
>> be used for UNION ALL plans.
>
> Hmm, seems like the example you show ought to work. I wonder if there
> was an oversight in that patch...
>
Huh, that definitely worked in
I just noticed that there doesn't seem to be any good way of finding
out what a postmaster's default value of unix_socket_directory is.
If you try to SHOW it you just get an empty string. We could probably
fix things so that SHOW exposes the actual setting, but (1) there might
be security argument
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > why would we do this client-side rather than server-side?
>
> Because the timeout is supposed to be a limit on the time allowed
> for specific Java methods to complete, which might be running a
> large number of SQL statements within one invoc
Bruce Momjian wrote:
> why would we do this client-side rather than server-side?
Because the timeout is supposed to be a limit on the time allowed
for specific Java methods to complete, which might be running a
large number of SQL statements within one invocation, and which may
include signifi
Tom Lane wrote:
> Bruce Momjian writes:
> >> Tom Lane wrote:
> >>> I'm all for doing this client-side.
>
> > Uh, why would we do this client-side rather than server-side? If we do
> > it server-side, all interfaces get it.
>
> 1. The API that's being implemented is JDBC-specific.
>
> 2. Even
Bruce Momjian writes:
>> Tom Lane wrote:
>>> I'm all for doing this client-side.
> Uh, why would we do this client-side rather than server-side? If we do
> it server-side, all interfaces get it.
1. The API that's being implemented is JDBC-specific.
2. Even if you want to argue that it would b
Tom Lane wrote:
> you are confusing an array over a domain type with a domain over
> an array type.
Yes I was. Sorry. Argument withdrawn.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
Kevin Grittner wrote:
> Tom Lane wrote:
>
> > I'm all for doing this client-side.
>
> Well, that makes a big difference. Unless someone can make a
> convincing argument for why we should modify the server side to
> support this, I think we should just focus on this one client-side
> patch.
>
"Kevin Grittner" writes:
> Tom Lane wrote:
>> So we will downcast myia to int[], or at least one might assume
>> that's what's happening. But actually it's worse than that: the
>> result of this operation is thought to be myia not int[], because
>> myia itself is taken as matching ANYARRAY, and
Tom Lane wrote:
> regression=# select array[1,2] || 3::myi;
> ERROR: operator does not exist: integer[] || myi
>
> In this case, one might expect myi to be automatically downcast to
< int so that it could be matched up with the int array, but that's
> not happening.
I guess it should allow t
On Thu, 2010-10-21 at 10:29 -0500, Kevin Grittner wrote:
> Basically, when we already have a pivot, but no transaction has yet
> committed, we wait to see if TN commits first. If so, we have a
> problem; if not, we don't. There's probably some room for improving
> performance by cancelling T0 or
Robert Haas writes:
> On Wed, Oct 20, 2010 at 10:03 AM, Tom Lane wrote:
>> My point is that anyplace that is relying on the surface typelem,
>> without drilling down to see what the base type is, is wrong.
>> So yeah, those lookups are (will be) necessary.
> OK. In that case, +1 from me.
I've
On Thu, Oct 21, 2010 at 11:12 AM, Dimitri Fontaine
wrote:
> "David E. Wheeler" writes:
>> Sure. The reason to do it, though, is so that extension authors can create
>> just one metadata file, instead of two (or three, if one must also put such
>> data into the Makefile).
>
> That's a good idea, b
Excerpts from Dimitri Fontaine's message of jue oct 21 12:53:18 -0300 2010:
> This part of the problem didn't receive much thoughts yet, and it shows
> up. About the rest of the patch have been in my head for months, I
> expect less problems there...
Keep on it. You're doing a terrific job.
--
"David E. Wheeler" writes:
> Be aware that PGXS sets a $(VERSION) variable already, so you'll need
> to use another name, I think, to guard from conflicts. This is in
> Makefile.global:
Of course that's not a problem for contribs, and I used EXTVERSION in a
previous version of the patch. I guess
On Oct 21, 2010, at 8:12 AM, Dimitri Fontaine wrote:
> That's a good idea, but my guess is that the implementation cost of
> supporting the control format in your perl infrastructure is at least an
> order of magnitude lower than the cost for me to support your current
> JSON file format, so I lea
Jeff Davis wrote:
> That looks like a reasonable state to me, but I'm not sure exactly
> what the design calls for. I am guessing that the real problem is
> in PreCommit_CheckForSerializationFailure(), where there are 6
> conditions that must be met for an error to be thrown. T2 falls
> out righ
On Tue, Oct 19, 2010 at 8:30 PM, daveg wrote:
> On Wed, Oct 20, 2010 at 04:08:37PM +1300, Mark Kirkwood wrote:
>> On 20/10/10 16:05, Mark Kirkwood wrote:
>> >
>> >
>> >shmget and friends are hugetlbpage aware, so it seems it should 'just
>> >work'.
>> >
>>
>> Heh - provided you specify
>>
>> SHM_
"David E. Wheeler" writes:
> Sure. The reason to do it, though, is so that extension authors can create
> just one metadata file, instead of two (or three, if one must also put such
> data into the Makefile).
That's a good idea, but my guess is that the implementation cost of
supporting the contr
On Wed, Oct 20, 2010 at 1:13 PM, Robert Haas wrote:
> On Wed, Oct 20, 2010 at 3:47 PM, daveg wrote:
>> On Wed, Oct 20, 2010 at 12:28:25PM -0700, Greg Stark wrote:
>>> On Wed, Oct 20, 2010 at 12:17 PM, Greg Stark wrote:
>>> > I don't think it's a big cost once all the processes
>>> > have been fo
On Oct 21, 2010, at 12:33 AM, Dimitri Fontaine wrote:
> I don't see what it buys us in this very context. The main thing here to
> realize is that I wrote about no code to parse the control file. I don't
> think the extension patch should depend on the JSON-in-core patch.
>
> Now, once we have JS
Tom Lane writes:
> ... well, that's just a bug in hstore. *All* the contrib modules
> should be using PGXS, unless they have a damn good reason not to;
> which is not apparent for hstore.
Here's a patch.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Jeff Davis wrote:
>> Also, it appears to be non-deterministic, to a degree at least,
>> so you may not observe the problem in the exact way that I do.
> The SELECTs only look at the root and the predicate doesn't match.
> So each SELECT sets an SIReadLock on block 0 and exits the search.
> Looks
Dimitri Fontaine writes:
> Itagaki Takahiro writes:
>> Why does only hstore have version '9.1'? Any other modules have
>> '9.1devel'.
> It's the only contrib that's not using PGXS but instead directly
> includes $(top_builddir)/src/Makefile.global,
... well, that's just a bug in hstore. *All*
"Stephen R. van den Berg" writes:
> Robert Haas wrote:
>> and break on-disk compatibility just to make it easier to
> If it's inserted in the "special" area, it will not break any
> compatibility.
I'll tell you what I really don't like about this proposal: we discuss
some scheme or other for tak
Itagaki Takahiro writes:
> On Thu, Oct 21, 2010 at 2:18 PM, Tom Lane wrote:
>> The plan for UNION initially involves a couple of SubqueryScan nodes,
>> which impose an extra cost of cpu_tuple_cost per tuple. Â Those later
>> get optimized away, but we don't try to readjust the cost estimates
>> f
Hi,
Here's an updated patch.
I'm still not too fond of the logic in spi.c, but I can't see a better
way to do this. If someone sees a better way, I'm not going to object.
I also made some changes to the SQL functions now that we have a
different API. The previous code pushed and popped sna
1 - 100 of 105 matches
Mail list logo
