> 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 sure it *should* be safe, it just seems
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 when
> I have some more definitive info.
My first reaction would be to
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, I've
noticed that on certain
Look at HEAD branch.
Kaare Rasmussen wrote:
David Fetter writes in PostgreSQL Weekly News - November 13 2005:
Teodor Sigaev has been making lots of improvements to tsearch2, a
full-text search engine.
I can't find them. Am I blind? Can someone help?
---(end of broad
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=> insert into test values (1);
> INSERT 165068987 1
>
> session_2=> beg
On Tuesday 15 November 2005 12:29 am, Jim C. Nasby wrote:
> Why do you need to run PostgreSQL as admin? There shouldn't be any need
> for this.
Actually I've run into a scenario where this was needed. I'm not a Windows
expert, so there might be some way to get around this:
I have a localadmin ac
On Tue, Nov 15, 2005 at 09:19:23AM +0100, Andreas Joseph Krogh wrote:
> On Tuesday 15 November 2005 12:29 am, Jim C. Nasby wrote:
> > Why do you need to run PostgreSQL as admin? There shouldn't be any need
> > for this.
>
> Actually I've run into a scenario where this was needed. I'm not a Windows
Well, from my point of view it is a special case of predicate locking
supported well by existing code, in this case the unique index (you said
that, I'm not familiar with the code). I don't see why this cannot be
capitalized on, to implement a sub-set of what predicate locking is,
based on the mech
> > > Why do you need to run PostgreSQL as admin? There
> shouldn't be any
> > > need for this.
> >
> > Actually I've run into a scenario where this was needed. I'm not a
> > Windows expert, so there might be some way to get around this:
> >
> > I have a localadmin account on the workstation(w
On Tue, Nov 15, 2005 at 01:51:04PM +0100, Magnus Hagander wrote:
> Huh. The stated problem is that the low privilege account does *not*
> have the required privilege (to log in).
> Note that PostgreSQL doesn't really require "log on locally" for
> anything other than initdb. So if you can initdb on
> 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, I've
> noticed that o
> > Huh. The stated problem is that the low privilege account
> does *not*
> > have the required privilege (to log in).
> > Note that PostgreSQL doesn't really require "log on locally" for
> > anything other than initdb. So if you can initdb on a different box
> > and copy it there, or somehow
On Tuesday 15 November 2005 02:07 pm, Martijn van Oosterhout wrote:
> On Tue, Nov 15, 2005 at 01:51:04PM +0100, Magnus Hagander wrote:
> > Huh. The stated problem is that the low privilege account does *not*
> > have the required privilege (to log in).
> > Note that PostgreSQL doesn't really requir
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Magnus Hagander
> Sent: 15 November 2005 13:31
> To: Martijn van Oosterhout
> Cc: Andreas Joseph Krogh; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Running PostGre on DVD
>
> Yes. And th
> > Yes. And this is a good thing! :-)
> > There is no reason a normal user should be able to run a service
> > process. And services should normally have dedicated accounts, and
> > there is no reason you should ever need to log in as that account
> > interactively.
>
> Yes there is, to setup
On Tuesday 15 November 2005 02:16 pm, Pollard, Mike 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
> > that
> > the user w
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=
> -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!
> > 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,
> >
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
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
> 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
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
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
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
"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
> > 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'
>
> 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
> > 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'
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
>
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 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:
> 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: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
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
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
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
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
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
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
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
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
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, 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
> -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 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.
> > > 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 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
> 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, 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
> -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, 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
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 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
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 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,
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
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
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
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
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
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
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
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
* 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 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
> > 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 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
> > > 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 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
> > > 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: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
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, 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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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)
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.
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
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
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
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?
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
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 -
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
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
1 - 100 of 116 matches
Mail list logo
