Hi All,
Some of the ideas regarding vacuum improvements were discussed here:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00863.php
http://archives.postgresql.org/pgsql-patches/2008-06/msg00059.php
A recent thread was started by Robert Haas, but I don't know if we logically
concluded t
Indeed I was acting weird there. I had completely forgotten about the
bool pointer. Moreover, I actually got confused about the palloc0's
return type...whether it was a datum or a pointer to datum. Looked back
at the expansion and got it clear.
Thanks a lot Mr. Tom.
Regards,
Vaibhav
On Mon, 20
On Mon, May 23, 2011 at 2:57 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, May 23, 2011 at 8:26 AM, Bruce Momjian wrote:
>> > Sorry, I was unclear. ?The question is whether the case of _name_ of the
>> > locale is significant, meaning can you have two locale names that differ
>> > only
On Mon, May 23, 2011 at 10:47 PM, Hitoshi Harada wrote:
> That's true. But if the planning cost is an only issue, why not adding
> new GUC for user to choose if they prefer it or not? Of course if we
> have some method to predict which way to go before proving both ways,
> it's great. Do you have
On Mon, May 23, 2011 at 4:02 PM, Tom Lane wrote:
>> ...we'd need to plan the subquery twice, once with a parameterized
>> qual m_id = $1 pushed down, and once without that. We could then
>> compare the cost of a nest-loop with the qual to the cost of a merge
>> or hash join without it. But this
On Mon, May 23, 2011 at 10:13 PM, Josh Kupershmidt wrote:
> Well actually, I got into messing with this solely from the Todo list.
> Which, of course, neglected to mention the thread about pg_comments,
> or the other objects missing from \dd.
Heh. Sounds like updating the Todo list would be a go
2011/5/24 Tom Lane :
> Robert Haas writes:
> Yeah. I fixed the executor in 9.1, but got hung up on how to fix the
> planner. So the planner still only knows how to do this for the case of
> an inner indexscan, ie, it can't handle parameterizing any piece of a
> plan larger than a single indexsca
2011/5/24 Robert Haas :
> On Sat, May 21, 2011 at 12:49 PM, Hitoshi Harada wrote:
>> 2011/5/5 Hitoshi Harada :
>> Do I understand correctly? If so, could someone explain more detail of
>> how to get Parameterized Scan in the planner?
>
> I think we're going to need Tom to give the definitive word
At the developer meeting last week:
http://wiki.postgresql.org/wiki/PgCon_2011_Developer_Meeting there was
an initial schedule for 9.2 hammered out and dutifully transcribed at
http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Development_Plan , and
the one part I wasn't sure I had written down
On Sun, May 22, 2011 at 11:33 PM, Robert Haas wrote:
> On Thu, May 19, 2011 at 10:36 PM, Josh Kupershmidt wrote:
>> Precisely, and I think there's a solid argument for putting
>> constraints into bucket 1 above, as this patch does, since there's no
>> good room to display constraint comments insi
On Fri, May 13, 2011 at 4:16 PM, Noah Misch wrote:
> if (level >= ShareUpdateExclusiveLock)
> ++strong_lock_counts[my_strong_lock_count_partition]
> sfence
> if (strong_lock_counts[my_strong_lock_count_partition] == 1)
> /*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
According to Linux Standard Base Core Specification 3.1 [1], the exit
status should be '3' when the server isn't running.
I've attached a very simple patch that resolves this cosmetic issue,
which applies to all branches.
My initial search regardin
Dan Ports wrote:
> [I think it's similar to the argument you were making.]
Similar, but you found a simpler, shorter way to the end, which
should make Robert happy. ;-)
> On Sat, May 21, 2011 at 03:09:12PM -0500, Kevin Grittner wrote:
>> The issue can be rephrased to this: If transaction T1
I have thought about this quite a bit and am fairly certain we do not need
to track this linkage between row versions. One strong hint to this
is that all the work I've seen on multiversion serializability
theory defines a rw-conflict to be one transaction reading an object
and the other writing *t
Dan Ports wrote:
> Specifically, the problem is a missing check in
> OnConflict_CheckForSerializationFailure. We check whether the
> conflict has caused the writer to become a pivot, but only if
> neither the reader or writer is committed. Why is that last
> condition there? In this case, the re
On Mon, May 23, 2011 at 03:01:40PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Good deal. Given that conclusion, the other policy decision I anticipate
> > affecting this particular patch is the choice of syntax. Presumably, it
> > will be
> > a new common_func_opt_item. When I last looked
On Mon, May 23, 2011 at 02:53:01PM -0400, Robert Haas wrote:
> On Mon, May 23, 2011 at 2:46 PM, Noah Misch wrote:
> > On Mon, May 23, 2011 at 02:11:39PM -0400, Robert Haas wrote:
> >> On Mon, May 23, 2011 at 1:53 PM, Tom Lane wrote:
> >> > Maybe. ?But casts would be the least of our concerns if w
Greg Stark writes:
> This was the thing that concerned me. If anyone wants to add this
> feature for a new data type they're going to have to understand and
> tie their code to all this internal parser node stuff. That means
> their code will be much more closely tied to a specific version, will
>
Dan Ports wrote:
> On Sat, May 21, 2011 at 03:09:12PM -0500, Kevin Grittner wrote:
>> I went back to the example which persuaded me and took another
>> look. On review I see that this didn't prove the point because
>> there was a dangerous structure with T1 as a pivot which should
>> have caused
On Mon, May 23, 2011 at 12:01 PM, Tom Lane wrote:
> Given that the helper function is going to have a
> signature along the lines of "(internal, internal) -> internal", it's
> going to be difficult for anyone to use it for non-builtin functions
> anyhow.
I hate to go around in circles on this bu
I forgot to commit before diff. Here is correct version.
--
With best regards,
Alexander Korotkov.
arrayanalyze-0.2.1.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
Robert Haas writes:
> On Sat, May 21, 2011 at 12:49 PM, Hitoshi Harada wrote:
>> Do I understand correctly? If so, could someone explain more detail of
>> how to get Parameterized Scan in the planner?
> I think we're going to need Tom to give the definitive word on this,
> but I believe that the
On Wed, May 11, 2011 at 8:46 AM, Pavan Deolasee
wrote:
> Why do the set and clear functions need pass-by-reference (Buffer *)
> argument ? I don't see them modifying the argument at all. This patch adds
> the clear function, but the existing set function also suffers from that.
Yep, I just copied
Noah Misch writes:
> Good deal. Given that conclusion, the other policy decision I anticipate
> affecting this particular patch is the choice of syntax. Presumably, it will
> be
> a new common_func_opt_item. When I last looked at the keywords list and tried
> to come up with something, these w
On Mon, May 23, 2011 at 2:46 PM, Noah Misch wrote:
> On Mon, May 23, 2011 at 02:11:39PM -0400, Robert Haas wrote:
>> On Mon, May 23, 2011 at 1:53 PM, Tom Lane wrote:
>> > Maybe. ?But casts would be the least of our concerns if we were trying
>> > to change the column type. ?Changing typmod doesn'
On Sat, May 21, 2011 at 12:49 PM, Hitoshi Harada wrote:
> 2011/5/5 Hitoshi Harada :
>> https://commitfest.postgresql.org/action/patch_view?id=548
>>
>> I'll work further if I find time.
>
> After more thought, pulling up aggregate subquery in narrow
> conditional cases is quite hard path, especial
On Mon, May 23, 2011 at 02:11:39PM -0400, Robert Haas wrote:
> On Mon, May 23, 2011 at 1:53 PM, Tom Lane wrote:
> > Maybe. ?But casts would be the least of our concerns if we were trying
> > to change the column type. ?Changing typmod doesn't affect the set of
> > operations that could be applied
On Sat, May 21, 2011 at 03:09:12PM -0500, Kevin Grittner wrote:
> I went back to the example which persuaded me and took another look. On
> review I see that this didn't prove the point because there was a
> dangerous structure with T1 as a pivot which should have caused SSI to
> break the cycle.
On Sun, May 22, 2011 at 5:52 AM, Kohei KaiGai wrote:
> The attached patch fixes up case handling in foreign tables.
>
> Now it didn't assign security label on foreign table on its creation
> time, and didn't check access rights on the dml hook.
> This patch fixes these problems; It allows foreign
On Mon, May 23, 2011 at 1:53 PM, Tom Lane wrote:
> Maybe. But casts would be the least of our concerns if we were trying
> to change the column type. Changing typmod doesn't affect the set of
> operations that could be applied to a column, whereas changing type
> surely does.
OK, this is the cr
Second version of patch attached. Main changes:
1) ANY and ALL keywords handling.
2) Collecting statistics of array length. It is used in "column <@ const".
3) Relatively accurate estimation of "column <@ const" selectivity. This
estimation is most hard part of patch. I'm warrying that there could
Robert Haas writes:
> On Mon, May 23, 2011 at 1:21 PM, Tom Lane wrote:
>> ... But I remain of the opinion that that's the wrong place
>> to put it.
> So you said here:
> http://archives.postgresql.org/pgsql-hackers/2011-01/msg02575.php
> http://archives.postgresql.org/pgsql-hackers/2011-01/msg0
On Mon, May 23, 2011 at 1:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 23, 2011 at 12:42 PM, Noah Misch wrote:
>>> There were two proposals on the table:
>>>
>>> 1. Attach a "f(from_typmod, to_typmod, is_explicit) RETURNS boolean"
>>> function
>>> to the pg_cast; call it in fin
Robert Haas writes:
> On Mon, May 23, 2011 at 12:42 PM, Noah Misch wrote:
>> There were two proposals on the table:
>>
>> 1. Attach a "f(from_typmod, to_typmod, is_explicit) RETURNS boolean" function
>> to the pg_cast; call it in find_coercion_pathway()
>> 2. Attach a "f(FuncExpr) RETURNS Expr
On Mon, May 23, 2011 at 8:26 AM, Bruce Momjian wrote:
> Sorry, I was unclear. The question is whether the case of _name_ of the
> locale is significant, meaning can you have two locale names that differ
> only by case and behave differently?
That would seem surprising to me, but I really have no
On Mon, May 23, 2011 at 12:42 PM, Noah Misch wrote:
> I'd like to revive the discussion that arose during the last CommitFest over
> the proper design for identifying no-op length coercions like varchar(4) ->
> varchar(8). Here is the root of the original debate:
>
> http://archives.postgresql.o
I'd like to revive the discussion that arose during the last CommitFest over
the proper design for identifying no-op length coercions like varchar(4) ->
varchar(8). Here is the root of the original debate:
http://archives.postgresql.org/message-id/20110109220353.gd5...@tornado.leadboat.com
Th
Robert Haas wrote:
> The point I was driving at is - in what way will that affect the
> behavior of subsequent operations?
You haven't answered why you think it should matter for OID or for
write conflict on READ COMMITTED but not here. The logical concept
of a row which is modified is a mean
On Sun, May 22, 2011 at 12:32:48PM -0500, Josh Berkus wrote:
> MauMau,
>
> > Could you give me your frank opinions about which of 8.4 or 9.0
> > you recommend to ISVs who embed PostgreSQL?
> As an ISV, though, you need to devise a plan whereby you can apply
> update releases to your client's mach
Oh...well... I messed it up! Thanks a lot for that. The problem I think is
the bool pointer. Will check it soon.
--
Sent from my Android
On 23 May 2011 19:28, "Tom Lane" wrote:
> Vaibhav Kaushal writes:
>> My mind started wandering after that error. Now, actually, i was trying
to
>> do something
From: "Kevin Grittner"
"MauMau" wrote:
Make pg_ctl's -s option suppress informational event logging.
This will ultimately be up to a committer (and I'm not one), but to
me it seems reasonable to back-patch if it is addressed this way.
the PostgreSQL Windows service must be registered by "
On Mon, May 23, 2011 at 10:20 AM, Tom Lane wrote:
> Aidan Van Dyk writes:
>> So, if SSI conflicts something on the UPDATE case, it would necessrily
>> have to conflict the DELETE+INSERT case as well, and vice-versa.
>
> This argument is fundamentally bogus, because an UPDATE is not the same
> thi
On Sun, May 22, 2011 at 11:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> I believe, however, that applying this will invalidate the contents of
>> any hash indexes on array types that anyone has built using 9.1beta1.
>> Do we need to do something about that?
>
> Like bumping catversion?
Sure.
Aidan Van Dyk writes:
> So, if SSI conflicts something on the UPDATE case, it would necessrily
> have to conflict the DELETE+INSERT case as well, and vice-versa.
This argument is fundamentally bogus, because an UPDATE is not the same
thing as DELETE followed by INSERT. In the former case the new
On Mon, May 23, 2011 at 2:26 AM, Kevin Grittner
wrote:
> I don't see that -- it could be correct because of the conceptual
> difference between an UPDATE and a DELETE/INSERT pair.
>
>> In other words, if SSI needs to be more rigorous in the UPDATE
>> case, it can only be because snapshot isolati
Vaibhav Kaushal writes:
> My mind started wandering after that error. Now, actually, i was trying to
> do something like this:
> *last_result = palloc0(sizeof(Datum));
> bool *isnnuull = true;
> *last_result = slot_getattr(slot, num_atts, *isnnuull);
This seems utterly confused about data types.
On 05/16/2011 04:09 AM, Magnus Hagander wrote:
On Mon, May 16, 2011 at 06:14, Andrew Dunstan wrote:
I've committed a bunch of changes both in the Postgres code and the
buildfarm code to enable running the isolation checks under MSVC. There's
one hurdle that I haven't overcome: the code tries
Robert Haas wrote:
> On Sun, May 22, 2011 at 9:39 PM, Bruce Momjian wrote:
> > Tim Uckun wrote:
> >> pg_upgrade from 8.4 to 9.0 fails with the following error message.
> >>
> >> old and new cluster lc_collate values do not match
> >>
> >>
> >> on 8.4 show lc_collate outputs
> >>
> >>
Thanks for the suggestion. I will look into that shortly and let you know.
By the way i am on fedora 13.
--
Sent from my Android
On 23 May 2011 17:28, "Kevin Grittner" wrote:
> Vaibhav Kaushal wrote:
>
>> Do you think its the 'slot_getattr' causing the seg-fault?
>
> On many platforms it's not ha
nil nil wrote:
> i have read all that material from that link it gives me overall
> detail but i am still not clear how to develop it. what softwares i
> need to use, how to integrate with postgresql, i want to know the
> basic steps for patch development.
It would help if we knew where you we
Vaibhav Kaushal wrote:
> Do you think its the 'slot_getattr' causing the seg-fault?
On many platforms it's not hard to get a core file out of a segfault
(perhaps by using ulimit), and then get a stack trace (using gdb or
similar) to see exactly where it is happening.
-Kevin
--
Sent via pg
Well, I had thought of the same what you said.
My mind started wandering after that error. Now, actually, i was trying to
do something like this:
*last_result = palloc0(sizeof(Datum));
bool *isnnuull = true;
*last_result = slot_getattr(slot, num_atts, *isnnuull);
elog(INFO, "Last result for slot_
On 23.05.2011 13:44, Vaibhav Kaushal wrote:
Hello,
I made some code changes, compilation went fine but the database could not
start with the message:
LOG: server process (PID 17684) was terminated by signal 11: Segmentation
fault
I think this is because of memory allocation outside of any mem
Hello,
I made some code changes, compilation went fine but the database could not
start with the message:
LOG: server process (PID 17684) was terminated by signal 11: Segmentation
fault
I think this is because of memory allocation outside of any memory context.
Is it possible to create some va
54 matches
Mail list logo
