Andres Freund wrote:
> Hi,
>
> It might be relevant for the whole discussion about inclusion of some form of
> row level permissions, whatever based on, that there exist heaps of (in my
> eyes conflicting) patents about row level permissions for relational
> databases. I don't have any real clu
Andrew Sullivan wrote:
On Fri, Oct 10, 2008 at 01:44:49PM +0900, KaiGai Kohei wrote:
Andrew Sullivan wrote:
I want to focus on this description, because you appear to be limiting
the problem scope tremendously here. We've moved from "general
security policy for database system" to "security po
Simon Riggs <[EMAIL PROTECTED]> writes:
> ISTM that xact_desc routines do not work properly when called with
> WAL_DEBUG enabled from XLogInsert().
Well, now that you mention it, that code is utterly, completely broken,
and always has been. It's passing only the first rdata-chunk of the WAL
recor
ISTM that xact_desc routines do not work properly when called with
WAL_DEBUG enabled from XLogInsert().
LOG: INSERT @ 0/3740978: prev 0/3740938; xid 5699: Transaction -
commit: 2008-10-14 03:14:14.866437+01; subxacts: 10447936 0
STATEMENT: commit;
LOG: INSERT @ 0/37409F0: prev 0/37409B0; xid 57
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> I agree I need to work on that. Also from the spec, "RESPECT NULLS /
> IGNORE NULLS" may be specified but not supported yet. This syntax
> specification is out of the postgres general function call so I wonder
> if those functions are treated specially
2008/10/14 David Rowley <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>>I made up my mind to scratch former window functions and redesigned
>>completely new execution model, based on the discussion with Heikki.
>>Attached is the v06 against HEAD today.
>>http://umitanuki.net/pgsql/wfv06/design.html
Tom Lane escribió:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> I'm inclined to apply the patch with binary-coercibility adjustments
> >> and not try to turn RECORD or RECORD[] into full-fledged polymorphic
> >> types.
Hitoshi Harada wrote:
>I made up my mind to scratch former window functions and redesigned
>completely new execution model, based on the discussion with Heikki.
>Attached is the v06 against HEAD today.
>http://umitanuki.net/pgsql/wfv06/design.html
First off, fantastic work!
In my eyes this and WI
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I'm inclined to apply the patch with binary-coercibility adjustments
>> and not try to turn RECORD or RECORD[] into full-fledged polymorphic
>> types. It's not immediately clear w
Magnus Hagander wrote:
Second, once I've successfully built and installed postgres, I run into
a bigger problem. When using initdb, I get this error:
creating template1 database in c:/Data/postgres30/base/1 ... FATAL:
could not create shared memory segment: 5
DETAIL: Failed system call was C
Greg Smith wrote:
The drives themselves, and possibly the OS and disk controller, are all
running read-ahead algorithms to accelerate this case. In fact, this
*exact* case for the Linux read-ahead stuff that just went mainline
recently: http://kerneltrap.org/node/6642
Apparently only the "s
On Mon, 13 Oct 2008 15:34:04 -0500
"Kevin Grittner" <[EMAIL PROTECTED]> wrote:
> ccdev=# select pg_total_relation_size('"DbTranImageStatus"');
> pg_total_relation_size
>
> 253952
> (1 row)
>
> ccdev=# cluster "DbTranImageStatus";
> CLUSTER
> ccdev=# sele
On Mon, 13 Oct 2008, Tom Lane wrote:
I notice now that kudu and dragonfly are actually the same machine ...
could this be an OS-specific problem? Kris, has there been any
system-software change on that machine recently?
This is a VM that I haven't touched in some time. It was turned off a
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Tom Lane <[EMAIL PROTECTED]> writes:
>>> Short of actually running an ANALYZE, I'm not seeing a good way to
>>> derive the same number it derives.
>
>> Well we could print the _old_ value at least.
>
> +1 ...
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Short of actually running an ANALYZE, I'm not seeing a good way to
>> derive the same number it derives.
> Well we could print the _old_ value at least.
+1 ... seems an appropriate amount of effort for the likely
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I agree with that. I like the idea of printing a message though -- we should
>> just have it print the correlation for now and when we improve the stats
>> we'll
>> print the new metric.
>
> Short of actually runn
Gregory Stark <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Until we have a better metric for "sortedness", my earlier suggestion to
>> print
>> it was probably a bad idea. If anything, should probably print the same
>> correlation metric that ANALYZE calculates,
I wrote:
> Two different buildfarm machines are currently showing the same failure:
> ERROR: could not fsync segment 0 of relation 1663/16384/29270/1: No such
> file or directory
> ERROR: checkpoint request failed
Some tests show that when the serial regression tests are run in a
freshly initdb
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Jim Cox wrote:
>> On Mon, Oct 13, 2008 at 8:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>>
>>> It'd be possible to count the number of order reversals during the
>>> indexscan, ie the number of tup
Hello,
We finally got around to releasing Replicator as FOSS. It is BSD
licensed and available here:
https://projects.commandprompt.com/public/replicator/wiki
(Yes it is a self signed cert, its on the list to fix).
Enjoy folks!
Sincerely,
Joshua D. Drake
--
The PostgreSQL Company since 199
On Oct 13, 2008, at 12:35, Zdenek Kotala wrote:
Tom Lane napsal(a):
Generally you'd use --with-system-tzdata on a platform where you
expect
to receive routine package updates for the tzdata files,
independently
of the Postgres release cycle. It seems reasonable to assume that
anyone curre
On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I wrote:
>> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>>> select foo from foo order by foo;
>>> ERROR: could not identify an ordering operator for type foo
>
>> Yeah, these are because of the incomplete handling of named rec
Tom Lane napsal(a):
Generally you'd use --with-system-tzdata on a platform where you expect
to receive routine package updates for the tzdata files, independently
of the Postgres release cycle. It seems reasonable to assume that
anyone currently shipping tzdata is offering 64-bit files. (But w
On Mon, 2008-10-13 at 08:30 -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > No, I was thinking of something along the lines of:
> > INFO: clustering "public.my_c"
> > INFO: complete, was 33%, now 100% clustered
> > The only such measure that we have is the correlation,
On Oct 13, 2008, at 11:53, Tom Lane wrote:
Oh. Is it not preferable to use the tzdata that ships with
PostgreSQL?
Not necessarily; the system might have a more up-to-date tzdata.
Gotcha.
Generally you'd use --with-system-tzdata on a platform where you
expect
to receive routine package u
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Oct 13, 2008, at 11:37, Zdenek Kotala wrote:
>> when you use --with-system-tzdata and run make check on head it
>> fails on systemes without 64bit tzinfo support.
> Oh. Is it not preferable to use the tzdata that ships with PostgreSQL?
Not nec
On Oct 13, 2008, at 11:37, Zdenek Kotala wrote:
when you use --with-system-tzdata and run make check on head it
fails on systemes without 64bit tzinfo support.
Oh. Is it not preferable to use the tzdata that ships with PostgreSQL?
Thanks,
David
--
Sent via pgsql-hackers mailing list (pgsq
Two different buildfarm machines are currently showing the same failure:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=kudu&dt=2008-10-13%2015:30:00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonfly&dt=2008-10-13%2016:30:01
The postmaster log in each case shows
ERROR: could not fsy
David E. Wheeler napsal(a):
On Oct 13, 2008, at 11:22, Zdenek Kotala wrote:
PostgreSQL 8.4 uses 64bit data type for time. But if you use system
timezone then you can get in trouble if system does not support 64bit
zic files.
I've never noticed a problem with the TZinfo database that ships on
On Oct 13, 2008, at 11:24, Andrew Chernow wrote:
PostgreSQL doesn't use the standard time_t and time functions for
its timestamp types. Therefore, any limitations in regards to 64-
bit time_t values on 32-bit platforms don't apply; other than the
limitation Tom spoke of ... no 64-bit int.
On Oct 13, 2008, at 11:22, Zdenek Kotala wrote:
PostgreSQL 8.4 uses 64bit data type for time. But if you use system
timezone then you can get in trouble if system does not support
64bit zic files.
I've never noticed a problem with the TZinfo database that ships on
systems I've used. How w
David E. Wheeler wrote:
On Oct 13, 2008, at 11:13, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
As long as the C compiler supports int64 ...
I was afraid you'd s
David E. Wheeler napsal(a):
On Oct 13, 2008, at 11:13, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
As long as the C compiler supports int64 ...
I was afraid you
On Oct 13, 2008, at 11:13, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
As long as the C compiler supports int64 ...
I was afraid you'd say that. See:
http://c
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Probably no problem, then. Do dates in PostgreSQL work for their
> entire documented ranges on 32bit processors?
As long as the C compiler supports int64 ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsq
On Oct 13, 2008, at 11:01, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
Not sure if PostgreSQL uses time_t,
We got rid of that some time ago.
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
Thanks,
David
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Not sure if PostgreSQL uses time_t,
We got rid of that some time ago.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
Howdy,
Not sure if PostgreSQL uses time_t, but if so, this project provides
useful code (a drop-in replacement for time.h) to address the 2038 bug
on 32-bit platforms.
http://code.google.com/p/y2038/
Useful for PostgreSQL?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Oct 12, 2008, at 20:15, Joshua D. Drake wrote:
Yeah I would agree with that. I find that only "real" issue with
PgFoundry is the PgFoundry (aka Gforge) not the quality of the
projects being hosted.
The other thing that could use some love is searching for projects.
Google doesn't rank
Zdenek Kotala wrote:
I expect that function cannot get toast pointer. It can get only
detoasted attributes. Correct me if I'm wrong.
A function is passed a raw datum, which can be toasted. Now, practically
all functions call one of the PG_GETARG_* macros that detoast the datum
before doing an
On Fri, 2008-10-10 at 09:41 -0400, Tom Lane wrote:
> So I was looking for other omissions in utility.c, and I noticed that
> check_xact_readonly() doesn't reject CLUSTER, REINDEX, or VACUUM.
> Now the notion of "read only" that we're trying to enforce is pretty
> weak (I think it's effectively "n
Jim Cox wrote:
On Mon, Oct 13, 2008 at 8:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
No, I was thinking of something along the lines of:
INFO: clustering "public.my_c"
INFO: complete, was 33%, now 100% clustered
The only such measure that we have
I have added a link at the bottom of the page.
All the info on how to use Eclipse with Postgres can be found at
http://wiki.postgresql.org/wiki/Working_with_Eclipse
All suggestions and comments are welcome of course.
Emmanuel
Looks great, thanks!
--Chris
--
Sent via pgsql-hackers mailing li
On Oct 10, 2008, at 3:40 PM, Robert Haas wrote:
I dislike all own creatures - because nobody will understand so do
some wrong thing - using non standard formats is bad thing. So
it's is
necessary, then who need it then he found it on pgfoundry. But why
smudge core?
I'm opposed to smudging co
On Mon, Oct 13, 2008 at 8:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > No, I was thinking of something along the lines of:
> > INFO: clustering "public.my_c"
> > INFO: complete, was 33%, now 100% clustered
> > The only such measure that we have
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> This file was moved lo, these many years
>
> Done ... but why did your patch change oidjoins.out and not oidjoins.sql?
I had other changes in my tree, I just diffed the files individually rather
than doing a cvs d
I wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> select foo from foo order by foo;
>> ERROR: could not identify an ordering operator for type foo
> Yeah, these are because of the incomplete handling of named record
> types. I'm not sure how far we want to go in that direction.
On look
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Besides, the "read all formats" approach wouldn't really avoid it
either. If you passed a toasted datum to a function, when the
function needs to detoast it, detoast_datum still wouldn't know
whether the datum is
Heikki Linnakangas napsal(a):
It occurs to me that instead of storing a chunk id, we could store a
byte offset of the chunk. That would allow random access even if every
chunk was of different size. You probably don't want any new changes you
need to deal with in the upgrade, though :-).
Y
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> The record ops work as promised. IMO this patch stands in its own
> merits with or without the CTE changes. I played around with it and
> noticed a couple of oddities:
> select foo = foo from foo; --works
> but
> select distinct foo from foo; --yi
Gregory Stark <[EMAIL PROTECTED]> writes:
> This file was moved lo, these many years
Done ... but why did your patch change oidjoins.out and not oidjoins.sql?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, Oct 8, 2008 at 4:27 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> On Tue, Oct 7, 2008 at 9:58 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> * Instead of the above, we could try to make
>>> ROW(some columns) = ANY (array variable)
>>> work. This is
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> No, I was thinking of something along the lines of:
> INFO: clustering "public.my_c"
> INFO: complete, was 33%, now 100% clustered
> The only such measure that we have is the correlation, which isn't very
> good anyway, so I'm not sure if that's w
This file was moved lo, these many years
diff --git a/src/tools/findoidjoins/make_oidjoins_check
b/src/tools/findoidjoins/make_oidjoins_check
index 5061634..9c6b850 100755
--- a/src/tools/findoidjoins/make_oidjoins_check
+++ b/src/tools/findoidjoins/make_oidjoins_check
@@ -54,7 +54,7 @@ $AWK -F
Jim Cox wrote:
On Fri, Oct 10, 2008 at 10:23 AM, Heikki Linnakangas <
[EMAIL PROTECTED]> wrote:
Kevin Grittner wrote:
"Jim Cox" <[EMAIL PROTECTED]> wrote:
if present an INFO message is generated which displays
the schema.tblname just before actual clustering is kicked off (see
example
b
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> EXPLAIN EXECUTE p('2008-07-01');
> -
> Append
> -> Result
> One-Time Filter: (('2008-01-01' <= $1) AND ($1 < '2009-01-01'))
> -> Index Scan on test_
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Not all chunks need to be the same size. We do currently require that,
but AFAICS it's only because that allows random access to a given
offset within a datum. That's of course nice, but I think we could
live without it.
Good point. I think
Dear All,
I took a look at the source code for hash join this morning and I realized
that the block nested loop join is somewhat similar to that.
Thanks for the discussions.
Bramandia R.
On Fri, Oct 10, 2008 at 8:19 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Gregory Stark <[EMAIL PROTECTED]> wr
Hello,
Constraint exclusion (CE) is very useful for partitioned tables,
but prepared statements interfere with CE if the parameter
contains partition keys, because CE is a planner-time optimization
but the actual parameters are given at executor-time.
I have an idea to use constraint exclusion an
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Besides, the "read all formats" approach wouldn't really avoid it
either. If you passed a toasted datum to a function, when the function
needs to detoast it, detoast_datum still wouldn't know whether the
datum is in old or new format. You'd st
Hi,
Josh Berkus wrote:
> So it sounds like intagg is still in use/development. But ... is it
> more of an example, or is it useful as a type/function in production?
We use it in production for quite remarkable speedups of operations on
int4[].
Having reviewed the last commit fest's intagg patch
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
The problem what I need to solve is how to handle different TOAST
chunk size which becomes with upgrade. if you insert new record into
TOAST table it will be created on the new page which has different max
chunk size, because it depends on pag
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
PostgreSQL stores all table's external data in one TOAST table and
stored data does not contains any clue about datatype. When postgreSQL
reads TOSTEed value then there is not possible detect what type it is
and perform varlena conversion on c
ITAGAKI Takahiro napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> wrote:
Bacause MAX_TOAST_CHUNK_SIZE is related on page layout version I need have toast
chunk size more flexible.
I agree that flexible toast threshold is useful, but I have
several questions in your implementations.
relblocksize
Zdenek Kotala wrote:
The problem what I need to solve is how to handle different TOAST chunk
size which becomes with upgrade. if you insert new record into TOAST
table it will be created on the new page which has different max chunk
size, because it depends on page header size. It means that on
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Bacause MAX_TOAST_CHUNK_SIZE is related on page layout version I need have toast
chunk size more flexible.
Attached patch add three new columns into pg_class
relblocksize - which is always BLCKSZ. I put it there for fullness, but
Zdenek Kotala wrote:
PostgreSQL stores all table's external data in one TOAST table and
stored data does not contains any clue about datatype. When postgreSQL
reads TOSTEed value then there is not possible detect what type it is
and perform varlena conversion on composite datatypes or arrays.
67 matches
Mail list logo
