On Sun, 2006-11-05 at 01:15 -0500, [EMAIL PROTECTED] wrote:
> The new PG_MAGIC_MODULE requirement threw me for a loop. I expect it
> will catch others off guard as well.
Did you find the documentation adequate? Could you locate what you
needed to know quickly and accurately? Do you think the chan
On Sat, 2006-11-04 at 12:35 -0500, Tom Lane wrote:
> I wrote:
> > It's usually going to be the case that the oldest datvacuumxid is
> > template0's, meaning that it will never be possible to truncate clog
> > until autovacuum decides that template0 is at risk of wraparound and
> > goes and vacuums
Tom Lane wrote:
* It might seem that there's no point in per-table adjustment of
critical_age, since only the system-wide maximum means anything for
resource consumption. I'm not so sure though --- for a really large
table, the time needed to finish vacuuming it could be significant,
meaning it
Dear PostgreSQL gurus,
having read through the thread on the topic cited above, I still think the change - however well-founded it may be - carries a problem: That of an upgrade on installations that relied on the statement.
Currently, I'm preparing to switch a PostgreSQL-8.0.3-installation to
Dr. Ernst Molitor wrote:
> Dear PostgreSQL gurus,
>
> having read through the thread on the topic cited above, I still think
> the change - however well-founded it may be - carries a problem: That of
> an upgrade on installations that relied on the statement.
>
> Currently, I'm preparing to switc
On Sun, Nov 05, 2006 at 09:11:07AM +, Simon Riggs wrote:
> On Sun, 2006-11-05 at 01:15 -0500, [EMAIL PROTECTED] wrote:
> > The new PG_MAGIC_MODULE requirement threw me for a loop. I expect it
> > will catch others off guard as well.
> Did you find the documentation adequate? Could you locate wh
On Sat, 2006-11-04 at 13:29 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >> On Fri, Nov 03, 2006 at 11:25:09AM -0500, Tom Lane wrote:
> >>> Since 8.1 has done this all along and no one's actually complained about
> >>> it, I guess no one is using scripts that do "cd". I'm i
On Sun, 2006-11-05 at 01:15 -0500, [EMAIL PROTECTED] wrote:
> Compiled fine. Still a few warnings (using Fedora Core 6 / AMD64).
Presumably those are just the standard warnings we can't easiy
eliminate. If not, can you post them please?
-Neil
---(end of broadcast)--
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Sat, 2006-11-04 at 13:29 -0500, Tom Lane wrote:
>> Looking back in the archives, I note that one of the arguments for
>> making the server use relative paths everywhere was so that it'd be
>> robust against things like DBAs moving directories that cont
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> now we have agreed to have only 4 eras, IIRC:
> 1. In Progress Transactions 0 - OldestXmin
> < limit is OldestXmin
> 2. Completed, normal Xids, status in clog
> < limit is Freeze distance?
> 3. Frozen Xids, tuples fr
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I think a global critical_age parameter is just fine. If you have one
> huge table that takes a long time to vacuum, just adjust critical_age so
> that there's enough time for the huge table vacuum to finish before
> wrap-around. That means that
On Sun, Nov 05, 2006 at 11:01:40AM -0500, Neil Conway wrote:
> On Sun, 2006-11-05 at 01:15 -0500, [EMAIL PROTECTED] wrote:
> > Compiled fine. Still a few warnings (using Fedora Core 6 / AMD64).
> Presumably those are just the standard warnings we can't easiy
> eliminate. If not, can you post them p
On Sun, 2006-11-05 at 11:10 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Sat, 2006-11-04 at 13:29 -0500, Tom Lane wrote:
> >> Looking back in the archives, I note that one of the arguments for
> >> making the server use relative paths everywhere was so that it'd be
> >>
I wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Perhaps you could edit the above if needed?
> < Xids older than freeze_distance will be frozen whenever
> next visited by VACUUM, but there is no forcing function
> until they exceed freeze_limit
>> In
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I'm pretty sure most people don't move live postmasters very frequently,
> plus it isn't clear to me why we should support the people that want
> that to do that, yet not the people who want the absolute-path option.
As already discussed upthread, anyone
On Sun, 2006-11-05 at 12:01 -0500, Tom Lane wrote:
> After re-reading the above, it strikes me that maybe names based around
> "freeze_min" and "freeze_max" would be useful?
Works for me. They are clearly related, yet different and allow a
straightforward explanation of their need and use.
e.g.
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Sun, 2006-11-05 at 12:01 -0500, Tom Lane wrote:
>> After re-reading the above, it strikes me that maybe names based around
>> "freeze_min" and "freeze_max" would be useful?
> Works for me. They are clearly related, yet different and allow a
> straight
Hi all,
I tried to work with NULL items in an array but there are two things I
don't understand. (I just did a cvs update, make, make install... so
sources are current.)
On http://momjian.us/main/writings/pgsql/sgml/arrays.html, you can read :
To set an element of an array constant to NULL, wri
On Sun, 2006-11-05 at 11:49 -0500, Tom Lane wrote:
> I don't see why we should go out of our way to
> provide a bad substitute for pwd.
That argument is conclusive. Agreed.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> vacuum_freeze_min The latest TransactionId that will be "frozen" during
> a VACUUM is calculated by CurrentTransactionId - vacuum_freeze_min.
>
> vacuum_freeze_max
> The maximum age, calculated as distance from CurrentTransactionId, that
> will be al
Guillaume Lelarge wrote:
Hi all,
I tried to work with NULL items in an array but there are two things I
don't understand. (I just did a cvs update, make, make install... so
sources are current.)
On http://momjian.us/main/writings/pgsql/sgml/arrays.html, you can read :
To set an element of a
On Sun, Nov 05, 2006 at 08:23:59PM +0100, Guillaume Lelarge wrote:
> Setting a NULL value seems to work.
>
> amarok=# SELECT ARRAY['a',"NULL",'c'];
> ERROR: column "NULL" does not exist
> LINE 1: SELECT ARRAY['a',"NULL",'c'];
> ^
>
> Using double quotes throws an error.
On Sun, 2006-11-05 at 14:47 -0500, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > vacuum_freeze_min The latest TransactionId that will be "frozen" during
> > a VACUUM is calculated by CurrentTransactionId - vacuum_freeze_min.
> >
> > vacuum_freeze_max
> > The maximum age,
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Sun, 2006-11-05 at 14:47 -0500, Gregory Stark wrote:
>> That way it's unambiguous which is which. Ie, that it's minimum and maximum
>> age and not minimum and maximum transaction id which would be the other way
>> around.
> Sounds logical. Hadn't seen
On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
> I think we're probably better off to just forcibly remove the init file
> during post-recovery cleanup. The easiest place to do this might be
> BuildFlatFiles, which has to scan pg_database anyway ...
Patch enclosed.
Clean apply to HEAD, make
Martijn van Oosterhout a écrit :
> On Sun, Nov 05, 2006 at 08:23:59PM +0100, Guillaume Lelarge wrote:
>> Setting a NULL value seems to work.
>>
>> amarok=# SELECT ARRAY['a',"NULL",'c'];
>> ERROR: column "NULL" does not exist
>> LINE 1: SELECT ARRAY['a',"NULL",'c'];
>> ^
>>
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
>> I think we're probably better off to just forcibly remove the init file
>> during post-recovery cleanup. The easiest place to do this might be
>> BuildFlatFiles, which has to scan pg_database anyway .
On Sat, 2006-11-04 at 23:34 -0500, Tom Lane wrote:
> Perhaps use a PG_TRY construct?
At least for the existing code, this doesn't work well: the function
exits early via ereport(LOG) and then "return STATUS_ERROR;", so AFAICS
there isn't an easy way to simplify the existing error handling logic
vi
Neil Conway <[EMAIL PROTECTED]> writes:
> On Sat, 2006-11-04 at 23:34 -0500, Tom Lane wrote:
>> Perhaps use a PG_TRY construct?
> At least for the existing code, this doesn't work well: the function
> exits early via ereport(LOG) and then "return STATUS_ERROR;", so AFAICS
> there isn't an easy way
I wrote:
> ... Not sure that
> this is actually a net win though, as a PANIC might well be considered a
> worse problem than a one-time leak of some LDAP state.
Come to think of it: either elog(ERROR) or a failure return from
CheckLDAPAuth is going to lead directly to backend exit, so the
whole
On Sun, 2006-11-05 at 19:28 -0500, Tom Lane wrote:
> Come to think of it: either elog(ERROR) or a failure return from
> CheckLDAPAuth is going to lead directly to backend exit, so the
> whole thing is pretty much a cosmetic issue anyway.
Thanks for the feedback. Patch applied, with an additional
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
> Nothing except initdb should add objects in pg_catalog. AFAICS,
> adminpack doesn't have any special requirements, so it should behave
> like all other contrib modules.
Where are we on this? When this topic was last discussed, the thr
Hello hackers,
I noticed that the table description given by \d in psql
does not indicate whether a trigger is enabled or disabled.
In my opinion, if a trigger is disabled, that fact is essential
information that a person looking at the output of \d would want to
know. I would like to add this
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> My first impulse was to just append a " (disabled)" after each
> disabled trigger, but perhaps that is not visually obvious enough,
> especially if the table has many triggers on it.
Agreed, but maybe put it up at the front?
Triggers:
y AFTER DELET
34 matches
Mail list logo
