o break.
It would be interesting to capture the output of "env" in the sub-shell
to see which environment variables and functions are getting through.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make change
data is not marked as dead after updates,
Have you checked for uncommitted prepared transactions?
If "select * from pg_prepared_xacts" finds anything, that's
probably your problem.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@pos
> same thing? It just feels like such an obvious feature.
Doesn't jsonb_agg() do exactly that?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
r...@bb-c.de (Rainer J.H. Brandt) writes:
> Tom Lane writes:
>> The whole thing's odd though --- certainly many people are building
>> PG successfully on macOS. There's got to be something unusual about
>> Rainer's build environment, but what?
> I thought so, too, bu
You are right! I totally forgot about this dollar quoting :)
Typically one of those things you will only remember the hard way ;-)
Thanks a lot,
Tom
On Wed, Jul 5, 2017 at 5:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Tom van Tilburg <tom.van.tilb...@gmail.com> writes
Tom van Tilburg <tom.van.tilb...@gmail.com> writes:
> I think I misunderstand. How would that help my insert statement?
> You would get INSERT INTO mytable VALUES ($ javascript with a lot of
> unescaped characters like /n " // etc. $);
Sure, but in a dollar-quoted literal you
I think I misunderstand. How would that help my insert statement?
You would get INSERT INTO mytable VALUES ($ javascript with a lot of
unescaped characters like /n " // etc. $);
and: Am I correct that INSERTS are the way to go in extensions?
Best,
Tom vT.
On Wed, Jul 5, 2017 at 4:57 PM
Tom van Tilburg <tom.van.tilb...@gmail.com> writes:
> I am trying to build an extension where there is the need to insert large
> strings consisting of javascript code.
> ...
> What would be a proper way to get this code into a table via an extension?
> I've been working
for the extension's sql
file but it seems a tedious job to escape the code myself.
Best,
Tom
op and maintain. People were more excited about spending
human effort to save machine cycles forty years ago than they are today.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
build environment, but what?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
error,
> and everything works fine. Unfortunately, I need the 64-bit version.
This makes little sense to me. 64-bit builds have been the default on
macOS for some time.
It's possible that by overriding LDFLAGS you're removing linker switches
that need to be there ...
"Daniel Verite" <dan...@manitou-mail.org> writes:
> Tom Lane wrote:
>> If it is a newline-conversion problem, compressed pg_dump archives would
>> be just as subject to corruption as your binary COPY file is.
> It's mentioned in [1] that the signatu
e careful about how you do the cross-machine file
transfers. I suspect what is really happening is you're not always
doing that the same way, and that some of the methods allow a newline
conversion to happen to the file while others don't.
regards, tom lane
--
Sent
Moreno Andreo <moreno.and...@evolu-s.it> writes:
> Il 04/07/2017 16:51, Tom Lane ha scritto:
>> Pushing binary data around on Windows is always a hazardous proposition.
> So what you are saying is "in the last 5 years you've been extremely
> lucky?" :-)
Yup, pa
length words used in binary-COPY format to
contain such bytes.
You might be better off using plain text COPY format; it can withstand
this sort of thing much better.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
ike it'd often be
useful to load dictionary files that don't match the database's
prevailing locale. Do we really need the t_isalpha tests, or would
it be good enough to assume that anything that isn't t_isspace is
part of a word?
regards, tom lane
--
Sent via pgsql-g
at would allow the
restore to ignore the new parameters and move on.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
hat first ON
clause can only refer to "u" and "d", because only those two tables
are in-scope for it.
There are other RDBMSes (mumble ... ancient mysql versions ... mumble)
that give the commas a different syntactic priority and would allow
that ON clause to reference "wl"
dvance,
it's worth considering.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
t the moment.
> It looks like inserts aren't applied in order, and I'm wondering if this is
> something I should expect.
Hard to comment on that without seeing your test case.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To ma
at file, and it wasn't the postmaster.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
tice would be
Values[1] = CStringGetTextDatum(char-*-ptr);
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
er than your OS name. Nobody's particularly
felt the need though, since the log message is harmless.
[ pokes at it a bit... ] Actually, you don't need a -U switch,
because setting PGUSER in pg_ctl's environment works.
regards, tom lane
--
Sent via pgsql-general mailing
ole that has permissions to change table B.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ue?
https://wiki.postgresql.org/wiki/Guide_to_reporting_problems
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
hat's the point of
letting the child column type be different?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
The point of the libpq "options" argument is that you can pass server
settings using that same switch syntax, for settings you'd be allowed to
change at runtime. This is obsolete legacy stuff; all of the available
options can be set with SET commands, and that's the preferred way to do
you're trying to cache data across
rows, or in even longer-lived ways, that you really need to be
careful.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
lts might be inconsistent. Either one will add some complexity
to your application code.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
t doesn't offer much to go on in
terms of being able to make a more reproducible case.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
me non-breaking spaces,
or other weird stuff that didn't show up in your email? I find it a bit
fishy that it looks like there's two spaces after "resigned at the score"
in your function text, but only one in the error message.
regards, tom lane
--
Sent via p
a tablespace?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
k that Harry is testing against a master/slave setup not
just a standalone server. Maybe that's not as irrelevant as it should be.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.po
e is okay.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Do you know
which binary mime types they won't reject?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
out how to
explain that part; I suspected a cause of this form but couldn't
make that theory match the 9-iterations observation. (I still can't.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ion=# select '{"z":"\u0001"}'::json::text ~ '\\u';
?column?
--
f
(1 row)
It's true that we won't let you cast such a value to JSONB or do any
exciting JSON-ish manipulations on it, but I'm not seeing an error
in cast-to-text.
regards, tom
Rob Nikander <rob.nikan...@gmail.com> writes:
>> On Jun 10, 2017, at 10:34 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> […] but it'd be better to adjust the query to ensure a deterministic
>> update order.
> Thank you for the answer. Since `update` has no `order by
point,
producing a different row locking order.
If it's (B) you could ameliorate the problem by disabling syncscan,
but it'd be better to adjust the query to ensure a deterministic
update order.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general
-enable-cassert. The memory
clobber stuff that's enabled by the latter is very good at turning coding
errors into reproducible, debuggable crashes ;-)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
e do not hijack an existing thread to ask an unrelated question.
Start a new thread (ie "compose" don't "reply") and use an appropriate
subject line.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
ion that I'm not duplicating. Can you explain what sort
of platform you're testing on, and what nondefault configuration settings
you're using?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscr
s would be easier to credit if
there are hooks both extensions try to get into.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
tions; but we don't really. You can do that, if you're
a superuser who's willing to take risks, but our policy is that if
you break the catalogs that way you get to keep both pieces.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
e tar format so nobody's bothered.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Harry Ambrose <harry.ambr...@gmail.com> writes:
> Tom - I can provide a jar that I have been using to replicate the issue.
> Whats the best transport method to send it over?
If it's not enormous, just send it as an email attachment.
regards, tom lane
--
Se
following has been reported:
> https://www.postgresql.org/message-id/20161201165505.4360.28...@wrigleys.postgresql.org
That person never came back with a self-contained test case, either.
https://wiki.postgresql.org/wiki/Guide_to_reporting_problems
regards, tom lane
--
S
e what you have here.
The fact that those other tables would need to be restored first
simply isn't visible to pg_dump.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
in any absolute sense; reindexing the older index
would reverse that preference, at least for a time.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
"Wetzel, Juergen (Juergen)" <wet...@avaya.com> writes:
> Tom Lane <t...@sss.pgh.pa.us> writes:
>> You might get some traction by creating indexes on lower(searchfield1) etc.
> I will try that. Does that mean the column statistics will only be collected
> when
collect stats. But if you have other queries with more selective
LIKE patterns then maybe a trigram index in particular is worthwhile.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
t least "make clean"
and preferably "make distclean" before reconfiguring.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
n is? Alternatively, if you're attempting
to overwrite an old installation, did you remember to restart
the server?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ems much more likely that
people writing that are making a mistake.
We discussed the associativity-of-= issue in the thread leading up to
that patch,
https://www.postgresql.org/message-id/flat/12603.1424360914%40sss.pgh.pa.us
but I evidently forgot to mention this detail in the commit log message,
s
input arguments, but not on their precise values. I don't recall the
details beyond that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Thomas Kellerer <spam_ea...@gmx.net> writes:
> Tom Lane schrieb am 26.05.2017 um 20:18:
>>> The error message reported in the logfile is:
>>> pg_dump: unrecognized collation provider: p
>> Ugh :-( ... seems like a rather obvious typo in dumpCollation().
>>
mparator.
You could maybe make your docs a bit clearer if you consistently refer
to the namespace objects as "SQL schemas", reserving the generic term
for the generic meaning.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.or
ng-explain.html
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
l2 you have installed. Hard to guess more than that.
If you're not actually using contrib/xml2 in the 9.6 installation,
probably dropping that extension would let you do the upgrade.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.
our tree, then that's an error code that
FormatMessage doesn't recognize. Anybody have a clue what it means?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ls when taking
> the schema only dump from one database.
> The error message reported in the logfile is:
>pg_dump: unrecognized collation provider: p
Ugh :-( ... seems like a rather obvious typo in dumpCollation().
Thanks for finding it!
regards, tom lane
-line storage, but 12-byte fields
are too small to benefit from either.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e above patch is simply an impossibly bad idea. Don't do it.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
David Wall <d.w...@computer.org> writes:
> They do have a slave DB running via WAL shipping. Would that likely
> help us in any way?
Have you tried taking a backup from the slave? It's possible that
the corruption exists only on the master.
regards, tom lan
et back to where you are.
I hope this is being done as part of migration to more up-to-date
software.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
s should convince the planner to pre-run the function to get an
estimated result at plan time.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Wed, May 24, 2017 at 11:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> This looks a whole lot like a bug we fixed in 9.3.15, cf
>> https://www.postgresql.org/message-id/flat/DB5PR07MB15416C65687A1EA9AC0D26F8D6E
//www.postgresql.org/message-id/flat/DB5PR07MB15416C65687A1EA9AC0D26F8D6E00%40DB5PR07MB1541.eurprd07.prod.outlook.com
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
want to look at "func_table:" and associated productions
in gram.y, and maybe compare those to the RangeFunction-making productions
in 9.3's gram.y.
(Since RangeFunction isn't used past the raw parsetree stage, it's not
very clear to me why you'd need to make one anywhere else ...)
cal and practical difficulties. As one example,
once we've released that lock, someone could change the child's
constraint, invalidating the proof. (Indeed, since AccessShareLock is
such a weak lock, it would more or less require DDL on the child table
for there to be any conflict.)
s any special meaning ?
Postgres thinks it's a valid identifier character, as long as it's
not the first character. I don't believe it's standard SQL, but
we hacked it in a long time ago for compatibility with Oracle or
somebody like that.
regards, tom lane
--
Sent via p
o.2 library before the /opt/PostgreSQL/9.6/lib/
> one.
IIRC this is determined ultimately by /etc/ld.so.conf, but there's
a layer of caching that might be giving trouble. See "man 8 ld.so"
and also "man 8 ldconfig". Looking at the output of "ldconfig -p"
might be info
actual Terminate protocol message ('X') or is just closing the
socket. If the latter, maybe it isn't really closing because the
socket is shared with some child process, or something like that?
Turning on log_connections/log_disconnections might help clarify
what's happening.
to see how they could be out of
sync. Maybe you have another copy of one of those libraries floating
around, and the wrong copy is getting pulled into your link?
I'd suggest some investigation with "ldd" and "nm -D" to see what's what.
regards, tom lane
--
S
text-constant", and that operator doesn't match the index.
Probably, casting the parameter to char(n) explicitly would fix this.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
stallation before it would play nice with a
9.6 libpq, so that might be surprising. (It would also break existing
9.2 installations that were explicitly setting unix_socket_directory,
but we can hope there are very few of those.)
regards, tom lane
--
Sent via pgsql
t do that, at
least not more often than you have to. This particular symptom is a new
one on me, but there are lots of other reasons not to do it.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscriptio
ered separately.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
he most
> felicitous way of representing a text value that I can imagine.
> Note that if I add a single space after “Works!”, I get quotes around the
> string.
As per spec:
https://www.postgresql.org/docs/current/static/arrays.html#ARRAYS-IO
regards, tom lan
only make sense to do that if we supported
configuring NAMEDATALEN, which we don't really: you have to
manually edit pg_config_manual.h, and how well the result works
is on your own head.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
itself.
So I'm thinking what's happening here is the 9.2 psql is picking
up a libpq.so supplied by 9.6.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
n 9.2 and 9.6. But the first step would be to use
"ldd" to see which libpq your invoked psql is pulling in.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Mathieu Fenniak <mathieu.fenn...@replicon.com> writes:
> I've taken your patches, Tom, and applied them to a test deployment of my
> actual application.
> The most accessible way I have to reproduce this issue is to run a
> maintenance task that we typically run during a s
uality and completeness (and the fact that we never ever break
> links even when the website is rewritten).
Amen to the value. Thanks to those who've made this happen.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
ng() does
not so blatantly exceed its authority, only the documented argument
order will work.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ere isn't
anything in Postgres right now that makes that type of inference,
let alone a way to export it to userland.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
t you're going to be able to do.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ng to a five-minute-old
message that probably isn't an issue. The trim-quotes-and-reply-below
style evolved for discussions that might last over days, where readers
can benefit from a quick reminder. Bottom posting without trimming
is just an awful combination: whatever you do, don't do tha
Mathieu Fenniak <mathieu.fenn...@replicon.com> writes:
> Andres, it seems like the problem is independent of having large data
> manipulations mixed with schema changes. The below test case demonstrates
> it with just schema changes.
> Tom, I've tested your patch, and it seems
returning ctid, which it could not get out of the index. This is
necessary for possible EPQ rechecks.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Igor Korot <ikoro...@gmail.com> writes:
> On Sat, May 6, 2017 at 8:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I do not see any arrays named "length", nor even any arrays of size 2,
>> on that page, so I'm pretty confused what you're talking about. Plea
se then you
*must* look directly at the catalogs.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
not see any arrays named "length", nor even any arrays of size 2,
on that page, so I'm pretty confused what you're talking about. Please
be more specific.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
r to be invalidating caches
>> based upon the cache value.
> I think optimizing those has some value (and I see Tom is looking at
> that aspect, but the bigger thing would probably be to do fewer lookups.
I'm confused --- the lookup side of things is down in the noise in
Mathieu's trace.
ing to the destination
server version*, not the latest version you can find anywhere.
No version of pg_dump has ever promised that its output would load
perfectly cleanly into lower-version destination servers, and that's
not a set of new compatibility constraints that I'd want to take on.
s in the
attached patch. It'd be interesting to see if this patch helps your
scenario #1. (Patch is against HEAD but seems to apply cleanly to 9.5)
Most likely, your scenario #2 is completely stuck on the
RelfilenodeMapInvalidateCallback issue, though it would be good
to get a trace to confirm that.
ter_maximum_length |
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
EAL, and DOUBLE PRECISION are collectively
referred to as approximate numeric types.
— Exact numeric types and approximate numeric types are collectively
referred to as numeric types. Values of numeric types are referred
to as numbers.
regards, tom lane
--
Sent
some other size.
If you try it on bigint or smallint columns, you'll get other answers.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
201 - 300 of 14105 matches
Mail list logo
