On 05/29/2014 04:59 AM, Peter Geoghegan wrote:
Consider this example:
[local]/postgres=# SELECT to_char(1e9::float8,'9D9');
to_char
--
10.0
(1 row)
[local]/postgres=# SELECT to_char(1e20::float8,'9D9
On 29 May 2014 01:07, Bruce Momjian wrote:
> On Wed, May 28, 2014 at 04:04:13PM +0100, Simon Riggs wrote:
>> On 28 May 2014 15:34, Fujii Masao wrote:
>>
>> >> Also, compress_backup_block GUC needs to be merged with full_page_writes.
>> >
>> > Basically I agree with you because I don't want to add
Hi all,
I'm little confused by the *convertJsonbValue* functon at *jsonb_utils.c*
Maybe I misunderstood something, so I need help =)
>>> if (IsAJsonbScalar(val) || val->type == jbvBinary)
>>> convertJsonbScalar(buffer, header, val);
As I can see, the *convertJsonbScalar* function is used for
On May 29, 2014 12:12 AM, "Amit Kapila" wrote:
>
> I agree with you that there are only few corner cases where evicting
> shared buffers by this utility would harm, but was wondering if we could
> even save those, say if it would only use available free buffers. I think
> currently there is no su
# select '"\uaBcD"'::json;
json
--
"\uaBcD"
but
# select '"\uaBcD"'::jsonb;
ERROR: invalid input syntax for type json
LINE 1: select '"\uaBcD"'::jsonb;
^
DETAIL: Unicode escape values cannot be used for code point values above 007F
when the server encoding is no
postgres=# select '["\u"]'::json->0;
?column?
--
"\u"
(1 row)
Time: 1,294 ms
postgres=# select '["\u"]'::jsonb->0;
?column?
---
"\\u"
(1 row)
It seems to me that escape_json() is wrongly used in jsonb_put_escaped_value(),
right name of escape_json() is a es
>Thanks for extending and revising the FPW-compress patch! Could you add
>your patch into next CF?
Sure. I will make improvements and add it to next CF.
>Isn't it worth measuring the recovery performance for each compression
>algorithm?
Yes I will post this soon.
On Wed, May 28, 2014 at 8:04 PM,
On 05/29/2014 07:55 AM, Teodor Sigaev wrote:
# select '"\uaBcD"'::json;
json
--
"\uaBcD"
but
# select '"\uaBcD"'::jsonb;
ERROR: invalid input syntax for type json
LINE 1: select '"\uaBcD"'::jsonb;
^
DETAIL: Unicode escape values cannot be used for code point val
So I ran into the case again where a system crashed while a hot backup
was being taken. Postgres couldn't start up automatically because the
backup_label was present. This has come up before e.g.
http://www.postgresql.org/message-id/caazkufap1gxcojtyzch13rvevjevwro1vvfbysqtwgud9is...@mail.gmail.com
On 5/27/14, 10:37 PM, Tom Lane wrote:
> I'm not terribly happy about pushing such a change post-beta1 either,
> but it's not like this isn't something we've known was needed. Anyway,
> what's the worst case if we find a bug here? Tell people not to use
> uuid-ossp?
Mainly some more discussion ti
On 5/27/14, 10:37 PM, Tom Lane wrote:
> If you don't like this change, we can revert it and also revert the upgrade
> to 2.69.
Nobody else appears to be concerned, but I would have preferred this option.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 05/29/2014 08:00 AM, Teodor Sigaev wrote:
postgres=# select '["\u"]'::json->0;
?column?
--
"\u"
(1 row)
Time: 1,294 ms
postgres=# select '["\u"]'::jsonb->0;
?column?
---
"\\u"
(1 row)
It seems to me that escape_json() is wrongly used in
jsonb_put_escap
inconsistent. It's been the subject of some discussion on -hackers previously,
IIRC. I actually referred to this difference in my talk at pgCon last Friday.
I see, and I wasn't on your talk :( I'm playing around jsquery and now trying to
implement UTF escapes there.
--
Teodor Sigaev
On 2014-05-29 08:14:48 -0400, Peter Eisentraut wrote:
> On 5/27/14, 10:37 PM, Tom Lane wrote:
> > If you don't like this change, we can revert it and also revert the upgrade
> > to 2.69.
>
> Nobody else appears to be concerned, but I would have preferred this option.
I am pretty concerned actual
On 5/28/14, 7:02 PM, Andres Freund wrote:
> That's a good idea. What i've been thinking about is to add
> -Wno-deprecated to the bison rule in the interim. Maybe after a
> configure test for the option. All deprecation warnings so far seem to
> be pretty unhelpful.
Here is a patch.
diff --git a/c
On 05/29/2014 08:21 AM, Andres Freund wrote:
On 2014-05-29 08:14:48 -0400, Peter Eisentraut wrote:
On 5/27/14, 10:37 PM, Tom Lane wrote:
If you don't like this change, we can revert it and also revert the upgrade to
2.69.
Nobody else appears to be concerned, but I would have preferred this o
On 5/29/14, 8:21 AM, Andres Freund wrote:
> But I don't see downgrading to an
> earlier autoconf as something really helpful.
Well, we could have just hacked up that particular header check to do
what we want.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 2014-05-29 08:49:38 -0400, Peter Eisentraut wrote:
> On 5/29/14, 8:21 AM, Andres Freund wrote:
> > But I don't see downgrading to an
> > earlier autoconf as something really helpful.
>
> Well, we could have just hacked up that particular header check to do
> what we want.
Still wouldn't have s
Thanks for looking at it!
> Date: Thu, 29 May 2014 00:19:33 +0300
> From: hlinnakan...@vmware.com
> To: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
> CC: klaussfre...@gmail.com
> Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
> and patch
>
> On 05/28/2014 11
I have pasted below the EXPLAIN of one of my benchmark queries
(the one I reference in the README).
Plenty of nested loop joins.
However I think I understand your question as to how effective it would be
if the outer is not sorted, and I will see if I can dig into that
if I get time (and it s
On 2014-05-29 08:33:05 -0400, Peter Eisentraut wrote:
> On 5/28/14, 7:02 PM, Andres Freund wrote:
> > That's a good idea. What i've been thinking about is to add
> > -Wno-deprecated to the bison rule in the interim. Maybe after a
> > configure test for the option. All deprecation warnings so far se
El 28/05/2014 22:12, "Peter Geoghegan" escribió:
>
> On Wed, May 28, 2014 at 5:59 PM, Claudio Freire
wrote:
> > For nestloop, correct me if I'm wrong, but index scan nodes don't have
> > visibility of the next tuple to be searched for.
>
> Nested loop joins are considered a particularly compellin
Andres Freund writes:
> On 2014-05-29 08:49:38 -0400, Peter Eisentraut wrote:
>> Well, we could have just hacked up that particular header check to do
>> what we want.
> Still wouldn't have solved that ossp already didn't work on several
> platforms at all anymore and is likely to work on even fe
Andres Freund writes:
> FWIW, I vote for applying something like it. It seems better to collect
> the -Wno-deprecated in one place (i.e. configure) instead of having it
> in every developer's Makefile.custom. The latter will be harder to get
> rid of.
Yeah, that's a good point.
> I'd add a comme
Andrew Dunstan writes:
> On 05/29/2014 08:21 AM, Andres Freund wrote:
>> Yes, it'd have been nice if this were done a month+ ago. But nobody
>> stepped up :(. Seems like the least bad choice :/
> The most worrying thing is that we didn't find the occasioning problem
> when we switched to autocon
I don't think that checkAllTheSame is broken, but it probably would be
after this patch --- ISTM you're breaking the corner case described in the
header comment for checkAllTheSame, where we need to force splitting of a
set of existing tuples that the opclass can't distinguish.
INHO, this patch wi
On 05/29/2014 08:15 AM, Andrew Dunstan wrote:
On 05/29/2014 08:00 AM, Teodor Sigaev wrote:
postgres=# select '["\u"]'::json->0;
?column?
--
"\u"
(1 row)
Time: 1,294 ms
postgres=# select '["\u"]'::jsonb->0;
?column?
---
"\\u"
(1 row)
It seems to me that es
On Thu, May 29, 2014 at 3:09 AM, Heikki Linnakangas
wrote:
> Yeah, the code is pretty crufty, I'm not sure what the proper fix would be.
> I wonder if psprintf would be useful.
I don't know that it's worth worrying about the case you highlight. It
is certainly worth worrying about the lack of a
On Thu, May 29, 2014 at 08:33:05AM -0400, Peter Eisentraut wrote:
> On 5/28/14, 7:02 PM, Andres Freund wrote:
> > That's a good idea. What i've been thinking about is to add
> > -Wno-deprecated to the bison rule in the interim. Maybe after a
> > configure test for the option. All deprecation warnin
What features in 9.4 need more beta testing for recovery?
I've applied my partial-write testing harness to several scenarios in 9.4.
So far its found a recovery bug for gin indexes, a recovery bug for btree,
a vacuum bug for btree indexes (with foreign keys, but that is not relevant
to the bug),
Actually, this is just the tip of the iceberg.
Funny, but
postgres=# select '\u'::text;
text
\u
(1 row)
postgres=# select array['\u']::text[];
array
-
{"\\u"}
postgres=# select '{"\u"}'::text[];
text
-
{u}
postgres=# select '{"\
On Wed, May 28, 2014 at 11:23 PM, Tom Lane wrote:
> Buildfarm critters smew and shearwater are reporting regression test
> failures that suggest that the UUID library can't get a system MAC
> address:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=smew&dt=2014-05-28%2023%3A38%3A28
> http
On Thu, May 29, 2014 at 11:21:44AM +0100, Simon Riggs wrote:
> > Uh, how would that work if you want to compress the background_FPWs?
> > Use compressed_background_FPWs?
>
> We've currently got 1 technique for torn page protection, soon to have
> 2 and with a 3rd on the horizon and likely to recei
On Thu, May 29, 2014 at 02:21:57PM +0200, Andres Freund wrote:
> On 2014-05-29 08:14:48 -0400, Peter Eisentraut wrote:
> > On 5/27/14, 10:37 PM, Tom Lane wrote:
> > > If you don't like this change, we can revert it and also revert the
> > > upgrade to 2.69.
> >
> > Nobody else appears to be conce
On Thu, May 29, 2014 at 09:39:56AM -0700, Jeff Janes wrote:
> What features in 9.4 need more beta testing for recovery?
>
> I've applied my partial-write testing harness to several scenarios in 9.4. So
> far its found a recovery bug for gin indexes, a recovery bug for btree, a
> vacuum bug for bt
Bruce Momjian writes:
> One thing that concerns me is that we already had the problem that users
> creating the uuid-ossp extension had to double-quote the name because of
> the dash, and we have regularly questioned the viability of the
> uuid-ossp codebase.
> Now that we know we have to support
Josh Kupershmidt writes:
> On Wed, May 28, 2014 at 11:23 PM, Tom Lane wrote:
>> I've just committed regression test adjustments to prevent that from
>> being a failure case, but I am confused about why it's happening.
>> I wouldn't be surprised at not getting a MAC address on a machine that
>> la
On Thu, May 29, 2014 at 01:56:22PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > One thing that concerns me is that we already had the problem that users
> > creating the uuid-ossp extension had to double-quote the name because of
> > the dash, and we have regularly questioned the viability o
Jeff Janes wrote:
> One thing is that I want to find a way to drive multixact in fast forward,
> so that the freezing cycle gets a good workout. Currently I can't consume
> enough of them to make them wrap around within the time frame of a test.
IIRC I lobotomized it up by removing the XLogInsert
On Sun, May 25, 2014 at 11:34 PM, Michael Paquier
wrote:
> I noticed a couple of typos in Solution.pm, fixed by the patch
> attached. Those things have been introduced by commits cec8394 (visual
> 2013 support) and 0a78320 (latest pgident run, not actually a problem
> of pgident, because of a misu
On 05/29/2014 09:39 AM, Jeff Janes wrote:
>
> I've applied my partial-write testing harness to several scenarios in
> 9.4. So far its found a recovery bug for gin indexes, a recovery bug
> for btree, a vacuum bug for btree indexes (with foreign keys, but that
> is not relevant to the bug), and no
Teodor Sigaev writes:
>> I don't think that checkAllTheSame is broken, but it probably would be
>> after this patch --- ISTM you're breaking the corner case described in the
>> header comment for checkAllTheSame, where we need to force splitting of a
>> set of existing tuples that the opclass can'
Alvaro Herrera writes:
> Jeff Janes wrote:
>> One thing is that I want to find a way to drive multixact in fast forward,
>> so that the freezing cycle gets a good workout. Currently I can't consume
>> enough of them to make them wrap around within the time frame of a test.
> IIRC I lobotomized it
On 05/29/2014 02:38 PM, Tom Lane wrote:
Josh Kupershmidt writes:
On Wed, May 28, 2014 at 11:23 PM, Tom Lane wrote:
I've just committed regression test adjustments to prevent that from
being a failure case, but I am confused about why it's happening.
I wouldn't be surprised at not getting a M
On Sun, May 25, 2014 at 6:12 AM, Anastasia Lubennikova
wrote:
> Hi, hackers!
> There are first results of my work on GSoC project "Index-only scans for
> GIST".
Cool.
> 1. Version of my project code is in forked repository
> https://github.com/lubennikovaav/postgres/tree/indexonlygist2
> Patch i
On 05/29/2014 04:12 PM, John Lumby wrote:
Thanks for looking at it!
Date: Thu, 29 May 2014 00:19:33 +0300
From: hlinnakan...@vmware.com
To: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
CC: klaussfre...@gmail.com
Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
One of the annoying things about the SPGiST bug Teodor pointed out is
that once you're in the infinite loop, query cancel doesn't work to get
you out of it. There are a couple of CHECK_FOR_INTERRUPTS() calls in
spgdoinsert() that are meant to get you out of exactly this sort of
buggy-opclass situa
On Thu, May 22, 2014 at 12:18 AM, Michael Paquier
wrote:
> On Thu, May 22, 2014 at 12:44 PM, Michael Paquier
> wrote:
>> Hi all,
>>
>> As written in subject, replication protocol documentation lacks
>> details about logical slots in CREATE_REPLICATION_SLOT command:
>> http://www.postgresql.org/do
On 05/29/2014 11:25 PM, Tom Lane wrote:
One of the annoying things about the SPGiST bug Teodor pointed out is
that once you're in the infinite loop, query cancel doesn't work to get
you out of it. There are a couple of CHECK_FOR_INTERRUPTS() calls in
spgdoinsert() that are meant to get you out o
On Thu, May 29, 2014 at 5:23 PM, Heikki Linnakangas
wrote:
> On 05/29/2014 04:12 PM, John Lumby wrote:
>>
>> Thanks for looking at it!
>>
>>> Date: Thu, 29 May 2014 00:19:33 +0300
>>> From: hlinnakan...@vmware.com
>>> To: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
>>> CC: klaussfre...@gma
On Thu, May 29, 2014 at 1:34 PM, Heikki Linnakangas
wrote:
> Also checking that CritSectionCount == 0 seems like a good idea...
What do you do if it isn't?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
On 05/29/2014 11:34 PM, Claudio Freire wrote:
On Thu, May 29, 2014 at 5:23 PM, Heikki Linnakangas
wrote:
On 05/29/2014 04:12 PM, John Lumby wrote:
On 05/28/2014 11:52 PM, John Lumby wrote:
The patch seems to assume that you can put the aiocb struct in shared
memory, initiate an asynchronous
Heikki Linnakangas writes:
> On 05/29/2014 11:25 PM, Tom Lane wrote:
>> In point of fact, we'd be happy to give up the locks and then throw
>> the error. So I was thinking about inventing some macro or out-of-line
>> function that went about like this:
>>
>> if (InterruptPending && (QueryCancelP
Peter Geoghegan writes:
> On Thu, May 29, 2014 at 1:34 PM, Heikki Linnakangas
> wrote:
>> Also checking that CritSectionCount == 0 seems like a good idea...
> What do you do if it isn't?
Not throw the error. (If we did, it'd turn into a PANIC, which doesn't
seem like what we want.)
On Thu, May 29, 2014 at 5:39 PM, Heikki Linnakangas
wrote:
> On 05/29/2014 11:34 PM, Claudio Freire wrote:
>>
>> On Thu, May 29, 2014 at 5:23 PM, Heikki Linnakangas
>> wrote:
>>>
>>> On 05/29/2014 04:12 PM, John Lumby wrote:
> On 05/28/2014 11:52 PM, John Lumby wrote:
>
> Th
On Thu, May 29, 2014 at 1:42 PM, Tom Lane wrote:
> Not throw the error. (If we did, it'd turn into a PANIC, which doesn't
> seem like what we want.)
Of course, but it isn't obvious to me that that isn't what we'd want,
if the alternative is definitely that we'd be stuck in an infinite
uninterrup
Peter Geoghegan writes:
> On Thu, May 29, 2014 at 1:42 PM, Tom Lane wrote:
>> Not throw the error. (If we did, it'd turn into a PANIC, which doesn't
>> seem like what we want.)
> Of course, but it isn't obvious to me that that isn't what we'd want,
> if the alternative is definitely that we'd b
Claudio Freire writes:
> Didn't fix that, but the attached patch does fix regression tests when
> scanning over index types other than btree (was invoking elog when the
> index am didn't have ampeeknexttuple)
"ampeeknexttuple"? That's a bit scary. It would certainly be unsafe
for non-MVCC snaps
On Thu, May 29, 2014 at 4:06 PM, Andrew Dunstan wrote:
> On 05/29/2014 02:38 PM, Tom Lane wrote:
>> Josh Kupershmidt writes:
>> Interesting. Looks like you have access only to virtual network
>> interfaces, and they report all-zero MAC addresses, which the UUID library
>> is smart enough to igno
On Thu, May 29, 2014 at 6:19 PM, Tom Lane wrote:
> Claudio Freire writes:
>> Didn't fix that, but the attached patch does fix regression tests when
>> scanning over index types other than btree (was invoking elog when the
>> index am didn't have ampeeknexttuple)
>
> "ampeeknexttuple"? That's a b
On Thu, May 29, 2014 at 6:43 PM, Claudio Freire wrote:
> On Thu, May 29, 2014 at 6:19 PM, Tom Lane wrote:
>> Claudio Freire writes:
>>> Didn't fix that, but the attached patch does fix regression tests when
>>> scanning over index types other than btree (was invoking elog when the
>>> index am d
> Date: Thu, 29 May 2014 18:00:28 -0300
> Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
> and patch
> From: klaussfre...@gmail.com
> To: hlinnakan...@vmware.com
> CC: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
>
> On Thu, May 29, 2014 at 5:39 PM, Heikki L
Claudio Freire writes:
> On Thu, May 29, 2014 at 6:43 PM, Claudio Freire
> wrote:
>> On Thu, May 29, 2014 at 6:19 PM, Tom Lane wrote:
>>> "ampeeknexttuple"? That's a bit scary. It would certainly be unsafe
>>> for non-MVCC snapshots (read about vacuum vs indexscan interlocks in
>>> nbtree/REA
> From: t...@sss.pgh.pa.us
> To: klaussfre...@gmail.com
> CC: hlinnakan...@vmware.com; johnlu...@hotmail.com;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
> and patch
> Date: Thu, 29 May 2014 17:56:57 -0400
>
> Claudio Freire wr
On Thu, May 29, 2014 at 6:56 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Thu, May 29, 2014 at 6:43 PM, Claudio Freire
>> wrote:
>>> On Thu, May 29, 2014 at 6:19 PM, Tom Lane wrote:
"ampeeknexttuple"? That's a bit scary. It would certainly be unsafe
for non-MVCC snapshots (re
On Thu, May 29, 2014 at 7:11 PM, John Lumby wrote:
>> Nonetheless, getting the next tid out of the index may involve stepping
>> to the next index page, at which point you've lost your interlock
>
> I think we are ok as peeknexttuple (yes bad name, sorry, can change it
> ...
> never advances to
Hi,
On 2014-05-29 17:53:51 -0400, John Lumby wrote:
> to see how we have done it. And I am attaching corrected version
> of your test program which runs just fine.
It's perfectly fine to not be up to the coding style at this point, but
trying to adhere to it to some degree will make code review
> Date: Thu, 29 May 2014 18:00:28 -0300
> Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
> and patch
> From: klaussfre...@gmail.com
> To: hlinnakan...@vmware.com
> CC: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
>
> >>>
> >>> Even if it worked on Linux tod
On Thu, May 29, 2014 at 6:53 PM, John Lumby wrote:
> Well, as mentioned earlier, it is not broken. Whether it is efficient
> I am not sure.
> I have looked at the mutex in aio_suspend that you mentioned and I am not
> quite convinced that, if caller is not the original aio_read process,
> i
On Thu, May 29, 2014 at 7:26 PM, Claudio Freire wrote:
> 1) If it's the same process, wait for the full timeout (no looping).
> If you have to loop (EAGAIN or EINTR - which I just noticed you don't
> check for), that's ok.
Sorry, meant to say just looping on EINTR.
About the style guidelines, no
On 05/29/2014 05:41 PM, Josh Kupershmidt wrote:
On Thu, May 29, 2014 at 4:06 PM, Andrew Dunstan wrote:
Almost all my critters run in VMs (all but jacana and bowerbird).
They're not running on OpenVZ, are they? `ifconfig` on shearwater says:
[...]
and it seems this all-zeros MAC address is
On Fri, May 30, 2014 at 5:31 AM, Robert Haas wrote:
> Thanks, this looks good. But shouldn't the bit about output plugin
> options mention say something like:
>
> ( option_name option_argument [, ...] )
>
> ...instead of just:
>
> ( option [, ...] )
> ?
Yes, true. Here is an updated patch.
--
Mi
Here is a draft patch for some of the issues to do with unicode escapes
that Teodor raised the other day.
I think it does the right thing, although I want to add a few more
regression cases before committing it.
Comments welcome.
cheers
andrew
diff --git a/src/backend/utils/adt/json.c b/s
On Thu, May 29, 2014 at 10:09 PM, Jeff Janes wrote:
>
> What features in 9.4 need more beta testing for recovery?
Another feature which have interaction with recovery is reduced WAL
for Update operation:
http://www.postgresql.org/message-id/e1wnqjm-0003cz...@gemulon.postgresql.org
Commit: a3115f
On Tue, May 27, 2014 at 12:11 AM, Michael Paquier
wrote:
> The feature itself is already mentioned in the release notes in a very
> general manner, by telling that bgworkers can be dynamically
> "registered" and "started". Users can still refer to the documentation
> to see more precisely what kin
On Tue, May 27, 2014 at 8:15 AM, Heikki Linnakangas
wrote:
> Since you will be flushing the buffers one "redo partition" at a time, you
> would want to allow the OS to do merge the writes within a partition as much
> as possible. So my even-odd split would in fact be pretty bad. Some sort of
> str
On Mon, May 26, 2014 at 10:47 PM, Shigeru Hanada
wrote:
> 2014-05-24 0:09 GMT+09:00 Sandro Santilli :
>> Indeed I tried "DISCARD ALL" in hope it would have helped, so I find
>> good your idea of allowing extensions to register an hook there.
>>
>> Still, I'd like the FDW handler itself to possibly
On Wed, May 28, 2014 at 8:53 PM, Andres Freund
wrote:
> Hi,
>
> Since a64ca63e59c11d8fe6db24eee3d82b61db7c2c83 pg_sleep() uses
> WaitLatch() to wait. That's fine in itself. But
> procsignal_sigusr1_handler, which is used e.g. when resolving recovery
> conflicts, doesn't unconditionally do a SetLat
78 matches
Mail list logo
