Itagaki Takahiro wrote:
Stephen Frost sfr...@snowman.net wrote:
Can you provide an update on this patch? Joe, you were going to
review and possibly commit it. Itagaki, did you have a new version?
Are there any outstanding issues?
Thanks for your reviewing.
Here is an updated
Itagaki Takahiro wrote:
Hi,
contrib/dblink doesn't transfar any non-error messages. Is it by design
or to be a ToDo item? We can use PQsetNoticeReceiver() here.
I never thought about or needed, and no one else ever asked...patch
welcomed.
Joe
signature.asc
Description: OpenPGP digital
On Tue, 2009-07-21 at 20:54 +0300, Alexey Klyukin wrote:
Attached is the updated version of the patch (the original description
is here: http://archives.postgresql.org/pgsql-hackers/2009-07/msg01332.php)
that doesn't use global variables. It also shows the last line of
the context in
On Wed, Sep 16, 2009 at 12:24 AM, Abhijit Menon-Sen a...@toroid.org wrote:
LOG: received SIGHUP, reloading configuration files
LOG: parameter log_connections reset to default value off
LOG: parameter log_disconnections reset to default value off
LOG: Parameter max_connections cannot be
At 2009-09-16 01:18:10 -0500, jcasa...@systemguards.com.ec wrote:
ok, maybe this is not the most brilliant observation but someone has
to say it... keep the same case in the word parameter ;)
Oops, thanks. Re²vised patch attached.
-- ams
diff --git a/src/backend/utils/misc/guc-file.l
That's what I want to believe. But picture if you have, say a
1-terabyte table which is 50% dead tuples and you don't have a spare
1-terabytes to rewrite the whole table.
But trying to VACUUM FULL that table is going to be horridly painful
too, and you'll still have bloated indexes afterwards.
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
This patch changes plpgsql IN parameters so they are mutable.
Makes sense, applies fine, works fine.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, 2009-09-15 at 12:37 -0400, Robert Haas wrote:
Instead of calling these generalized index constraints, I wonder if we
oughtn't to be calling them something like don't-overlap constraints
(that's a bad name, but something along those lines). They're not
really general at all, except
On Tue, 2009-09-15 at 12:22 -0700, Jeff Davis wrote:
I don't like using the word unique in the description, I think it
only
adds to the confusion.
It would emphasize that a unique constraint is a common special case of
the feature.
--
Sent via pgsql-hackers mailing list
--On 15. September 2009 22:41:59 +0100 Simon Riggs si...@2ndquadrant.com
wrote:
http://wiki.postgresql.org/images/0/01/Hot_Standby_Recovery_Functions.pdf
This doesn't work for me, it seems the correct link is
http://wiki.postgresql.org/images/1/10/Hot_Standby_Recovery_Functions.pdf
?
OK, that makes sense. I thought you had hacked either XLogInsert or the
heap WAL replay code so that you could just accumulate tuples in the
rdata
chain and then submit them all under the cover of a single WALInsertLock.
Ah, no, I did not do that.
This would be difficult to do : rdata
Hi,
On Wed, Sep 16, 2009 at 11:37 AM, Fujii Masao masao.fu...@gmail.com wrote:
I was thinking that the automatic reconnection capability is the TODO item
for the later CF. The infrastructure for it has already been introduced in the
current patch. Please see the macro MAX_WALRCV_RETRIES
On Sun, 2009-09-13 at 23:46 -0400, Alvaro Herrera wrote:
Should create_help.pl be run on make dist?
It is.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Abhijit Menon-Sen wrote:
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
This patch changes plpgsql IN parameters so they are mutable.
Makes sense, applies fine, works fine.
How does this compare with PLSQL? I know in Ada an IN argument is in
effect a constant. I
At 2009-09-16 08:37:40 -0400, and...@dunslane.net wrote:
How does this compare with PLSQL?
I don't remember anything of PL/SQL myself, but Pavel Stehule had this
to say in response to the original post:
This behave is in conflict with PL/SQL, what should do some problems.
I thing, so I
Stef Walter wrote:
[Looks like my response to this never made it to the mailing list,
sending again...]
Your original message did not carry a Message-Id header, and neither
does this one (at least the copy I got). Are you doing something weird
to the message? This worries me, because we
On Sep 16, 2009, at 8:37 AM, Andrew Dunstan and...@dunslane.net wrote:
Abhijit Menon-Sen wrote:
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
This patch changes plpgsql IN parameters so they are mutable.
Makes sense, applies fine, works fine.
How does this compare with
Abhijit Menon-Sen wrote:
At 2009-09-16 08:37:40 -0400, and...@dunslane.net wrote:
How does this compare with PLSQL?
I don't remember anything of PL/SQL myself, but Pavel Stehule had this
to say in response to the original post:
This behave is in conflict with PL/SQL, what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Sep 15, 2009 at 10:28:28AM -0700, Jeff Davis wrote:
On Tue, 2009-09-15 at 13:16 -0400, Robert Haas wrote:
Uhh so what happens if I create an index constraint using the
+(integer, integer) operator?
You can use any operator that has
Selena Deckelmann escribió:
From the patch review group this evening, courtesy of Webb Sprague and
Brent Dombrowski. I'm replying on their behalf so that this response
is in the correct thread.
Looks like Peter also reviewed, but I'm forwarding this on anyway.
(Note: Problem running
Andrew Dunstan wrote:
It probably won't cause any problem with code being migrated from
PLSQL, but it will affect code going the other way. The question is:
do we care about that? I'm prepared to be persuaded that we
shouldn't care, but I'm not quite there yet.
Anybody trying to port code
Andrew Dunstan and...@dunslane.net writes:
It probably won't cause any problem with code being migrated from PLSQL,
but it will affect code going the other way. The question is: do we care
about that? I'm prepared to be persuaded that we shouldn't care, but I'm
not quite there yet.
IIRC
I'm not terribly impressed by either of Pavel's arguments. SQL/PSM is
irrelevant, and the existence of one inconsistency doesn't seems to me to be
a good rationale to create another. If there were a major increase in
utility I would be more willing, but at best this overcomes a minor
On Sep 16, 2009, at 6:03 AM, Andrew Dunstan wrote:
Abhijit Menon-Sen wrote:
At 2009-09-16 08:37:40 -0400, and...@dunslane.net wrote:
How does this compare with PLSQL?
I don't remember anything of PL/SQL myself, but Pavel Stehule had
this
to say in response to the original post:
This
On Tue, Sep 15, 2009 at 7:02 PM, Joshua Tolley eggyk...@gmail.com wrote:
On Tue, Sep 15, 2009 at 05:52:35PM -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Tue, 2009-09-15 at 14:42 -0700, Jeff Davis wrote:
operator constraints
operator exclusion constraints
operator
OK, I have a number of comments on this proposal.
What does it buy us, in general, and compared to the existing (non-LSB)
script?
This becomes clearer when you consider what LSB actually entails, which
is:
- INFO header
- standardized exit codes
- functions from /lib/lsb/init-functions
My
On Wed, Sep 16, 2009 at 8:59 AM, Robert Haas robertmh...@gmail.com wrote:
On Sep 16, 2009, at 8:37 AM, Andrew Dunstan and...@dunslane.net wrote:
Abhijit Menon-Sen wrote:
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
This patch changes plpgsql IN parameters so they are mutable.
On Sep 16, 2009, at 8:49 AM, Merlin Moncure wrote:
On Wed, Sep 16, 2009 at 8:59 AM, Robert Haas robertmh...@gmail.com
wrote:
At worst it's an upward-compatible extension, or am I wrong? If it's
useful, which I think it is, what's the harm?
are we guarding against cases like:
select _foo,
On Wed, 2009-09-16 at 15:11 +0200, to...@tuxteam.de wrote:
One question: does the operator have to be reflexive? I.e. A op A holds
for all A?
I don't think that reflexivity is a strict requirement. You could make
this a constraint over a boolean attribute such that false conflicts
with true and
Peter Eisentraut pete...@gmx.net wrote:
OK, I have a number of comments on this proposal.
Thanks for looking at it.
What does it buy us, in general, and compared to the existing
(non-LSB) script?
A conforming script for use in LSB conforming implementations.
what LSB actually
IIRC the original complaint was from someone trying to migrate code
from T/SQL or some other not-quite-PLSQL language. Like you, I'm on
the fence about whether to accept this patch, but it does have some
in-migration rationale.
As someone who writes a lot of plpgsql, I'm in favor of the
On Wed, 2009-09-16 at 10:14 +0300, Peter Eisentraut wrote:
What they should be called is generalized unique constraints, without
reference to index. Because what they generalize is the operator by
which uniqueness is determined.
How about GUC, for short? ;-)
Do you think that Tomás's
On Tue, 2009-09-15 at 22:52 +1000, Brendan Jurd wrote:
I'm just getting started reviewing this version now. I noticed that
your patch seems to have been generated by git.
Ok, I now have a public git repo on git.postgresql.org, and I rebased my
patch before I pushed it.
See updates in my
On Wed, Sep 16, 2009 at 3:14 AM, Peter Eisentraut pete...@gmx.net wrote:
On Tue, 2009-09-15 at 12:37 -0400, Robert Haas wrote:
Instead of calling these generalized index constraints, I wonder if we
oughtn't to be calling them something like don't-overlap constraints
(that's a bad name, but
Hackers,
Here's the feedback on replacing VACUUM FULL with VACUUM REWRITE:
http://it.toolbox.com/blogs/database-soup/getting-rid-of-vacuum-full-feedback-needed-33959
Of note:
a) To date, I have yet to hear a single person bring up an actual
real-life use-case where VACUUM FULL was desireable
Josh Berkus j...@agliodbs.com wrote:
a) To date, I have yet to hear a single person bring up an actual
real-life use-case where VACUUM FULL was desireable and REWRITE
would not be.
Would rewrite have handled this?:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01016.php
-Kevin
Josh Berkus wrote:
Hackers,
Here's the feedback on replacing VACUUM FULL with VACUUM REWRITE:
http://it.toolbox.com/blogs/database-soup/getting-rid-of-vacuum-full-feedback-needed-33959
Of note:
a) To date, I have yet to hear a single person bring up an actual
real-life use-case where
On Sep 16, 2009, at 13:40 , Josh Berkus wrote:
3. This patch eliminates a common plpgsql beginner error and saves all
of us heavy plpgsql users some typing, especially when the use of a
mutable variable means that we can eliminate the DECLARE section
entirely, as in:
This:
CREATE PROCEDURE
On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote:
2) Another utility that does something like UPDATE ... WHERE ctid ? to
move tuples to lower pages. It will be different from current VACUUM
FULL in some ways. It won't require a table lock, for example, but it
won't be able to move
On 9/16/09 11:20 AM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
a) To date, I have yet to hear a single person bring up an actual
real-life use-case where VACUUM FULL was desireable and REWRITE
would not be.
Would rewrite have handled this?:
On Wed, 2009-09-16 at 11:10 -0700, Josh Berkus wrote:
Hackers,
Here's the feedback on replacing VACUUM FULL with VACUUM REWRITE:
http://it.toolbox.com/blogs/database-soup/getting-rid-of-vacuum-full-feedback-needed-33959
Of note:
a) To date, I have yet to hear a single person bring up an
On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote:
I was just going to post that we should make a decision about this,
because ISTM there's some code in Simon's hot standby patch that is only
required to support VACUUM FULL. If we make the decision that we drop
VACUUM FULL in 8.5,
Hannu,
The only case is when you are out of disk space and can't afford to
write out a full set of live rows.
Well, it's actually rather specific. You need to have:
a) *Some* free disk space (FULL requires extra disk) but not enough to
copy one entire table and its indexes.
b) be already
On Wed, 2009-09-16 at 11:10 -0700, Josh Berkus wrote:
Hackers,
Here's the feedback on replacing VACUUM FULL with VACUUM REWRITE:
http://it.toolbox.com/blogs/database-soup/getting-rid-of-vacuum-full-feedback-needed-33959
Of note:
a) To date, I have yet to hear a single person bring up an
On Wed, 2009-09-16 at 13:20 -0500, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
a) To date, I have yet to hear a single person bring up an actual
real-life use-case where VACUUM FULL was desireable and REWRITE
would not be.
Would rewrite have handled this?:
On Wed, 2009-09-16 at 11:48 -0700, Josh Berkus wrote:
Hannu,
The only case is when you are out of disk space and can't afford to
write out a full set of live rows.
Well, it's actually rather specific. You need to have:
a) *Some* free disk space (FULL requires extra disk) but not
Hannu,
If it is a sequence of
1. ordinary VACUUM (it can't run out of FSM anymore, no?)
2. a process moving live tuples from end (using reverse seqscan) to free
space found scanning in first-to-last direction, either one tuple at a
time or one page at a time, until the two scans meet
3.
Michael,
This is also currently valid:
CREATE FUNCTION mod (x int, y int)
RETURNS int LANGUAGE plpgsql
AS $f$
DECLARE
z INT := x % y;
BEGIN
RETURN z;
END; $f$
As is this:
CREATE FUNCTION mod (x int, y int)
RETURNS int LANGUAGE plpgsql
AS $f$
BEGIN
RETURN (x % y);
END;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Sep 16, 2009 at 09:45:52AM -0700, Jeff Davis wrote:
On Wed, 2009-09-16 at 15:11 +0200, to...@tuxteam.de wrote:
One question: does the operator have to be reflexive? I.e. A op A holds
for all A?
I don't think that reflexivity is a
On Sep 16, 2009, at 15:17 , Josh Berkus wrote:
Michael,
This is also currently valid:
CREATE FUNCTION mod (x int, y int)
RETURNS int LANGUAGE plpgsql
AS $f$
DECLARE
z INT := x % y;
BEGIN
RETURN z;
END; $f$
As is this:
CREATE FUNCTION mod (x int, y int)
RETURNS int LANGUAGE plpgsql
AS $f$
On Sep 16, 2009, at 12:44 PM, Michael Glaesemann wrote:
Certainly. I was doing that to have a simple example; obviously you
wouldn't write a mod funciton, and you wouldn't do it in plpgsql.
There
are other case where the lack of mutability in IN parameters causes
you
to create a
Hannu Krosing wrote:
On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote:
2) Another utility that does something like UPDATE ... WHERE ctid ? to
move tuples to lower pages. It will be different from current VACUUM
FULL in some ways. It won't require a table lock, for example, but it
On Wed, 2009-09-16 at 23:53 +0300, Heikki Linnakangas wrote:
Hannu Krosing wrote:
On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote:
2) Another utility that does something like UPDATE ... WHERE ctid ? to
move tuples to lower pages. It will be different from current VACUUM
FULL
On Wed, 2009-09-16 at 23:53 +0300, Heikki Linnakangas wrote:
For the kicks, I looked at what it would take to write a utility like
that. It turns out to be quite trivial, patch attached. It uses the same
principle as VACUUM FULL, scans from the end, moving tuples to
lower-numbered pages until
Michael,
Have an example at hand? I'd argue that in a case of a function of more
complexity from a code clarity standpoint you'd want to assign to a new
variable that describes what the new value reflects.
Depends on what programming language you're used to. For those of us
who do a lot of
On Wed, Sep 16, 2009 at 4:53 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hannu Krosing wrote:
On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote:
2) Another utility that does something like UPDATE ... WHERE ctid ? to
move tuples to lower pages. It will be
Josh Berkus wrote:
Michael,
Have an example at hand? I'd argue that in a case of a function of more
complexity from a code clarity standpoint you'd want to assign to a new
variable that describes what the new value reflects.
Depends on what programming language you're used to. For
All,
Now that Simon has submitted this, can some of the heavy-hitters here
review it? Heikki?
Nobody's name is next to it.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Sep 16, 2009 at 1:42 PM, Josh Berkus j...@agliodbs.com wrote:
On 9/16/09 11:20 AM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
a) To date, I have yet to hear a single person bring up an actual
real-life use-case where VACUUM FULL was desireable and REWRITE
would not
Robert,
Here is a new version of the patch with an updated doc and psql.
I changed the name of the CSV options to prefix them with csv_ to avoid
confusion with any future options. I also had to change the grammar to
allow '*' as a parameter (needed for cvs_force_quote).
When we decide to
Robert Haas robertmh...@gmail.com wrote:
I think this should be in core, not a contrib module.
+1
I also wonder whether we should consider teaching regular VACUUM to
do a little of this every time it's run. Right now, once your table
gets bloated, it stays bloated forever, until you
On Wed, Sep 16, 2009 at 6:05 PM, Josh Berkus j...@agliodbs.com wrote:
Now that Simon has submitted this, can some of the heavy-hitters here
review it? Heikki?
Nobody's name is next to it.
I don't think anyone is planning to ignore this patch, but it wasn't
included in the first round of
Robert Haas wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Hannu Krosing wrote:
On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote:
2) Another utility that does something like UPDATE ... WHERE ctid ? to
I also wonder whether we should consider teaching regular
Josh Berkus j...@agliodbs.com writes:
3. This patch eliminates a common plpgsql beginner error
With respect, that argument is one hundred percent false. I can think
of maybe two complaints about the behavior that we've heard in the last
ten years.
The only real argument I've heard in favor of
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
For the kicks, I looked at what it would take to write a utility like
that. It turns out to be quite trivial, patch attached.
I don't think you've really thought this through; particularly not this:
+ rel = heap_open(relid,
Hi all,
Sorry for my late reply.
There is no other update for this patch since the 13th of August, at least
until today. The new patch is attached
By the way I worked on the comments that Dan and Gabriel pointed out.
I added a check on system such as to prevent an error from this side.
By the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I'm in favor of removing VACUUM FULL in 8.5. To replace it, we should offer:
1) VACUUM REWRITE, which is like CLUSTER but doesn't use an index, and
Check, although I'm not eager to make REWRITE a fully reserved word,
which is what
On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote:
I was just going to post that we should make a decision about this,
because ISTM there's some code in Simon's hot standby patch that is only
required to support VACUUM FULL. If we make the decision that we drop
VACUUM FULL in 8.5,
On Wed, 2009-09-16 at 11:40 -0700, Jeff Davis wrote:
Another thing to think about is that lazy vacuum only shrinks the heap
file if it happens to be able to acquire an access exclusive lock.
Because vacuum can't be run inside a transaction block, I don't think
there's currently a way to
On Wed, Sep 16, 2009 at 6:43 PM, Emmanuel Cecchet m...@asterdata.com wrote:
Here is a new version of the patch with an updated doc and psql.
Thanks, that's great.
I don't think the way the doc changes are formatted is consistent with
what we've done elsewhere. I think that breaking the options
Well, Andrew McNamara just posted today:
http://archives.postgresql.org/message-id/20090916063341.0735c5ac...@longblack.object-craft.com.au
Had VACUUM FULL not been available, though, I'm pretty sure he would've
come up with something else instead.
Indeed I would have. And it was our own
On Wed, 2009-09-16 at 20:36 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
For the kicks, I looked at what it would take to write a utility like
that. It turns out to be quite trivial, patch attached.
I don't think you've really thought this through;
Simon Riggs si...@2ndquadrant.com writes:
What we need is VACUUM FULL CONCURRENTLY and REINDEX CONCURRENTLY.
VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were
possible doesn't make it so.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Tue, Sep 15, 2009 at 4:51 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Same problem. Build log attached.
...Robert
My renonc, please, try new patch. I forgot mark regproc.c file.
regards
Pavel Stehule
This one compiles for me.
...Robert
--
Sent via pgsql-hackers mailing list
On Wed, 2009-09-16 at 21:00 -0400, Tom Lane wrote:
But if
we get rid of old-style VACUUM FULL then we do need something to cover
those few-and-far-between situations where you really do desperately
need to compact a table in place; and a utility like this seems like a
reasonable solution.
Simon Riggs si...@2ndquadrant.com writes:
I think it would be useful to have an additional option to force VACUUM
to wait for the lock so it can truncate. It's annoying to have to re-run
VACUUM just to give it a chance at the lock again.
It would be better to separate out the
Simon Riggs si...@2ndquadrant.com writes:
The way I read the thread so far is that there are multiple
requirements:
* Shrink a table efficiently - when time and space available to do so
To be addressed by the CLUSTER-based solution (VACUUM REWRITE or
whatever we call it).
* Shrink a table
On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
The way I read the thread so far is that there are multiple
requirements:
* Shrink a table efficiently - when time and space available to do so
To be addressed by the CLUSTER-based
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
* Shrink a table concurrently - when no dedicated time available
Wishful thinking, which should not stop us from proceeding with the
On Wed, 2009-09-16 at 21:48 -0400, Tom Lane wrote:
Yeah, I was just wondering about that myself. Seems like there would
be lots of situations where short exclusive-lock intervals could be
tolerated, even though not long ones.
But a short-lived exclusive lock can turn into a long-lived
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-09-16 at 21:48 -0400, Tom Lane wrote:
Yeah, I was just wondering about that myself. Seems like there would
be lots of situations where short exclusive-lock intervals could be
tolerated, even though not long ones.
But a short-lived exclusive
Robert Haas wrote:
I don't think the way the doc changes are formatted is consistent with
what we've done elsewhere. I think that breaking the options out as a
separate block could be OK (because otherwise they have to be
duplicated between COPY TO and COPY FROM) but it should be done more
like
Emmanuel Cecchet m...@asterdata.com writes:
Robert Haas wrote:
When we decide to drop the old syntax (in 8.6?), we will be able to clean a
lot especially in psql.
Considering that we are still carrying syntax that was deprecated in
7.3, I don't think it's likely that we'll phase out the
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
* Shrink a table concurrently - when no dedicated time available
Wishful thinking, which should not stop us from proceeding
On ons, 2009-09-16 at 12:05 -0500, Kevin Grittner wrote:
what LSB actually entails, which is:
- INFO header
- standardized exit codes
- functions from /lib/lsb/init-functions
As well as a standardized set of actions and standard semantics for
them, if we're only talking about the
85 matches
Mail list logo
