"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
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
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
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
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
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
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
"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 .
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'];
>> ^
>>
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
"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 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,
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.
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
"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
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
"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
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.
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
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 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
> >>
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
"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
"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
"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
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)--
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
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
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
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
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
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
34 matches
Mail list logo
