Hi,
first of all, thanks to all, that replied!
On Wed, Nov 16, 2005 at 08:28:31AM +0100, Martijn van Oosterhout wrote:
On Wed, Nov 16, 2005 at 08:09:31AM +0100, Yann Michel wrote:
Well, thanks for all the answers. Are the locks then released once they
are not needed any more like in 2PC?
Am Dienstag, 15. November 2005 00:01 schrieb Alvaro Herrera:
Good question. Peter, is pgtranslation supposed to be the primary
source of translations?
Yes, and more importantly, your changes will get overwritten by pgtranslation.
---(end of
On Wed, Nov 16, 2005 at 09:27:55AM +0100, Yann Michel wrote:
On Wed, Nov 16, 2005 at 08:28:31AM +0100, Martijn van Oosterhout wrote:
On Wed, Nov 16, 2005 at 08:09:31AM +0100, Yann Michel wrote:
Well, thanks for all the answers. Are the locks then released once they
are not needed any more
Douglas McNaught wrote:
Which will be the same as the second call. There is quite a big
difference in performance using bind variables.
Does Postgres work the same? Where can I go for more info?
You can do this (or close to it) but you need to explicitly PREPARE
the query (or use the
On Wed, Nov 16, 2005 at 09:56:44AM +0100, Marcus Engene wrote:
Douglas McNaught wrote:
You can do this (or close to it) but you need to explicitly PREPARE
the query (or use the protocol-level prepare, which some client
libraries will do for you). See the SQL documentation for PREPARE.
But
Christopher Kings-Lynne wrote:
Oracle recently gave some money to Zend to make proper Oracle
support
for PHP. In that interface they use bind variables. Apart from
greater
speed, sqlinjection becomes history as well.
I did the same for PostgreSQL for PHP 5.1.
Martijn van Oosterhout wrote:
But this is of no use in a web-context. According to the docs, this
prepare is per session.
Unless you use something like pgpool, in which case a single session
may include multiple requests.
ok. Good point.
This sql cache I think is a really good thing. Is
On Nov 16, 2005, at 15:37 , Michael Glaesemann wrote:
I'm using per-branch configurations, but missed HEAD. I'll get that
fixed. Thanks for the catch.
Back to normal:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=wallaroodt=2005-11-16%
2009:12:09
Michael Glaesemann
grzm myrealbox com
I've a problem occurring daily for me, I get quite a few deadlocks every day,
and the concurrency is not so high. Happens with postgresql 8.0 and 8.1. as
well...
Here's a self-contained testcase, which I think it might be the problem I have
in our production database. While it might be some
Peter Eisentraut wrote:
Am Dienstag, 15. November 2005 00:01 schrieb Alvaro Herrera:
Good question. Peter, is pgtranslation supposed to be the primary
source of translations?
Yes, and more importantly, your changes will get overwritten by pgtranslation.
Ok, I'll update it too and make
Mario Weilguni wrote:
Hi,
T1: BEGIN;
T2: BEGIN;
-- these are the queries similar to those from the foreign key code
T1: SELECT 1 FROM ONLY lookup1 x WHERE id = 1 FOR UPDATE OF x;
T2: SELECT 1 FROM ONLY lookup2 x WHERE id = 3 FOR UPDATE OF x;
T1: SELECT 1 FROM ONLY lookup2 x WHERE id = 3
Ok, this my fault, and you're right.
I took the query from the error messages (a 8.0.3 DB) and applied it to a 8.1
DB on a testing system without thinking too much.
Still I think reordering those queries might prevent a deadlock.
Best regards
Am Mittwoch, 16. November 2005 12:21 schrieb
Hi folks
We're developing here gist index (which works finally, and I remember
about writing some docs about it).
I have few fprintf(stderr,) in function that converts internal
rep. into string. I was really supprised to see them on me screen when :
select count(b) from blah where b ~
Mario Weilguni wrote:
Ok, this my fault, and you're right.
I took the query from the error messages (a 8.0.3 DB) and applied it to a 8.1
DB on a testing system without thinking too much.
Still I think reordering those queries might prevent a deadlock.
Well, if we could reorder them, we
On Wed, Nov 16, 2005 at 10:05:36AM +0100, Grzegorz Jaskiewicz wrote:
Hi folks
We're developing here gist index (which works finally, and I remember
about writing some docs about it).
I have few fprintf(stderr,) in function that converts internal
rep. into string. I was really supprised
On K, 2005-11-16 at 10:05 +0100, Grzegorz Jaskiewicz wrote:
Hi folks
We're developing here gist index (which works finally, and I remember
about writing some docs about it).
I have few fprintf(stderr,) in function that converts internal
rep. into string. I was really supprised to see
Firstly, if you just want a count, what's wrong with count(1) or
count(*).
Because unless the column does not allow nulls, they will not return the
same value.
Mike Pollard
SUPRA Server SQL Engineering and Support
Cincom Systems, Inc.
Better to remain silent
Pollard, Mike wrote:
Firstly, if you just want a count, what's wrong with count(1) or
count(*).
Because unless the column does not allow nulls, they will not return the
same value.
Ah, but in the example given the column was being matched against a
value, so nulls were already excluded.
Richard Huxton wrote:
Pollard, Mike wrote:
Firstly, if you just want a count, what's wrong with count(1) or
count(*).
Because unless the column does not allow nulls, they will not return
the
same value.
Ah, but in the example given the column was being matched against a
value, so
Pollard, Mike schrieb:
Richard Huxton wrote:
Pollard, Mike wrote:
Firstly, if you just want a count, what's wrong with count(1) or
count(*).
Because unless the column does not allow nulls, they will not return
the
same value.
Ah, but in the example given the column was being
On Wed, Nov 16, 2005 at 08:28:28AM -0500, Pollard, Mike wrote:
Details, details. But there is a valid general question here, and
changing the semantics of the query will not address it. When doing a
count(col), why convert col into a string just so you can determine if
it is null or not?
If count(col) convert col to a string (an assumption that Martijn
has cast into doubt, or perhaps shredded), then rather than convert all
non-nulls that are not a string into a string, I was proposing
converting the values into an int with the values 0 or 1 (0 means that
row was null for that
Martijn van Oosterhout kleptog@svana.org writes:
Unless you use something like pgpool, in which case a single session
may include multiple requests.
Actually, I've found pgpool to be no better when it comes to using
real prepared queries---there's no guarantee that any given request is
going to
Pollard, Mike schrieb:
If count(col) convert col to a string (an assumption that Martijn
has cast into doubt, or perhaps shredded), then rather than convert all
non-nulls that are not a string into a string, I was proposing
converting the values into an int with the values 0 or 1 (0 means that
I'm asking, because we have a bigger datawarehouse and dump the data for
a backup every night. Unfortunately, the backup now takes realy long.
You may want to consider upgrading and using PITR backups instead. They
can be much faster to both backup and to restore if something goes
wrong.
--
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
We should probably throw a notice or warning if we go to a table lock,
too.
That's not very useful, because you can only do somethign about it AFTER
the 1 hour exclusive lock merge has already run :)
We shouldn't do anything remotely like
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:
Tad hard to believe. Maybe you missed a make distclean or so?
Yann Michel [EMAIL PROTECTED] writes:
Well, now that I'm thinking about, what you've written I think this is
exactly the point. I think, that there is a VACUUM waiting for the dump
to finish whereas the INSERTS are waiting for the VACUUM to finish.
Only if it's a VACUUM FULL ... plain VACUUM
Grzegorz Jaskiewicz [EMAIL PROTECTED] writes:
I have few fprintf(stderr,) in function that converts internal
rep. into string. I was really supprised to see them on me screen when :
select count(b) from blah where b ~ 'something';
was issued. What the hell, isn't it wrong ?
Depends ... what
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:
Tad hard to believe. Maybe
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for
I agree. I would never ever ever want it to silently start doing
table locks. I would simply avoid using merge at all if that was a
possibility.
However it seems like the idea is to eventually flesh out full
fledged merge. And to do that it sounds like you would need to do
one of the
On Tue, Nov 15, 2005 at 10:27:06PM -0600, Jim C. Nasby wrote:
On Tue, Nov 15, 2005 at 11:04:59PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl,
You could also just add something to the merge syntax like ALLOW
TABLE LOCK or something. The idea is just that the user can
explicitly allow the table lock and thus the more complicated merge.
The problem here is that many people will see that option and think
it's safe to do it... i mean,
Interesting approach. Actually, we could tell the user they have to use
BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
already have a table lock.
---
Rick Gigger wrote:
I agree. I would never ever ever
Yes, sorry for the mess. The problem was somewhere else (not quite
well written log procedure issuing conversion used for logging, even
tho log was off).
--
GJ
If we knew what we were doing, it wouldn't be called Research, would
it? - AE
---(end of
Jim C. Nasby [EMAIL PROTECTED] writes:
I do have perl, python, tcl and nls enabled, could one of them
be trying to pull libssl and libcrypto in for some reason?
Perhaps --- try otool -L (local equivalent of ldd) on them to find
out.
regards, tom lane
On 11/16/05, Bruce Momjian pgman@candle.pha.pa.us wrote:
Interesting approach. Actually, we could tell the user they have to use
BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
already have a table lock.
If the lock will be required, what's the problem in doing it
Jaime Casanova [EMAIL PROTECTED] writes:
If the lock will be required, what's the problem in doing it
internally?
I already explained that: lock upgrading is deadlock-prone.
regards, tom lane
---(end of broadcast)---
TIP
Jaime Casanova wrote:
On 11/16/05, Bruce Momjian pgman@candle.pha.pa.us wrote:
Interesting approach. Actually, we could tell the user they have to use
BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
already have a table lock.
If the lock will be required, what's
On Wed, Nov 16, 2005 at 11:50:51AM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I do have perl, python, tcl and nls enabled, could one of them
be trying to pull libssl and libcrypto in for some reason?
Perhaps --- try otool -L (local equivalent of ldd) on them to find
Jim C. Nasby [EMAIL PROTECTED] writes:
[EMAIL PROTECTED]:13]~/buildfarm/source:39%otool -L `which perl`
/opt/local/bin/perl:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 71.1.3)
These aren't particularly relevant: you need to look at the shared
libraries
On Wed, Nov 16, 2005 at 11:37:46AM -0500, Bruce Momjian wrote:
Interesting approach. Actually, we could tell the user they have to use
BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
already have a table lock.
The bit I'm still missing is why there needs to be a lock at
While hacking on the nulls-in-arrays addition, I noticed a couple of
behaviors that seem a bit bogus to me.
First, array slicing returns NULL any time the requested slice falls
completely outside the array bounds. For instance
regression=# select ('{1,2,3}'::int[])[2:4];
int4
---
{2,3}
(1
Tom Lane wrote:
Log Message:
---
make_restrictinfo() failed to attach the specified required_relids to
its result when the clause was an OR clause. Brain fade exposed by
example from Sebastian B?ck.
I wonder if there should be regression tests for all the bugs exposed
after 8.1 ...
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Wed, Nov 16, 2005 at 11:37:46AM -0500, Bruce Momjian wrote:
Interesting approach. Actually, we could tell the user they have to use
BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
already have a table
Alvaro Herrera [EMAIL PROTECTED] writes:
I wonder if there should be regression tests for all the bugs exposed
after 8.1 ... I mean, what stops anyone from introducing the same bugs
again?
I've never been a fan of regression tests in the narrow sense of
let's test for this specific mistake we
I leaving for Mexico in a few hours to speak at a conference. I return
on Monday.
Is it helpful to tell hackers when I am not around? I was in NYC last
week for four days and didn't publicize it. Of course, I didn't finish
my backlog of email until yesterday. I guess the question is whether
On Wed, 2005-11-16 at 13:09 -0500, Bruce Momjian wrote:
I leaving for Mexico in a few hours to speak at a conference. I return
on Monday.
Is it helpful to tell hackers when I am not around? I was in NYC last
week for four days and didn't publicize it. Of course, I didn't finish
my
On Wed, 2005-11-16 at 18:34 +0100, Martijn van Oosterhout wrote:
On Wed, Nov 16, 2005 at 11:37:46AM -0500, Bruce Momjian wrote:
Interesting approach. Actually, we could tell the user they have to use
BEGIN;LOCK tab before doing MERGE, and throw an error if we don't
already have a table
On Wed, Nov 16, 2005 at 12:59:36PM -0500, Bruce Momjian wrote:
Martijn van Oosterhout wrote:
The bit I'm still missing is why there needs to be a lock at all. The
SQL standard doesn't say anywhere that concurrent MERGE operations
can't conflict. It seems to me that standard visibility rules
Tom Lane [EMAIL PROTECTED] writes:
regression=# select '[0:2]={1,2,3}'::int[] = '{1,2,3}'::int[];
?column?
--
t
(1 row)
regression=# select '{1,2,3,4}'::int[] = '{{1,2},{3,4}}'::int[];
?column?
--
t
(1 row)
This seems pretty bogus as well.
The second case
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Simon Riggs
Sent: Wednesday, November 16, 2005 10:35 AM
To: Martijn van Oosterhout
Cc: Bruce Momjian; Rick Gigger; Tom Lane; Christopher Kings-Lynne; Jim
C.
Nasby; josh@agliodbs.com;
On Wed, Nov 16, 2005 at 11:06:15AM -0800, Dann Corbit wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Simon Riggs
Conceptually, a MERGE statement is just a long string of INSERTs and
UPDATEs in the same transaction and I
Greg Stark [EMAIL PROTECTED] writes:
And changing that would make it harder to test just the contents of the array
without having to match bounds as well.
Fair point, but currently it's impossible to make a comparison that
*does* consider the bounds, which one would think would be the ordinary
Tom Lane [EMAIL PROTECTED] writes:
I could go for a separate operator that has the current behavior
(might as well ignore number of dimensions too, if we're going to
ignore bounds). Any thoughts about the operator name?
Well to me these are two different cases. At least the way I see it
On Tue, Nov 15, 2005 at 13:01:20 -0500,
Dave Cramer [EMAIL PROTECTED] wrote:
I've talked to Ken Geis via email. He suggests that there is
considerable overhead to be saved if we go to binary; especially in
date, and timestamp fields
One thing though if the date is 64 bit instead of
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I could go for a separate operator that has the current behavior
(might as well ignore number of dimensions too, if we're going to
ignore bounds). Any thoughts about the operator name?
Well to me these are two different
Hi Martijn,
On Wed, Nov 16, 2005 at 09:47:33AM +0100, Martijn van Oosterhout wrote:
Ah yes, PostgreSQL doesn't use 2PL, it uses MVCC. quick overview here:
http://linuxgazette.net/issue68/mitchell.html
THX! That was interesting!
Thanks. BTW: Is there anything about locks and their meaning
Hi,
On Wed, Nov 16, 2005 at 10:07:24AM -0500, Tom Lane wrote:
Yann Michel [EMAIL PROTECTED] writes:
Well, now that I'm thinking about, what you've written I think this is
exactly the point. I think, that there is a VACUUM waiting for the dump
to finish whereas the INSERTS are waiting for
Tom Lane [EMAIL PROTECTED] writes:
Well, in that case what do you think about
{{1,2},{3,4},{5,6},{7,8}}
vs
{{1,2,3,4},{5,6,7,8}}
In the first case the first element is {1,2} and in the second case the first
element is {1,2,3,4} so from my point of view there's no way these are
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Well, in that case what do you think about
{{1,2},{3,4},{5,6},{7,8}}
vs
{{1,2,3,4},{5,6,7,8}}
In the first case the first element is {1,2} and in the second case the first
element is {1,2,3,4} so from my point of view
On Wed, Nov 16, 2005 at 03:03:53PM -0500, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I could go for a separate operator that has the current behavior
(might as well ignore number of dimensions too, if we're going to
ignore bounds). Any thoughts about the operator name?
David Fetter [EMAIL PROTECTED] writes:
On Wed, Nov 16, 2005 at 03:03:53PM -0500, Greg Stark wrote:
It occurs to me that it would also make sense to have an operator
that considered the arrays in an order-insensitive comparison.
That sounds more like the SQL:2003 MULTISET, which is
Other than backing up $PGDATA
and running pg_resetxlog
Is there any advice ?
Dave
Nov 16 18:03:30 dx1-ptr postgres[22337]: [6-2] '2005-11-16 17:47:31'
Nov 16 18:03:32 dx1-ptr postgres[29335]: [2-1] LOG: received fast
shutdown request
Nov 16 18:03:32 dx1-ptr postgres[29335]: [3-1] LOG:
Conceptually, a MERGE statement is just a long string of INSERTs and
UPDATEs in the same transaction and I think we should treat it as
such.
I've just got one question about this. Everyone seems to be saying
that try to insert and if that fails update is the same as try to
insert and if
On Wed, Nov 16, 2005 at 09:49:28AM -0500, Tom Lane wrote:
I think we should do REPLACE-like functionality that simply fails if the
match condition isn't equality on a primary key. If we can use SQL-spec
MERGE syntax for this, that's fine, but let's not think in terms of
silently changing to a
daveg [EMAIL PROTECTED] writes:
I agree, but would like to relax the primary key requirement to simply
a unique index. I can see use cases for unique so long as not null keys,
so it would be nice if the MERGE operation would work for these. As nulls
are not equal anyway this doesn't seem to do
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Well, in that case what do you think about
{{1,2},{3,4},{5,6},{7,8}}
vs
{{1,2,3,4},{5,6,7,8}}
In the first case the first element is {1,2} and in the second case the first
element is {1,2,3,4} so from
Joe Conway [EMAIL PROTECTED] writes:
First, the spec only allows arrays to have a lower bound of 1. That
requirement simplifies a whole lot of things. I don't think that many
people actually depend on other than 1 as a lower bound (or at least if
they do, they weren't dumping and reloading
Dave Cramer [EMAIL PROTECTED] writes:
Nov 16 18:03:32 dx1-ptr postgres[23410]: [4-1] LOG: shutting down
Nov 16 18:03:35 dx1-ptr postgres[23410]: [5-1] LOG: database system
is shut down
Nov 16 18:21:18 dx1-ptr postgres[10884]: [1-1] LOG: could not create
IPv6 socket: Address family not
On Wed, Nov 16, 2005 at 04:51:07PM -0500, Tom Lane wrote:
daveg [EMAIL PROTECTED] writes:
I agree, but would like to relax the primary key requirement to simply
a unique index. I can see use cases for unique so long as not null keys,
so it would be nice if the MERGE operation would work for
Yann Michel wrote:
... I guiess that the AUTOVACUUM switch only does an automated VACUUM
but no VACUUM FULL?
Certainly.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of
Tom Lane [EMAIL PROTECTED] writes:
Joe Conway [EMAIL PROTECTED] writes:
First, the spec only allows arrays to have a lower bound of 1. That
requirement simplifies a whole lot of things. I don't think that many
people actually depend on other than 1 as a lower bound (or at least if
Apparently the machine hung in between those two times.
I don't have any specific information, I am debugging remotely over
the phone.
Dave
On 16-Nov-05, at 5:21 PM, Tom Lane wrote:
Dave Cramer [EMAIL PROTECTED] writes:
Nov 16 18:03:32 dx1-ptr postgres[23410]: [4-1] LOG: shutting down
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Joe Conway [EMAIL PROTECTED] writes:
First, the spec only allows arrays to have a lower bound of 1. That
requirement simplifies a whole lot of things. I don't think that many
people actually depend on other than 1 as a lower bound (or at
I've never been a fan of regression tests in the narrow sense of
let's test for this specific mistake we made once. If you can devise
a test that catches a class of errors including the one you actually
made, that's a different story, because it's much more likely to catch a
real future problem.
Christopher Kings-Lynne wrote:
I've never been a fan of regression tests in the narrow sense of
let's test for this specific mistake we made once. If you can devise
a test that catches a class of errors including the one you actually
made, that's a different story, because it's much more
On Wednesday 16 November 2005 21:05, Alvaro Herrera wrote:
Christopher Kings-Lynne wrote:
I've never been a fan of regression tests in the narrow sense of
let's test for this specific mistake we made once. If you can devise
a test that catches a class of errors including the one you
On Tuesday 15 November 2005 04:03, Teodor Sigaev wrote:
Look at HEAD branch.
Kaare Rasmussen wrote:
David Fetter writes in PostgreSQL Weekly News - November 13 2005:
Teodor Sigaev has been making lots of improvements to tsearch2, a
full-text search engine.
I can't find them. Am I
Hi guys,
I've set up a new sample databases project:
http://pgfoundry.org/projects/dbsamples/
If any of you have sample databases (schema + data, pg_dump format) that
you are willing to share under the BSD license, please send 'em to me so
I can host them on the project.
You might also
I assume CREATE TABLESPACE refuses to use a non-empty directory because of the
risk of trashing existing files. Makes sense, but consider the following:
# mkfs -t ext2 /dev/sdc1
# mount -t ext2 /dev/sdc1 /mnt/pg_tables
# chown postgres /mnt/pg_tables
# su -c psql pyarra
pyarra=# CREATE
On Thu, 17 Nov 2005, Philip Yarra wrote:
I assume CREATE TABLESPACE refuses to use a non-empty directory because of the
risk of trashing existing files. Makes sense, but consider the following:
Right, that was the reasoning.
# mkfs -t ext2 /dev/sdc1
# mount -t ext2 /dev/sdc1 /mnt/pg_tables
Philip Yarra [EMAIL PROTECTED] writes:
This is because lost+found exists. Since lost+found would be a reasonably
common directory to find at a mount-point on Unix-like OSs*, would it make
sense for CREATE TABLESPACE to ignore it if present?
No. There is no reason to use a volume's root
On Wed, 16 Nov 2005, Robert Treat wrote:
On Tuesday 15 November 2005 04:03, Teodor Sigaev wrote:
Look at HEAD branch.
Kaare Rasmussen wrote:
David Fetter writes in PostgreSQL Weekly News - November 13 2005:
Teodor Sigaev has been making lots of improvements to tsearch2, a
full-text search
Jim C. Nasby [EMAIL PROTECTED] writes:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=cuckoodt=2005-11-15%2023:56:22
I took a closer look at this, and noticed something interesting:
ccache gcc -no-cpp-precomp -O2 -fno-strict-aliasing -g -Wall
-Wmissing-prototypes -Wmissing-declarations -bundle
86 matches
Mail list logo
