"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
* 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
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 semanti
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 tha
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
{gumby=arwdRxt/gumby,other=r
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 priviliege
>> ...
>> 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 n
"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
wait
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? Also, if the first grant was 'select' for the
'other' u
"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 broadcast)
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 to
I'm playing around trying to fix the problem where ACLs enter an illegal
state when you change the owner of a table, say.
This is the current situation:
test=# create user gumby;
CREATE USER
test=# create user other;
CREATE USER
test=# create table test (a int4);
CREATE TABLE
test=# grant select
Simon Riggs <[EMAIL PROTECTED]> writes:
> Yes, I agree, but the checkpointer isn't waking up often enough
> currently to do this effectively. It's just randomly doing it.
Agreed. Maybe it should be part of the bgwriter's idle loop, and
not directly associated with checkpoints at all.
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
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 pe
> 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 sup
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)
>
> Chec
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 necessar
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:
> 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 t
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
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 (wh
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 mome
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 broad
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 in
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 burs
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.
Meanw
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]: Leav
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 i
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 pa
> 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 ther
-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.
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 k
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
denni
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 m
-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 fo
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
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
>
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 somet
39 matches
Mail list logo