Alex Shulgin writes:
> Heikki Linnakangas writes:
>>>
>>> It appears that replication connection doesn't support URI but only the
>>> traditional conninfo string.
>>>
>>> src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in
>>> libpqrcv_connect():
>>>
>>> snprintf(conninfo_r
On Tue, Nov 25, 2014 at 3:33 PM, Michael Paquier
wrote:
> For now here are the patches either way, so feel free to comment.
And of course the patches are incorrect...
--
Michael
From f0f4f8789c774d6b6fe69e66df0efffb63a9de52 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 25 Nov 2014 14
On Thu, Nov 13, 2014 at 12:15 AM, Andres Freund wrote:
>
> On 2014-11-12 10:13:18 -0500, Robert Haas wrote:
> > On Tue, Nov 11, 2014 at 4:27 AM, Andres Freund
> > wrote:
> > > The more important thing here is that I see little chance of this
> > > getting in before Heikki's larger rework of the
Hi,
I found in pg_dump.c what I believe to be a typo.
-* relationships are set up by doing ALTER INHERIT rather than
using
+* relationships are set up by doing ALTER TABLE INHERIT
rather than using
Attached fixes this if appropriate to do so.
Thanks,
Amit
2014
On Mon, Nov 24, 2014 at 10:49:45AM -0300, Alvaro Herrera wrote:
> What's the general opinion on having test programs somewhere other than
> contrib/ ?
General opinion: slightly favorable.
> We currently have a number of subdirectories for test-only programs:
>
> test_parser (a toy text search pa
On Wed, Jan 22, 2014 at 11:48:26PM +0900, Fujii Masao wrote:
> (3) PQhost() cannot return the hostaddr.
> We can fix the problem (3) by changing PQhost() so that it also
> returns the hostaddr. But this change might break the existing
> application using PQhost(). So, I added new libpq function PQ
On Tue, Nov 25, 2014 at 1:56 AM, Thom Brown wrote:
>
> Hi,
>
> I haven't seen this mentioned anywhere (although it may have as I haven't
read through the entire history of it), but would others find it useful to
have ALTER SYSTEM support comments?
>
> e.g.
>
> ALTER SYSTEM SET autovacuum_vacuum_sc
Hi,
The new WAL format calculates FPI vs plain record data like:
rec_len = XLogRecGetDataLen(record) + SizeOfXLogRecord;
fpi_len = record->decoded_record->xl_tot_len - rec_len;
Due to the amount of data now handled outside the main data portion ,
that doesn't seem correct to me. A
(2014/11/23 6:16), Tom Lane wrote:
> I committed this with some cosmetic adjustments, and one not-so-cosmetic
> one:
Thanks for improving and committing the patch!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
> ROW(x AS something, y AS somethingelse)
Apologies, it looks like Pavel already bought this up:
http://www.postgresql.org/message-id/cafj8prb1t1w6g0sppn-jetyzjpluuz_fxtnbme5okd3xxvf...@mail.gmail.com
and I missed it.
--
Craig Ringer http://www.2ndQuadrant.com/
Postgre
Hi all
Especially with the introduction of json support, but also in the past
with hstore and other things, I've sometimes found myself wishing I
could provide aliases in an anonymous row constructor, e.g.
ROW(x AS something, y AS somethingelse)
The same thing can be done using a scalar subq
Adam Brightwell wrote
> A few related threads/discussions/posts:
>
> * http://www.postgresql.org/message-id/
> 20141016115914.GQ28859@.snowman
> *
> http://www.postgresql.org/message-id/CA+TgmobkYXNOWKEKzX2qGPSr_nvacFGueV=
> orxND-xmZvOVYvg@.gmail
> * http://www.postgresql.org/message-id/
> 2
On 2014-11-24 15:39:22 -0500, Adam Brightwell wrote:
> * int64 (C) to int8 (SQL) mapping for genbki.
That definitely should be a separate patch. Which can be committed much
earlier than the rest - even if we don't actually end up needing it for
this feature, it's still good to have it.
> * replac
> And here is v10 which fixes conflicts with Heikki's WAL API changes (no
> changes otherwise).
After some slight additional changes, here's v11, which I intend to
commit early tomorrow. The main change is moving the test module from
contrib to src/test/modules.
--
Álvaro Herrera
On 14/11/21 22:10, Heikki Linnakangas wrote:
> On 11/21/2014 06:23 AM, Ian Barwick wrote:
>> I thought it might be useful to add a few words at the top
>> of 'src/test/regress/regress.c' to explain what it does and
>> to help differentiate it from 'pg_regress.c' and
>> 'pg_regress_main.c'.
>
> Mak
On 11/24/2014 02:18 PM, Alex Shulgin wrote:
>
> Josh Berkus writes:
Before I go into my ideas, though, what does the current patch do
regarding non-replication PITR?
>>>
>>> It removes that $PGDATA/standby.enable trigger file it relies on to
>>> start the PITR in the first place.
>
On Thu, Nov 20, 2014 at 11:00 AM, Robert Haas wrote:
> On Thu, Nov 20, 2014 at 7:30 AM, Amit Kapila wrote:
>> Few compilation errors in the patch:
>> 1>contrib\postgres_fdw\postgres_fdw.c(2107): error C2198:
>> 'set_config_option' : too few arguments for call
>> 1>contrib\postgres_fdw\postgres_fd
Josh Berkus writes:
>>>
>>> Before I go into my ideas, though, what does the current patch do
>>> regarding non-replication PITR?
>>
>> It removes that $PGDATA/standby.enable trigger file it relies on to
>> start the PITR in the first place.
>
> OK, and that's required for replication too? I'm
On 11/24/2014 02:00 PM, Alex Shulgin wrote:
>
> Josh Berkus writes:
>>>
>>> only that you need to start in recovery mode to start replication
>>
>> Right, but my point is that having a trigger file *is not necessary for
>> replication, only for PITR* -- and maybe not necessary even for PITR.
>> T
On 2014-11-24 12:02:52 -0800, Josh Berkus wrote:
> On 11/24/2014 09:24 AM, Jaime Casanova wrote:
> >> ... I don't honestly think we need a 4th method for promotion.
> >>
> >
> > this is not for promotion, this is to force postgres to start in
> > recovery mode and read recovery configuration param
Josh Berkus writes:
>>
>> only that you need to start in recovery mode to start replication
>
> Right, but my point is that having a trigger file *is not necessary for
> replication, only for PITR* -- and maybe not necessary even for PITR.
> That is, in a streaming replication configuration, hav
Jaime Casanova writes:
>>>
>>> Either way, from the code it is clear that we only stay in recovery if
>>> standby_mode is directly turned on. This makes the whole check for a
>>> specially named file unnecessary, IMO: we should just check the value of
>>> standby_mode (which is off by default).
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Nov 24, 2014 at 4:22 PM, Thom Brown wrote:
> > Perhaps the parser could automatically remove any comment blocks which are
> > followed by a blank/empty line.
>
> Well, if we can agree on something, it doesn't bother me any. I'm
> just saying
* Thom Brown (t...@linux.com) wrote:
> On 24 November 2014 at 20:40, Stephen Frost wrote:
> > I will point out that this use of COMMENT is novel though, no? Comments
> > are normally handled as "COMMENT ON blah IS 'whatever';" ALTER SYSTEM
> > is certainly special but I'm not sure I like the ide
On Mon, Nov 24, 2014 at 4:22 PM, Thom Brown wrote:
> Perhaps the parser could automatically remove any comment blocks which are
> followed by a blank/empty line.
Well, if we can agree on something, it doesn't bother me any. I'm
just saying we spent years arguing about it, because we couldn't agr
All,
While reviewing the supporting documentation and functions for role
attributes I noticed that there seems to be some confusion (at least for
me) with CATUPDATE.
This was prompted by the following comment from Peter about
'has_rolcatupdate' not having a superuser check.
http://www.postgresql
On 24 November 2014 at 21:04, Robert Haas wrote:
> On Mon, Nov 24, 2014 at 3:26 PM, Thom Brown wrote:
> > I haven't seen this mentioned anywhere (although it may have as I haven't
> > read through the entire history of it), but would others find it useful
> to
> > have ALTER SYSTEM support comme
On Mon, Nov 24, 2014 at 3:26 PM, Thom Brown wrote:
> I haven't seen this mentioned anywhere (although it may have as I haven't
> read through the entire history of it), but would others find it useful to
> have ALTER SYSTEM support comments?
Oh, please no.
The main thing that caused us to have n
On Mon, Nov 24, 2014 at 6:26 AM, Robert Haas wrote:
> On Fri, Nov 21, 2014 at 3:38 PM, Peter Geoghegan wrote:
>> What do other people think? Should RETURNING project updated tuples as
>> well as inserted tuples, as described here?
>
> I think it should.
Looks like the consensus is that we should
On 24 November 2014 at 20:40, Stephen Frost wrote:
> * Thom Brown (t...@linux.com) wrote:
> > I haven't seen this mentioned anywhere (although it may have as I haven't
> > read through the entire history of it), but would others find it useful
> to
> > have ALTER SYSTEM support comments?
>
> I do
* Thom Brown (t...@linux.com) wrote:
> I haven't seen this mentioned anywhere (although it may have as I haven't
> read through the entire history of it), but would others find it useful to
> have ALTER SYSTEM support comments?
I do think it'd be useful. I don't think 'inline' deserves inclusion
All,
I am simply breaking this out into its own thread from the discussion on
additional role attributes (
http://www.postgresql.org/message-id/20141015052259.gg28...@tamriel.snowman.net
).
A few related threads/discussions/posts:
*
http://www.postgresql.org/message-id/20141016115914.gq28...@tam
* Josh Berkus (j...@agliodbs.com) wrote:
> On 11/24/2014 07:29 AM, Stephen Frost wrote:
> >> > > > Sigh, here we go again. I don't think you can disable
> >> > > > postgresql.auto.conf
> >> > > > in the current code. As I recall, the argument was that it's harder
> >> > > > to
> >> > > > diagno
Hi,
I haven't seen this mentioned anywhere (although it may have as I haven't
read through the entire history of it), but would others find it useful to
have ALTER SYSTEM support comments?
e.g.
ALTER SYSTEM SET autovacuum_vacuum_scale_factor = 0.01
WITH [ INLINE | HEADLINE ] COMMENT $$As most of
Re: Robert Haas 2014-11-24
> > https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mipsel&ver=9.4~rc1-1&stamp=1416547779
> >
> > mips had the problem as well in the past (9.4 beta3):
> >
> > https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mips&ver=9.4~beta3-3&sta
On 11/24/2014 07:29 AM, Stephen Frost wrote:
>> > > > Sigh, here we go again. I don't think you can disable
>> > > > postgresql.auto.conf
>> > > > in the current code. As I recall, the argument was that it's harder to
>> > > > diagnose problems if postgresql.auto.conf takes effect in some system
On 11/24/2014 09:24 AM, Jaime Casanova wrote:
>> ... I don't honestly think we need a 4th method for promotion.
>>
>
> this is not for promotion, this is to force postgres to start in
> recovery mode and read recovery configuration parameters.
>
>> The main reason to want a "we're in recovery fil
Hello
now a functions with more than one polymorphic arguments are relative
fragile due missing casting to most common type. Some our "functions" like
"coalesce" can do it, so it is surprising for our users.
our custom polymorphic function foo(anyelement, anyelement) working well for
foo(10,20)
On Mon, Nov 24, 2014 at 2:07 PM, Tom Lane wrote:
> Two comments on that:
>
> 1. What is the likely use-case for such a thing (considering SQL is not
> exactly friendly to pointers or reference types),
I happen to know that Oracle supports more possible LHS syntaxes in
PL/SQL than we do in PL/pgsq
On Thu, Nov 20, 2014 at 4:45 PM, Andres Freund wrote:
> How about a frontend process having created a relation that then starts
> a parallel query. Then the frontend process ERRORs out and, in the
> course of that, does smgrDoPendingDeletes(). Which will delete the new
> relation. Boom. The backgr
Robert Haas writes:
> On Sun, Nov 23, 2014 at 4:40 PM, Tom Lane wrote:
>> Attached is a draft patch that de-reserves 17 of plpgsql's existing
>> reserved words, leaving 24 still reserved (of which only 9 are not also
>> reserved in the core grammar). This would make it painless to invent an
>> A
On Sun, Nov 23, 2014 at 4:40 PM, Tom Lane wrote:
> I wrote:
>> The core of that complaint is that we'd have to make ASSERT a plpgsql
>> reserved word, which is true enough as things stand today. However,
>> why is it that plpgsql statement-introducing keywords need to be
>> reserved? The only re
On Mon, Nov 24, 2014 at 12:24 PM, Jaime Casanova wrote:
> On Fri, Nov 21, 2014 at 12:55 PM, Josh Berkus wrote:
>> On 11/21/2014 09:35 AM, Alex Shulgin wrote:
>>> Hello,
>>>
>>> Here's an attempt to revive this patch.
>>
>> Yayy! Thank you.
>>
People might not like me for the suggestion, but
On Mon, Nov 24, 2014 at 3:51 AM, Heikki Linnakangas
wrote:
> Ok, applied those extra paragraphs now, and marked as "committed" in the
> commitfest.
Thanks!
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On Fri, Nov 21, 2014 at 12:55 PM, Josh Berkus wrote:
> On 11/21/2014 09:35 AM, Alex Shulgin wrote:
>> Hello,
>>
>> Here's an attempt to revive this patch.
>
> Yayy! Thank you.
>
>>> People might not like me for the suggestion, but I think we should
>>> simply always include a 'recovery.conf' in $
On Mon, Nov 24, 2014 at 9:36 AM, Christoph Berg wrote:
> I'm still seeing trouble with test_shm_mq on mipsel (9.4 rc1):
Boy, that test has certainly caught its share of bugs, and not in the
places I would have expected.
The last round of wrestling with this had to do with working around
HP-UX be
Stephen Frost wrote
> * Alvaro Herrera (
> alvherre@
> ) wrote:
>> Stephen Frost wrote:
>> > * Amit Kapila (
> amit.kapila16@
> ) wrote:
>> > > What exactly you mean by 'disable postgresql.auto.conf', do you
>> > > mean user runs Alter System to remove that entry or manually disable
>> > > som
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-11-21 10:12:40 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > I still think this change makes the error message more verbose, without
> > > any win in clarity.
> >
> > Can we agree that there should be
Heikki Linnakangas writes:
>>
>> It appears that replication connection doesn't support URI but only the
>> traditional conninfo string.
>>
>> src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in
>> libpqrcv_connect():
>>
>> snprintf(conninfo_repl, sizeof(conninfo_repl),
>>
Antonin Houska writes:
> While checking how BM_PERMANENT flag is set (in buffer header), I noticed that
> hash index has it set too. Shouldn't pg_class(relpersistence) be 'u' in this
> case?
See archives; we do not currently have a way to support unlogged indexes
on logged tables. The whole hash
Alvaro Herrera writes:
> We currently have a number of subdirectories for test-only programs:
> test_parser (a toy text search parser, added in 2007)
> dummy_seclabel (for SECURITY LABEL regression testing, added Sept 2010)
> worker_spi (for bgworkers, added Dec 2012)
> test_shm_mq (test program
Alex Shulgin writes:
> Maybe we should move these check/assign hooks to xlog.c, but that's
> likely going to create header files dependency problem due to use of
> GucSource in the hook prototype...
As far as that goes, there is already plenty of precedent for declaring
assorted check/assign hook
On 2014-11-24 10:13:58 -0500, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Stephen Frost wrote:
> > > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > > > What exactly you mean by 'disable postgresql.auto.conf', do you
> > > > mean user runs Alter System to remov
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>
> > > > Last I paid attention to this, there was a clear way to disable the
> > > > inclusion of postgresql.auto.conf in the postgresql.conf. If that's
> > > > gone,
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Last I paid attention to this, there was a clear way to disable the
> > > inclusion of postgresql.auto.conf in the postgresql.conf. If that's
> > > gone, then there is a serious problem. Administrators who manage the
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > > What exactly you mean by 'disable postgresql.auto.conf', do you
> > > mean user runs Alter System to remove that entry or manually disable
> > > some particular entry?
Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > What exactly you mean by 'disable postgresql.auto.conf', do you
> > mean user runs Alter System to remove that entry or manually disable
> > some particular entry?
>
> Last I paid attention to this, there was a clear way to
Hi,
I'm still seeing trouble with test_shm_mq on mipsel (9.4 rc1):
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mipsel&ver=9.4~rc1-1&stamp=1416547779
mips had the problem as well in the past (9.4 beta3):
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mi
Hi,
On 2014-11-24 10:49:45 -0300, Alvaro Herrera wrote:
> I'm now contemplating the addition on a new one in the commit-timestamps
> patch, and I'm starting to feel that these are all misplaced. I think
> we have been dumping them to contrib not because they really belong
> there, but because of
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> What exactly you mean by 'disable postgresql.auto.conf', do you
> mean user runs Alter System to remove that entry or manually disable
> some particular entry?
Last I paid attention to this, there was a clear way to disable the
inclusion of postgre
On Fri, Nov 21, 2014 at 3:38 PM, Peter Geoghegan wrote:
> What do other people think? Should RETURNING project updated tuples as
> well as inserted tuples, as described here?
I think it should.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent
On Mon, Nov 24, 2014 at 6:57 AM, Kouhei Kaigai wrote:
> Indeed, I don't think it is a good idea to start from this harder portion.
> Let's focus on just varno/varattno remapping to replace join relation by
> custom-scan, as an immediate target.
We still need something like this for FDWs, as well.
On 24/11/14 14:49, Alvaro Herrera wrote:
I'm now contemplating the addition on a new one in the commit-timestamps
patch, and I'm starting to feel that these are all misplaced. I think
we have been dumping them to contrib not because they really belong
there, but because of the lack of a better p
While checking how BM_PERMANENT flag is set (in buffer header), I noticed that
hash index has it set too. Shouldn't pg_class(relpersistence) be 'u' in this
case? Currently it's set to 'p':
postgres=# CREATE TABLE a(i int);
CREATE TABLE
postgres=# CREATE INDEX ON a USING HASH (i);
WARNING: hash in
What's the general opinion on having test programs somewhere other than
contrib/ ?
We currently have a number of subdirectories for test-only programs:
test_parser (a toy text search parser, added in 2007)
dummy_seclabel (for SECURITY LABEL regression testing, added Sept 2010)
worker_spi (for bgw
On 11/24/2014 02:41 PM, Alex Shulgin wrote:
Hackers,
It appears that replication connection doesn't support URI but only the
traditional conninfo string.
src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in
libpqrcv_connect():
snprintf(conninfo_repl, sizeof(conninfo_repl),
Hackers,
It appears that replication connection doesn't support URI but only the
traditional conninfo string.
src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in
libpqrcv_connect():
snprintf(conninfo_repl, sizeof(conninfo_repl),
"%s dbname=replication replicatio
Hi, Heikki!
Thank you for summarizing. In general, I agree with your notes with
some exceptions.
On Mon, Nov 24, 2014 at 1:52 PM, Heikki Linnakangas wrote:
> On 11/10/2014 10:30 PM, Alexander Korotkov wrote:
>
>> Don't allowing CREATE ACCESS METHOD command seems problematic for me. How
>> could
Josh Berkus writes:
>>
>> Well, the latest version of this patch fails to start when it sees
>> 'recovery.conf' in PGDATA:
>>
>> FATAL: "recovery.conf" is not supported anymore as a recovery method
>> DETAIL: Refer to appropriate documentation about migration methods
>>
>> I've missed al
On 09/25/2014 05:10 AM, Robert Haas wrote:
On Wed, Sep 24, 2014 at 2:34 PM, Fabien COELHO wrote:
Sigh.
How to transform a trivial 10 lines patch into a probably 500+ lines project
involving flex & bison & some non trivial data structures, and which may get
rejected on any ground...
Maybe I'll
> Kouhei Kaigai writes:
> > Let me explain the current idea of mine.
> > CustomScan node will have a field that hold varnode mapping
> > information that is constructed by custom-scan provider on
> > create_customscan_plan, if they want. It is probably a list of varnode.
> > If exists, setrefs.c c
On 09/27/2014 09:36 AM, Peter Geoghegan wrote:
On Fri, Sep 26, 2014 at 11:34 PM, Amit Kapila wrote:
I have observed that this patch is in 'Needs Review' state for
next CF. Do you expect any further review from myside? I think
we can use text recommended by Heikki and after that if you
feel so
NVM. I asked people in IRC and it turns out that after I used ALTER
DATABASE bdrdemo SET default_sequenceam=department_id_seq; command I have
to exit from psql session first and it works again :)
On Mon, Nov 24, 2014 at 6:29 PM, Thom Brown wrote:
> On 24 November 2014 at 09:55, Jirayut Nimsaeng
On 24 November 2014 at 09:55, Jirayut Nimsaeng
wrote:
> Hi,
>
> I'm using PostgreSQL BDR 9.4beta2 to test BDR capability right now.
>
> $ psql --version
> psql (PostgreSQL) 9.4beta2
>
> I used database name bdrdemo for BDR then I've created tables with this DDL
>
> CREATE TABLE DEPARTMENT(
>I
On 11/08/2014 04:21 PM, Simon Riggs wrote:
On 5 November 2014 17:32, Heikki Linnakangas wrote:
Why does sequence_alloc need the current value? If it's a "remote" seqam,
the current value is kept in the remote server, and the last value that was
given to this PostgreSQL server is irrelevant.
T
On 11/10/2014 10:30 PM, Alexander Korotkov wrote:
Don't allowing CREATE ACCESS METHOD command seems problematic for me. How
could it work with pg_upgrade? pg_dump wouldn't dump extra pg_am records.
So, pg_upgrade would break at creating operator classes on new cluster. So,
I agree with dropping c
Hi,
I'm using PostgreSQL BDR 9.4beta2 to test BDR capability right now.
$ psql --version
psql (PostgreSQL) 9.4beta2
I used database name bdrdemo for BDR then I've created tables with this DDL
CREATE TABLE DEPARTMENT(
ID SERIAL PRIMARY KEY NOT NULL,
DEPT CHAR(50) NOT NULL,
On 11/14/2014 10:17 AM, Heikki Linnakangas wrote:
On 10/30/2014 04:12 PM, Andres Freund wrote:
Hi,
I've just once more looked at the WAL stream ans was briefly confused
about all the XLOG_FPI records. Since 54685338e3
log_newpage/log_newpage_buffer and XLogSaveBufferForHint() use the same
WAL r
Alex Shulgin writes:
>
>>> > * Why do you include xlog_internal.h in guc.c and not xlog.h?
>>
>>> we actually need both but including xlog_internal.h also includes xlog.h
>>> i added xlog.h and if someone things is enough only putting
>>> xlog_internal.h let me know
>>
>> What's required from xlo
79 matches
Mail list logo
