On Sat, Jan 7, 2017 at 5:30 PM, Andrey Borodin wrote:
> The new status of this patch is: Ready for Committer
I don't think that this thread has reached a conclusion yet. From what
I can see the last patch does not apply, so I have moved the patch to
next CF with "waiting on author".
--
Michael
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Here’s review of Background Sessions v2 patch.
===Purpose===
On 11/10/16 21:54, Merlin Moncure wrote:
> On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek wrote:
>> On 10/10/16 16:44, Merlin Moncure wrote:
>>> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote:
On 6 October 2016 at 21:27, Robert Haas wrote:
> I think we should implement background tra
2016-10-11 21:54 GMT+02:00 Merlin Moncure :
> On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek
> wrote:
> > On 10/10/16 16:44, Merlin Moncure wrote:
> >> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs
> wrote:
> >>> On 6 October 2016 at 21:27, Robert Haas wrote:
> I think we should implement ba
On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek wrote:
> On 10/10/16 16:44, Merlin Moncure wrote:
>> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote:
>>> On 6 October 2016 at 21:27, Robert Haas wrote:
I think we should implement background transactions and call them
background transac
2016-10-11 17:06 GMT+02:00 Petr Jelinek :
> On 10/10/16 16:44, Merlin Moncure wrote:
> > On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs
> wrote:
> >> On 6 October 2016 at 21:27, Robert Haas wrote:
> >>> I think we should implement background transactions and call them
> >>> background transactions.
On 10/10/16 16:44, Merlin Moncure wrote:
> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote:
>> On 6 October 2016 at 21:27, Robert Haas wrote:
>>> I think we should implement background transactions and call them
>>> background transactions. That allows us to expose additional
>>> functionality
On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote:
> On 6 October 2016 at 21:27, Robert Haas wrote:
>> I think we should implement background transactions and call them
>> background transactions. That allows us to expose additional
>> functionality which is useful, like the ability to kick some
On 2016-10-06 10:56:34 +0100, Simon Riggs wrote:
> On 7 September 2016 at 20:46, Robert Haas wrote:
> > On Sat, Sep 3, 2016 at 7:09 AM, Simon Riggs wrote:
> > True. I believe this issue has been discussed before, and I think
> > it's a solvable issue. I believe that an autonomous transaction co
On Thu, Oct 6, 2016 at 4:53 PM, Simon Riggs wrote:
> For myself, I don't care what you call it.
>
> I just want to be able to invoke it by saying PRAGMA AUTONOMOUS_TRANSACTION;
> and I know many others do also.
To me, those statements are rather contradictory, and I don't support
the latter propo
On 6 October 2016 at 21:27, Robert Haas wrote:
>> * The labelling "Autonomous Transaction" is a simple coat of paint,
>> which can easily be transferred to a better implementation if one
>> comes. If one doesn't then its better to have something than nothing.
>> So I suggest we commit Background
On Thu, Oct 6, 2016 at 5:56 AM, Simon Riggs wrote:
> Just to point out that I've actually written this approach already.
> The patch is available, Autonomous Subtransactions.
> We discussed it in Ottawa and it was rejected. (I thought Robert was
> there, but Serge and Tom definitely were).
Where
On 06/10/16 11:56, Simon Riggs wrote:
>
> * The labelling "Autonomous Transaction" is a simple coat of paint,
> which can easily be transferred to a better implementation if one
> comes. If one doesn't then its better to have something than nothing.
> So I suggest we commit Background Transactions
On 7 September 2016 at 20:46, Robert Haas wrote:
> On Sat, Sep 3, 2016 at 7:09 AM, Simon Riggs wrote:
>> On 2 September 2016 at 09:45, Robert Haas wrote:
>>> On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut
>>> wrote:
I would like to propose the attached patch implementing autonomous
On 9/3/16 9:08 AM, Serge Rielau wrote:
> Interestingly, despite being supported in PL/SQL on nested BEGIN END blocks,
> we nearly exclusively see AT’s covering the entire function or trigger.
Oracle only supports an entire PL/SQL function to be declared
autonomous. But it was pretty easy in my i
On 8/31/16 9:11 AM, Craig Ringer wrote:
> Peter, you mention "Oracle-style autonomous transaction blocks".
>
> What are the semantics to be expected of those with regards to:
>
> - Accessing objects exclusively locked by the outer xact or where the
> requested lockmode conflicts with a lock held
On 8/31/16 8:46 AM, Greg Stark wrote:
> I'm surprised by the background worker. I had envisioned autonomous
> transactions being implemented by allowing a process to reserve a
> second entry in PGPROC with the same pid. Or perhaps save its existing
> information in a separate pgproc slot (or stack
On 8/31/16 12:38 AM, Jaime Casanova wrote:
> On 30 August 2016 at 20:50, Peter Eisentraut
> wrote:
>>
>> - Patches to PL/pgSQL to implement Oracle-style autonomous transaction
>> blocks:
>>
>> AS $$
>> DECLARE
>> PRAGMA AUTONOMOUS_TRANSACTION;
>> BEGIN
>> FOR i IN 0..9 LOOP
>> START TRANSA
On Tue, Sep 13, 2016 at 5:06 PM, Petr Jelinek wrote:
> I mostly agree. I think if this was called something like background
> transactions it might be better. It's definitely useful functionality but
> the naming is clearly contentious. It won't stop people using it for same
> use-cases as autonom
On 13/09/16 22:24, Robert Haas wrote:
On Wed, Sep 7, 2016 at 9:14 PM, Craig Ringer
wrote:
That's probably going to be one of the smaller costs. Doing this with
bgworkers won't be cheap, but you need to consider the alternative.
Factoring out all transaction-specific data currently stored in or
On Wed, Sep 7, 2016 at 9:14 PM, Craig Ringer
wrote:
> That's probably going to be one of the smaller costs. Doing this with
> bgworkers won't be cheap, but you need to consider the alternative.
> Factoring out all transaction-specific data currently stored in or
> pointed to by globals into a tran
On 8 Sep. 2016 1:38 pm, "Andres Freund" wrote:
>
> I kind of dislike this approach for a different reason than already
> mentioned in this thread: Namely it's not re-usable for implementing
> streaming logical replication of large transaction, i.e. allow to decode
> & apply un-committed changes.
Hi,
On 2016-08-30 21:50:05 -0400, Peter Eisentraut wrote:
> I would like to propose the attached patch implementing autonomous
> transactions for discussion and review.
>
> This work was mostly inspired by the discussion about pg_background a
> while back [0]. It seemed that most people liked th
On 8 September 2016 at 08:18, Tsunakawa, Takayuki
wrote:
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer
>> Of course, if we could decrease the startup cost of a bgworker
>
>> For this use in autonomous tx's we could probably pool
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer
> Of course, if we could decrease the startup cost of a bgworker
For this use in autonomous tx's we could probably pool workers. Or at least
lazily terminate them so that the loop cases
On 8 Sep. 2016 3:47 am, "Robert Haas" wrote:
>
> Of course, if we could decrease the startup cost of a bgworker
For this use in autonomous tx's we could probably pool workers. Or at least
lazily terminate them so that the loop cases work better by re-using an
existing bgworker.
I'm pretty sure
On Sat, Sep 3, 2016 at 7:09 AM, Simon Riggs wrote:
> On 2 September 2016 at 09:45, Robert Haas wrote:
>> On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut
>> wrote:
>>> I would like to propose the attached patch implementing autonomous
>>> transactions for discussion and review.
>>
>> I'm pretty
On 3 Sep. 2016 20:27, "Greg Stark" wrote:
>
> Well using a separate process also requires rewriting locking and
> deadlock detection since a reasonable user might expect that second
> process to have access to data locked in their current transaction.
The user is going to hit some confusing iss
> On Sep 3, 2016, at 5:25 AM, Greg Stark wrote:
>
> On Sat, Sep 3, 2016 at 12:09 PM, Simon Riggs wrote:
>> So doing autonomous transactions inside a single backend doesn't gain
>> you very much, yet it is an enormously invasive patch to do it that
>> way, not least because it requires you to re
On Sat, Sep 3, 2016 at 12:09 PM, Simon Riggs wrote:
> So doing autonomous transactions inside a single backend doesn't gain
> you very much, yet it is an enormously invasive patch to do it that
> way, not least because it requires you to rewrite locking and
> deadlocks to make them work correctly
On 2 September 2016 at 09:45, Robert Haas wrote:
> On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut
> wrote:
>> I would like to propose the attached patch implementing autonomous
>> transactions for discussion and review.
>
> I'm pretty skeptical of this approach. Like Greg Stark, Serge Rielau,
On 9/2/16 3:45 AM, Robert Haas wrote:
So my suggestion is
that you pursue the work but change the name.
That might make the plpgsql issues significantly easier to deal with as
well, by making it very explicit that you're doing something with a
completely separate connection. That would make r
On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut
wrote:
> I would like to propose the attached patch implementing autonomous
> transactions for discussion and review.
I'm pretty skeptical of this approach. Like Greg Stark, Serge Rielau,
and Constantin Pan, I had expected that autonomous transac
On Thu, Sep 1, 2016 at 8:38 PM, Andres Freund wrote:
>
> I'm not convinced this makes much sense. All FDWs, dblink etc. already
> allow you do stuff outside of a transaction.
You as a DBA can prevent FDWs from being used and dblink is an
extension that you don't have to install.
So if preventing
On 2016-08-31 06:10:31 +0200, Joel Jacobson wrote:
> This is important if you as a caller function want to be sure none of
> the work made by anything called down the stack gets committed.
> That is, if you as a caller decide to rollback, e.g. by raising an
> exception, and you want to be sure *eve
On Wed, Aug 31, 2016 at 6:22 PM, Simon Riggs wrote:
> On 31 August 2016 at 14:09, Joel Jacobson wrote:
>> My idea on how to deal with this would be to mark the function to be
>> "AUTONOMOUS" similar to how a function is marked to be "PARALLEL
>> SAFE",
>> and to throw an error if a caller that ha
On Thu, Sep 1, 2016 at 12:12 AM, Vik Fearing wrote:
> Part of what people want this for is to audit what people *try* to do.
> We can already audit what they've actually done.
>
> With your solution, we still wouldn't know when an unauthorized attempt
> to do something happened.
The unauthorized
On Wed, 31 Aug 2016 14:46:30 +0100
Greg Stark wrote:
> On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut
> wrote:
> > - A API interface to open a "connection" to a background worker, run
> > queries, get results: AutonomousSessionStart(),
> > AutonomousSessionEnd(), AutonomousSessionExecute(), e
On 08/31/2016 03:09 PM, Joel Jacobson wrote:
> On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova
> wrote:
>>
>> On 30 August 2016 at 23:10, Joel Jacobson wrote:
>>>
>>> There should be a way to within the session and/or txn permanently
>>> block autonomous transactions.
>>>
>>
>> This will defeat o
> On Aug 31, 2016, at 6:46 AM, Greg Stark wrote:
>
> Using a background worker mean that the autonomous transaction can't
> access any state from the process memory. Parameters in plpgsql are a
> symptom of this but I suspect there will be others. What happens if a
> statement timeout occurs dur
On Wed, Aug 31, 2016 at 3:11 PM, Craig Ringer wrote:
>
> I suspect that there'll be way too much code that relies on stashing
> xact-scoped stuff in globals for that to be viable. Caches alone.
> Peter will be able to explain more, I'm sure.
>
> We'd probably need a new transaction data object tha
On 31 August 2016 at 14:09, Joel Jacobson wrote:
> On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova
> wrote:
>>
>> On 30 August 2016 at 23:10, Joel Jacobson wrote:
>> >
>> > There should be a way to within the session and/or txn permanently
>> > block autonomous transactions.
>> >
>>
>> This will
On 31/08/16 16:11, Craig Ringer wrote:
On 31 August 2016 at 21:46, Greg Stark wrote:
On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut
wrote:
- A API interface to open a "connection" to a background worker, run
queries, get results: AutonomousSessionStart(), AutonomousSessionEnd(),
Autonomous
On 31 August 2016 at 21:46, Greg Stark wrote:
> On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut
> wrote:
>> - A API interface to open a "connection" to a background worker, run
>> queries, get results: AutonomousSessionStart(), AutonomousSessionEnd(),
>> AutonomousSessionExecute(), etc. The co
On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut
wrote:
> - A API interface to open a "connection" to a background worker, run
> queries, get results: AutonomousSessionStart(), AutonomousSessionEnd(),
> AutonomousSessionExecute(), etc. The communication happens using the
> client/server protocol
2016-08-31 15:09 GMT+02:00 Joel Jacobson :
> On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova
> wrote:
> >
> > On 30 August 2016 at 23:10, Joel Jacobson wrote:
> > >
> > > There should be a way to within the session and/or txn permanently
> > > block autonomous transactions.
> > >
> >
> > This wi
On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova
wrote:
>
> On 30 August 2016 at 23:10, Joel Jacobson wrote:
> >
> > There should be a way to within the session and/or txn permanently
> > block autonomous transactions.
> >
>
> This will defeat one of the use cases of autonomous transactions: audit
On 30 August 2016 at 20:50, Peter Eisentraut
wrote:
>
> - Patches to PL/pgSQL to implement Oracle-style autonomous transaction
> blocks:
>
> AS $$
> DECLARE
> PRAGMA AUTONOMOUS_TRANSACTION;
> BEGIN
> FOR i IN 0..9 LOOP
> START TRANSACTION;
> INSERT INTO test1 VALUES (i);
> IF i % 2
On 30 August 2016 at 23:10, Joel Jacobson wrote:
>
> There should be a way to within the session and/or txn permanently
> block autonomous transactions.
>
This will defeat one of the use cases of autonomous transactions: auditing
>
> Coding conventions, rules and discipline are all good and will
I would love to see autonomous transactions in core.
I just have one major concern, but thankfully it's easily addressed.
There should be a way to within the session and/or txn permanently
block autonomous transactions.
This is important if you as a caller function want to be sure none of
the wo
Robert Haas wrote:
On Thu, Sep 16, 2010 at 5:19 AM, Dimitri Fontaine
wrote:
I think they call that dynamic scope, in advanced programming
language. I guess that's calling for a quote of Greenspun's Tenth Rule:
Any sufficiently complicated C or Fortran program contains an ad hoc
informally-s
Robert Haas writes:
> I plan to reserve judgment on the best way of managing the relevant
> state until such time as someone has gone to the trouble of
> identifying what state that is.
The really fundamental problem here is that you never will be able to
identify all such state. Even assuming t
On Thu, Sep 16, 2010 at 5:19 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> One thing that strikes me (maybe this is obvious) is that the
>> execution of the main transaction and the autonomous transaction are
>> not interleaved: it's a stack. So in terms of globals and stuff,
>> assuming
Robert Haas writes:
> One thing that strikes me (maybe this is obvious) is that the
> execution of the main transaction and the autonomous transaction are
> not interleaved: it's a stack. So in terms of globals and stuff,
> assuming you knew which things needed to be updated, you could push
> all
On Wed, Sep 15, 2010 at 6:21 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié sep 15 14:57:29 -0400 2010:
>
>> I guess so, but the devil is in the details. I suspect that we don't
>> actually want to fork a new backend for every autonomous transactions.
>> That would be pre
Excerpts from Robert Haas's message of mié sep 15 14:57:29 -0400 2010:
> I guess so, but the devil is in the details. I suspect that we don't
> actually want to fork a new backend for every autonomous transactions.
> That would be pretty expensive, and we already have an expensive way
> of emula
Robert Haas wrote:
On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan wrote:
The point being, the answer to how to implement autonomous transactions
could be as simple as, do the same thing as how you manage multiple
concurrent client sessions, more or less. If each client gets its own
Postgres OS
On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan wrote:
> The point being, the answer to how to implement autonomous transactions
> could be as simple as, do the same thing as how you manage multiple
> concurrent client sessions, more or less. If each client gets its own
> Postgres OS process, then
Josh Berkus escribió:
> All,
>
>>
>> Added to TODO:
>>
>> * Add anonymous transactions
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php
>
> IMHO, autonomous transactions should be part of a package with a
> spec-compliant CREATE PROCEDURE statement.
IMHO we should try to
All,
Added to TODO:
* Add anonymous transactions
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php
IMHO, autonomous transactions should be part of a package with a
spec-compliant CREATE PROCEDURE statement.That is, the difference
between PROCEDURES and FUNCTIONS wou
Bruce Momjian wrote:
> > Plus I think we'd be able to improve the code for CREATE INDEX under
> > HOT, and probably a few other wrinkly bits of code.
>
> Added to TODO:
>
> * Add anonymous transactions
>
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php
Sorry, updated to "Ad
Simon Riggs wrote:
> On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
> > >
> > > Agreed. I think Pavel Stehule was doing some experiments with them, I
> > > don't know if he got anywhere.
> > >
> >
> > I did only first research. Any hack is possible - you can stack
> > current transaction
On Jan 25, 2008, at 7:27 AM, Decibel! wrote:
On Wed, Jan 23, 2008 at 05:50:02PM -0500, Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
From looking at how Oracle does them, autonomous transactions are
completely independent of the transaction that originates them
-- they
take a new
> On Wed, Jan 23, 2008 at 05:50:02PM -0500, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > >> From looking at how Oracle does them, autonomous transactions are
> > >> completely independent of the transaction that originates them --
> they
> > >> take a new database snapshot. This
On Wed, Jan 23, 2008 at 05:50:02PM -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> From looking at how Oracle does them, autonomous transactions are
> >> completely independent of the transaction that originates them -- they
> >> take a new database snapshot. This means that u
On Tuesday 22 January 2008 11:02, Roberts, Jon wrote:
> I really needed this functionality in PostgreSQL. A common use for
> autonomous transactions is error logging. I want to log sqlerrm in a
> function and raise an exception so the calling application knows there is
> an error and I have it lo
On Jan 23, 2008 10:06 PM, Gokulakannan Somasundaram <[EMAIL PROTECTED]> wrote:
> On Jan 24, 2008 2:46 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > > The Audit transaction, which is a autonomous transaction need not catch
> any
> > > error and resume the outer transaction.
> >
> > What if the l
On Jan 24, 2008 2:46 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Gokulakannan Somasundaram escribió:
>
> > The Audit transaction, which is a autonomous transaction need not catch
> any
> > error and resume the outer transaction.
>
> What if the logging fails, say because you forgot to create t
Simon Riggs <[EMAIL PROTECTED]> writes:
>> From looking at how Oracle does them, autonomous transactions are
>> completely independent of the transaction that originates them -- they
>> take a new database snapshot. This means that uncommitted changes in the
>> originating transaction are not visib
On Wed, 2008-01-23 at 09:30 +, Gregory Stark wrote:
> I think the hard part would be error handling. You have to be able to catch
> any errors and resume the outer transaction.
I agree that you'd need to do this, but I don't follow why it would be
particularly difficult. You essentially have a
Gokulakannan Somasundaram escribió:
> The Audit transaction, which is a autonomous transaction need not catch any
> error and resume the outer transaction.
What if the logging fails, say because you forgot to create the audit
table?
--
Alvaro Herrerahttp://www.Co
On Wed, 2008-01-23 at 00:26 -0800, Neil Conway wrote:
> On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
> > And there is most important question about data visibility - is
> > autonomous transaction independent on main transaction (isolation)?
>
> >From looking at how Oracle does them, aut
>
>
>
> I think the hard part would be error handling. You have to be able to
> catch
> any errors and resume the outer transaction.
>
I think this is not right. Autonomous transactions are used as soon as you
catch a error in order to log them. It can be used even for auditing. But
resuming the o
"Neil Conway" <[EMAIL PROTECTED]> writes:
> On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
>> And there is most important question about data visibility - is
>> autonomous transaction independent on main transaction (isolation)?
>
>>From looking at how Oracle does them, autonomous transac
On 23/01/2008, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
> > >
> > > Agreed. I think Pavel Stehule was doing some experiments with them, I
> > > don't know if he got anywhere.
> > >
> >
> > I did only first research. Any hack is possible - you
On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
> And there is most important question about data visibility - is
> autonomous transaction independent on main transaction (isolation)?
>From looking at how Oracle does them, autonomous transactions are
completely independent of the transacti
On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
> >
> > Agreed. I think Pavel Stehule was doing some experiments with them, I
> > don't know if he got anywhere.
> >
>
> I did only first research. Any hack is possible - you can stack
> current transaction, but real implementation needs sim
>
> Agreed. I think Pavel Stehule was doing some experiments with them, I
> don't know if he got anywhere.
>
I did only first research. Any hack is possible - you can stack
current transaction, but real implementation needs similar work like
nested transaction :( and it is too low level for me. A
> On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote:
> > Maybe someone could enhance this concept to include it with the core
> > database to provide autonomous transactions.
>
> I agree that autonomous transactions would be useful, but doing them via
> dblink is a kludge.
Kludge or hack but
Neil Conway wrote:
> On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote:
> > Maybe someone could enhance this concept to include it with the core
> > database to provide autonomous transactions.
>
> I agree that autonomous transactions would be useful, but doing them via
> dblink is a kludge. I
On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote:
> Maybe someone could enhance this concept to include it with the core
> database to provide autonomous transactions.
I agree that autonomous transactions would be useful, but doing them via
dblink is a kludge. If we're going to include anythi
81 matches
Mail list logo