Bruce Momjian wrote:
Gaetano Mendola wrote:
Bruce Momjian wrote:
Scott Marlowe wrote:
I use a checkpoint_segments = 16 but in my pg_xlog I have
35 files. Why 35 files ?
You have 35 because the max files in pg_xlog is 2*checkpoint_segments +1
or something like that. This is documented in
Fixed in CVS.
---
Gaetano Mendola wrote:
Hi all,
I'm compiling the last postgres CVS version and I get:
vacuum.c: In function `repair_frag':
vacuum.c:1528: warning: unused variable `myXID'
Regards
Gaetano
Gaetano Mendola wrote:
Well, today I stop the pg_autovacuum and I did a vacuum full and I
reindexed
all big tables and other 500 MB were reclamed. Could be the pg_autovacuum
running yesterday the responsible for these 500MB not reclamed during
a vacuum full and reindex already performed yesterday
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew T. O'Connor wrote:
| Gaetano Mendola wrote:
|
| Well, today I stop the pg_autovacuum and I did a vacuum full and I
| reindexed
| all big tables and other 500 MB were reclamed. Could be the pg_autovacuum
| running yesterday the responsible for
Oliver Jowett [EMAIL PROTECTED] writes:
Logs follow; basically this is issuing a Parse/Bind/Execute for a
parameterized DECLARE, which blows up with no value found for parameter
1 despite there definitely being one there. (also, that error appears
on Execute, not Parse/Bind).
This may be
Why do we have both the type text and type varchar (without limit)?
Couldn't we make one to be an alias for the other?
Since it's 2 distinct types there are some strange effects:
dennis= SELECT CAST ('123'::varchar AS integer);
ERROR: cannot cast type character varying to integer
Gaetano Mendola wrote:
I'm pretty sure, see the attached graph. Each morning at 7 a script stop
the autovacuum, vacuum full the database and reindex the eavy updated
tables
and restart of course the autovacuum. Note also that for all the day I
didn't
have the usual disk usage increment.
I don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew T. O'Connor wrote:
| Gaetano Mendola wrote:
|
| I'm pretty sure, see the attached graph. Each morning at 7 a script stop
| the autovacuum, vacuum full the database and reindex the eavy updated
| tables
| and restart of course the autovacuum.
I don't know why the 1st VACUUM FULL wasn't able to reclaim the same
amount of space as the 2nd one, but I would guess that it wasn't able to
get a lock on some table. It could have been autovac if it was doing a
vacuum at that moment, but it could have been something else too.
Or there
There is one problem with the optimizer that is a constant source of
frustration. When using prepared statements and functions (particularly
where function parameters are passed to a query), the optimizer often
fails to utilize an index inside a plan.
This is a well known problem because the
Title: Message
Perhaps it is a
Win32 only issue.
This is from today's
snapshot.
When compiling
zic.c, the definition for optarg was missing (obviously getopt.h was
missing). Adding getopt.h to zic.c solved that
problem.
Perhaps it is a
combination of compiler flags that skirts the
Title: Message
I have seen this
before with other compilers. The latest MINGW GCC compiler does not like a
goto label with no statements following.
pg_ctl.c: In
function `pgwin32_ServiceMain':pg_ctl.c:991: error: label at end of compound
statementmake[3]: *** [pg_ctl.o] Error 1make[3]:
Merlin Moncure wrote:
Merlin,
This will most likely never be accepted by the core team because it is
better to spend more time on fixing the planner than to invent some
non-standard.
As far as I know some databases support a syntax where hints can be
hidden in comments or something like that.
I notice this:
When a checkpoint occurs, if a log file is more than 75% full then a new
file will be allocated (in PreallocXlogFiles).
This assumes we checkpoint at least 4 times per log file, otherwise it
will be effectively random whether we actually ever do this or not. With
an uneven or
On Wed, 2004-07-21 at 19:12, Merlin Moncure wrote:
There is one problem with the optimizer that is a constant source of
frustration. When using prepared statements and functions (particularly
where function parameters are passed to a query), the optimizer often
fails to utilize an index
Tom Lane wrote:
Any chance of getting this fixed for 7.5?
I'm up to my keister in PITR and nested-xact issues and won't have time
to look at it soon. Do you want to take a look and see if you can find
where the ball is getting dropped?
Ok, I'll do that.
-O
---(end of
On Wed, 2004-07-21 at 18:54, Rod Taylor wrote:
I don't know why the 1st VACUUM FULL wasn't able to reclaim the same
amount of space as the 2nd one, but I would guess that it wasn't able to
get a lock on some table. It could have been autovac if it was doing a
vacuum at that moment, but
Merlin Moncure wrote:
Another way to deal with the problem is to defer plan generation until
the first plan execution and use the parameters from that execution.
When talking the V3 protocol, 7.5 defers plan generation for the unnamed
statement until parameters are received in the Bind message
On Wed, 21 Jul 2004, Oliver Jowett wrote:
It's going to be fun using anything more than very basic cursors via the
V3 protocol in the JDBC driver. DECLARE does not work with parameters
passed via a Parse/Bind combination -- which is how we currently always
pass parameters when talking
Simon Riggs [EMAIL PROTECTED] writes:
More verbosely (not numbered because they're not a sequence or
progression)
- if no recovery.conf is present we do crash recovery to end of logs on
pg_control timeline (i.e. current)
Check.
- if recovery.conf is present and we do not specify a target
On Wed, 21 Jul 2004, Simon Riggs wrote:
I notice this:
When a checkpoint occurs, if a log file is more than 75% full then a new
file will be allocated (in PreallocXlogFiles).
This assumes we checkpoint at least 4 times per log file, otherwise it
will be effectively random whether we
Simon Riggs [EMAIL PROTECTED] writes:
I would like to remove PreallocXlogFiles on the basis that it is dead,
or at least pointless code.
It could stand improvement I'm sure, but it's not pointless,
particularly not when you have archive mode turned on and so dead xlog
segments can't necessarily
On Wed, 2004-07-21 at 23:42, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
More verbosely (not numbered because they're not a sequence or
progression)
- if no recovery.conf is present we do crash recovery to end of logs on
pg_control timeline (i.e. current)
Check.
- if
What happens when a transaction fails to either commit or abort as a
result of a serious error?
That looks like a transaction-in-progress doesn't it?
Would that prevent VACUUM from doing its work? It should be able to
check the last startup xid to check that isn't the case, but suppose a
On Thu, 2004-07-22 at 00:35, Gavin Sherry wrote:
On Wed, 21 Jul 2004, Simon Riggs wrote:
I notice this:
When a checkpoint occurs, if a log file is more than 75% full then a new
file will be allocated (in PreallocXlogFiles).
This assumes we checkpoint at least 4 times per log file,
Simon Riggs [EMAIL PROTECTED] writes:
PITR should cope with these scenarios. These are described reasonably
closely but not as exact mechanical tests, so as to ensure that if
multiple solutions exist to these recovery scenarios that all paths are
tested.
[ snip ... ]
Now *my* head is
That gives us enough to talk through and begin some testing.
Anybody have any other horror stories, bring 'em on.
I think that the PITR docs will have to be written in two sections. One
will need to be a pure reference that orthogonally describes the
options, etc. The other section will need
Dann Corbit [EMAIL PROTECTED] writes:
When compiling zic.c, the definition for optarg was missing (obviously
getopt.h was missing). Adding getopt.h to zic.c solved that problem.
Fixed --- thanks.
regards, tom lane
---(end of
Dann Corbit [EMAIL PROTECTED] writes:
default:
; /* Just a semicolon added here */
/* assert(false); */
}
Personally I prefer writing
default:
break;
Switch branches that don't have break or return at the end are trouble
waiting to happen, compiler
...
Would that prevent VACUUM from doing its work? It should be able to
check the last startup xid to check that isn't the case, but suppose a
backend had exited without taking down the postmaster.
There is no such thing as a backend crashing without the postmaster
noticing (at least not
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
1. Should we make the owner aclitem NEVER appear in the acl list? ie.
when we do the first grant on an object, we don't put in a default acl
for the owner. Instead we special case the aclcheck to always allow the
owner full privilieges?
The solution I had in mind was for ALTER OWNER to run through the ACL
and replace the old owner ID with the new one wherever the old one
appears, in both grantor and grantee positions. So in your example
{chriskl=arwdRxt/chriskl,other=r/chriskl}
becomes
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
The solution I had in mind was for ALTER OWNER to run through the ACL
and replace the old owner ID with the new one wherever the old one
appears, in both grantor and grantee positions.
What about fixing existing bad acls?
When did that get to
When did that get to be part of the requirements? I don't even know
who you expect to do this (backend? pg_dump? user?) or at what level
you think the fixing should happen (GRANT/REVOKE? UPDATE pg_class
SET relacl = fixme(relacl)? direct hacking of the ACL array?). To
say nothing of the
* Have psql show more information about sequences
template1=# \d foo_seq
Sequence public.foo_seq
Column | Type
---+-
sequence_name | name
last_value| bigint
increment_by | bigint
max_value | bigint
min_value | bigint
cache_value | bigint
log_cnt
Magnus Hagander [EMAIL PROTECTED] writes:
Right. The problem we are actually faced with is to identify
which of the zic timezones is the best match for the system's
timezone setting.
One of the issues is that it's not clear what best means...
At the moment I like Oliver Jowett's idea of
36 matches
Mail list logo
