you need installed devel packages
I tried to install these packages (uuid-devel and systemd-unit) but yum can
not locate these packages. I tried to install selinux-policy but I found
out that selinux-policy 3.7.19 is already installed and is the latest
package available in Red Hat repository
Hi,
On Mon, 2014-01-20 at 15:46 +0800, Sameer Kumar wrote:
I have downloaded the tar source code of PostgreSQL and also the SPEC file.
I am trying to use rpmbuild command but I always get below error:
error: Failed build dependencies:
uuid-devel is needed by
On Mon, Jan 20, 2014 at 8:42 PM, David Rowley dgrowle...@gmail.com wrote:
On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug f...@phlo.org wrote:
* EXPLAIN VERBOSE ANALYZE now shows the max. number of forward aggregate
transitions per row and aggregate. It's a bit imprecise, because it
doesn't
On Sat, Jan 18, 2014 at 2:59 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/16/2014 08:01 AM, Magnus Hagander wrote:
On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net mailto:mag...@hagander.net
On Mon, Jan 20, 2014 at 1:51 AM, Dave Chinner da...@fromorbit.com wrote:
Postgres is far from being the only application that wants this; many
people resort to tmpfs because of this:
https://lwn.net/Articles/499410/
Yes, we covered the possibility of using tmpfs much earlier in the
thread,
On 16 January 2014 22:37, Stephen Frost sfr...@snowman.net wrote:
allow users to more easily move their various objects from
one tablespace to another. Included are docs and a regression test;
I'm happy to improve on both should folks send me suggestions.
Sounds good.
The command uses
On Fri, Jan 17, 2014 at 11:01:15AM -0800, Josh Berkus wrote:
Mel,
Hi,
So we have a few interested parties. What do we need to do to set up
the Collab session?
This is great and thanks!
There are two summits of interest here -- LSF/MM which will have all the
filesystem, storage and
On 2014-01-17 18:34:25 +, Mel Gorman wrote:
The scheme that'd allow us is the following:
When postgres reads a data page, it will continue to first look up the
page in its shared buffers, if it's not there, it will perform a page
cache backed read, but instruct that read to immediately
Craig Ringer wrote:
Out of personal interest (in pain and suffering) I was recently looking
into how to compile extensions out-of-tree on Windows using Visual
Studio (i.e. no PGXS).
It looks like the conventional answer to this is Do a source build of
PG, compile your ext in-tree in
On Sun, Jan 19, 2014 at 03:37:37AM +0200, Marti Raudsepp wrote:
On Wed, Jan 15, 2014 at 5:34 AM, Jim Nasby j...@nasby.net wrote:
it's very common to create temporary file data that will never, ever, ever
actually NEED to hit disk. Where I work being able to tell the kernel to
avoid flushing
On Jan19, 2014, at 20:00 , David Rowley dgrowle...@gmail.com wrote:
I've applied that patch again and put in the sort operators.
I've push a new version to https://github.com/fgp/postgres/tree/invtrans
which includes
* A bunch of missing declaration for *_inv functions
* An assert that the
Hi everyone,
Is it possible to add the hstore 2.0 patch (and later the json solution) as
an extension for 9.3 right now, so we'll not have to wait for 9.4
I can say that this patch is very important for my organisation's large
project, they won't approve it as a patch but as extension it will
reasonable，I removed the set,patch attached.
Jov
blog: http:amutu.com/blog http://amutu.com/blog
2014/1/20 Marti Raudsepp ma...@juffo.org
2014/1/17 Jov am...@amutu.com
but in the psql --help,-F say:
set field separator (default: |)
if user don't read the offical doc carefully,he can
On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug f...@phlo.org wrote:
On Jan19, 2014, at 20:00 , David Rowley dgrowle...@gmail.com wrote:
I've applied that patch again and put in the sort operators.
I've push a new version to https://github.com/fgp/postgres/tree/invtrans
which includes
* A
Hi,
Many thanks for the prompt response and the suggestions!
So, regarding the issue of production quality you've mentioned,
we understand there are two remaining matters to address:
1. debug_query_string:
As we can't rely on this flag, is there any alternative we can rely on?
2.
From: Amit Kapila amit.kapil...@gmail.com
Do you think without this the problem reported by you is resolved
completely.
User can hit same problem, if he tries to follow similar steps mentioned
in
your first mail. I had tried below steps based on description in your
first mail:
If user
On 1/20/14 2:25 AM, Robert Haas wrote:
On Fri, Jan 17, 2014 at 5:45 AM, Marko Tiikkaja ma...@joh.to wrote:
I see these as being two are different things. There *is* a need for a
full-blown static analyzer for PL/PgSQL, but I don't think it needs to be in
core. However, there seems to be a
On Sun, Jan 19, 2014 at 5:57 AM, Andreas Karlsson andr...@proxel.se wrote:
On 01/18/2014 08:13 PM, Jeremy Harris wrote:
On 31/12/13 01:41, Andreas Karlsson wrote:
On 12/29/2013 08:24 AM, David Rowley wrote:
If it was possible to devise some way to reuse any
previous tuplesortstate perhaps
On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja ma...@joh.to wrote:
What's so hard about plpgsql.warnings='all'? Or if the fact that it's a
list is your concern, I'm not going to oppose to making it a boolean.
Sure, that'd be fine. What I don't want is to have to start each function with:
On 1/20/14 1:55 PM, Robert Haas wrote:
On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja ma...@joh.to wrote:
What's so hard about plpgsql.warnings='all'? Or if the fact that it's a
list is your concern, I'm not going to oppose to making it a boolean.
Sure, that'd be fine. What I don't want is
* Simon Riggs (si...@2ndquadrant.com) wrote:
The command uses the word ALL but then less than all objects, i.e.
only moves objects that are owned by the user.
My thinking was that it was all from that user's perspective.
I would like to see two variants of this...
ALL ... which attempts to
On 19 January 2014 11:43, Marko Tiikkaja ma...@joh.to wrote:
New version attached, without the doc change.
This looks good to me.
- applies cleanly.
- compiles with no warnings.
- passes a sensible set of new regression tests.
- implements the agreed behaviour, per SQL spec.
- I can't
On 01/19/2014 10:31 PM, Rami Grossman wrote:
Hi everyone,
Is it possible to add the hstore 2.0 patch (and later the json
solution) as an extension for 9.3 right now, so we'll not have to wait
for 9.4
I can say that this patch is very important for my organisation's
large project, they
On 1/20/14 2:29 PM, Dean Rasheed wrote:
I think this is ready for committer
Thanks!
... although I would also like to see
the doc changes to make the table of array function descriptions a bit
more explicit about corner cases.
Hmm. I completely missed the fact that unnest() already uses a
On 20 January 2014 13:47, Marko Tiikkaja ma...@joh.to wrote:
On 1/20/14 2:29 PM, Dean Rasheed wrote:
I think this is ready for committer
Thanks!
... although I would also like to see
the doc changes to make the table of array function descriptions a bit
more explicit about corner cases.
On 20 January 2014 14:24, Stephen Frost sfr...@snowman.net wrote:
* Simon Riggs (si...@2ndquadrant.com) wrote:
The command uses the word ALL but then less than all objects, i.e.
only moves objects that are owned by the user.
My thinking was that it was all from that user's perspective.
I
On Jan20, 2014, at 08:42 , David Rowley dgrowle...@gmail.com wrote:
On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug f...@phlo.org wrote:
* An assert that the frame end doesn't move backwards - I realized that
it is after all easy to do that, if it's done after the loop which adds
the new
On Jan20, 2014, at 14:05 , Marko Tiikkaja ma...@joh.to wrote:
On 1/20/14 1:55 PM, Robert Haas wrote:
On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja ma...@joh.to wrote:
What's so hard about plpgsql.warnings='all'? Or if the fact that it's a
list is your concern, I'm not going to oppose to
On Mon, Jan 20, 2014 at 10:51:41AM +1100, Dave Chinner wrote:
On Sun, Jan 19, 2014 at 03:37:37AM +0200, Marti Raudsepp wrote:
On Wed, Jan 15, 2014 at 5:34 AM, Jim Nasby j...@nasby.net wrote:
it's very common to create temporary file data that will never, ever, ever
actually NEED to hit
the doc say:
ALTER USER is now an alias for ALTER
ROLEhttp://www.postgresql.org/docs/devel/static/sql-alterrole.html
.
but alter user lack the following format:
ALTER ROLE name [ IN DATABASE database_name ] SET configuration_parameter{ TO
| = } {
value | DEFAULT }
ALTER ROLE { name |
* Simon Riggs (si...@2ndquadrant.com) wrote:
Not a good argument since IN CURRENT DATABASE applies to all SQL
commands, so would clearly be unnecessary.
I suppose it depends on how you're looking at it.
ALTER TABLESPACE ... RENAME, for example, updates a shared catalog and
therefore the change
On Fri, Jan 17, 2014 at 03:24:01PM -0500, Gregory Smith wrote:
On 1/17/14 10:37 AM, Mel Gorman wrote:
There is not an easy way to tell. To be 100%, it would require an
instrumentation patch or a systemtap script to detect when a
particular page is being written back and track the context.
On Mon, 20 Jan 2014 10:51:41 +1100
Dave Chinner da...@fromorbit.com wrote:
On Sun, Jan 19, 2014 at 03:37:37AM +0200, Marti Raudsepp wrote:
On Wed, Jan 15, 2014 at 5:34 AM, Jim Nasby j...@nasby.net wrote:
it's very common to create temporary file data that will never, ever, ever
actually
Rushabh Lathia rushabh.lat...@gmail.com writes:
As per the PG documentation it says that foreign table do support the
NOT NULL, NULL and DEFAULT.
There has been a great deal of debate about what constraints on foreign
tables ought to mean. Right now, at least for postgres_fdw, they're just
Stephen Frost sfr...@snowman.net writes:
So you're still looking for an 'OWNED' noise word to be added? Also, I
did add the ability to specify types of objects (it's often that we'll
have a INDEXES tablespace, so this made sense), so how about:
ALTER TABLESPACE name MOVE OWNED TO name
On 20 January 2014 15:46, Stephen Frost sfr...@snowman.net wrote:
So you're still looking for an 'OWNED' noise word to be added?
To clarify what the command is actually doing.
Also, I
did add the ability to specify types of objects (it's often that we'll
have a INDEXES tablespace, so this
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What if you're a superuser and you want to move everybody's objects
(perhaps in preparation for dropping the tablespace)? I think there's
value in both the ALL and OWNED forms.
A superuser is considered to 'own' all objects and so 'ALL' and 'OWNED'
above
* Simon Riggs (si...@2ndquadrant.com) wrote:
ALTER TABLESPACE name MOVE OWNED TO name opt_nowait
The ALL seems to have value. MOVE ALL OWNED TO sounds better.
I could go either way on this, really.
ALTER TABLESPACE name MOVE TABLES OWNED TO name opt_nowait
ALTER TABLESPACE name MOVE
On 01/15/2014 10:52 PM, Alvaro Herrera wrote:
I gave this patch a look. There was a bug that the final bounds check
for int32 range was not done when there was no suffix, so in effect you
could pass numbers larger than UINT_MAX and pg_basebackup would not
complain until the number reached the
On Thu, Jan 16, 2014 at 12:07 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Okay, got your point.
Another minor thing is that in latest patch which I have sent yesterday,
I have modified it such that while formation of chunks if there is a data
at end of string which doesn't have
On 20 January 2014 17:00, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What if you're a superuser and you want to move everybody's objects
(perhaps in preparation for dropping the tablespace)? I think there's
value in both the ALL and OWNED forms.
A
Robert Haas escribió:
On Fri, Jan 3, 2014 at 9:11 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Yeah, this stuff is definitely underdocumented relative to vacuum right now.
I have added a paragraph or two. It's a (probably insufficient) start.
I would like to add a sample query to
Hi all,
Attached patch fixes the typo which is in src/backend/command/cluster.c.
Regards,
---
Sawada Masahiko
fix_typo-cluster.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Jan 21, 2014 at 2:13 AM, Sawada Masahiko sawada.m...@gmail.com wrote:
Hi all,
Attached patch fixes the typo which is in src/backend/command/cluster.c.
Thanks! Committed.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 17 January 2014 16:34, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 01/17/2014 05:20 PM, Simon Riggs wrote:
+ if (RelationNeedsWAL(indexrel))
+ CHECK_FOR_WAL_BUDGET();
I don't think we need the RelationNeedsWAL tests. If the relation is not
WAL-logged, you
On 17 January 2014 16:10, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-17 09:04:54 -0500, Robert Haas wrote:
That having been said, I bet it could be done at the tail of
XLogInsert().
I don't think there are many locations where this would be ok.
On 17 January 2014 16:30, Heikki Linnakangas hlinnakan...@vmware.com wrote:
It occurs to me that this is very similar to the method I proposed in June
to enforce a hard limit on WAL usage, to avoid PANIC caused by running out
of disk space when writing WAL:
-20140120.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera escribió:
Here's a first cut at this. Note I have omitted a setting equivalent to
autovacuum_freeze_max_age, but I think we should have one too.
Some more comments on the patch:
* I haven't introduced settings to tweak this per table for
autovacuum. I don't think those are
Hi,
On 2014-01-20 15:39:33 -0300, Alvaro Herrera wrote:
* The multixact_freeze_table_age value has been set to 5 million.
I feel this is a big enough number that shouldn't cause too much
vacuuming churn, while at the same time not leaving excessive storage
occupied by pg_multixact/members,
On Tue, Jan 14, 2014 at 4:25 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
This patch consists of two parts,
0001_expose_explain_triggers_v1_20140114.patch
Expose the code to print out trigger information currently
hidden in ExplainOnePlan().
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
I went to review this, and found that there's not actually a patch
attached ...
Attached. Sorry for that.
This looks good to me except for one thing: if the upcoming node is a
DCH_FX action (ie, turn on fx_mode), I don't think we want to
Jaime Casanova wrote:
On Tue, Jan 14, 2014 at 4:25 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
This patch consists of two parts,
0001_expose_explain_triggers_v1_20140114.patch
0002_auto_explain_triggers_v1_20140114.patch
Documentation will be added later..
I
Peter Geoghegan p...@heroku.com writes:
On Sat, Dec 7, 2013 at 9:26 AM, Fujii Masao masao.fu...@gmail.com wrote:
The patch doesn't apply cleanly against the master due to recent change of
pg_stat_statements. Could you update the patch?
Revision is attached, including changes recently
On Mon, Jan 20, 2014 at 12:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I see this is marked as ready for committer. Where does it stand in
relation to the other long-running thread about calls under-estimation
propagation? I was surprised to find that there isn't any CommitFest
entry linked to
Peter Geoghegan p...@heroku.com writes:
On Mon, Jan 20, 2014 at 12:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, I'm also thinking that the detected_version kluge is about ready
to collapse of its own weight, or at least is clearly going to break in
future. What we need to do is embed the
With apologies to our beloved commitfest-mace-wielding CFM, commitfest
2013-11 intentionally still contains a few open patches. I think that
CF is largely being ignored by most people now that we have CF 2014-01
in progress. If we don't want to do anything about these patches in the
immediate
Alvaro Herrera alvhe...@2ndquadrant.com writes:
With apologies to our beloved commitfest-mace-wielding CFM, commitfest
2013-11 intentionally still contains a few open patches. I think that
CF is largely being ignored by most people now that we have CF 2014-01
in progress. If we don't want to
18.11.2013 07:53, Sawada Masahiko kirjoitti:
On 13 Nov 2013, at 20:51, Mika Eloranta m...@ohmu.fi wrote:
Prevent excessive progress reporting that can grow to gigabytes
of output with large databases.
I got error with following scenario.
$ initdb -D data -E UTF8 --no-locale
/* setting the
On 20 January 2014 21:24, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
* fault tolerant DROP IF EXISTS
I gave a look and it looks good for application. This wasn't
superceded by a future version, correct?
No, this hasn't been superceded. +1 for applying it.
Regards,
Dean
--
Sent
On Wed, Jan 15, 2014 at 11:49:09AM +, Mel Gorman wrote:
It may be the case that mmap/madvise is still required to handle a double
buffering problem but it's far from being a free lunch and it has costs
that read/write does not have to deal with. Maybe some of these problems
can be fixed or
Hi,
On Tue, Jan 14, 2014 at 5:49 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
On Tue, Jan 14, 2014 at 12:54 AM, Marti Raudsepp ma...@juffo.org wrote:
I've been trying it out in a few situations. I implemented a new
enable_partialsort GUC to make it easier to turn on/off, this way it's a
Marko Kreen escribió:
http://www.viva64.com/en/b/0227/ reported that on-stack memset()s
might be optimized away by compilers. Fix it.
Just to clarify, this needs to be applied to all branches, right? If
so, does the version submitted apply cleanly to all of them?
--
Álvaro Herrera
Peter Eisentraut escribió:
src/backend/postmaster/postmaster.c:2255: indent with spaces.
+else
src/backend/postmaster/postmaster.c:2267: indent with spaces.
+break;
I just checked the Jenkins page for this patch:
(2014/01/13 22:53), Craig Ringer wrote:
On 01/09/2014 11:19 PM, Tom Lane wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
My first thought was that it should just preprocess any security
barrier quals in subquery_planner() in the same way as other quals are
preprocessed. But thinking about
Daniel Erez de...@redhat.com writes:
Many thanks for the prompt response and the suggestions!
So, regarding the issue of production quality you've mentioned,
we understand there are two remaining matters to address:
1. debug_query_string:
As we can't rely on this flag, is there any
(2014/01/14 18:24), Shigeru Hanada wrote:
2013/11/18 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
I think it's been previously proposed that we have some version of a
CHECK constraint that effectively acts as an assertion for query
optimization purposes, but isn't
On 20.1.2014 19:30, Heikki Linnakangas wrote:
Attached is a yet another version, with more bugs fixed and more
comments added and updated. I would appreciate some heavy-testing of
this patch now. If you could re-run the tests you've been using,
that could be great. I've tested the WAL
Thanks for the comments.
2014/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
In addition, an idea which I can't throw away is to assume that all
constraints defined on foreign tables as ASSERTIVE. Foreign tables
potentially have dangers to have wrong data by updating source data
not through foreign
Following the discussion on pgsql-general, I thought I'd have a go
implementing json_array_elements_text following the same pattern as
json_each_text. The function makes it possible to join elements of a
json array onto a table, for example:
CREATE TABLE object (name TEXT PRIMARY KEY, properties
On 01/20/2014 09:58 PM, Laurence Rowe wrote:
Following the discussion on pgsql-general, I thought I'd have a go
implementing json_array_elements_text following the same pattern as
json_each_text. The function makes it possible to join elements of a
json array onto a table,
Can we sneak this
On Mon, Jan 20, 2014 at 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Rushabh Lathia rushabh.lat...@gmail.com writes:
As per the PG documentation it says that foreign table do support the
NOT NULL, NULL and DEFAULT.
There has been a great deal of debate about what constraints on foreign
tables
On 01/21/2014 09:09 AM, KaiGai Kohei wrote:
(2014/01/13 22:53), Craig Ringer wrote:
On 01/09/2014 11:19 PM, Tom Lane wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
My first thought was that it should just preprocess any security
barrier quals in subquery_planner() in the same way as
Amit Kapila amit.kapil...@gmail.com writes:
On Mon, Jan 20, 2014 at 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There has been a great deal of debate about what constraints on foreign
tables ought to mean.
What is the reason for keeping DEFAULT behaviour different than
constraints. Right now
On Tue, Jan 21, 2014 at 9:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
On Mon, Jan 20, 2014 at 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There has been a great deal of debate about what constraints on foreign
tables ought to mean.
What is the reason
(2014/01/11 3:11), Robert Haas wrote:
On Mon, Jan 6, 2014 at 5:50 PM, Robert Haas robertmh...@gmail.com wrote:
This is only part of the solution, of course: a complete solution will
involve making the hash table key something other than the lock ID.
What I'm thinking we can do is making the
On 20 January 2014 18:58, Laurence Rowe l...@lrowe.co.uk wrote:
Following the discussion on pgsql-general, I thought I'd have a go
implementing json_array_elements_text following the same pattern as
json_each_text.
This updated patch makes the return type of ``json_array_elements_text``
text
On Mon, Jan 20, 2014 at 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Rushabh Lathia rushabh.lat...@gmail.com writes:
As per the PG documentation it says that foreign table do support the
NOT NULL, NULL and DEFAULT.
There has been a great deal of debate about what constraints on foreign
First of all, I apologize for submitting a patch and missing the commitfest
deadline. Given the size of the patch, I thought I'd submit it for your
consideration regardless.
This patch prevents non-superusers from viewing other user's
pg_stat_activity.application_name. This topic was discussed
(2014/01/21 11:44), Shigeru Hanada wrote:
Thanks for the comments.
2014/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
In addition, an idea which I can't throw away is to assume that all
constraints defined on foreign tables as ASSERTIVE. Foreign tables
potentially have dangers to have wrong data by
On Mon, Jan 20, 2014 at 5:38 PM, MauMau maumau...@gmail.com wrote:
From: Amit Kapila amit.kapil...@gmail.com
Do you think without this the problem reported by you is resolved
completely.
User can hit same problem, if he tries to follow similar steps mentioned
in
your first mail. I had
On Mon, Jan 20, 2014 at 9:49 PM, Robert Haas robertmh...@gmail.com wrote:
I ran Heikki's test suit on latest master and latest master plus
pgrb_delta_encoding_v4.patch on a PPC64 machine, but the results
didn't look too good. The only tests where the WAL volume changed by
more than half a
On Mon, Nov 25, 2013 at 6:55 PM, Robert Haas robertmh...@gmail.com wrote:
But even if that doesn't
pan out, I think the fallback position should not be OK, well, if we
can't get decreased I/O for free then forget it but rather OK, if we
can't get decreased I/O for free then let's get decreased
83 matches
Mail list logo
