On Sat, 2005-01-22 at 00:18 -0600, Jim C. Nasby wrote:
1) I'm in favor of autotuning anything possible.
2) In addition to turning group_commit on and off, what about also
adjusting the commit delay, based on statistics of recent commits? It
might require a slightly larger sample set (maybe the
Jim C. Nasby wrote:
On another naming note; the naming convention for system stuff has
always driven me nuts. Some the letter prefix (ie: tab for tables) in
front of every field name, with no underscores or anything. Extensive
use of abbreviations that you need to remember (ie: indnatts, indexprs,
On Fri, 21 Jan 2005 12:17:08 -0800, Josh Berkus wrote:
I'm proposing to expand both the coverage and number of system views.
Generally: Nice. But have you considered if the INFORMATION_SCHEMA could
be used? Unfortunately, the INFORMATION_SCHEMA currently has a major
problem in its usefulness in
Greetings,
for a couple of days I have been hacking on src/port/snprintf.c.
With Magnus' help I have managed to implement argument replacement
in snprintf(). The code is very crude and not quite optimised,
any suggestions will be more than welcome.
Here is what I did:
1. I renamed snprintf() to
hackers,
I am having a problem with table (identified by pg_dump). I get the follow
error when I try to COPY the table to
stdout (or /dev/null).
DB=# copy rnk to '/dev/null';
ERROR: could not access status of transaction 1076101119
DETAIL: could not open file
Nicolai Tufar wrote:
1. I renamed snprintf() to pg_snprintf(), vsnprintf() to
pg_vsnprintf() and introduced pg_printf() that calls pg_vsnprintf().
This is not necessary. You will notice that we already have configure
tests of snprintf format specifiers (%lld etc.), so using the original
I just upgraded to 7.4.6 and have the same error message.
-- Original Message ---
From: Jim Buttafuoco [EMAIL PROTECTED]
To: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Sat, 22 Jan 2005 09:35:02 -0500
Subject: [HACKERS] pg_clog problem (PG version 7.4.5)
hackers,
I
Jim Buttafuoco wrote:
hackers,
I am having a problem with table (identified by pg_dump). I get the follow error when I try to COPY the table to
stdout (or /dev/null).
DB=# copy rnk to '/dev/null';
ERROR: could not access status of transaction 1076101119
DETAIL: could not open file
On Sat, Jan 22, 2005 at 08:46:21PM +1100, Neil Conway wrote:
Jim C. Nasby wrote:
On another naming note; the naming convention for system stuff has
always driven me nuts. Some the letter prefix (ie: tab for tables) in
front of every field name, with no underscores or anything. Extensive
use
didn't work.
ERROR: could not access status of transaction 1076101119
DETAIL: could not read from file /usr/local/pgsql/data/pg_clog/0402 at
offset 57344: Success
any more ideas?
-- Original Message ---
From: Joshua D. Drake [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc:
On Sat, Jan 22, 2005 at 08:47:37AM +, Simon Riggs wrote:
On Sat, 2005-01-22 at 00:18 -0600, Jim C. Nasby wrote:
1) I'm in favor of autotuning anything possible.
2) In addition to turning group_commit on and off, what about also
adjusting the commit delay, based on statistics of recent
Some french guy on IRC showed the site http://www.postgresql.fr/ that does
not contain anything about postgresql. I don't speak french so I can't
tell what the page is about. It looks linux related.
This doesn't really belong on the -hackers list but I don't know where to
send the info or even
On Sat, Jan 22, 2005 at 12:06:46PM -0500, Jim Buttafuoco wrote:
didn't work.
ERROR: could not access status of transaction 1076101119
DETAIL: could not read from file /usr/local/pgsql/data/pg_clog/0402 at
offset 57344: Success
any more ideas?
You need to extend the file further
Alvaro,
Thanks for the reply. here is an ls of my pg_clog directory. The 0402 file,
I created as per Joshua's directions.
I might have created one too small. If so, what size do you think I should use.
Jim
bda1:/usr/local/pgsql/data# ls -l pg_clog
total 992
-rw--- 1 postgres dba
Jim Buttafuoco [EMAIL PROTECTED] writes:
Thanks for the reply. here is an ls of my pg_clog directory. The 0402
file, I created as per Joshua's directions.
I might have created one too small. If so, what size do you think I should
use.
bda1:/usr/local/pgsql/data# ls -l pg_clog
total
Hi Stephen and Hackers,
Moved to -hackers.
Here's a proof-of-concept pretty much untested (it compiles) patch
against HEAD for review of the general approach I'm taking to
merging pg_shadow and pg_group. This is in order to support group
ownership and eventually roles.
I have to
I was able to copy the table over to a temp table and truncate it with only a
little loss. I will be able to recover
the lost data from backup so no big deal. I will have to schedule downtime to
do the memory test with the big snow
storm it will not be until monday night.
thanks for the
* Euler Taveira de Oliveira ([EMAIL PROTECTED]) wrote:
Here's a proof-of-concept pretty much untested (it compiles) patch
against HEAD for review of the general approach I'm taking to
merging pg_shadow and pg_group. This is in order to support group
ownership and eventually
Added to TODO based on this discusion:
---
* Speed up COUNT(*)
We could use a fixed row count and a +/- count to follow MVCC
visibility rules, or a single cached value could be used and
invalidated if anyone modifies
On Sat, 22 Jan 2005 15:31:39 +0100, Peter Eisentraut [EMAIL PROTECTED] wrote:
Nicolai Tufar wrote:
1. I renamed snprintf() to pg_snprintf(), vsnprintf() to
pg_vsnprintf() and introduced pg_printf() that calls pg_vsnprintf().
This is not necessary. You will notice that we already have
Hi Stephen,
I have to disagree with your model. Roles are not so simple like
you
try to describe in your patch. I'm suposing this because your using
role* in all of the 'pg_shadow'.
The particular name isn't really important- and don't take it to mean
very much...
OK. So let it
Jonah H. Harris [EMAIL PROTECTED] writes:
I have a couple aquaintances at IBM that I can try to contact about it.
Rather than assume what IBM will do, why not just ask them? If they
don't respond, they don't respond. If they do respond, it's better than
us guessing.
People seem to be
Simon Riggs [EMAIL PROTECTED] writes:
Each transaction commit gets the current time(NULL) immediately before
it commits.
time() has 1 second resolution and ergo is utterly useless for this.
gettimeofday() may have sufficient resolution, but the resolution is
not specified anywhere.
Tom Lane wrote:
Tom Lane [EMAIL PROTECTED] writes:
Manfred Koizar [EMAIL PROTECTED] writes:
Last time we discussed this, didn't we come to the conclusion, that
resetting status bits is not a good idea because of possible race
conditions?
There's no race condition,
Actually, wait a
Josh Berkus josh@agliodbs.com writes:
I might suggest simply tables triggers types etc. The plurals
of these reserved words are no, AFAIK, reserved. And if users are
creating identically named objects in public, they just need to
remember to use the schema.
Only if you put them in some
Jim,
Just to be clear, I'm not suggesting renaming anything in any of the
existing pg_catalog objects. I'm suggesting creating a new, easier to
use set of views that would sit on top of pg_catalog.
I have no objection to using easier to read names for the system views.
(This is the
Nicolai Tufar [EMAIL PROTECTED] writes:
On Sat, 22 Jan 2005 15:31:39 +0100, Peter Eisentraut [EMAIL PROTECTED]
wrote:
Nicolai Tufar wrote:
2. Why would we not just take FreeBSD's vfprintf() and use it
instead?
Try it. It's painful.
src/port/snprintf.c is not not a particularly pretty.
Dawid Kuroczko [EMAIL PROTECTED] writes:
So... I thoght, why not use this unitext to sort texts?
So I've created functions, operators and operator class,
This time setlocale() was needed to get the behaviour
I needed (database initdb'ed to 'C', my order set to 'pl_PL',
or whatever locale I
On Sat, Jan 22, 2005 at 01:36:54PM -0800, Josh Berkus wrote:
Jim,
Just to be clear, I'm not suggesting renaming anything in any of the
existing pg_catalog objects. I'm suggesting creating a new, easier to
use set of views that would sit on top of pg_catalog.
I have no objection to
In [EMAIL PROTECTED], on 01/22/05
at 05:21 PM, Jim C. Nasby [EMAIL PROTECTED] said:
On Sat, Jan 22, 2005 at 01:36:54PM -0800, Josh Berkus wrote: Jim,
Just to be clear, I'm not suggesting renaming anything in any of the
existing pg_catalog objects. I'm suggesting creating a new, easier
On Sat, Jan 22, 2005 at 05:21:32PM -0600, Jim C. Nasby wrote:
Out of curiosity, what's the relation between the tables in pg_catalog
and the 'actual system objects'? I ass-u-me'd that these tables were the
backing store for the real information, but maybe that's not the case.
They are.
I
On Sat, 22 Jan 2005 17:05:22 -0500, Tom Lane [EMAIL PROTECTED] wrote:
src/port/snprintf.c is not not a particularly pretty. And
after my rework it got even uglier. I have looked at
FreeBDS's one and it is not *that* complicated.
If you can get it to work then it'd be a better bet than
Jim C. Nasby [EMAIL PROTECTED] writes:
If we're dropping the pg_, maybe call the new schema just 'catalog'?
Any new schemas introduced by PG itself will be named pg_something.
This is not open to negotiation --- it's what we've promised to users
to avoid tromping on their schema namespace.
Stephen Frost [EMAIL PROTECTED] writes:
Here's a proof-of-concept pretty much untested (it compiles) patch
against HEAD for review of the general approach I'm taking to
merging pg_shadow and pg_group. This is in order to support group
ownership and eventually roles. This patch
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
What's Role? A set of relations with their respective privileges and
a set of users and/or roles.
Huh? How did relations get into it?
What do we do with 'groups'? Well, we can have three categories of
object owners: users, groups and
35 matches
Mail list logo
