> Bruce Momjian writes:
> > I recieved this report of a failing set of queries:
>
> Fixed. ShutdownPostgres needs to be sure we've released buffer pins
> before it tries to drop newly-created files. This has actually been
> wrong all along, but it is masked pre-8.0 because DropRelFileNodeBuffer
Tom Lane wrote:
I don't believe there is any very significant amount of planner work
that is completely independent of any external database object. For
that matter, even the rewriter needs to be rerun when any views or
defaults change in the query. And for that matter, even the parse
analysis ph
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, I wonder whether it would be possible to move some preprocessing
> from the early stages of the planner to a "preprocessing" phase that
> would run after the rewriter but before the planner proper. The
> preprocessor would maintain the essential pro
Neil Conway <[EMAIL PROTECTED]> writes:
> I just noticed that there is a `PlanState' node in the executor, of all
> places. I'm thinking of using `QueryState' instead -- this parallels the
> usage of PlanState in the executor, to some degree (PlanState holds some
> of the state of the executor a
Qingqing Zhou wrote:
So is this change the preparation work of caching query plans? Like cleaning
the plans so they could be well shared?
Yeah, it is somewhat related to the centralized plan caching module that
Tom and I have been discussing in the "cached plan invalidation" thread.
When a cached
"Neil Conway" <[EMAIL PROTECTED]>
> I've been taking a look at how to stop the planner from scribbling on
> its input. This is my first modification of any significance to the
> planner, so don't hesitate to tell me what I've gotten wrong :)
>
So is this change the preparation work of caching quer
Neil Conway wrote:
(b) should be pretty easy to solve; we can create a per-Query PlanState
struct that contains this information, as well as holding a pointer to
the Query (and perhaps the in-construct Plan tree).
I just noticed that there is a `PlanState' node in the executor, of all
places. I'
Bruce Momjian writes:
> I recieved this report of a failing set of queries:
Fixed. ShutdownPostgres needs to be sure we've released buffer pins
before it tries to drop newly-created files. This has actually been
wrong all along, but it is masked pre-8.0 because DropRelFileNodeBuffers
was willin
"Bruce Momjian"
> I recieved this report of a failing set of queries:
>
> BEGIN;
> CREATE TABLE a (i INT);
> INSERT INTO a VALUES(1);
> DECLARE acur CURSOR FOR SELECT * FROM a;
> FETCH acur;
> \q
>
> It certainly looks like a simple set of queries.
>
> If this is done in 8.0.X the server shows:
>
I've been taking a look at how to stop the planner from scribbling on
its input. This is my first modification of any significance to the
planner, so don't hesitate to tell me what I've gotten wrong :)
I think the planner makes two kinds of modifications to the input Query:
(a) rewriting of the
I recieved this report of a failing set of queries:
BEGIN;
CREATE TABLE a (i INT);
INSERT INTO a VALUES(1);
DECLARE acur CURSOR FOR SELECT * FROM a;
FETCH acur;
\q
It certainly looks like a simple set of queries.
If this is done in 8.0.X the server
I wrote:
> I was thinking at the time, and still think, it is reasonable to treat
> EPERM as being a safe rather than unsafe case.
I remembered why we were rejecting that case originally: it protects us
against blowing away a Unix socket file belonging to a postmaster that's
running under someone
Even with Magnus' explanation that we're talking Hardware, and not OS
risk issues, I still think that the default should be the "least risky",
with the other options being well explained from both a risk/performance
standpoint, so that its a conscious decision on the admin's side ...
Any 'risk
Tom Lane <[EMAIL PROTECTED]> writes:
> We need to be able to write in the whole directory, not just the
> lockfile. But actually the point I am making above is in your favor:
> after adding a check on ownership, it would be a matter of your
> protection wishes what the directory protections need
Eric Parusel <[EMAIL PROTECTED]> writes:
> Is this what you're speaking of?
> --
> Item 1 -- Length: 1756 Offset: 3200 (0x0c80) Flags: USED
> Item 2 -- Length: 1728 Offset: 6464 (0x1940) Flags: USED
> Item 3 -- Length: 1756 Offset: 1444 (0x05a4) Flags: USED
> Item 4 -- L
Tom Lane wrote:
Eric Parusel <[EMAIL PROTECTED]> writes:
./pg_filedump -i -f -R 28393 /data1/pgsql/data/base/17760/18004
--snip--
Item 2 -- Length: 1728 Offset: 6464 (0x1940) Flags: USED
XMIN: 12 CMIN: 196608 XMAX: 122552335 CMAX|XVAC: 177664675
Block Id: 0 linp Index: 47241 Attributes:
Eric Parusel <[EMAIL PROTECTED]> writes:
> ./pg_filedump -i -f -R 28393 /data1/pgsql/data/base/17760/18004
> --snip--
> Item 2 -- Length: 1728 Offset: 6464 (0x1940) Flags: USED
> XMIN: 12 CMIN: 196608 XMAX: 122552335 CMAX|XVAC: 177664675
> Block Id: 0 linp Index: 47241 Attributes: 36
[EMAIL PROTECTED] writes:
> I've tried with 7.4.3 - *good* results with both SQL and PL/PGSQL
> (actually even less that best 8.0.1: 12Mb)
> I think this makes it a bug...
You haven't actually provided a test case that would let someone else
reproduce the problem ...
reg
I've tracked down a row that is failing:
maia=# select id FROM table WHERE id = 1401765;
ERROR: could not access status of transaction 1634148473
DETAIL: could not open file "/data1/pgsql/data/pg_clog/0616": No such
file or directory
db=# vacuum maia_mail;
WARNING: relation "table" TID 28393/2
Sorry it was for [EMAIL PROTECTED]
On Thu, 17 Mar 2005 18:08:03 -0500, Juan Pablo Espino
<[EMAIL PROTECTED]> wrote:
> set pgsql-hackers nomail
>
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
>
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I am strongly tempted to add a direct check in checkDataDir() that the
>> data directory actually does belong to our own uid, just for paranoia's
>> sake. Someone might decide that they could relax the permission chec
set pgsql-hackers nomail
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Tom Lane wrote:
>But I evidently didn't
>read the code quite carefully enough: as CreateLockFile() is written,
>it considers an EPERM error from kill() to be reason to treat the
>lockfile as valid.
>
>
I thought that was part of what you were going to address. There can
hardly be an objection
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Is one supposed to be able to alter the type of a table whose definition
> has been used A composite in another table?
If the alter is of a kind that we can support, yes.
> Somewhat surprisingly to
> me, the following test did not produce an error:
>
Tom Lane <[EMAIL PROTECTED]> writes:
> I am strongly tempted to add a direct check in checkDataDir() that the
> data directory actually does belong to our own uid, just for paranoia's
> sake. Someone might decide that they could relax the permission check
> ("hey, why not let the dbadmin group ha
Is one supposed to be able to alter the type of a table whose definition
has been used A composite in another table? Somewhat surprisingly to
me, the following test did not produce an error:
create table a( x text, y int);
create table b( z a);
insert into b values('(\'aaa\',3)');
select * from
On Thu, 2005-03-17 at 13:36 -0500, Merlin Moncure wrote:
> However, I still maintain that views are the perfect security mechanism
> for system catalogs. Imagine that all the system catalogs were all
> views, and could be redefined or even dropped by the dba. They would
> present exactly the same
Last fall I proposed a minor tweak to solve the problem of Postgres
not restarting after a system reboot, in cases where it looked at the
old lockfile and thought the old postmaster was still alive:
http://archives.postgresql.org/pgsql-hackers/2004-09/msg00935.php
However it turns out the bug is s
On Thu, Mar 17, 2005 at 17:40:52 +0200,
Marko Kreen wrote:
> On Wed, Mar 16, 2005 at 07:46:23AM -0800, Moran.Michael wrote:
> > How do you encrypt() & decrypt() data of types INT4 or DATE?
> >
> > The PGCrypto methods encrypt() and decrypt() each take BYTEA as input:
> >
> > i.e.,
> > encr
[EMAIL PROTECTED] wrote:
>
> As the copyright owner, "The PostgreSQL Global Development Group," has
> the right to license the documentation any way they see fit.
The PGDG has never asked for copyright assignments from contributors (as
I gather the PHP folks do), so the copyright to Postgres is co
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > You shouldn't insert encodings in the middle, because those numbers are
> > exposed to clients. We've had troubles with that before. If you add
> > an encoding, append it as the last one (before the client encodings in
> > this
Bruce Momjian writes:
> What should I do with the CVS code now? Why is adding a gap between
> client/server and client-only encodings in pg_wchar.h going to waste
> space?
IIRC there are some tables that are indexed directly by the encoding
number, so leaving holes in the code assignments requir
Bruce Momjian writes:
> Tom Lane wrote:
>> ISTM Windows' idea of fsync is quite different from Unix's and therefore
>> we should name the wal_sync_method that invokes it something different
>> than fsync. "write_through" or some such?
> Ah, I remember now. On Win32 our fsync is:
> #define
Andrew Dunstan wrote:
>
> First the good news. After several false tries I managed to get gettext
> and friends installed on MinGW so that I could get past configure when I
> set "--enable-nls". I did this by installing (in this order) the
> following packages from
> http://sourceforge.net/project
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> ISTM Windows' idea of fsync is quite different from Unix's and therefore
> >> we should name the wal_sync_method that invokes it something different
> >> than fsync. "write_through" or some such?
>
> > Ah, I remember now. On Win32
First the good news. After several false tries I managed to get gettext
and friends installed on MinGW so that I could get past configure when I
set "--enable-nls". I did this by installing (in this order) the
following packages from
http://sourceforge.net/project/showfiles.php?group_id=23617 in c
The default should clearly be the safest method.
Personally, I would disable anything but the safest method for all
database files that are not read-only.
IMO-YMMV.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
Sent: Thursday, March 17, 20
Mark Woodward wrote:
> Then, what you are saying, is that anyone could come along and create
> a paper trail calling themselves "The PostgreSQL Global Devlopment
> Group," and claim ownership.
No, the point is that we want to stick at least *some* copyright notice
in the code, so people are advis
Bruce Momjian writes:
> Tom Lane wrote:
>> we should name the wal_sync_method that invokes it something different
>> than fsync. "write_through" or some such? We already have precedent
>> that not all wal_sync_method values are available on all platforms.
> Yes, I am thinking that too. I hesis
Tom Lane wrote:
> Bruce Momjian writes:
> > However, I do prefer this patch and let Win32 have the same write cache
> > issues as Unix, for consistency.
>
> I agree that the open flag is more nearly O_DSYNC than O_SYNC.
>
> ISTM Windows' idea of fsync is quite different from Unix's and therefore
"Mark Woodward" <[EMAIL PROTECTED]> writes:
>> In my mind the real reason we stick "Copyright PGDG" in the sources is
>> just as a prophylactic against someone putting their own copyright on
>> the files and then trying to prevent anyone else from using the code.
>> Effectiveness of this measure re
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>> Sorry, that's not true. At least in the USA, any entity that can be
>> identified can own and control copyright. While it is true, however,
>> that
>> there can be ambiguity, an informal body, say "anarchists for stronger
>> government," without char
Marc G. Fournier wrote:
> On Thu, 17 Mar 2005, Bruce Momjian wrote:
>
> > Dave Page wrote:
> >>> 2. Another question is what to do with 8.0.X? Do we
> >>> backpatch this for
> >>> Win32 performance? Can we test it enough to know it will work well?
> >>> 8.0.2 is going to have a more rigorous te
Bruce Momjian writes:
> However, I do prefer this patch and let Win32 have the same write cache
> issues as Unix, for consistency.
I agree that the open flag is more nearly O_DSYNC than O_SYNC.
ISTM Windows' idea of fsync is quite different from Unix's and therefore
we should name the wal_sync_m
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > However, I'm a little unclear about where you stand on the relative
> > merit (whatever the implementation) of hiding at the very least
prosrc
> > from non-priv users.
>
> OK, in words of one syllable: I'm agin it.
> I think your proposal is a hac
Magnus Hagander wrote:
> > This indicated to me that open_sync did not require any
> > additional changes than our current fsync.
>
> fsync and open_sync both write through the write cache in the operating
> system. Only fsync=off turns this off.
>
> fsync also writes through the hardware write
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> Sorry, that's not true. At least in the USA, any entity that can be
> identified can own and control copyright. While it is true, however, that
> there can be ambiguity, an informal body, say "anarchists for stronger
> government," without charter or in
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> You shouldn't insert encodings in the middle, because those numbers are
> exposed to clients. We've had troubles with that before. If you add
> an encoding, append it as the last one (before the client encodings in
> this case). This would probab
On Thu, 17 Mar 2005, Bruce Momjian wrote:
Dave Page wrote:
2. Another question is what to do with 8.0.X? Do we
backpatch this for
Win32 performance? Can we test it enough to know it will work well?
8.0.2 is going to have a more rigorous testing cycle because of the
buffer manager changes.
This q
On Thu, 17 Mar 2005, Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 17 March 2005 05:32
To: Bruce Momjian
Cc: Magnus Hagander; Tom Lane; pgsql-hackers@postgresql.org;
[EMAIL PROTECTED]; Merlin Moncure
Subject: Re: [
> Mark Woodward wrote:
>> As the copyright owner, "The PostgreSQL Global Development Group,"
>> has the right to license the documentation any way they see fit. For
>> PHP to sub-license the documentation, it legally has to be transfered
>> in writing. Verbal agreements are not valid.
>
> The Postg
Bruce Momjian wrote:
> Tom Lane wrote:
> > You can't just randomly rearrange the pg_enc enum without forcing
> > an initdb, because the numeric values of the encodings appear in
> > system catalogs (eg pg_conversion).
>
> Oh, those numbers appear in the catalogs? I didn't relealize that.
>
> I wil
Mark Woodward wrote:
> As the copyright owner, "The PostgreSQL Global Development Group,"
> has the right to license the documentation any way they see fit. For
> PHP to sub-license the documentation, it legally has to be transfered
> in writing. Verbal agreements are not valid.
The PostgreSQL Glo
Dave Page wrote:
> > 2. Another question is what to do with 8.0.X? Do we
> > backpatch this for
> > Win32 performance? Can we test it enough to know it will work well?
> > 8.0.2 is going to have a more rigorous testing cycle because of the
> > buffer manager changes.
>
> This question was ask
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> However, I'm a little unclear about where you stand on the relative
> merit (whatever the implementation) of hiding at the very least prosrc
> from non-priv users.
OK, in words of one syllable: I'm agin it.
I think your proposal is a hack that solves
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > 1. Am I totally off my rocker for suggesting users without 'execute'
> > priv. should not be able to view procedure source.
>
> 1. I don't particularly buy that, no. Why draw the line at seeing
> source code? The mere name and argument list migh
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> 1. Am I totally off my rocker for suggesting users without 'execute'
> priv. should not be able to view procedure source.
1. I don't particularly buy that, no. Why draw the line at seeing
source code? The mere name and argument list might be conside
Right now in postgres it is impossible to hide stored procedure source
code from non-privileged users...namely the prosrc column of the pg_proc
table. For those of you in a hurry skip to the summary at the end :-).
From my point of view (not sure if others would agree), it would be nice
to suppr
On Wed, Mar 16, 2005 at 07:46:23AM -0800, Moran.Michael wrote:
> How do you encrypt() & decrypt() data of types INT4 or DATE?
>
> The PGCrypto methods encrypt() and decrypt() each take BYTEA as input:
>
> i.e.,
> encrypt( data::bytea, key::bytea, type::text)
> decrypt( data::bytea, key::b
> Peter Eisentraut wrote:
>> Mark Woodward wrote:
>> > I would say that "The PostgreSQL Global Development Group" or its
>> > representatives (I'm assuming Tom, Bruce, and/or Marc Fournier) just
>> > has to give something written, that says Christopher Kings-Lynne of
>> > "your address, city, count
Dave Cramer wrote:
Pre-7.4 servers used set autocommit on/off and that was the error they
referred to, however after asking them to get me a test case I haven't
heard back
9 times out of 10 this means that while creating their test case they
found the problem.
You do realize that OLE DB uses pql
Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
Shachar Shemesh wrote:
I don't know type 705 well enough to decide which would work best. If
it's guaranteed to be a validly encoded text string, then I'll just
put it in as DBTYPE_WSTR, and get it done with.
I think it's s
Peter Eisentraut wrote:
> Mark Woodward wrote:
> > I would say that "The PostgreSQL Global Development Group" or its
> > representatives (I'm assuming Tom, Bruce, and/or Marc Fournier) just
> > has to give something written, that says Christopher Kings-Lynne of
> > "your address, city, country, etc
> Mark Woodward wrote:
>> I would say that "The PostgreSQL Global Development Group" or its
>> representatives (I'm assuming Tom, Bruce, and/or Marc Fournier) just
>> has to give something written, that says Christopher Kings-Lynne of
>> "your address, city, country, etc" has the right to re-licen
Shachar Shemesh wrote:
Dave Cramer wrote:
Shachar,
I think with type oid 705 (unknown) it's safe to treat it as text.
Certainly better than punting.
Question is what DBTYPE to report it as. Options are DBTYPE_WSTR
(UTF-16 string, which means the input string must be a valid UTF-8
string), DBTYP
Dave Cramer <[EMAIL PROTECTED]> writes:
> Shachar Shemesh wrote:
>> I don't know type 705 well enough to decide which would work best. If
>> it's guaranteed to be a validly encoded text string, then I'll just
>> put it in as DBTYPE_WSTR, and get it done with.
> I think it's safe to assume it wil
Mark Woodward wrote:
> I would say that "The PostgreSQL Global Development Group" or its
> representatives (I'm assuming Tom, Bruce, and/or Marc Fournier) just
> has to give something written, that says Christopher Kings-Lynne of
> "your address, city, country, etc" has the right to re-license or
Alvaro Herrera wrote:
On Wed, Mar 16, 2005 at 07:35:57PM +0100, Thomas Hallgren wrote:
I have some test code that utilize SPI and does the following:
1. SPI_connect
2. set a savepoint (using BeginInternalSubTransaction)
3. execute a statement that contains a syntax error (within PG_TRY/PG_CATCH)
On Thu, 2005-03-17 at 16:11 +1100, Neil Conway wrote:
> Neil Conway wrote:
> > Do we want to share plans between call sites?
>
> After thinking about this a little more, I think the answer is "no" --
> it doesn't really buy us much, and introduces some extra complications
> (e.g. resource manage
On Tue, 2005-03-15 at 18:29 -0500, Bruce Momjian wrote:
> Nguyen Hai wrote:
> > Hi,
> >
> > Is it possible to convert palloc back to malloc?
> > If so, what should I do to make the change?
>
> You can, but palloc is automatically freed at the end of a query, while
> malloc has to be freed in the
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Marc
> G. Fournier
> Sent: 17 March 2005 05:32
> To: Bruce Momjian
> Cc: Magnus Hagander; Tom Lane; pgsql-hackers@postgresql.org;
> [EMAIL PROTECTED]; Merlin Moncure
> Subject: Re: [HACKERS] Changi
On Thu, 2005-03-17 at 12:40 +0900, Satoshi Nagayasu wrote:
> Tom Lane wrote:
> >>I saw Oracle's reference manual, and found ALTER DATABASE OPEN READ ONLY
> >>command
> >>to make a stand-by database.
> >
> > Perhaps, but that's *not* what the TODO item is about.
>
> I see.
>
> Thanks for comment
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> Sent: 17 March 2005 04:20
> To: Magnus Hagander
> Cc: Tom Lane; pgsql-hackers@postgresql.org;
> [EMAIL PROTECTED]; Merlin Moncure
> Subject: [HACKERS] Changing the default wal_sync_m
> > > > * Win32, with fsync, write-cache disabled: no data corruption
> > > > * Win32, with fsync, write-cache enabled: no data corruption
> > > > * Win32, with osync, write cache disabled: no data corruption
> > > > * Win32, with osync, write cache enabled: no data
> corruption. Once
> > > > I
>
> >> I'd like to see this one also considered for 8.0.x, though I'd
> >> certainly like to see some more testing as well. Perhaps it's
> >> suitable for the "8.0.x with extended testing" that is planned for
> >> the ARC replacement code?
> >>
> >> It does make a huge difference on win32. While w
75 matches
Mail list logo
