tance". Is it possible that this database is so old that
it contains a pre-extension (pre-9.1) version of earthdistance?
regards, tom lane
hich merely
sets up a postgresql.conf entry).
regards, tom lane
false);
> in the pg_dumpall output file.
I'm betting that won't help. The new-in-17 behavior is that
maintenance commands such as CREATE INDEX internally force
a "safe" search_path, regardless of the prevailing setting.
It would be useful to know what is the command at line 4102
of all.sql.
regards, tom lane
lready have
duplicate entries in the table, you'll need to correct them before
REINDEX will succeed.
regards, tom lane
hat.
If it is "*", then it seems like something is interfering with
expanding that. Maybe try explicitly setting it to "localhost"?
regards, tom lane
Adrian Klaver writes:
> On 12/1/24 13:14, Tom Lane wrote:
>> It would be useful to know what is the command at line 4102
>> of all.sql.
> It is here:
> https://gist.github.com/poperigby/fcb59eb6c22c6051800e06a0ec482b49
> CREATE TABLE public.geodata_places (
&g
PopeRigby writes:
> On 12/1/24 12:15, Tom Lane wrote:
>> Cool. You did actually install the new scripts into your target
>> installation, right?
> Oh, is applying the patch and rebuilding PostgreSQL not enough?
Not unless you did "make install" in the contrib
nd d0 is not a utf-8 character so it block reading whole log file by
> file_fdw.
You certain that server is 16.6? Because we fixed that in 16.5:
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=4fd4d7653
regards, tom lane
letion.
So in principle, you might get best results by defining your query
with DECLARE CURSOR and then using PQsetSingleRowMode on the FETCH.
But it'd really depend on the particular query whether this gives
any benefit.
regards, tom lane
le if you don't want to
think hard about this stuff.
regards, tom lane
wer than the extension's SQL files
(.../share/extension/repmgr.control etc).
You need to straighten out that version mismatch.
regards, tom lane
)
Filter: ((id)::text = 'foo'::text)
(2 rows)
Your index supports bpchar comparison semantics, not text,
so it doesn't work for this query.
You could work around this by creating an index on id::text,
but TBH I'd question the choice to use a bpchar column in
the first place. It&#x
ven on
> a system that old.
Another workaround is to connect from a remote instance of psql.
You'd probably need to modify the server's pg_hba.conf and perhaps
poke a hole in its firewall, but that's still easier than installing
new software.
regards, tom lane
done
locally on the old machine. You've got to shove the data over the
network sooner or later, so why not sooner?
regards, tom lane
k that's missing?
The most obvious bet is that you installed a postgresql-contrib
package that is not really compatible with the server package
you're using and it put all the extension files somewhere else
than where the server expects to find them. Try checking the
file listing for the postgresql-contrib package you used.
regards, tom lane
pretty clear: you need single quotes around the
value '1min', and you didn't provide them.
regards, tom lane
ed is that *passwordcheck is not an extension*.
It has no SQL-visible objects. It's just a shared library that
you must preload into the server, as per its documentation.
regards, tom lane
er versions
accepted them. But in a SET command I think no version will take it.
regards, tom lane
=?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
> is there any plan for another minor release?
https://www.postgresql.org/developer/roadmap/
regards, tom lane
in spi.c.
regards, tom lane
resql.org/docs/current/libpq-ssl.html
Those cause some additional checks to be made, but it's not like
you can expect a completely broken certificate to work without them.
regards, tom lane
;t
seem to work for you. I continue to suspect that you didn't
really install the updated extension, but it's unclear.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/3395418.1618352...@sss.pgh.pa.us
Isaac Morland writes:
> On Sun, 15 Dec 2024 at 12:29, Tom Lane wrote:
>> What I'd suggest as an improvement that could be implemented
>> immediately is to wrap the checks in a user-defined function
>> like "is_system_schema(nspname name)".
> Would it make
uot;system schema". As a
counterexample, for some maintenance activities (such as vacuuming)
you might wish to process pg_catalog.
What I'd suggest as an improvement that could be implemented
immediately is to wrap the checks in a user-defined function
like "is_system_schema(nspname name)".
regards, tom lane
NULL. Or perhaps what is wanted is
WHERE (original-clause) OR (x IS NULL AND y IS NULL AND ...)
??
regards, tom lane
things equivalent to that in the
core code, I think.
regards, tom lane
ot detoasting
saves work overall, because the object never has to get detoasted;
but I think that's rare. It'd probably look like
UPDATE t SET c = no_op_function(c) WHERE ...
which is something few people would write.
regards, tom lane
#x27;t really foresee
us accepting the costs of making it not act like that. I seem to
recall someone submitting a patch recently that would add such
locking, but I doubt it'll get accepted.
regards, tom lane
oint would surely make a mess of the replica's indexes.
You'll have to use logical replication for this.
regards, tom lane
er to that will be forthcoming.
Unofficially, however, I have no doubt that this bug is quite ancient.
regards, tom lane
e this long-running thread:
https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mdhcy4_qq0+noc...@mail.gmail.com
regards, tom lane
ff and on for the last few days, and I've
found three different things that will need to be changed to make
it work again. At least one of them looks too invasive to consider
for back-patch. So don't hold your breath for a proper fix, but
perhaps you could use UNION as a workaround?
regards, tom lane
(
sfunc = hs_concat,
stype = hstore
);
Either way though, the order of aggregation is unspecified and thus
it's unclear which input will win when there are duplicate keys.
If that matters then you'll need to think about how you want
to resolve it.
regards, tom lane
we did support that, it'd enormously complicate all timestamp
arithmetic --- and we could hardly do calculations with times in
the future at all, given the uncertainty around when leap seconds
will be declared. So if you want to do astronomical timekeeping,
you should use some other data type than timestamptz.
regards, tom lane
y moving
in the direction of never letting the server see cleartext passwords.
It's already possible to configure libpq to refuse such requests
(see require_auth parameter), although that hasn't been made the
default.
regards, tom lane
les at OS level are 65000.
I'm suspecting that you either need to increase that, decrease
max_files_per_process (which defaults to 1000), or decrease
max_connections.
regards, tom lane
nt results, and there have been few complaints about this
omission so far.
In the meantime, the most recommendable answer for you is probably
to switch over to using SERIALIZABLE mode. That'd require adding
application logic to retry after a serialization failure, but it
would produce co
tches what you use for the database.) If the results are different
then you definitely need to reindex; if they are the same then maybe
you're okay. Pay particular attention to columns containing
punctuation or non-ASCII characters, as those are the areas most
likely to see changes.
to master, then it will start to use
whatever settings it has (and no, postgresql.conf is not copied
by the replication infrastructure).
regards, tom lane
that database
already. It didn't come from pgvector, so where did it come from?
regards, tom lane
te the quotes) would provide an
intermediate level of compactness versus pain.
regards, tom lane
ch to a generic
plan if there's not too much change and the generic plan's estimated
rowcounts are in the same range. Or in other words, rather than
believing a cost comparison, what we'd look for is whether we get
basically the same plan in generic mode as in custom mode. I'm
not sure how to mechanize that, though.
regards, tom lane
ependencies and requires
close attention to correct shell quoting, so it's seldom
preferable IMO.
regards, tom lane
So if that's a top-level transaction, you can roll
it back, but if it's a subtransaction you can't.
regards, tom lane
Adrian Klaver writes:
> On 3/22/25 17:31, Igor Korot wrote:
>> Is there a way to determine the server version from such a script?
> show server_version_num;
psql already populates its SERVER_VERSION_NUM variable from that
for you.
regards, tom lane
going to show you
only a small fraction of the possible plans. If you are unhappy
because you suspect the planner rejected what would really have
been the best plan, the odds are good this won't help you because
the plan you want to see didn't survive long enough to be shown.
regards, tom lane
t;, edit out what
you don't want using any method you like, then use the edited list with
"pg_restore -L".
While I'd be in favor of improving pg_restore to accept wild-card
patterns, I'm very hesitant to start inventing new kinds of selection
switches for it. The interactions between such switches would be a
mess.
regards, tom lane
;s the "Backwards compatibility" comment that's
bothering you, a look at pg_type.h will show you that that's
only intended to apply to the CASHOID and LSNOID symbols.
Everything below that in pg_type_d.h is machine-generated.
regards, tom lane
regards, tom lane
"David G. Johnston" writes:
> On Thu, Mar 20, 2025 at 11:54 AM Tom Lane wrote:
>> I think it's a mistake to suppose that pg_type_d.h is the only
>> place where there's a risk of confusion. We should be thinking
>> about this more generally: genbki.pl
'm not sure what other parts would be useful
to label.
As for CASHOID and LSNOID, surely those have been deprecated long
enough that we could just remove them?
regards, tom lane
x27;t feel a need to change the docs yet.
regards, tom lane
Karsten Hilbert writes:
> Am Tue, Mar 25, 2025 at 06:55:34PM -0400 schrieb Tom Lane:
>> Works fine if you don't mess with the view's security_invoker
>> status.
> I know but doing so was kind of the point.
[ shrug... ] It's not going to work. When the view
l from v_partially_private;
> to work but selecting from the view fails.
Works fine if you don't mess with the view's security_invoker
status.
regards, tom lane
e made to do something
in debug builds but be no-ops in production builds. If you think
there's actually a realistic chance of the case happening in a
production context, you should use a regular if-test-and-ereport
instead of an Assert.
regards, tom lane
/include/numa.h isn't
there; but meson seems to fail as-expected without that,
or silently fall back to libnuma=disabled if you don't try to
force it.
regards, tom lane
es. That kind of looks like it might cause the
check to fail if the libnuma library isn't there, which is something
we do need to check, but doing it this way seems like it'd produce
a pretty misleading failure message if numa.h exists but the library
doesn't.
regards, tom lane
restorecon might help if so.
regards, tom lane
own habit when writing a SQL function that I wish to be
inlined is to leave off all those markings. They won't matter
if the function is successfully inlined, and they might get in
the way of that happening.
regards, tom lane
e but
not library presence (else it wouldn't have thought that
the library was there either, I guess). Kind of weird,
but I'm still learning about meson.
regards, tom lane
a/k/a UTC+2. To get it to mean Indian Standard Time a/k/a Asia/Calcutta
you need
set timezone_abbreviations TO 'India';
(or more likely, adjust that in your installation's postgresql.conf).
See https://www.postgresql.org/docs/current/datetime-config-files.html
regards, tom lane
th columns are covered by "idx_col_b_a".
They may be covered, but sort order matters, and that index has the
wrong sort order to help with this query. Try
create index on test_table(col_b, col_a);
regards, tom lane
e than before. That would be
surprising, but with zero details it's hard to debug.
regards, tom lane
able to do
CREATE TABLE mytable ...;
CREATE UNIQUE INDEX myindex ON mytable USING myam (...);
ALTER TABLE mytable ADD PRIMARY KEY USING INDEX myindex;
It doesn't look like we yet allow direct "USING myam" in
PRIMARY KEY, but sooner or later we might get to that.
paces around the
parameter symbol. It's really a bug that it didn't do so already,
since closely-adjacent cases like digits immediately after the
"?" would already have caused failures.
regards, tom lane
they sound
like they might be things that would take it on themselves to fool
with your stats-collection settings. I'd check their code for
something close to
SetConfigOption("track_counts", ..., PGC_S_OVERRIDE);
regards, tom lane
rg/docs/current/datatype-numeric.html#DATATYPE-SERIAL
regards, tom lane
for that.
We don't seem to have bothered with that exact syntax, but you
could spell it like
SET LOCAL lock_timeout TO DEFAULT;
regards, tom lane
Tim Starling writes:
> On 28/4/25 20:54, Tom Lane wrote:
>> Even if I were on board with arbitrarily adopting one of the two
>> possible interpretations, it's far from obvious to me that most people
>> would agree that "v" should mean the value from the existi
Igor Korot writes:
> On Wed, Apr 23, 2025 at 1:28 PM Tom Lane wrote:
>> If we do anything about this, I'd just say "systems that have
>> posix_fadvise()". If we write something more specific it's likely to
>> become obsolete, and it doesn't seem t
s why NoSQL
is not SQL, and this is one.
You can already approximate this sort of behavior in Postgres by
storing the less-structured aspects of your data in a JSON or XML
column. I'd suggest pursuing that approach rather than trying
to get us to mangle fundamental SQL semantics beyond recognition.
regards, tom lane
ring. Which part of this is responsible for seeing that
that gets freed?
regards, tom lane
which is actually more than the real difference in runtime. (I hasten
to add that I don't have a lot of faith in our function cost
estimates. But the planner is quite well aware that a non-inlined SQL
function is likely to be expensive.)
regards, tom lane
=postgresql.git;a=commitdiff;h=78637a8be
regards, tom lane
DE to it.
What extensions do you have installed?
regards, tom lane
lication
needn't connect to a particular database because it does no catalog
accesses (and hence can't run SQL). All it's able to do is suck out
the WAL stream. Logical replication can do SQL --- but it has to
connect to a specific database.
regards, tom lane
that as a good thing.
(You can, of course, speculate about some major rearchitecting
of the system catalogs that would make this situation different.
I doubt that's going to happen at this point, though. There's
too much stuff that's dependent on how things are now.)
regards, tom lane
h. So the collation-changed warnings that
Laurenz mentions are a lot more trustworthy for ICU collations.
2. It's at least *possible* to use your own fixed-version ICU
library if you're desperate enough. I don't think that would work
too well for libc; you're stuck with what the platform provides.
regards, tom lane
runcate both the referenced and
referencing tables in the same command. The state of the triggers
is not material to this, since TRUNCATE doesn't fire them anyway.
regards, tom lane
lanner's ability
to see that the outer query's join operator is compatible with
the table's index.
regards, tom lane
which
> would provide a bit more clarity.
If we do anything about this, I'd just say "systems that have
posix_fadvise()". If we write something more specific it's likely to
become obsolete, and it doesn't seem to me that it's hard for someone
to research "does my box have posix_fadvise()?".
regards, tom lane
promise that pg_dump version N will produce output
that you can use with pg_restore or server versions less than N,
whether they share the same archive version or not.
regards, tom lane
atching
version of pg_config would answer that.) Can you get a stack
trace from the crash?
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
regards, tom lane
about terminology. These three
databases are part of the ecosystem and clients generally expect them
to be there. But the server doesn't depend on them to function.
Does that make them "system" databases? All depends on what you
think that means.
regards, tom lane
tified by name not by OID.
You can drop template1, and the only thing that will be unhappy
is CREATE DATABASE, and if you make a new DB that is named
template1 then CREATE DATABASE will be happy again.
regards, tom lane
PG, thus allowing it to DWIM.
Even if I were on board with arbitrarily adopting one of the two
possible interpretations, it's far from obvious to me that most people
would agree that "v" should mean the value from the existing row,
rather than the new value. Better to make them say which they want.
regards, tom lane
ty exists around that software.
regards, tom lane
27;t understand why you don't have two slots, one for each).
regards, tom lane
Dominique Devienne writes:
> On Fri, Feb 21, 2025 at 3:44 PM Tom Lane wrote:
>> DROP OWNED also removes relevant permission entries (which can be
>> thought of as things owned by the role, if you hold your head at
>> the right angle). See its man page.
> Except when it
he get-go.
Nonetheless, it's there now and is a pretty similar precedent.
regards, tom lane
is complaining about
is that that fails to happen if there's a UNION ALL in the way.
Postgres is capable of doing that in other cases, so it's a fair
question.
regards, tom lane
imeout: it is
the lock wait time after which we check to see if there's a deadlock.
If there's not, we just log the above message (if configured to do so)
and keep waiting.
If you want to fail after X amount of time, lock_timeout or perhaps
statement_timeout is what to set for that.
regards, tom lane
vocation of another set-returning function, it's just
going to take whatever that function returns first.
regards, tom lane
s of their own, which is why
access rights are a poor gating mechanism for something that
needs to be applicable to indexes. Ownership could work,
because we make indexes inherit their table's ownership.
regards, tom lane
es.
(pg_prewarm wouldn't have either, without special pushups.)
regards, tom lane
Ron Johnson writes:
> On Mon, Feb 17, 2025 at 4:36 PM Tom Lane wrote:
>> It's not pulling in the TOAST storage where the bytea column lives.
>> (pg_prewarm wouldn't have either, without special pushups.)
> Puzzling, since I ran "PERFORM *". What if I exp
"David G. Johnston" writes:
> On Monday, February 17, 2025, Tom Lane wrote:
>> You'd really have to take that up with the author of pg_prewarm.
> This is our contrib module so this seems like the expected place to ask
> such a question. It’s neither a bug nor a to
happen here, because a subtransaction per
row is not practical.
regards, tom lane
ich that would.
Even ignoring the performance angle, this request seems remarkably
ill-specified. What is a "row-level handler" for errors that have
to do with identifying row boundaries?
regards, tom lane
Garfield Lewis writes:
> I would like to know if it is possible to get the CTID from within
> the OUTPUT and SEND functions of a CREATE TYPE?
No. A datatype output function has no reason to expect that the value
it's handed has ever been in a table at all.
r
2801 - 2900 of 2962 matches
Mail list logo
