GetEartquakeAll function:
select GetEartquakeAll('2020-01-01' ,'2020-03-01', -120, 40,200, 1.7) gives
me
ERROR: length of returned sequence did not match number of columns in row
How can I 'simply' return each list value as a row ?
Thanks
Karsten Venneman
Answering my own question I got it to work by a tiny change add SETOF for
the return definition:
Cheers
Karsten
...
RETURNS SETOF equake_values AS $$
...
-Original Message-
From: karsten [mailto:kars...@terragis.net]
Sent: Saturday, July 25, 2020 14:42
To: pgsql-general
be
> extremely grateful.
This is the closest I found with a quick searc
http://snapshot.debian.org/archive/debian/20170831T163230Z/pool/main/p/postgresql-9.6/postgresql-9.6-dbg_9.6.5-1_amd64.deb
Not sure this is close enough though.
Karsten
--
rs timestamp-withOUT-timezone to
the outside. Then force read access via the view.
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
fied" to mean "TimeZone value"). But, then,
OP could always force TimeZone to UTC on his servers :-)
Karsten
--
t one particular database
may have to offer over and above basic SQL for solving a
particular problem.
Karsten
--
n the postgresql.org
> infrastructure. In the case where a dispute of such a nature occurs
> outside said infrastructure, if other parties are unable to act, this code
> of conduct may be considered where it is, on the balance, in the interest
> of the global community to do so."
&
mselves.
And often it will be extremely hard to *codify* such working
definitions to even remotely the same degree of success.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
t;
And then, bugs have been fixed, the security implications of
which are not necessarily fully known.
Other than that, your question may need to become more specific.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
finity'::timestamptz;
-[ RECORD 1 ]-
timestamptz | infinity
gnumed_v22=>
is the highest timestamp.
(You *can* count the horses in *your* corral but there's
always more of them elsewhere ;-)
Just so you are aware.
Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
tabase where datname in
> ('CDF_100_1313')"/usr/lib/postgresql/11/bin/psql
> -p 5432 -U postgres -d $DBLIST -c "GRANT CONNECT ON DATABASE "$DBLIST" TO
> cpupdate"
>
> ERROR: database "cdf_100_1313" does not exist
Likely a quoting issue.
Karsten Hilbert
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
how be kept in sync).
Might crafty use of server side
COPY TO ... PROGRAM ...
enable OP to drop in dictionary data files as needed ?
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
h, we
support it, it's been in use a long time, it should work,
but, nah, one doesn't really want to choose it over UTF8 if
at all possible, or at least know *exactly* what one is doing
and BTW YMMV ?
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
n to use when "technical" sorting is
required (say, when uniqueness does not depend on the notion
of culturally equivalent characters).
> It's actually all the *other* collations where you should worry about
> their behavior being a moving target :-(.
But then that is to be expe
judicious use of COPY-FROM-with-subselect from blobs.doc_obj
restore
dance ?
Many thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
On Sun, Mar 15, 2020 at 07:23:49PM +0100, Karsten Hilbert wrote:
> We then tried to DELETE the offending row
>
> delete from blobs.doc_obj where pk = 82224;
>
> but that, again, shows the "unexpected chunk" problem.
According to
http://www.databasesoup.
curs no
> TOAST costs if none of the out-of-line values change."
However, where is the fault in my thinking ?
-> An UPDATE actually *would* change the TOASTed BYTEA field (which is corrupt).
I had hoped that the DELETE would NOT have to touch the TOAST
table at all (and thereby not
hanks for reminding.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
On Sun, Mar 15, 2020 at 02:35:39PM -0700, Adrian Klaver wrote:
> On 3/15/20 1:21 PM, Karsten Hilbert wrote:
> > On Sun, Mar 15, 2020 at 12:58:53PM -0700, Adrian Klaver wrote:
> >
> > > > > We then tried to DELETE the offending row
> > > > >
>
On Sun, Mar 15, 2020 at 08:11:18PM -0400, Tom Lane wrote:
> Karsten Hilbert writes:
> >>> According to
> >>> http://www.databasesoup.com/2013/10/de-corrupting-toast-tables.html
> >>> an UPDATE of the row is recommended -- should that work
> >>>
hing else
>RAISE NOTICE 'failed to return data';
>END;
> END LOOP;
> END
> $$
>
> should work. You can call it like
> SELECT (salvaged_rec.rec).* FROM (SELECT salvaged_text::salvage_me FROM
> salvage('salvage_me') AS salvaged_t
of Foo Cottage".
LAT/LON ?
https://plus.codes/ ?
Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
b type database belongs to
> 0 or 1 organisations.
Might postgres_fdw help in any way ?
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
ill would not be entirely surprised if
testing were to reveal something different.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
he Monitoring Tool based on your experience.
I suggest you read up on the fine manual first. It covers a
lot of ground already.
And to stick to one major project at a time.
Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
it that updating "more frequently"
(not "accruing technical debt") helps -- the trick is to find
the balance between early effort and lag.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
On Mon, Jun 01, 2020 at 12:36:14PM +0700, Stefan Knecht wrote:
> The rubber duck barely tells you how and why it floats
It sure doesn't spoonfeed but it certainly does tell us
*exactly* how and why it floats.
https://www.postgresql.org/docs/devel/install-getsource.html
Best,
to restore, we don't have any
> option apart from data directory(no wal files)
At this point you are very likely in need of (highly)
specialized professional help.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
on:
>
> https://postgresql-anonymizer.readthedocs.io/en/latest/
or https://github.com/marcmunro/veil
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
> If I want to create a new type Person (firstname varchar, lastname varchar,
> address varchar ...)
> what is the best way to procede in Postgresql
The best way is to re-evaluate the "I want".
Karsten
On Wed, Sep 30, 2020 at 09:06:13PM +0200, Matthias Apitz wrote:
> Btw: In all of the other DBS (Informix, Sybase, Oracle) we could define that
> point with START TRANSACTION.
You can always use SET SAVEPOINT.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
se a different COLLATE clause. For
> Postgres there is not any other way.
One might use a function producing a SELECT taking the locale as a parameter.
Or views in schemas per locale. Selecting the search path
per locale pulls in the right view.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
et session "mika.current_locale" = 'locale@2_use';
and use
select current_setting('mika.current_locale')
as needed inside the view definition
> This all seems unnecessarily complicated to me.
No one said it is going to be particularly convenient... You
d in the view, just like column names or table names.
> I don't see how you could use the setting to control the COLLATE clause
> through a view.
The view might produce its rows by calling a function which
in turn reads the setting and dynamically constructs and exexcutes
the query needed to produce the locale-dependant rows, no ? =8-)
Convoluted ? I guess so ...
Karsten
the business of timekeeping the worklife of
people so I guess sorting might matter there.
Karsten
Am Wed, Dec 30, 2020 at 02:37:59PM -0500 schrieb Demitri Muna:
> I want to index the results of these repeated, unchanging calculations to
> speed up other queries. Which mechanism would be best to do this? Create
> additional columns? Create another table?
A materialized view ?
sure that analogy holds up.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
and it seems to
> be choosing one of smaller size which leads to less IO and hence returns
> the result faster.
Would you mind throwing in a test for
select count(1) ...
?
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
numed/gnumed/server/sql
Karsten
> How long does iteration over 4-5 million rows usually take?
>
> 4-5 million times as long as it takes to do one iteration ( if you’re doing
> it correctly)
I may not take quite that long because setup/teardown times might not be needed
for each iteration.
Best,
Karsten
Am Mon, Apr 04, 2022 at 11:33:14AM + schrieb Sebastien Flaesch:
> Is there any plan to have an equivalent of psql's
>
> set ON_ERROR_ROLLBACK on
>
> in the DB engine?
That is already what happens.
SQL fails, transaction rolls back.
Karsten
--
GPG 40BE 5B0E C98E 1713
so far:
it requires laboriously constructing an array on the right
hand side for the above use case, along the lines of:
select pg_typeof('a'::text) = any(ARRAY[pg_typeof(''::text),
pg_typeof(''::name)]);
Is there anything obvious I am missing for easily
resurrecting the above "is of" use ?
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Am Sat, Apr 23, 2022 at 10:14:03PM +0200 schrieb Karsten Hilbert:
> I can't find anything in the changelog saying that "is of"
> was removed. For what it's worth, nothing in the docs ever
> said it existed either (though it did, as per real life).
Oh, wait,
cting the above "is of" use ?
>
> Actually it can be done as:
>
> select pg_typeof('test'::text) in ('text'::regtype, 'varchar'::regtype);
Found that, but thanks anyway.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
> I tried various ways to set password in psql command line, but got no luck.
Have you tried all the methods that you showed in your mail or did you try
others as well ?
Best regards,
Karsten
rimary key, not to *add*
one.
You said that there *is* a primary key.
So, more thought/explanation would need to go into why that
cannot be used.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
not having changed might be
another solution for detecting concurrent transacations if
one is bent on using system columns for that.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
uot;pk AS ctid"
(untested, however)
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Am Wed, Jul 20, 2022 at 09:15:29AM + schrieb Sebastien Flaesch:
> Thomas, we already have a similar solution.
> The idea is to use the native PostgreSQL SERIAL type.
Which does not guarantuee gaplessness.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
ht. After all, how would I know which of the eight to skip
while I don't know the intended rules for the current_role?
= You'd certainly start out with all eight but then whittle down to what still
exhibits the problem and post that.
= Karsten
l?
Essential to proper operation of the database code as of now.
Best, Karsten
than a no-op grant.
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Am Wed, Sep 14, 2022 at 10:10:30AM +0200 schrieb Karsten Hilbert:
> Am Tue, Sep 13, 2022 at 05:10:58PM -0400 schrieb Tom Lane:
>
> > (I recall that somewhere we have some code that warns about no-op
> > grants. I wonder if issuing a warning for no-op revokes would be
> >
Yes, one will forget most of what's
written there. However, a coarse structure of a new mental model will form.
Karsten
there's no such table.
And, indeed, there isn't. Perhaps there's a table s."silly name".
It is accidental if unfortunate that the is quoted with ""'s in
the \d output...
Karsten
m of a table integrated with PGs access/security infrastructure
that would be really helpful for some scenarios.
A view-on-top-of-file_fdw kind of thing ?
LO seems to nearly be there by now, or am I misunderstanding ?
Karsten
>
> bob || {}
> mary || {}
> postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
Just a hint: you may want to use "mary_os" and "mary_db&
uccessful login)
should not change (mary is still mary). despite the
additional code path.
It seems to be a way of bisecting in order to verify/falsify
assumptions in his mental model.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
rying to *embed* PostgreSQL ?
But that would not go with the account of multi-tenancy that's been presented.
Karsten
t for short-term feedback.
It might be prudent for Barmenia, a large insurance company, to consider
purchasing commercial support rather than requesting short-term feedback
from volunteers.
Other than that there's also excellent documentation and freely
inspectable source code.
Best regards,
Karsten
"Note: you may
need to refresh the default collation even if the query above
does not show any objects directly affected by a collation
version change" ?
Thanks for considering.
Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
ntation is rather assertive
(even if may true to the letter) and may warrant some more cautionary
wording ? Added, perhaps, some variation of this:
> For now, the only safe way to go is either reindex everything, or everything
> except some safe cases (non-partial indexes on plain-non-collatable datatypes
> only).
Best,
Karsten
sion and the currently reported one unless you REALLY know what you're
> doing."
Given that it does not seem straightforward to mechanically detect objects
in need of a collation-associated rebuild I would think that such a warning
would change matters for the better, documentation-wise.
Karsten
COLLATION every_collation_from_pg_collation REFRESH VERSION;
Note that I am currently _not_ concerned with minimizing
work by running this on objects only that really need a
reindex/refresh.
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Am Sun, Nov 13, 2022 at 12:46:53PM -0800 schrieb Christophe Pettus:
> > On Nov 13, 2022, at 12:45, Karsten Hilbert wrote:
> > REINDEX DATABASE db_in_question;
> > ALTER DATABASE db_in_question REFRESH COLLATION VERSION;
> > ALTER COLLATION every_collation_f
all this has been discussed in detail, I'd be glad for a
pointer into the archive.
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
realize... That's a
> great idea.
> Honestly not sure how to even run it?
>
> Thanks for the support, it's encouraging... especially when I know there's
> an 80% chance that
> this may fail to get accepted for any number of reasons.
I don't think that estimate n
he output of pg_get_functiondef, applied
> to the stored diff?).
I wonder whether that would tie the sanity check to a particular PG version.
I mean, pg_get_functiondef output being a server runtime artifact it might
well change between server versions, no ?
Best,
Karsten
n my
database(s).
What is the canonical advice on the way forward here ? Is
the _suggested_ solution to delete the collation or am I
missing to see the "proper" approach to fixing it ?
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Am Sun, Dec 04, 2022 at 01:22:02PM +0100 schrieb Karsten Hilbert:
> gnumed_v22=> ALTER COLLATION pg_catalog."br_FR@euro" REFRESH VERSION;
> ERROR: collation "pg_catalog.br_FR@euro" for encoding "UTF8" does not
> exist
The OS (libc) does see
Am Sun, Dec 04, 2022 at 01:22:02PM +0100 schrieb Karsten Hilbert:
> following an ICU upgrade, collations in a stock Debian PG 15.1
> cluster now have divergent version information in pg_collations.
Correction: this is following a libc upgrade 2.35 -> 2.36
Karsten
--
GPG 40BE 5B0E
p (the "reindex /
revalidate constraint / refresh collation version" dance).
There also was a libc upgrade which also affected locales.
Most of them were fixable by that dance but some popped up
(such as br_FR@euro) to not be "correctable" showing the
"does not exist for encoding" error.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
”, precisely for that reason.
I see. That makes sense.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
W.euctw" will
be ignored by the server for all practical purposes.
Does this mean it is impossible to "correct" its version
information ?
And if so, that is expected to be non-harmful and is not
expected to trigger nag messages ?
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
to help you ?
Such as not to top post.
Best regards,
Karsten
> On Mon, 5 Dec, 2022, 1:36 pm Pavel Stehule, wrote:
>
> >
> >
> > po 5. 12. 2022 v 8:42 odesílatel shashidhar Reddy <
> > shashidharreddy...@gmail.com> napsal:
> >
> >> Pavel,
Dear all,
I managed to drop the "special" collations default, C, and
POSIX with OIDs 100, 950, 951.
Is there a way to recreate them (short of restoring a backup)
? Naive attempts with create collation do not seem to work
out.
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA
#x27;c', TRUE, -1, 'POSIX', 'POSIX');
Many thanks ! I wasn't so sure whether inserting appropriate
rows would be equivalent to create collation... (pg_collation
might have been a view projecting inner workings of the
server engine).
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Am Wed, Dec 21, 2022 at 03:46:48PM +0100 schrieb Karsten Hilbert:
> I wasn't so sure whether inserting appropriate
> rows would be equivalent to create collation...
For that matter, is DELETE FROM pg_collation ... equivalent
to DROP COLLATION ?
Thanks,
Karsten
--
GPG 40BE 5B0E C98
the stuff from the living room to the bedroom and then jettison
> the living room.
>
> Isn't that how you normally vacuum your living room?
Well, yeah, I wouldn't expect the table to be *copied*. After all, there's
not that much use for more than one per living room.
Karsten
here to be read. And it tends to be the longer the
more details it is expected to cover, isn't it ?
Searching for generic terms on typical search engines can be quite a task,
agreed.
Karsten
the last incoming call timestamp for a
> phone number will be exactly that.
timezones ?
DST ?
spoofing ?
...
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
l) PK with respect to a given time line only, right?
> > spoofing ?
>
> ¿ Of what ?
The time stamp. But then I assume that is obtained on the
logging system.
All I really wanted to hint at is that "incoming call
timestamp" may work pretty well in given settings but does
not _always_ make for a "unique enough" key.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Am Fri, Apr 14, 2023 at 10:44:19PM +0100 schrieb John Howroyd:
> The problem is that SQLAlchemy is an ORM [...]
...
> [...] as the majority of the python world will use this ORM for
> their database needs.
I wouldn't be so sure on this count ...
Karsten
--
GPG 40BE 5B0E C98E 1
bers: GNUmed uses psycopg2 for upgrades
and its databases default to default_transaction_read_only=true
but I have taken both aspects out of the loop manually for
the above test.)
Thanks for any hints,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
s ask for
a physical write test ?).
Attached the output of pg_filedump which, to me, doesn't seem
to show anything out of the ordinary either.
Corrupt index should not be the case because the databse is
REINDEXed during the upgrade process before the failing
statement.
Will attempt to get a st
On Thu, Nov 01, 2018 at 03:42:57PM +0100, Karsten Hilbert wrote:
> Will attempt to get a stack trace ...
Meanwhile, in case it helps, an strace of the crash.
epoll_wait(7, [{EPOLLIN, {u32=47607120, u64=35184419695952}}], 1, -1) =
1
recv(13, "Q\0\0\0`DELETE FROM ref.aut
On Thu, Nov 01, 2018 at 04:11:33PM +0100, Karsten Hilbert wrote:
>> Will attempt to get a stack trace ...
Eventually, the stack trace (attached).
Thanks for insights,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Script started on 2018-11-01 16:16:02+01:00
root@
On Thu, Nov 01, 2018 at 12:27:23PM -0300, Alvaro Herrera wrote:
> In general terms, this bug report would have been more actionable if you
> had shown the definition of the tables involved right from the start.
Sorry for that, will supply.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC
trigdata' in frame 2?
Sure, how ? :-)
(I can surely type "print trigdata" but does that already
auto-select from "frame 2" ?)
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Ausgabeformat ist »wrapped«.
all ?
(gdb) frame 2
#2 0x00879bf7 in RI_FKey_cascade_del (fcinfo=0xbfbda9e4) at
./build/../src/backend/utils/adt/ri_triggers.c:917
917 ./build/../src/backend/utils/adt/ri_triggers.c: Datei oder
Verzeichnis nicht gefunden.
(gdb) print trigdata
$1 = (TriggerData *) 0xbfbdaca4
It is from another run, however.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
||
(5 Zeilen)
BTW, do you want me to attach text files or include into the
body (potential wrapping issues on display) ?
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
ollback;
the expected segfault does indeed occur.
Conversely, moving the offending
DELETE FROM ref.auto_hint WHERE title = 'Kontraindikation: ACE/Sartan
<-> Schwangerschaft';
to right before the ALTER TABLEs makes the full upgrade run
through without further problems.
Looking at 040a1df61/372102b81 feels like it fits the bill.
So, I guess I can work around the issue by the above
manoeuvre and report back once 040a1df61/372102b81 is
released.
Anything else you'd want me to look into ?
Many thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
On Sat, Nov 03, 2018 at 11:39:49AM -0400, Tom Lane wrote:
> Karsten Hilbert writes:
> > On Fri, Nov 02, 2018 at 11:56:58PM -0400, Tom Lane wrote:
> >> I was feeling baffled about this, but it suddenly occurs to me that maybe
> >> the bug fixed in 040a1df61/372102b81
/var/lib/dpkg/status
11.0-1+b1 990
990 http://httpredir.debian.org/debian buster/main i386 Packages
I can report that my issued is fixed by that version.
Thanks to all,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
file system.
I doubt we can get more certainty than this:
https://www.postgresql.org/docs/devel/creating-cluster.html#CREATING-CLUSTER-NFS
Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
ring ?
(Mind you, the code above does not abort the *transaction*
but does not execute the second SQL command.)
Many thanks for insights,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
e right.
>
> The "pg_trgm" extension does *not* exist in the database, and that is your
> problem.
Wow, I didn't realize the difference between pg_extension and
pg_available_extensions ...
> Perhaps you preinstalled the extension in the wrong database (postgres?).
It
?
The copies then get thrown away.
Same here, pre-copying a bunch of VMs would help. Disk space
is (apparently) cheaper than time (for your use case).
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
as if they lived inside the database.
Also, a combination of
COPY TO FORMAT binary
pg_read_binary_file()
and suitable plpgsql security definer functions might provide
for a Poor Man's binary file integrated external storage.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BE
stgresql.org/wiki/BinaryFilesInDB
Karsten Hilbert
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
1 - 100 of 215 matches
Mail list logo
