Hi Teodor,
I think there's a little bug in ginInsertValue. A page is marked as
dirty with MarkBufferDirty after writing the corresponding WAL record
with XLogInsert. That's not safe, MarkBufferDirty needs to be called
before XLogInsert to avoid a race condition in checkpoint, see comments
in
The big question is do we want to drop the target tuple size down
to
512, and increase the chunk size to 8k for 8.3? Dropping the tuple
size down to 512 is going to give us some smaller TOAST values to
fill
in free space created by the 8k chuck size, assuming you have both
types
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I tried to repeat the DBT-2 runs with the oldestxmin refresh patch,
but to my surprise the baseline run with CVS head, without the patch,
behaved very differently than it did back in March.
I rerun the a shorter 1h test with CVS
with XLogInsert. That's not safe, MarkBufferDirty needs to be called
before XLogInsert to avoid a race condition in checkpoint, see comments
in SyncOneBuffer in bufmgr.c for an explanation.
Ugh, thank you fixed. It's a trace of misunderstood of WriteBuffer().
--
Teodor Sigaev
Wilhansen Li wrote:
Basically, better support for binary formats which includes, but not
limited
to:
1) functions for converting to and from various datatypes
2) reducing the need to convert to and from network byte order
3) better documentation
My suggestion on using ASN.1 was merely a naive
Am Dienstag, 5. Juni 2007 06:39 schrieb Golden Liu:
According to this, column privilege descriptors are created automatically
while table privilege descriptor is created. Then, while checking
privilege, can I JUST check column level privilege?
While possible, for performance reasons it would
Hi Marc,
Is there a written procedure about creating tarballs? I'd like to start
working on 8.3 RPMs and I want to know what I should to to create a
tarball.
Regards,
--
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated
Peter Eisentraut wrote:
Am Dienstag, 5. Juni 2007 06:39 schrieb Golden Liu:
According to this, column privilege descriptors are created automatically
while table privilege descriptor is created. Then, while checking
privilege, can I JUST check column level privilege?
While possible,
Is it correct that a user with CREATEROLE privilege but without CREATEDB
privilege can create a user with *CREATEDB* privilege, thus bypassing his
original restrictions? This sequence doesn't look right:
pei=# create user foo1 createrole;
CREATE ROLE
pei=# \c - foo1
You are now connected to
--On Dienstag, Juni 05, 2007 16:04:44 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Is it correct that a user with CREATEROLE privilege but without CREATEDB
privilege can create a user with *CREATEDB* privilege, thus bypassing his
original restrictions? This sequence doesn't look right:
On 6/4/07, Wilhansen Li [EMAIL PROTECTED] wrote:
First of all, apologies if this was not meant to be a feedback/wishlist
mailing list.
Binary formats in libpq has been (probably) a long issue (refer to the
listings below) and I want to express my hope that the next
revision of PostgreSQL would
--On Montag, Juni 04, 2007 15:34:14 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
The reason I'm thinking per-transaction is that we could tie this to
setting up a cached list of tablespace OIDs, which would avoid the
overhead of repeat parsing and tablespace validity checking. We had
rejected
Heikki Linnakangas [EMAIL PROTECTED] writes:
... MarkBufferDirty needs to be called
before XLogInsert to avoid a race condition in checkpoint, see comments
in SyncOneBuffer in bufmgr.c for an explanation.
Right, see also the Write-Ahead Log coding section in
src/backend/access/transam/README
--On Montag, Juni 04, 2007 15:34:14 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Perhaps a reasonable compromise could work like this: at the first point
in a transaction where a temp file is created, choose a random list
element, and thereafter advance cyclically for the duration of that
Golden Liu [EMAIL PROTECTED] writes:
According to this, column privilege descriptors are created automatically
while table privilege descriptor is created. Then, while checking privilege,
can I JUST check column level privilege?
Since we don't have any, no ;-)
You could imagine implementing
Richard Huxton [EMAIL PROTECTED] writes:
Wilhansen Li wrote:
Basically, better support for binary formats which includes, but not
limited
to:
1) functions for converting to and from various datatypes
2) reducing the need to convert to and from network byte order
3) better documentation
Bernd Helmle [EMAIL PROTECTED] writes:
--On Dienstag, Juni 05, 2007 16:04:44 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Is it correct that a user with CREATEROLE privilege but without CREATEDB
privilege can create a user with *CREATEDB* privilege, thus bypassing his
original
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is this a TODO?
I don't think so; there is no demand from anybody but Zdenek to remove
those programs. Has it ever even come up before?
Tom, Bruce
I started with postgres 6.5 as administrator and from this version names
of these
Zdenek Kotala wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is this a TODO?
I don't think so; there is no demand from anybody but Zdenek to remove
those programs. Has it ever even come up before?
Personally I found really strange to have createuser and createdb
shipped by
I wrote:
I've been experimenting with another solution, which is to not add any
weird error cases but instead add operators that will capture the
problem cases back away from the anyelement||anyarray operators.
My current prototype is
create function catany(text, anyelement) returns text as
On Jun 5, 9:19 am, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
Zdenek Kotala wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is this a TODO?
I don't think so; there is no demand from anybody but Zdenek to remove
those programs. Has it ever even come up before?
Peter Eisentraut wrote:
Is it correct that a user with CREATEROLE privilege but without CREATEDB
privilege can create a user with *CREATEDB* privilege, thus bypassing his
original restrictions? This sequence doesn't look right:
pei=# create user foo1 createrole;
CREATE ROLE
pei=# \c - foo1
I have been trying to come up with a simple plan to make log rotation
more robust, particularly in not splitting log lines across files. Greg
Smith complained that lines could be split if logs are rotated on size,
but AFAICS the danger also exists for time based rotation.
My thought is to
Andrew Dunstan [EMAIL PROTECTED] writes:
My thought is to have the logger mark each true log line line end with a
null byte.
This seems not to help much when you consider interleaved output from
different backends...
regards, tom lane
---(end
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
My thought is to have the logger mark each true log line line end with a
null byte.
This seems not to help much when you consider interleaved output from
different backends...
True. We have two
Tom Lane wrote:
The expressions
'abc' || 34
34 || 'abc'
would no longer work, with the following error message:
ERROR: 22P02: array value must start with { or dimension information
Hm, that's annoying. Not that the expressions fail --- we want them to
--- but that the error message is so
Zeugswetter Andreas ADI SD wrote:
The big question is do we want to drop the target tuple size down
to
512, and increase the chunk size to 8k for 8.3? Dropping the tuple
size down to 512 is going to give us some smaller TOAST values to
fill
in free space created by the 8k
27 matches
Mail list logo
