On Sat, 8 Oct 2005, Jim C. Nasby wrote:
On Fri, Oct 07, 2005 at 12:22:14PM -0400, Rod Taylor wrote:
I could vote for:
bool pg_query_cancel(int)
backend_cancel or cancel_backend sounds like it should terminate the
entire backend like kill -TERM would do.
Agreed. In fact, I thought th
Josh Berkus writes:
>> I was wonderring, because I create a lot of server side utility functions,
>> whether adding an option to pg_dump to just dump functions has been
>> considered. I did a quick perusal of the code, and noted that there is a
>> separate section within pg_dump to get the functio
On Sat, Oct 08, 2005 at 02:24:00PM -0700, Josh Berkus wrote:
> Sean,
>
> > I was wonderring, because I create a lot of server side utility functions,
> > whether adding an option to pg_dump to just dump functions has been
> > considered. I did a quick perusal of the code, and noted that there is a
On Thu, Sep 29, 2005 at 03:28:27PM +0200, Zeugswetter Andreas DAZ SD wrote:
>
> > In my original example, a sequential scan of the 1TB of 2KB
> > or 4KB records, => 250M or 500M records of data, being sorted
> > on a binary value key will take ~1000x more time than reading
> > in the ~1GB Btree
On Sat, Oct 08, 2005 at 04:59:22PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Maybe I'm missing something, but is it possible to ensure notifications
> > aren't lost using Heikki's method, since everything's only in shared
> > memory? Or is the idea that stuff would not
Sean,
> I was wonderring, because I create a lot of server side utility functions,
> whether adding an option to pg_dump to just dump functions has been
> considered. I did a quick perusal of the code, and noted that there is a
> separate section within pg_dump to get the functions, but it is not
While it's important to stick with policies lest they become useless, I
think the bigger picture needs to be remembered: the policies are in
place to produce good design decisions and to not let the development
cycle drag out uncontrollably. In this case, ISTM that there is now a
better naming sche
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Maybe I'm missing something, but is it possible to ensure notifications
> aren't lost using Heikki's method, since everything's only in shared
> memory? Or is the idea that stuff would not survive a backend crash?
Listen/notify state has never survived
On Fri, Oct 07, 2005 at 12:22:14PM -0400, Rod Taylor wrote:
> I could vote for:
>
> bool pg_query_cancel(int)
>
> backend_cancel or cancel_backend sounds like it should terminate the
> entire backend like kill -TERM would do.
Agreed. In fact, I thought that's what it actually did
On Thu, Oct 06, 2005 at 10:30:24AM -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > It might make sense to change the semantics so that we never lose a
> > notification, if we're going to implement NOTIFY 'msg', but that's another
> > discussion.
>
> That's pretty much
Jaime Casanova <[EMAIL PROTECTED]> writes:
> but this example seems to clarify (or at least i think) that we have to avoid
> pulling up subquerys containing volatile functions:
This is exactly the same example discussed in previous threads on this
issue. Do you think it will change anyone's mind?
sandeep satpal wrote:
> The _bt_compare function in "nbtree.c" file calls "FunctionCall2" and it
> passes two arguments , one is the scankey which we want to search on and
> other key is on current b-tree node.
>
> My problem is I want to pass three parameter and the third argument will
> be
the comments fot contain_volatile_functions in clauses.c says...
src/backend/optimizer/util/clauses.c:
*
* XXX we do not examine sub-selects to see if they contain uses of
* volatile functions. It's not real clear if that is correct or not...
*/
but this example seems to clarify (or at least
> The point is I'm having a hard time seeing what the actual
> gain is in not changing it back. If the principal name
> mismatches, we're going to get rejected anyway, so it's not
> really a problem there. Even though the gain in changing it
> back isn't all that big either, why should we intro
> > Anyway. This makes it impossible for a 8.1 client to
> connect to a 8.0
> > server, or a 8.0 client to a 8.1 server, in any case where
> the service
> > name has changed - such as a win32 active directory deployment, but
> > I'm sure many others as well.
>
> How important is that really?
On Sat, Oct 08, 2005 at 12:48:50PM +0530, sandeep satpal wrote:
> The _bt_compare function in "nbtree.c" file calls "FunctionCall2" and it
> passes two arguments , one is the scankey which we want to search on and
> other key is on current b-tree node.
>
> My problem is I want to pass three par
I was wonderring, because I create a lot of server side utility functions,
whether adding an option to pg_dump to just dump functions has been
considered. I did a quick perusal of the code, and noted that there is a
separate section within pg_dump to get the functions, but it is not able to
be trig
Tom Lane <[EMAIL PROTECTED]>:
> Atsushi Ogawa <[EMAIL PROTECTED]> writes:
> > When _bt_check_unique finds a dead item that has same data as new
> > item, LP_DEAD is set to the item. Can we reuse this dead item instead
> > of inserting new item?
>
> This strikes me as a pretty bad idea for the same
Argh! That's some sed coolness :)
Chris
Martijn van Oosterhout wrote:
On Fri, Oct 07, 2005 at 04:46:12PM +0800, Christopher Kings-Lynne wrote:
If you have huge plain text dumps, and just want to restore one table
it's usually painful. Attached is a small shell script that can take a
plain
Hello,
Sorry for last mail.
I hope this time I will explain my doubt more clearly.
The _bt_compare function in "nbtree.c" file calls "FunctionCall2" and it
passes two arguments , one is the scankey which we want to search on and
other key is on current b-tree node.
My problem is I want to p
20 matches
Mail list logo
