Is there any reason to keep separate pg_id and pg_encoding programs, or
should they be merged into a C version of initdb? AFAICS initdb is the
only thing that uses them.
We'll also need to decide the Windows equivalent of the 'don't run as
root' rule - or even if we want to enforce it at all, g
Andrew Dunstan wrote:
>
> Is there any reason to keep separate pg_id and pg_encoding programs, or
> should they be merged into a C version of initdb? AFAICS initdb is the
> only thing that uses them.
Yes, I assume they would go away with a C version.
> We'll also need to decide the Windows equ
Bruce Momjian wrote:
We'll also need to decide the Windows equivalent of the 'don't run as
root' rule - or even if we want to enforce it at all, given that it
appears to be very common practice on Windows to run all services as a
user with Administrator privileges.
I assume we will relax t
Robert Treat writes:
> Hmm... the counter state seems to be that now these commands would tell you
> they are doing something even though they are arn't really doing anything:
Commands are defined in terms of their results, not in terms of their
actions, and certainly not in terms of the amount o
"Andreas Pflug" <[EMAIL PROTECTED]> wrote:
> Bruce Momjian wrote:
>
> >>We'll also need to decide the Windows equivalent of the 'don't run as
> >>root' rule - or even if we want to enforce it at all, given that it
> >>appears to be very common practice on Windows to run all services as a
> >>us
Gaetano Mendola wrote:
Work as non-root is a good practice for windows user too, I'll not bet
for the future that on windows all users will be "super user";
you can choose to start a service like a non super user too, I'd like to
mantain the same policy on windows too.
We're talking about
Hi,
I have those errors on Unixware 713 with yesterday and today's CVS
Script started on Sun Sep 7 20:19:16 2003
$ make
Using GNU make found at /usr/local/bin/gmake
/usr/local/bin/gmake -C doc all
gmake[1]: Entering directory `/home/postgres/pgsql/doc'
gmake[1]: Nothing to be done for `all'.
gmak
--On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
[snip]
/usr/local/bin/gmake -C libpq all
gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq'
cc -O -Kinline,no_host -I../../../src/include -I/usr/local/include -c -o
ip.o ip.c UX:acomp: ERROR: "ip.c", lin
On Sun, 7 Sep 2003, Larry Rosenman wrote:
>
>
> --On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
>
> [snip]
>
> > /usr/local/bin/gmake -C libpq all
> > gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq'
> > cc -O -Kinline,no_host -I../../../src/include -I
--On Sunday, September 07, 2003 12:52:18 -0700 Stephan Szabo
<[EMAIL PROTECTED]> wrote:
On Sun, 7 Sep 2003, Larry Rosenman wrote:
--On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
[snip]
> /usr/local/bin/gmake -C libpq all
> gmake[3]: Entering directory `/home/postgre
On Sun, Sep 07, 2003 at 06:36:47PM +0200, Peter Eisentraut wrote:
> Robert Treat writes:
>
> > Hmm... the counter state seems to be that now these commands would tell you
> > they are doing something even though they are arn't really doing anything:
>
> Commands are defined in terms of their resu
On Sun, 7 Sep 2003, Larry Rosenman wrote:
>
>
> --On Sunday, September 07, 2003 12:52:18 -0700 Stephan Szabo
> <[EMAIL PROTECTED]> wrote:
>
> >
> > On Sun, 7 Sep 2003, Larry Rosenman wrote:
> >
> >>
> >>
> >> --On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
> >>
> >> [snip]
On Sun, 2003-09-07 at 16:46, Bruce Momjian wrote:
> Andrew Dunstan wrote:
> >
> > Is there any reason to keep separate pg_id and pg_encoding programs, or
> > should they be merged into a C version of initdb? AFAICS initdb is the
> > only thing that uses them.
>
> Yes, I assume they would go awa
> However, as of 7.4, that problem is gone too. If you write the function
> just as above (language sql, volatile, not strict) then the planner will
> inline it and indeed what you get is a CASE. Watch this:
Hm. I wonder if there are cases of people using functions like this with
user-defined v
A row lock is represented by storing the locking transaction's ID in
xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is
needed to distinguish this from the case where the transaction is
deleting the tuple.
where is 'HEAP_MARKED_FOR_UPDATE infomask bit' found ?
thanks
From: Tom L
On Sun, Sep 07, 2003 at 04:07:42PM -0700, Jenny - wrote:
> >A row lock is represented by storing the locking transaction's ID in
> >xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is
> >needed to distinguish this from the case where the transaction is
> >deleting the tuple.
>
>
Greg Stark <[EMAIL PROTECTED]> writes:
> Hm. I wonder if there are cases of people using functions like this with
> user-defined volatile functions depending on the function's side effects
> happening the correct number of times. Or do volatile functions not get
> inlined like this?
SQL functions
>A row lock is represented by storing the locking transaction's ID in xmax and setting
>the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is needed to distinguish
>this from the case where the transaction is deleting the tuple.Is there a similar bit modified if the row in question is being waited
Larry Douzie <[EMAIL PROTECTED]> writes:
>> A row lock is represented by storing the locking transaction's ID in
>> xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is
>> needed to distinguish this from the case where the transaction is
>> deleting the tuple.
> Is there a similar
On Sun, Sep 07, 2003 at 11:24:42PM -0400, Tom Lane wrote:
> No. We handle that case by waiting for the transaction that's locked
> the row to commit or abort. (Waiting for a transaction is done by
> having every transaction take out exclusive lock on its xact ID when it
> starts; then would-be w
Is there a array or some sort of datastructures that store all the HeapTupleDatas for all rows in the db?
like we have the LockData storing all the current locks in the db.
thanks!Tom Lane <[EMAIL PROTECTED]> wrote:
Larry Douzie <[EMAIL PROTECTED]>writes:>> A row lock is represented by storing the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Now, if a subtransaction has got a lock on some tuple, and another
> transaction tree tries to grab the lock on that tuple, it should have to
> wait for the entire transaction tree to finish. But what if the
> subtransaction that got the lock aborts? M
Larry Douzie <[EMAIL PROTECTED]> writes:
> Is there a array or some sort of datastructures that store all the
> HeapTupleDatas for all rows in the db?
Er, wouldn't that be the database files?
regards, tom lane
---(end of broadcast)-
Larry Douzie <[EMAIL PROTECTED]>writes:> Is there a array or some sort of datastructures that store all the> HeapTupleDatas for all rows in the db?Er, wouldn't that be the database files?
What i mean is, whats the pointer name to this list of HeapTupleDatas?Tom Lane <[EMAIL PROTECTED]> wrote:
crega
FreeBSD 4.8/i386:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
Chris
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Kurt Roeckx" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, Se
Christopher Kings-Lynne wrote:
> FreeBSD 4.8/i386:
>
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
Interesting. Do you have all the *_r files listed in thread.c? I sure
hope so. I assume you used the template threa
-On [20030908 06:32], Bruce Momjian ([EMAIL PROTECTED]) wrote:
>> Your gethostbyname() is _not_ thread-safe
>> Your getpwuid() is _not_ thread-safe
>> Your functions are _not_ all thread-safe
>
>Interesting. Do you have all the *_r files listed in thread.c? I sure
>hope so. I assume you used the
> Any comments on the UNKNOWN issue? It's not too late to change that for
> 7.4, if we have consensus that we should.
I would actually prefer to get UNKNOWN so I can apply my own default
type, but we're not even given the chance to resolve the unknown issue
ourselves.
CREATE OR REPLACE FUNCTION
Hi all,
Just wondering if someone could help me with this rather specific problem.
I am trying to figure out where i should insert some code that basically
resets stats after a certain number of transactions(or sql statements)
have been executed. Collects Stats after some more statements have been
Rod Taylor <[EMAIL PROTECTED]> writes:
>> Any comments on the UNKNOWN issue? It's not too late to change that for
>> 7.4, if we have consensus that we should.
> I would actually prefer to get UNKNOWN so I can apply my own default
> type, but we're not even given the chance to resolve the unknown
> I don't feel that the anyelement in -> anyelement out mechanism is the
> last word in polymorphism, though. Care to propose additional features
> of the same kind? If you can find a way to describe the behavior you
> want in terms of the function signature, it'd be worth considering ...
For my
Manfred Koizar wrote:
> On Sun, 7 Sep 2003 11:43:42 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >I assume this completes this TODO:
> >
> > * Order duplicate index entries by tid for faster heap lookups
>
> I don't think so, because the patch does nothing to keep the sort
> order
On Sun, 07 Sep 2003 12:23:28 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Maybe so, but it would degrade the performance in the unique-index case
>if we do it as the TODO is worded.
The patch would only hurt with a unique index, if there are lots of
duplicate tuples at CREATE INDEX time.
>My own o
On Mon, 01 Sep 2003 08:46:09 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] writes:
>> it took 69 minutes to finish, 75% of this time was devoted to create 2
>> indexes on varchar(2) with value being 'O', 'N' or null;
>
>I still say it's either strcoll or qsort's fault.
If qsort is
I assume this completes this TODO:
* Order duplicate index entries by tid for faster heap lookups
and you will submit it for 7.5? If you want to post it now, I can get
it into the 7.5 queue so we don't forget it.
-
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume this completes this TODO:
> * Order duplicate index entries by tid for faster heap lookups
I don't know why that TODO entry exists, but I think the idea is
counterproductive. The existing btree code will tend to put newer
versions of a ro
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I assume this completes this TODO:
> > * Order duplicate index entries by tid for faster heap lookups
>
> I don't know why that TODO entry exists, but I think the idea is
> counterproductive. The existing btree code will tend to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> * Order duplicate index entries by tid for faster heap lookups
>
>> I don't know why that TODO entry exists, but I think the idea is
>> counterproductive.
> I assume you are talking about a unique index that probably only has a
> few
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >>> * Order duplicate index entries by tid for faster heap lookups
> >
> >> I don't know why that TODO entry exists, but I think the idea is
> >> counterproductive.
>
> > I assume you are talking about a unique index
On Sun, 7 Sep 2003 11:43:42 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>I assume this completes this TODO:
>
> * Order duplicate index entries by tid for faster heap lookups
I don't think so, because the patch does nothing to keep the sort
order once the index is initially created
--On Sunday, September 07, 2003 14:19:00 -0500 Larry Rosenman
<[EMAIL PROTECTED]> wrote:
--On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
[snip]
/usr/local/bin/gmake -C libpq all
gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq'
cc -O -Kinline,no_h
41 matches
Mail list logo
