> >> 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
> > > > * 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
>
> -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
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 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 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
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
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)
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
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
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
> 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
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
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
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
> 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
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
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
"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
> "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:
> 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
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
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
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 Postg
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: [
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
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
"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
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
> "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
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
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
> "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
"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
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
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
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
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
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
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
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
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
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
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
[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
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
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, 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
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
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
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 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
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
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
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
>
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
[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
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
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:
> 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 <[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
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
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
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'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
"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:
>
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
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'
"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
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]> 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
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
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
> 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
75 matches
Mail list logo
