On Fri, Dec 2, 2011 at 6:52 AM, Kohei KaiGai wrote:
> At least, it is working. However, it is not a perfect solution to the
> future updates
> of code paths in the core.
Hmm. So, do you want this committed? If so, I think the major thing
it lacks is documentation.
I can't help noticing that th
On Saturday, December 03, 2011 01:09:48 AM Alvaro Herrera wrote:
> Excerpts from Andres Freund's message of vie dic 02 19:09:47 -0300 2011:
> > Hi all,
> >
> > There is also the point about how permission checks on the actual
> > commands (in comparison of modifying command triggers) and such are
On Fri, Dec 2, 2011 at 7:09 PM, Alvaro Herrera
wrote:
> Hmm, we currently even have a patch (or is it already committed?) to
> avoid locking objects before we know the user has permission on the
> object. Getting to the point of calling the trigger would surely be
> even worse.
I committed a fir
Excerpts from Andres Freund's message of vie dic 02 19:09:47 -0300 2011:
> Hi all,
>
> There is also the point about how permission checks on the actual commands
> (in
> comparison of modifying command triggers) and such are handled:
>
> BEFORE and INSTEAD will currently be called independentl
On Fri, Dec 2, 2011 at 6:25 PM, Daniel Farina wrote:
> Here's a protocol: have pg_start_backup() write a file that just means
> "backing up". Restarts are OK, because that's all it means, it has no
> meaning to a recovery/restoration process.
>
> When one wishes to restore, one must touch a file
On Thu, Dec 1, 2011 at 3:47 PM, Robert Haas wrote:
> On Tue, Nov 29, 2011 at 9:10 PM, Daniel Farina wrote:
>> Reviving a thread that has hit its second birthday:
>>
>> http://archives.postgresql.org/pgsql-hackers/2009-11/msg00024.php
>>
>> In our case not being able to restart Postgres when it ha
Hi,
First thing first: thank you Andres for a great review, I do appreciate
it. Please find attached a newer version of the patch. The github
repository is also updated.
Andres Freund writes:
> I think at least a
> * command_tagtext
Added.
> Why is there explicit documentation of not che
Heikki Linnakangas writes:
> Hmm, so you're saying that the FDW function needs to be able to return
> multiple paths for a single joinrel. Fair enough, and that's not
> specific to remote joins. Even a single-table foreign scan could be
> implemented differently depending on whether you prefer
On 03.12.2011 00:24, Tom Lane wrote:
Heikki Linnakangas writes:
On 02.12.2011 18:55, Tom Lane wrote:
Furthermore, you seem to be imagining that there is only one best path
for any join, which isn't the case.
No, I understand that the planner considers many alternatives, even at
the same tim
Heikki Linnakangas writes:
> On 02.12.2011 18:55, Tom Lane wrote:
>> Furthermore, you seem to be imagining that there is only one best path
>> for any join, which isn't the case.
> No, I understand that the planner considers many alternatives, even at
> the same time, because of different output
Heikki tipped me off to a possible problem with CLOG contention that
he noticed while doing some benchmarking, and so I (you know what's
coming, right?) tried to reproduce it on Nate Boley's 32-core AMD
machine. It turns out that increasing NUM_CLOG_BUFFERS from 8 to 32
delivers a significant perf
Hi all,
There is also the point about how permission checks on the actual commands (in
comparison of modifying command triggers) and such are handled:
BEFORE and INSTEAD will currently be called independently of the fact whether
the user is actually allowed to do said action (which is inconsist
Tom Lane wrote:
> Bruce Momjian writes:
> > I have applied the attached patch to mention the debugger. OK?
>
> > Server developers should consider using the configure options
> > --enable-cassert and --enable-debug to
> > enhance the
> > ability to detect and debug serv
On 24.11.2011 23:56, Jan Urbański wrote:
On 24/11/11 16:15, Heikki Linnakangas wrote:
On 24.11.2011 10:07, Jan Urbański wrote:
On 23/11/11 17:24, Mika Eloranta wrote:
[PL/Python in 9.1 does not preserve SQLSTATE of errors]
Oops, you're right, it's a regression from 9.0 behaviour.
The fix lo
"Kevin Grittner" wrote:
> Robert Haas wrote:
>> Kevin Grittner wrote:
>>> The extraWaits code still looks like black magic to me
>> [explanation of the extraWaits behavior]
>
> Thanks. I'll spend some time reviewing this part. There is some
> rearrangement of related code, and this should
Hi,
Hm. I just noticed a relatively big hole in the patch: The handling of
deletion of dependent objects currently is nonexistant because they don't go
through ProcessUtility...
Currently thinking what the best way to nicely implement that is. For other
commands the original command string is
On 02.12.2011 18:55, Tom Lane wrote:
Heikki Linnakangas writes:
Tom, what do you think of this part? I think it would be a lot more
natural API if the planner could directly ask the FDW to construct a
plan for a three (or more)-way join, instead of asking it to join a join
relation into another
All:
*ping*
Trying to restart this discussion, since the feature bogged down on
spec. We have consensus that we need to change how replication mode is
mangaged; surely we can reach consensus on how to change it?
On 11/8/11 11:39 AM, Josh Berkus wrote:
>
>> configuration data somewhere else, bu
2011/12/2 Pavel Stehule :
> Hello
>
>>
>> My attempt at a syntax that could also cover Peter's wish for multiple
>> checker functions:
>>
>> CHECK FUNCTION { func(args) | ALL [IN SCHEMA schema] [FOR ROLE user] }
>> [ USING check_function ] OPTIONS (optname optarg [, ...])
>>
>
some other idea abo
Robert Haas wrote:
> On Fri, Dec 2, 2011 at 2:35 PM, Bruce Momjian wrote:
> > Agreed. ?Doing something once and doing something in the sort loop are
> > two different overheads.
>
> OK, so I tried to code this up. Adding the new amproc wasn't too
> difficult (see attached). It wasn't obvious to
Hello
>
> My attempt at a syntax that could also cover Peter's wish for multiple
> checker functions:
>
> CHECK FUNCTION { func(args) | ALL [IN SCHEMA schema] [FOR ROLE user] }
> [ USING check_function ] OPTIONS (optname optarg [, ...])
>
check_function should be related to one language, so you
On Fri, Dec 2, 2011 at 2:35 PM, Bruce Momjian wrote:
> Agreed. Doing something once and doing something in the sort loop are
> two different overheads.
OK, so I tried to code this up. Adding the new amproc wasn't too
difficult (see attached). It wasn't obvious to me how to tie it into
the tupl
>>
>> [ shrug... ] If you are bothered by that, get off your duff and provide
>> the function for your datatype. But it's certainly going to be in the
>> noise for btree index usage, and I submit that query parsing/setup
>> involves quite a lot of syscache lookups already. I think that as a
>> pe
Tom Lane wrote:
> Robert Haas writes:
> > OK, but I think it's also going to cost you an extra syscache lookup,
> > no? You're going to have to check for this new support function
> > first, and then if you don't find it, you'll have to check for the
> > original one. I don't think there's any h
Hello
>
>> Also, what kind of report does this generate?
>
> Good question. I suspect what Pavel has now will raise errors, but that
> doesn't scale very nicely to checking more than one function, or even to
> finding more than one bug in a single function.
>
I stop on first error now. Reason is
Heikki Linnakangas writes:
> Tom, what do you think of this part? I think it would be a lot more
> natural API if the planner could directly ask the FDW to construct a
> plan for a three (or more)-way join, instead of asking it to join a join
> relation into another relation.
I think this is f
On Thu, Dec 1, 2011 at 6:21 AM, Joel Jacobson wrote:
> 2011/12/1 Kris Jurka
>>
>>
>>
>> On Wed, 30 Nov 2011, Joel Jacobson wrote:
>>
>> > As you know, LISTEN/NOTIFY is broken in the Java client library. You
>> > have to
>> > do a SELECT 1 in a while-loop to receive the notifications.
>> >
>> > ht
On 2011-12-01 22:14, Peter Eisentraut wrote:
On tor, 2011-12-01 at 14:37 +0100, Yeb Havinga wrote:
On 2011-11-29 18:47, Peter Eisentraut wrote:
On tis, 2011-11-29 at 07:07 +0200, Peter Eisentraut wrote:
On mån, 2011-11-28 at 11:41 +0100, Yeb Havinga wrote:
On 2011-11-15 21:50, Peter Eisentrau
2011/12/1 Kris Jurka
>
>
> On Wed, 30 Nov 2011, Joel Jacobson wrote:
>
> > As you know, LISTEN/NOTIFY is broken in the Java client library. You
> have to
> > do a SELECT 1 in a while-loop to receive the notifications.
> >
> > http://jdbc.postgresql.org/documentation/head/listennotify.html
>
> Thi
In Postgres 8.4, pg_upgrade preserved pg_class relfilenodes by creating
files in the file system. In Postgres 9.0, we changed this by creating
pg_upgrade_support functions which allow us to directly preserve
pg_class.oids.
Unfortunately, check.c was not updated to reflect this and clusters
using
Robert Haas writes:
> OK, but I think it's also going to cost you an extra syscache lookup,
> no? You're going to have to check for this new support function
> first, and then if you don't find it, you'll have to check for the
> original one. I don't think there's any higher-level caching around
Peter Eisentraut writes:
> On ons, 2011-11-30 at 10:53 -0500, Tom Lane wrote:
>> I think the important point here is that we need to support more than
>> one level of validation, and that the higher levels can't really be
>> applied by default in CREATE FUNCTION because they may fail on perfectly
- Цитат от Tom Lane (t...@sss.pgh.pa.us), на 02.12.2011 в 05:21 -
> Robert Haas writes:
>> On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost wrote:
>>> I don't have any particular care about if cidr has indexing support or
>>> not. I'm certainly not *against* it, except insofar as it encour
On Fri, Dec 2, 2011 at 12:16 AM, Tom Lane wrote:
> It should be the same or better. Right now, we are going through
> FunctionCall2Coll to reach the FCI-style comparator. The shim function
> would be more or less equivalent to that, and since it's quite special
> purpose I would hope we could sh
On Fri, Dec 2, 2011 at 3:42 AM, Peter Eisentraut wrote:
> - ip4 is fixed-length, so it's much faster. (Obviously, this is living
> on borrowed time. Who knows.)
Fair point.
> - Conversely, it might be considered a feature that ip4 only stores IPv4
> addresses.
True, although this can also be
* Peter Eisentraut (pete...@gmx.net) wrote:
> - ip4 really only stores a single address, not a netmask, not sometimes
> a netmask, or sometimes a range, or sometimes a network and an address,
> or whatever. That really seems like the most common use case, and no
> matter what you do with the other
On 2 December 2011 01:13, Tom Lane wrote:
> Regardless of that, I'm still of the opinion that this patch is
> fundamentally misdesigned. The way it's set up, it is only possible to
> have a fast path for types that are hard-wired into tuplesort.c, and
> that flies in the face of twenty years' wor
On 17.11.2011 17:24, Tom Lane wrote:
Heikki Linnakangas writes:
When the FDW recognizes it's being asked to join a ForeignJoinPath and a
ForeignPath, or two ForeignJoinPaths, it throws away the old SQL it
constructed to do the two-way join, and builds a new one to join all
three tables.
It sh
I tried to implement remaining portion of the object creation permission patches
using this approach; that temporary saves contextual information using existing
ProcessUtility hook and ExecutorStart hook.
It likely works fine towards my first problem; system catalog entry
does not have
all the inf
Rebased with head.
--
With best regards,
Alexander Korotkov.
rangetypegist-0.4.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.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
>> Do I understand right that the reason why the check function is
>> different from the validator function is that it would be more
difficult
>> to add the checks to the validator function?
>
>> Is that a good enough argument? From a user's perspective it is
>> difficult to see wh
On ons, 2011-11-30 at 10:53 -0500, Tom Lane wrote:
> I think the important point here is that we need to support more than
> one level of validation, and that the higher levels can't really be
> applied by default in CREATE FUNCTION because they may fail on perfectly
> valid code.
How would this w
On 04.10.2011 09:43, Fujii Masao wrote:
On Mon, Oct 3, 2011 at 4:32 PM, Simon Riggs wrote:
I don't think this should use the rm_safe_restartpoint machinery. As you
said, it's not tied to any specific resource manager. And I've actually been
thinking that we will get rid of rm_safe_restartpoint
On ons, 2011-11-30 at 17:56 -0500, Robert Haas wrote:
> On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost wrote:
> > Erm, isn't there a contrib type that already does all that for you..?
> > ip4r or whatever? Just saying, if you're looking for that capability..
>
> Oh, huh, good to know. Still, I'
44 matches
Mail list logo
