-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Dec 15, 2006 at 06:44:10PM -0500, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Operator Superclass ?
>
> Yeah, I thought about that too, but I don't like it much ... can't
> entirely put my finger on why not [...]
I think I
Andrew Dunstan wrote:
> Tom Lane wrote:
>> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>>
>>> We change libpq from time to time. Besides, how many DBs are there that
>>> match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
>>> expect lots of surprise.
>>>
>>
>> Um, but how many
Gregory Stark <[EMAIL PROTECTED]> writes:
> Perhaps something like
> Operator Class
> and
> Data Type Class
> Data type classes happens to involve operator classes but it sounds like
> you're looking for them to specify other behaviours of how data types
> inter-relate than just their operator cl
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Operator Superclass ?
>
> Yeah, I thought about that too, but I don't like it much ... can't
> entirely put my finger on why not, except that class/superclass usually
> implies that the objects you're talking ab
Gregory Stark <[EMAIL PROTECTED]> writes:
> Operator Superclass ?
Yeah, I thought about that too, but I don't like it much ... can't
entirely put my finger on why not, except that class/superclass usually
implies that the objects you're talking about are all the same kind of
thing, whereas what we
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The main objection I can think of is that a novice seeing the terms
> "operator class" and "operator group" isn't going to have any context
> to know which is which, but I'm not sure that we can devise any terms
> that would help much.
Operator Superclass
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
I don't understand how we decide that everybody who needs a given
event+message has got it, if we don't know who (if anyone) is listening?
How do we decide that we no longer need the info in the shmem buff
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> I don't understand how we decide that everybody who needs a given
>> event+message has got it, if we don't know who (if anyone) is listening?
>> How do we decide that we no longer need the info in the shmem buffer?
> Keep a p
Andrew Dunstan wrote:
> I don't understand how we decide that everybody who needs a given
> event+message has got it, if we don't know who (if anyone) is listening?
> How do we decide that we no longer need the info in the shmem buffer?
Keep a pointer in shared memory for each listener backen
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
My current (possibly naive) thought is that I'll need two structures,
one of listeners and one of
notifications waiting to be picked up, each protected by a lock. In the
case of the second structure, we would just separate the eve
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> My current (possibly naive) thought is that I'll need two structures,
> one of listeners and one of
> notifications waiting to be picked up, each protected by a lock. In the
> case of the second structure, we would just separate the event and the
>
Martijn van Oosterhout writes:
> I think we're on the same page. I thought of another motivation also:
> protections/permissions. We don't currently allow people to mess with
> definitions needed by system catalogs, so you don't want to allow users
> to mess with the btree(int4) class, but you wan
Martijn van Oosterhout writes:
> The trigger never runs as the owner of the table AIUI, only ever as the
> definer of the function or as session user.
Yeah. This might itself be seen as a bug: I think you could make a
reasonable case that the default behavior ought to be to run as the
table owne
Martijn van Oosterhout wrote:
On Fri, Dec 15, 2006 at 11:52:33AM -0500, Andrew Dunstan wrote:
Isn't the problem that they can do more than just things with the table?
If the trigger runs as the owner of the table it can do *anything* the
owner can do. So if we allow the alter privilege to in
On Fri, Dec 15, 2006 at 11:52:33AM -0500, Andrew Dunstan wrote:
> Isn't the problem that they can do more than just things with the table?
> If the trigger runs as the owner of the table it can do *anything* the
> owner can do. So if we allow the alter privilege to include ability to
> place a t
At 10:45 AM 12/15/2006, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
> There are various attempts at providing better timing infrastructure at low
> overhead but I'm not sure what's out there currently. I expect to
do this what
> we'll have to do is invent a pg_* abstraction that ha
Albe Laurenz wrote:
Looking at pg_trigger I have the impression that there is no such thing
as an 'owner of a trigger', and consequently the owner of the trigger
would automatically be the table owner.
I understand the reservations about the TRIGGER privilege, but I think
that it is obvious anyw
Joachim Wieland <[EMAIL PROTECTED]> writes:
> Appended is a patch that adds JST and JDT into Asia.txt and the Default set.
Um ... is there a JDT? Last I heard, Japan does not observe daylight
time. I don't see a JDT in the old PG set of recognized zone names, and
I'd think we'd have heard compla
On Fri, Dec 15, 2006 at 10:17:20AM -0500, Tom Lane wrote:
> >> However, I encounter the problem of timestamp.:-(
> >> Was anyone recognizing this problem?
> > The list of accepted timezones is now configurable, check through the
> > docs how to find the list and set it the way you want.
> Yeah, b
Ted Petrosky wrote:
take a look at this link
http://www.entropy.ch/blog/Software/2006/02/04/PostgreSQL-Universal-Binary-Build-Tips.html
I've seen links to there before, but it always times out for me. As it
is now :-(
I've got your followup email though, so I'll try a build as soon a I
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > There are various attempts at providing better timing infrastructure at low
> > overhead but I'm not sure what's out there currently. I expect to do this
> > what
> > we'll have to do is invent a pg_* abstraction
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
> Hi.
>
> I was doing the field test of Slony-I 1.2.2 release now.
> However, I encounter the problem of timestamp.:-(
> Was anyone recognizing this problem?
>
> Ver 8.1.5
> saito=# select 'Fri Dec 15 14:26:05.502000 2006 JST'::timestamp;
>timesta
Hackers,
I had a server reboot for an unknown reason, after the server restarted one
of the disks was not mounted before Postgresql tried to start. The startup
failed (see log below), after I mounted the disks and tried to start
Postgresql again there was a HINT about corrupted data and a WARN
Tom Lane <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout writes:
>> On Fri, Dec 15, 2006 at 03:48:50PM +0900, Hiroshi Saito wrote:
>>> I was doing the field test of Slony-I 1.2.2 release now.
>>> However, I encounter the problem of timestamp.:-(
>>> Was anyone recognizing this problem?
>
>> T
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 15. Dezember 2006 11:28 schrieb Simon Riggs:
>> Until we work out a better solution we can fix this in two ways:
>>
>> 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ...
>> 2. enable_analyze_timer = off | on (default) (USERSET)
On Fri, Dec 15, 2006 at 09:56:57AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Fri, Dec 15, 2006 at 12:20:46PM +, Simon Riggs wrote:
> >> Maybe sampling every 10 rows will bring things down to an acceptable
> >> level (after the first N). You tried less than 10 didn't you?
>
Gregory Stark <[EMAIL PROTECTED]> writes:
> There are various attempts at providing better timing infrastructure at low
> overhead but I'm not sure what's out there currently. I expect to do this what
> we'll have to do is invent a pg_* abstraction that has various implementations
> on different ar
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> You left out the case where --enable_thread_safety is specified.
> ...
> If libldap_r.so does require the same libs, please add $EXTRA_LDAP_LIBS
> to the 'LDAP_LIBS_FE="-lldap_r"' line as well.
Actually, I did that in the patch-as-committed. It seems t
Martijn van Oosterhout writes:
> On Fri, Dec 15, 2006 at 03:48:50PM +0900, Hiroshi Saito wrote:
>> I was doing the field test of Slony-I 1.2.2 release now.
>> However, I encounter the problem of timestamp.:-(
>> Was anyone recognizing this problem?
> The list of accepted timezones is now configur
Martijn van Oosterhout writes:
> On Fri, Dec 15, 2006 at 12:20:46PM +, Simon Riggs wrote:
>> Maybe sampling every 10 rows will bring things down to an acceptable
>> level (after the first N). You tried less than 10 didn't you?
> Yeah, it reduced the number of calls as the count got larger. It
Am Freitag, 15. Dezember 2006 11:28 schrieb Simon Riggs:
> Until we work out a better solution we can fix this in two ways:
>
> 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ...
>
> 2. enable_analyze_timer = off | on (default) (USERSET)
The second one is enough in my mind.
--
Peter E
Martijn van Oosterhout wrote:
>> I guess that adding $EXTRA_LDAP_LIBS to -lldap_r will be enough,
>> judging from the evidence on Linux.
>
> Linux doesn't need the extra libraries, it's linked properly.
Yes - what I mean is, libldap_r.so references only
NEEDED libsasl.so.7
NEEDED li
* Simon Riggs:
>> I think the best option is setitimer(), but it's not POSIX so
>> platform support is going to be patchy.
>
> Don't understand that. I thought that was to do with alarms and
> signals.
You could use it for sampling. Every few milliseconds, you record
which code is executing (pos
On Fri, Dec 15, 2006 at 12:20:46PM +, Simon Riggs wrote:
> > I
> > wrote a patch that tried statistical sampling, but the figures were too
> > far off for people's liking.
>
> Well, I like your ideas, so if you have any more...
>
> Maybe sampling every 10 rows will bring things down to an acc
On Fri, Dec 15, 2006 at 12:15:59PM +, Gregory Stark wrote:
> There are various attempts at providing better timing infrastructure at low
> overhead but I'm not sure what's out there currently. I expect to do this what
> we'll have to do is invent a pg_* abstraction that has various implementati
On Fri, 2006-12-15 at 11:50 +0100, Martijn van Oosterhout wrote:
> On Fri, Dec 15, 2006 at 10:28:08AM +, Simon Riggs wrote:
> > Until we work out a better solution we can fix this in two ways:
> >
> > 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ...
> >
> > 2. enable_analyze_time
On Fri, Dec 15, 2006 at 01:06:08PM +0100, Albe Laurenz wrote:
> I guess that adding $EXTRA_LDAP_LIBS to -lldap_r will be enough,
> judging from the evidence on Linux.
Linux doesn't need the extra libraries, it's linked properly.
Additionally, on Linux there is no difference between ldap and ldap_
"Martijn van Oosterhout" writes:
> BTW, doing gettimeofday() without kernel entry is not really possible.
That's too strong a conclusion. Doing gettimeofday() without some help from
the kernel isn't possible but it isn't necessary to enter the kernel for each
call.
There are various attempts at
Olivier PRENANT wrote:
>> You left out the case where --enable_thread_safety is specified.
>> In that case, the frontend has to be linked with libldap_r.so
>> instead of libldap.so.
>
> Yes, this was on purpose, my goal is to try to make a second
> patch when...
>
>> Does libldap_r.so _not_ requi
Hi Albe,
Thanks for your remarks
On Fri, 15 Dec 2006, Albe Laurenz wrote:
> Date: Fri, 15 Dec 2006 09:54:13 +0100
> From: Albe Laurenz <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr, Tom Lane <[EMAIL PROTECTED]>
> Cc: pgsql-hackers list
> Subject: RE: [HACKERS] unixware and --with-ldap
>
> > Here's the
On Fri, Dec 15, 2006 at 08:20:22PM +0900, Hiroshi Saito wrote:
> Thanks.
> I do not think that this is normal.
>
> As for 8.2..
> SELECT timeofday()::timestamp;
> ERROR: invalid input syntax for type timestamp: "Fri Dec 15
> 14:26:05.502000 2006 JST"
Err, sounds like a bug to me. Good ahead
Hi list,
Le vendredi 15 décembre 2006 11:50, Martijn van Oosterhout a écrit :
> BTW, doing gettimeofday() without kernel entry is not really possible.
> You could use the cycle counter but it has the problem that if you have
> multiple CPUs you need to calibrate the result. If the CPU goes to
> sl
- Original Message -
From: "Martijn van Oosterhout"
I was doing the field test of Slony-I 1.2.2 release now.
However, I encounter the problem of timestamp.:-(
Was anyone recognizing this problem?
The list of accepted timezones is now configurable, check through the
docs how to find the
On Fri, Dec 15, 2006 at 10:28:08AM +, Simon Riggs wrote:
> Until we work out a better solution we can fix this in two ways:
>
> 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ...
>
> 2. enable_analyze_timer = off | on (default) (USERSET)
What exactly would this do? Only count actu
On Fri, Dec 15, 2006 at 03:48:50PM +0900, Hiroshi Saito wrote:
> Hi.
>
> I was doing the field test of Slony-I 1.2.2 release now.
> However, I encounter the problem of timestamp.:-(
> Was anyone recognizing this problem?
The list of accepted timezones is now configurable, check through the
docs h
On Thu, 2006-12-14 at 19:05 -0500, Tom Lane wrote:
> "Kelly Burkhart" <[EMAIL PROTECTED]> writes:
> > I hope this isn't a "crummy mainboard" but I can't seem to affect
> > things by changing clock source (kernel 2.6.16 SLES10). I tried
> > kernel command option clock=XXX where XXX in
> > (cyclone,
On Thu, Dec 14, 2006 at 08:31:59PM -0500, Tom Lane wrote:
> > How the backend implements it may be easier as one single large
> > opclass. Essentially the operater class table becomes merely a
> > placeholder for the name (maybe also aliases?), which can still be used
> > in index declarations, but
Peter Eisentraut wrote:
> Tom Lane wrote:
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
The question in my mind is what privilege to check and when.
>>>
>>> By extrapolation of the SQL standard, I'd say we'd need to check
>>> the EXECUTE privilege of the function at run t
> Here's the diff for configure.in that works for me.
I have a concern about this patch:
> if test "$enable_thread_safety" = yes; then
> # on some platforms ldap_r fails to link without PTHREAD_LIBS
> AC_CHECK_LIB(ldap_r, ldap_simple_bind, [],
> [AC_MSG_ERRO
49 matches
Mail list logo
