Yann Michel wrote:
Hi,
On Wed, Nov 16, 2005 at 01:25:43PM +0800, Christopher Kings-Lynne wrote:
I belive a lock is acquired on every table including inherited children
BEFORE doing ANY dumping. To allow pg_dump to get a consistent dump
snapshot.
Well, thanks for all the answers. Are the lo
On Wed, Nov 16, 2005 at 08:09:31AM +0100, Yann Michel wrote:
> Well, thanks for all the answers. Are the locks then released once they
> are not needed any more like in 2PC?
2PC doesn't release any locks, it can't to maintain integrity.
> That should still leaqve the taken snapshot of the release
I'm asking, because we have a bigger datawarehouse and dump the data for
a backup every night. Unfortunately, the backup now takes realy long.
That means, other processes that insert data will have to wait which is
sometime really long! I was searching for a way to avoid this. I thought
besides th
Hi,
On Wed, Nov 16, 2005 at 01:25:43PM +0800, Christopher Kings-Lynne wrote:
> I belive a lock is acquired on every table including inherited children
> BEFORE doing ANY dumping. To allow pg_dump to get a consistent dump
> snapshot.
Well, thanks for all the answers. Are the locks then released
> Oracle recently gave some money to Zend to make proper Oracle support
> for PHP. In that interface they use bind variables. Apart from
greater
> speed, sqlinjection becomes history as well.
I did the same for PostgreSQL for PHP 5.1.
http://au3.php.net/manual/en/function.pg-
On Nov 16, 2005, at 13:53 , Tom Lane wrote:
[ looks at buildfarm... ] It looks like you dropped the extra options
on all of wallaroo's branches, which is not good. They should work in
8.0 and later, and you should test 'em where they're claimed to work.
[looks at build-farm.conf, blushes] A
In some cases, Oracle will also replace literals with bind variables so that it can perform a sort-of-bind-value soft parse later.
On 11/15/05, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
PostgreSQL combines both parses into one, so every new query iseffectively a hard parse (unless it's prepared, th
On Wed, Nov 16, 2005 at 01:27:29PM +0800, Christopher Kings-Lynne wrote:
> >We should probably throw a notice or warning if we go to a table lock,
> >too.
>
> That's not very useful, because you can only do somethign about it AFTER
> the 1 hour exclusive lock merge has already run :)
Not true; i
On Tue, Nov 15, 2005 at 11:53:11PM -0500, Tom Lane wrote:
> Michael Glaesemann <[EMAIL PROTECTED]> writes:
> > On Nov 15, 2005, at 23:19 , Tom Lane wrote:
> >> Apparently you don't get to have --enable-nls either :-(
>
> > And we've got green! :)
> > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=w
We should probably throw a notice or warning if we go to a table lock,
too.
That's not very useful, because you can only do somethign about it AFTER
the 1 hour exclusive lock merge has already run :)
Chris
---(end of broadcast)---
TIP 2: Don't
I belive a lock is acquired on every table including inherited children
BEFORE doing ANY dumping. To allow pg_dump to get a consistent dump
snapshot.
Chris
Yann Michel wrote:
Hi,
On Wed, Nov 16, 2005 at 09:59:44AM +0800, Christopher Kings-Lynne wrote:
It acquires share locks on EVERY tabl
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On Nov 15, 2005, at 23:19 , Tom Lane wrote:
>> Apparently you don't get to have --enable-nls either :-(
> And we've got green! :)
> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=wallaroo&dt=2005-11-15%
> 2022:55:15
> Thanks, Tom, for taking the tim
On Tue, Nov 15, 2005 at 11:04:59PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > So the recent thread about getting 7.4 compiling on OS X inspired me.
> > But what I can't understand is that I've yanked --with-ssl, but it's
> > still looking for libssl:
>
> Tad hard to be
On Tue, Nov 15, 2005 at 11:04:59PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > So the recent thread about getting 7.4 compiling on OS X inspired me.
> > But what I can't understand is that I've yanked --with-ssl, but it's
> > still looking for libssl:
>
> Tad hard to be
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Hi, I can run following odd command(note that no spaces between 1 and
> where):
> test=# select 1where true;
> Is this a bug or a feature? This is PostgreSQL 8.1.0.
Standard flex lexer behavior. "1" followed by "w" cannot begin
a legal token, therefore
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> So the recent thread about getting 7.4 compiling on OS X inspired me.
> But what I can't understand is that I've yanked --with-ssl, but it's
> still looking for libssl:
Tad hard to believe. Maybe you missed a "make distclean" or so?
(BTW, the flag is -
On Tue, Nov 15, 2005 at 07:16:21PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Josh Berkus writes:
> > > But even REPLACE requires predicate locking. There's no real way to get
> > > around it.
> >
> > The point though is that REPLACE is restricted to a type of predicate
> > narrow enough
PostgreSQL combines both parses into one, so every new query is
effectively a hard parse (unless it's prepared, then there is no parse
or optimization at all).
On Tue, Nov 15, 2005 at 07:33:46PM +0100, Marcus Engene wrote:
> Hi list.
>
> I've mostly used Oracle in the past, but for a web-project
So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=cuckoo&dt=2005-11-15%2023:56:22
ccache gcc -no-cpp-precomp -O2 -fno-strict-aliasing -g -
On 2005-11-16, Yann Michel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Wed, Nov 16, 2005 at 09:59:44AM +0800, Christopher Kings-Lynne wrote:
>> It acquires share locks on EVERY table.
>
> do you mean on EVERY inherited table once one of them is dumped? Or do
> you mean that a share lock is requested(an
Hi,
On Wed, Nov 16, 2005 at 09:59:44AM +0800, Christopher Kings-Lynne wrote:
> It acquires share locks on EVERY table.
do you mean on EVERY inherited table once one of them is dumped? Or do
you mean that a share lock is requested(and hold) on each of them once
one is dumped, i.e., sequentially?
Marcus Engene <[EMAIL PROTECTED]> writes:
> Which will be the same as the second call. There is quite a big
> difference in performance using bind variables.
>
> Does Postgres work the same? Where can I go for more info?
You can do this (or close to it) but you need to explicitly PREPARE
the quer
It acquires share locks on EVERY table.
Yann Michel wrote:
Hi all,
On Sun, Nov 13, 2005 at 03:22:23AM +0100, Yann Michel wrote:
I'm using PG_DUMP for backing up a postgres 7.4 database. As I have
seen, the pg_dump aquires a table lock while dump the table's content.
What will happen, if I hav
NO, it won't reduce everybody's security.
You obviously don't understand what I'm trying to say.
It would NOT be the default option. The user could just choose by
SPECIFYING it, that PostGre don't control the privileged he has.
This discussion is amazing. Without this option, I CANNOT use PostG
Larry Rosenman wrote:
> Bruce Momjian wrote:
> > The SCO compiler is so buggy (and for so many years) I see no reason
> > to even look at a bug report from someone using it.
> >
>
> I **REALLY** wish you would STOP saying that, Bruce. The current OpenServer
I will not if I believe it is true.
Hi, I can run following odd command(note that no spaces between 1 and
where):
test=# select 1where true;
?column?
--
1
(1 row)
Is this a bug or a feature? This is PostgreSQL 8.1.0.
--
SRA OSS, Inc. Japan
Tatsuo Ishii
---(end of broadcast)
Renaming the file sounds like an excellent design decision since the current
name is a proven "human factor" bug.
I am sorry, but as soon as you look at the files it is obvious that they
are not "just" log files. If someone
is going to delete the xlog they are going to do it no matter what w
Yann Michel wrote:
> Hi all,
>
> On Sun, Nov 13, 2005 at 03:22:23AM +0100, Yann Michel wrote:
> >
> > I'm using PG_DUMP for backing up a postgres 7.4 database. As I have
> > seen, the pg_dump aquires a table lock while dump the table's content.
> > What will happen, if I have a basic table and se
On Nov 15, 2005, at 23:19 , Tom Lane wrote:
Apparently you don't get to have --enable-nls either :-(
And we've got green! :)
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=wallaroo&dt=2005-11-15%
2022:55:15
Thanks, Tom, for taking the time to look at this and explaining it a
bit to me.
Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
> > The driver does not actually issue PREPARE or EXECUTE statements; the
> > server is pretending that the protocol-level Prepare/Bind/Execute
> > messages are actually something issuing PREPARE/EXECUTE at the SQL level
>
> I had not
Hi all,
On Sun, Nov 13, 2005 at 03:22:23AM +0100, Yann Michel wrote:
>
> I'm using PG_DUMP for backing up a postgres 7.4 database. As I have
> seen, the pg_dump aquires a table lock while dump the table's content.
> What will happen, if I have a basic table and several inherited tables.
> Will th
Just to summarize, MySQL REPLACE is INSERT or DELETE/INSERT, while they
have a SET clauses that allows UPDATE, and INSERT has a ON DUPLICATE KEY
UPDATE clause too.
I think the INSERT ... ON DUPLICATE KEY is undesirable because this
functionality should have a new keyword in the first position, e
Josh Berkus wrote:
> So we thus have two seperate use cases. The first, for bulk loading/ETL is
> what MERGE fulfills rather neatly and for that full table locking is
> perfectly OK, even desirable. You really don't want to MERGE-load the
> same table on two threads at once.
>
> The second
Simon Riggs wrote:
> I've been looking at ways of doing INSERT then UPDATE, but it doesn't
> seem very easy to avoid unique index violations in that case. So doing
> the UPDATE first then INSERTs later seems like the way to go.
INSERT has to be first to avoid a race condition (see my previous
emai
On Monday 2005-11-14 20:48, Tim Allen wrote:
OOPS deleted pg_xlog because surely it was only a log file.
>
> We've seen reports of people firing this particular foot-gun before,
> haven't we? Would it make sense to rename pg_xlog to something that
> doesn't sound like it's "just" full of log fil
Tom Lane wrote:
> Josh Berkus writes:
> > But even REPLACE requires predicate locking. There's no real way to get
> > around it.
>
> The point though is that REPLACE is restricted to a type of predicate
> narrow enough to be enforced through a unique-index mechanism, and so
> it's implementable
Josh Berkus wrote:
> Jaime,
>
> > why? seems that REPLACE only work if there are at least one row
> > matching...
>
> Scenario:
>
> session1: REPLACE 1
> session2: REPLACE . 1
> session1: check to see that "1" exists no
> session2: ch
We were initially logging out of the Windows GUI environment and back in
again to do the Windows builds. Discovering runas made the whole
process MUCH less painful. So far I haven't needed to use any advanced
features of sudo or runas; in my view either is easy to use for the
common
cases. I'll
Bruce Momjian wrote:
> The SCO compiler is so buggy (and for so many years) I see no reason
> to even look at a bug report from someone using it.
>
I **REALLY** wish you would STOP saying that, Bruce. The current OpenServer
Compiler (UDK), is the same as on UnixWare, and is **MUCH** better than
http://www.postgresql.org/docs/faqs.FAQ_MINGW.html
That is where we started, and I should have mentioned it, even
though the post to which I was replying suggested that Gevik had
read that and was looking for more detail. We hope to contribute
a patch to fill in details; meanwhile, I was hoping I
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > This only happens because of the unique index. There's no predicate
> > locking involved. The btree code goes some lengths to make this work;
>
> That's one way to look at it; the other is to say that we have predicate
> locking fo
On Tue, 2005-11-15 at 10:27 -0800, Josh Berkus wrote:
> > The UPSERT concept is also supported by Teradata, who simply append an
> > ELSE INSERT clause onto the standard UPDATE syntax. MySQL REPLACE seems
> > to me to be a fairly small subset of MERGE functionality and we ought to
> > be able to o
The SCO compiler is so buggy (and for so many years) I see no reason to
even look at a bug report from someone using it.
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Thu, Nov 10, 2005 at 11:53:04PM
On Tue, Nov 15, 2005 at 10:29:34PM +0100, Magnus Hagander wrote:
> You still lose in the nested group scenario.
>
> And whlie a privilege like backup/restore can be used to overwrite any
> file on the system, you must be able to execute arbitrary API calls to
> do that. Whereas with admin/poweruse
> > > Ah, now we are making progress. If there was a way to
> give up file
> > > access permissions so you could no longer write files to,
> say, the
> > > Windows System directory, this would go a long way to solving the
> > > issue. Currently, if the Postmaster runs as admin, anyone with
>
On Tue, Nov 15, 2005 at 10:15:01PM +0100, Magnus Hagander wrote:
> > Ah, now we are making progress. If there was a way to give up
> > file access permissions so you could no longer write files
> > to, say, the Windows System directory, this would go a long
> > way to solving the issue. Currentl
> > > For example, does the windows model allow you to say (without
> > > creating a new user): I irrevocably restrict my access to files
> > > owned by user X for this process *only*. Or to files under
> > > subdirectory Y. Or I irrevocably restrict my access to open new
> > > network sockets.
On Tue, Nov 15, 2005 at 08:43:06PM +0100, Magnus Hagander wrote:
> Ok. Didn't know that part about nonexistant ids.
Usernames are implementation details, if you ask to become user 38587,
the kernel doesn't check whether they exist. You just might not be able
to open any files anymore :)
> > For e
> > There is *NOTHING* wrong with the model in this case. It's the
> > specific implementation of the mdoel that is broken.
> > If you assign every user uid "0" in Unix, I beleive you'd
> get the same
> > problem as when you assign every user an admin on
> windows... Both are
> > equally stupi
On 11/15/05, Josh Berkus wrote:
> Simon,
>
> > The UPSERT concept is also supported by Teradata, who simply append an
> > ELSE INSERT clause onto the standard UPDATE syntax. MySQL REPLACE seems
> > to me to be a fairly small subset of MERGE functionality and we ought to
> > be able to offer that f
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Normally I'd plump for following the standard ... but AFAIR, we have had
> bucketloads of requests for REPLACE functionality, and not one request
> for spec-compatible MERGE. If, as it appears, full-spec MERGE is also a
> whole lot harder and slower than REP
On Tue, Nov 15, 2005 at 10:27:10AM -0800, Josh Berkus wrote:
> Yes, I guess my hesitation on the full-table-lock strategy is that it
> doesn't really fulfill the mandate for why people want REPLACE-like
> statements ... to give them an INSERT-or-UPDATE with *higher* efficiency
> and concurrency
Hi list.
I've mostly used Oracle in the past, but for a web-project I took the
opportunity to try Postgres.
When a select is done in Oracle, it first checks if the select is cached
(ie parsed tree, optimizer choices & such). It does this by
[functionality equal to] a byte to byte compare wit
Simon,
> The UPSERT concept is also supported by Teradata, who simply append an
> ELSE INSERT clause onto the standard UPDATE syntax. MySQL REPLACE seems
> to me to be a fairly small subset of MERGE functionality and we ought to
> be able to offer that functionality as a side branch of the main wo
There is a long TODO about it:
* Merge xmin/xmax/cmin/cmax back into three header fields
Before subtransactions, there used to be only three fields needed to
store these four values. This was possible because only the current
transaction looks at the
You made no mention that you read our FAQ_MINGW file, which is the
definitive document on how to build on Win32.
---
Kevin Grittner wrote:
> We have spent a lot of time on this to be able to do Windows builds
> during the be
Dave Cramer <[EMAIL PROTECTED]> writes:
> One thing though if the date is 64 bit instead of float, what does
> the binary output look like? Are they different ?
Quite, it's int64 instead of double ...
> If so this would seem to complicate things quite a bit.
Recent PG versions tell you which r
I've talked to Ken Geis via email. He suggests that there is
considerable overhead to be saved if we go to binary; especially in
date, and timestamp fields
One thing though if the date is 64 bit instead of float, what does
the binary output look like? Are they different ?
If so this would
On T, 2005-11-15 at 09:53 +0100, Martijn van Oosterhout wrote:
> On Tue, Nov 15, 2005 at 01:38:31AM -0500, Jonah H. Harris wrote:
> > Hey Simon,
> > I'm doing some research into recursive query planning in terms of theory
> > as-well-as actual implementation in other RDBMS. Let me get back to you
On Tue, Nov 15, 2005 at 10:58:31AM -0600, Jim C. Nasby wrote:
> BTW, my point was that the reason many windows users run with admin
> rights is because windows doesn't provide a viable alternative (unlike
> OS X).
Err, sorry, hit send too soon. My point about OS X isn't meant to start
a flame war,
Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > (Of course this just begs the question of whether we could convert
> > over to GNU indent. But I suppose that isn't a realistic option
> > for the current go-round.)
>
> Yeah, I was wondering the same thing yesterday. The README in the
> pgindent di
On Tue, Nov 15, 2005 at 11:39:37AM -0500, Rod Taylor wrote:
> > Well, a bigger issue is that windows makes things a lot more difficult
> > to do if you don't have admin on your account. Yes, there is runas, but
> > windows doesn't exactly foster people working from the command line. And
> > IIRC ru
On Tue, Nov 15, 2005 at 05:33:38PM +0100, Magnus Hagander wrote:
> There is *NOTHING* wrong with the model in this case. It's the specific
> implementation of the mdoel that is broken.
> If you assign every user uid "0" in Unix, I beleive you'd get the same
> problem as when you assign every user a
Tom Lane wrote:
> Bruce Momjian writes:
> > Alvaro Herrera wrote:
> >> It would be nice if the developers could run pgindent easily on their
> >> local trees to minimize conflicts.
>
> > The entire NetBSD indent, already patched, is on our FTP server. Isn't
> > that good enough?
>
> News to me,
On Mon, Nov 14, 2005 at 07:38:00PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Do we really need to prevent inserts from happening under a SELECT FOR
> > UPDATE? ISTM that's trying to apply serializable concurrency to SELECT
> > FOR UPDATE even if it's running in a read
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rod Taylor
> Sent: 15 November 2005 16:40
> To: Jim C. Nasby
> Cc: Pollard, Mike; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Running PostGre on DVD
>
> > Well, a bigger issue is that wind
On Mon, 2005-11-14 at 22:30, [EMAIL PROTECTED] wrote:
> On Mon, Nov 14, 2005 at 10:02:32PM -0500, Robert Treat wrote:
> > > Isn't this the sort of case that Tom just explained as not functioning
> > > in 8.1, as the STABLE functions, and all functions called by the
> > > STABLE functions will use t
> Well, a bigger issue is that windows makes things a lot more difficult
> to do if you don't have admin on your account. Yes, there is runas, but
> windows doesn't exactly foster people working from the command line. And
> IIRC runas isn't nearly as nice to use as sudo.
Couldn't the installer cre
On Mon, Nov 14, 2005 at 10:30:48PM -0500, [EMAIL PROTECTED] wrote:
> On Mon, Nov 14, 2005 at 10:02:32PM -0500, Robert Treat wrote:
> > > Isn't this the sort of case that Tom just explained as not functioning
> > > in 8.1, as the STABLE functions, and all functions called by the
> > > STABLE functio
> > > I don't understand why an user can't WILLINGLY (by EXPLICITLY
> > > setting an
> > > OPTION) allow a privileged administrator to run PostGre.
> >
> > Well, to start with, it increases the support costs of the
> product as
> > a whole to the community. Adding an option with severe security
On Tue, Nov 15, 2005 at 09:56:03AM -0500, Pollard, Mike wrote:
> a little painful to get to it. But at least by putting it into contrib,
> it may be useful to someone. Especially if the idea is to put a sample
Keep in mind that compiling something on windows is extremely painful
for most people.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: 15 November 2005 15:15
> To: Magnus Hagander
> Cc: pgsql-hackers@postgresql.org
> Subject: Réf. : RE: [HACKERS] Running PostGre on DVD
>
>
>
>
>
> I don't understand
On Tue, Nov 15, 2005 at 08:10:40AM -0800, Stephan Szabo wrote:
> On Tue, 15 Nov 2005 [EMAIL PROTECTED] wrote:
>
> > I don't understand why an user can't WILLINGLY (by EXPLICITLY setting an
> > OPTION) allow a privileged administrator to run PostGre.
>
> Well, to start with, it increases the suppo
Andrew, I'm getting a bit angry (and I'm sorry for that) because I think
the performances of Postgres are better than Firebird and I'm frustrated to
have to compile it whereas it would be simpler for everybody to have an
option.
It seem to be impossible though, I will use Firebird.
Thanks for
On Tue, 15 Nov 2005 [EMAIL PROTECTED] wrote:
> I don't understand why an user can't WILLINGLY (by EXPLICITLY setting an
> OPTION) allow a privileged administrator to run PostGre.
Well, to start with, it increases the support costs of the product as a
whole to the community. Adding an option with
Well, first, you ought to learn the name of the product. It's Postgres
or PostgreSQL, but not PostGre.
I suspect that you will find other issues anyway in running from a
datadir on a read-only medium. I suggest you see if you can do it
regardless of this issue. If not, then some other produc
Tom Lane wrote:
> (Of course this just begs the question of whether we could convert
> over to GNU indent. But I suppose that isn't a realistic option
> for the current go-round.)
Yeah, I was wondering the same thing yesterday. The README in the
pgindent directory mentions a GNU indent version
Bruce Momjian writes:
> Alvaro Herrera wrote:
>> It would be nice if the developers could run pgindent easily on their
>> local trees to minimize conflicts.
> The entire NetBSD indent, already patched, is on our FTP server. Isn't
> that good enough?
News to me, and I guess to Alvaro too. Is th
On 11/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I don't understand why an user can't WILLINGLY (by EXPLICITLY setting an
> OPTION) allow a privileged administrator to run PostGre.
> It is a MAJOR problem for me, that will force me to use another database
> because my database will be on
NO, it won't reduce everybody's security.
You obviously don't understand what I'm trying to say.
It would NOT be the default option. The user could just choose by
SPECIFYING it, that PostGre don't control the privileged he has.
This discussion is amazing. Without this option, I CANNOT use Po
Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > One of the reasons I wanted Bruce to post the proposed diff was so that
> > we could eyeball-verify that it's only hitting comments. I think it's
> > worth a little more trouble to check the results given that we plan to
> > run it against 8.1.
>
> I
I don't understand why an user can't WILLINGLY (by EXPLICITLY setting an
OPTION) allow a privileged administrator to run PostGre.
It is a MAJOR problem for me, that will force me to use another database
because my database will be on a DVD and I'm not sure that on the PC on
which it will be ex
On Tue, Nov 15, 2005 at 04:01:24PM +0100, Andreas Joseph Krogh wrote:
> > The example given in this thread certainly isn't going to change
> > anybody's mind. "Hi, I propose reducing everybody's security because
> > my local admins insist on an utterly brain-dead security policy."
>
> Tom, nobody
Tom Lane wrote:
> Bruce Momjian writes:
> > Magnus Hagander wrote:
> >> Do we really want to run cosmetic cleanups on a stable branch?
>
> > Agreed, it is not a great idea, but if we don't, then 8.1.X and CVS HEAD
> > will not match indenting, and patches generated by 8.1.X users will not
> > app
On Tue, Nov 15, 2005 at 04:13:47PM +0200, Hannu Krosing wrote:
> On T, 2005-11-15 at 09:53 +0100, Martijn van Oosterhout wrote:
> > On Tue, Nov 15, 2005 at 01:38:31AM -0500, Jonah H. Harris wrote:
> > > Hey Simon,
> > > I'm doing some research into recursive query planning in terms of theory
> > >
Tom Lane wrote:
> One of the reasons I wanted Bruce to post the proposed diff was so that
> we could eyeball-verify that it's only hitting comments. I think it's
> worth a little more trouble to check the results given that we plan to
> run it against 8.1.
It would be nice if the developers coul
On Tuesday 15 November 2005 03:37 pm, Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> >> To be honest, the fact that Postgres forces you to run as a
> >> non-admin user has given me nothing but headaches. (yes, I
> >> know, the problem is defaulting everyone to admin rights is
>
> > This has been proposed before, and always rejected. While you're
> > always welcome to provide a patch, I'm very doubtful it would be
> > accepted into the main product.
>
> The example given in this thread certainly isn't going to change
anybody's mind.
> "Hi, I propose reducing everybody'
>
> The example given in this thread certainly isn't going to change
> anybody's mind. "Hi, I propose reducing everybody's security because
> my local admins insist on an utterly brain-dead security policy."
>
What's wrong with that? ;)
But seriously, the proposal is not to reduce everybody's s
> > Magnus Hagander wrote:
> >> Do we really want to run cosmetic cleanups on a stable branch?
>
> > Agreed, it is not a great idea, but if we don't, then 8.1.X and CVS
> > HEAD will not match indenting, and patches generated by 8.1.X users
> > will not apply cleanly to CVS HEAD. And if we don'
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> To be honest, the fact that Postgres forces you to run as a
>> non-admin user has given me nothing but headaches. (yes, I
>> know, the problem is defaulting everyone to admin rights is
>> the problem. But that's where I am). I have been kicking
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This only happens because of the unique index. There's no predicate
> locking involved. The btree code goes some lengths to make this work;
That's one way to look at it; the other is to say that we have predicate
locking for a very specific class of p
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> Makes sense. I've stripped --with-openssl, and --with-tcl and --with-
> python for good measure. It still fails, and to my eye, with the same
> failure.
Much smaller list of symbols though:
ld: Undefined symbols:
_bindtextdomain
_dgettext
Appar
On Tuesday 15 November 2005 03:05 pm, Magnus Hagander wrote:
> > > I explain myself about running PostGre as admin.
> > >
> > > In fact I don't want specifically run PostGre as admin. The problem
> >
> > is, on
> >
> > > the computers the application including PostGre will run,
> >
> > I'm not sure
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Is there any chance it is related to the 8.0 problem I reported on
> > Wednesday?
>
> Too soon to tell ... though one would like to think we don't have more
> than one bug in that area ;-).
>
> If either of you can come up with even a low-probability tes
Bruce Momjian writes:
> Magnus Hagander wrote:
>> Do we really want to run cosmetic cleanups on a stable branch?
> Agreed, it is not a great idea, but if we don't, then 8.1.X and CVS HEAD
> will not match indenting, and patches generated by 8.1.X users will not
> apply cleanly to CVS HEAD. And i
Magnus Hagander wrote:
> > I think we should rerun pgindent on 8.1.X and HEAD to correct
> > the reported problems. I am betting 90% of our patches
> > either come from CVS head or 8.1.X branches greater than 8.1.0.
>
> Do we really want to run cosmetic cleanups on a stable branch?
>
> I'm sur
> > I explain myself about running PostGre as admin.
> >
> > In fact I don't want specifically run PostGre as admin. The problem
> is, on
> > the computers the application including PostGre will run,
> I'm not sure
> > that the user won't have any admin or power user rights.
> Furthermore,
> >
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: 15 November 2005 13:45
> To: Dave Page; Martijn van Oosterhout
> Cc: Andreas Joseph Krogh; pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] Running PostGre on DVD
>
> > > Yes. And this is a good thing!
On 11/15/05, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Csaba Nagy wrote:
>
> > session_1=> create table test (col smallint primary key);
> > NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> > "test_pkey" for table "test"
> > CREATE TABLE
> > session_1=> begin;
> > BEGIN
> > cnagy=
1 - 100 of 116 matches
Mail list logo
