alid
unless one of them is punctuation (e.g. 1+2), but our lexer is a bit
less rigid about that.
regards, tom lane
Also: have you been reloading the server configuration after
modifying the file? The postmaster only re-reads that file
after getting SIGHUP. ("pg_ctl reload" is the usual way to
send the signal.)
regards, tom lane
ertainly beats trying
to manually identify and drop the obsolete types and functions.
You will need to do this in 9.5, or at the latest 9.6, because we
dropped support for that extension in v10.
regards, tom lane
Howard News writes:
> On 30/01/2019 18:08, Tom Lane wrote:
>> Note that if you had those functions laying around ever since 8.3,
>> they're probably just "loose" and not wrapped into an extension at all.
> unfortunately running
> create extension tsearch2 fro
cribed it --- verify with pg_filenode_relation that the
file doesn't correspond to any pg_class entry, then manually delete.
(There is a crash-recovery phase that does something similar, but
I think it's only designed to clean up temporary files.)
regards, tom lane
Hannes Erven writes:
> Am 10.02.19 um 16:41 schrieb Tom Lane:
>> What do you mean by "crash" exactly?
> Here's the exact log (the pgadmin process was running the VACCUM FULL):
> 2019-02-09 23:44:53.516 CET [20341] @/ <> PANIC: could not write to
> file &q
ibrary
correctly built, so I think this must boil down to the
"shared_preload_libraries" setting not having taken. You could
cross-check that by seeing what "SHOW shared_preload_libraries"
prints.
I wonder if you forgot to remove the comment marker (#) on the
shared_preload_libraries line?
regards, tom lane
standard, and in Postgres,
they're not at all the same thing.)
regards, tom lane
entation, it doesn't seem like there's anything else that
has to be set.
I wonder whether pgaudit actually works on Windows? It might have
some weird dependency on children being spawned with fork not exec,
for instance. You probably ought to contact the authors and ask.
regards, tom lane
ight to you, it probably
means that you don't have the timezone parameter set correctly.
regards, tom lane
I believe this means
you're trying to load an 11.2 build of plpython2.so into an 11.1 server.
You need to either update the server, or find an 11.1 build of plpython.
regards, tom lane
first item in the release notes:
https://www.postgresql.org/docs/11/release-11-2.html
Also, we'd quite like to hear more details; can you find any PANIC
messages in the server log?
regards, tom lane
f
any of the branches in pg_flush_data really need the data_sync_elevel
treatment, somebody's mental model of that operation needs adjustment.
Maybe it's mine.
regards, tom lane
ync-failure?
I'm of the opinion that we shouldn't be panicking for sync_file_range
failure, period.
regards, tom lane
Andres Freund writes:
> On February 15, 2019 9:13:10 AM PST, Tom Lane wrote:
>> I'm of the opinion that we shouldn't be panicking for sync_file_range
>> failure, period.
> With some flags it's strictly required, it does"eat"errors depending on
re t4e_contractor_id = 'nicklas.a...@jordogskog.no');
when you need to drive the lookup from something other than raw
machine_key. This'll fail, as-is, if there's more than one
contractor_access row with t4e_contractor_id =
'nicklas.a...@jordogskog.no', but you can probably adapt the idea
to make it work.
regards, tom lane
errnos
that mean trouble, instead of a blacklist of some that don't. I'm
especially troubled by the idea that blacklisting some errnos might
reduce to ignoring them completely, which would be a step backwards
from our pre-PANIC behavior.
regards, tom lane
rtant to preserve?
I believe that the EXPLAIN will leave the remote transaction holding
AccessShareLock on the query's tables, meaning that doing it in one
transaction provides some positive protection against such problems,
which we'd lose if we changed this.
regards, tom lane
ally practical to support
these things in a generic inheritance tree.
Probably we should revise that bit of documentation to point people
at the partitioning features; I doubt anything's ever going to be
done about this for generic inheritance.
regards, tom lane
on that the value couldn't be null doesn't hold. In any
case you're better off without the runtime type conversion: that
isn't doing much for you except raising the odds of getting an error.
regards, tom lane
at
> the deduction that the value couldn't be null doesn't hold.
Hmm ... on closer inspection, we do assume that CoerceViaIO is strict,
but not everyplace knows that, so there's something that could be
improved here. In the meantime, try it as stated above.
regards, tom lane
s a fair bit like what you are describing.
regards, tom lane
Mike Yeap writes:
>> Are the "postgres" executable and libpq linked with the same version of
>> OpenLDAP?
> How should I check whether they are linked?
"ldd" should show the dependencies of whatever executable or library
you point it at.
regards, tom lane
rd of a better solution.
system("rm -rf $OLDPGDATA") ... nah, that is not a better idea.
regards, tom lane
vaguely
recall hearing that EDB had decided to cut back the number of distinct
Windows versions they build packages for, but that's theirs to decide
not a community matter.
regards, tom lane
[1] https://buildfarm.postgresql.org/cgi-bin/register-form.pl
its those cross-checks. I'd be afraid
to risk it in the back branches though ...
regards, tom lane
Peter Eisentraut writes:
> I tried reproducing the issue locally, but the required OpenSSL version
> is too old to be easily available.
Hm, I've got buildfarm hosts with quite old OpenSSLs handy. What
tests do you want done, exactly?
regards, tom lane
Thomas Munro writes:
> On Wed, Feb 27, 2019 at 3:57 AM Tom Lane wrote:
>> If pthread_is_threaded_np(), or something equivalent, is widely available
>> then it might be all right to try solving this going forward by switching
>> to libldap_r and seeing if anyone hits those
the file system isn't mounted. You need that,
and you do *not* want automated attempts to "repair" that.
regards, tom lane
g on what characters you actually need to work with,
you might have better luck using one of the ISO8859 character set
locales. Though if you actually need both Hebrew and Armenian
in the same DB, that suggestion is a nonstarter.
regards, tom lane
opers did). But this has been in our
folklore long enough now that anybody who's still doing that definitely
should get yelled at ...
regards, tom lane
ether; but that will break things
for some people too, no doubt :-(
regards, tom lane
dex.
4. Rename intarray's && operator to something else (will bite you at
next dump/reload, where the renaming will be lost).
5. Always schema-qualify references to the core && operator.
All of these have obvious downsides, especially if you're actively
using the intarray extension for other purposes.
regards, tom lane
n is in READ_COMMITTED.
Another line of thought is to use SERIALIZABLE mode and just retry
the inevitable serialization failures. However, if there are a lot
of concurrent processes doing this, you'd probably get so many
serialization failures that it'd be quite inefficient.
regards, tom lane
g either
of these template databases accidentally. Overriding that is
left as an exercise for the student.)
regards, tom lane
there such as
Perl's. That wikipedia entry doesn't seem to go into much detail, but
I suspect the examples it gives are intended to cause problems for Perl's
engine. Perl's engine does a lot more backtracking than ours does, and
consequently it's easier to send it down
ng, which is
something you could usefully investigate with strace, perhaps.
regards, tom lane
.57..7760.25 rows=1912 width=31) (actual
> time=0.539..0.540 rows=1 loops=1)
>
>
> Index Cond: ((name)::text = 'foo'::text)
> Planning time: 6.728 ms
> Execution time: 0.587 ms
> (5 rows)
Hm, so possibly corruption in that index? REINDEX might help.
regards, tom lane
ent collation behavior.
regards, tom lane
Matthew Pounsett writes:
> On Tue, 5 Mar 2019 at 12:54, Tom Lane wrote:
>> Given that (a) this was triggered by a server migration and (b)
>> the leading column of the index looks like it's probably varchar,
>> I'm suspicious that the new server has different colla
Matthew Pounsett writes:
> On Tue, 5 Mar 2019 at 13:55, Tom Lane wrote:
>> Yeah, that would fit the theory :-(. Debian would be using glibc
>> and FreeBSD would not be.
> The rsync migration was because we needed to do a cross-country copy before
> putting the original
Matthew Pounsett writes:
> On Tue, 5 Mar 2019 at 18:09, Tom Lane wrote:
>> If you're planninng to install (the same version of) FreeBSD on
>> the original server hardware, then rsync'ing back from the new
>> system should be fine. But Debian<->FreeBSD is go
7;m not entirely sure how such a case would have got past
parsing and into execution, but it's worth thinking about.
In any case, this isn't solvable with just what you've shown us here.
regards, tom lane
like to keep the same encoding, connection limit (if
>> anything was specified), etc. Is there a way to create this DDL?
> pg_dump --schema-only maybe?
The specific settings the OP mentions are database-level settings;
so she'd need pg_dumpall (perhaps with -g), or pg_dump with -C.
helmed by the usefulness
of the information presented that I thought incorporating it would
be mostly a waste of effort. Maybe there's an argument that it's
better than nothing at all; but I think we'd still be driven to
asking people to get stack traces with better tools.
regards, tom lane
that's a very new feature, and I don't think
anyone's done serious performance comparisons of that vs. rules.
regards, tom lane
equest would require case-insensitive
uniqueness enforcement in the system catalogs' unique indexes on names.
You have no idea how large a can of worms that opens (but I'll just
mention that "which characters are letters" doesn't even have a well
defined universal answer).
regards, tom lane
of namespaces from this query? I think the old and new behaviors are
the same if no namespaces are involved.
regards, tom lane
supplied configuration adjustment script.
More than that is hard to say without familiarity with the ubuntu
postgres packages, which I lack.
regards, tom lane
hex the performance would
be less data-dependent.
regards, tom lane
o not have different frontend and backend LDAP libs.
As far as the specifics of the patch go, I don't like that you didn't
adjust any of the comments near pthread_is_threaded_np() usages.
regards, tom lane
regards, tom lane
OP's desired
security model (which he hasn't explained).
regards, tom lane
Thomas Kellerer writes:
> Tom Lane schrieb am 20.03.2019 um 14:59:
>> No, it wouldn't. The point of CREATEROLE is to allow user creation
>> and deletion to be done by a role that's less than full superuser.
>> If we changed it like that, then you'd be right b
een widely panned, and it also turns
out that Oracle throws an error in such cases. Since these functions
are nominally Oracle-compatibility features, let's change that.
regards, tom lane
here some other way to fingerprint the LDAP implementation?
regards, tom lane
Thomas Munro writes:
> On Wed, Mar 20, 2019 at 10:51 AM Tom Lane wrote:
>> It's reasonable to assume that the proposed patch won't cause real issues
>> on any modern platform, but I'm not sure we can assume that for old ones,
>> so the whole thing is ma
dered here
-- the OP is apparently talking about the speed of bytea_in,
while the rest of us have been thinking about bytea_out.
The question about whether the text representation is hex or
"escape" style still applies, though.
regards, tom lane
Thomas Munro writes:
> On Thu, Mar 21, 2019 at 5:07 PM Tom Lane wrote:
>> Thomas Munro writes:
>>> If someone out there is not enabling any of that stuff
>>> because their system doesn't like threads, they can use
>>> --disable-thread-safety to avoid t
'm not
sure if ODBC provides any way to get at that.
Or, if you want to check/enforce this from the server side,
you could enable log_connections and see what's logged;
or simply change pg_hba.conf to disallow non-SSL connections.
regards, tom lane
authorized: user=testuser database=yle
> Why Postgres 9.1.5 version does not show ssl connection info here ?
Because that was added in 9.4 :-(
9.1.x is long out of support, and even if it weren't, the last release
was 9.1.24. You *REALLY* need to update.
regards, tom lane
he other pipe step.
(This is assuming that unpacking straight into /usr is actually what
you want to do. I share the doubts of the other responders about
that being a wise procedure.)
regards, tom lane
form-
specific roundoff error, but it seems fishy.
regards, tom lane
es what the *server's* default for client_encoding is,
but an awful lot of client-side code will immediately override that.
psql will try to set it based on its LANG/LC_CTYPE environment,
for example. I don't know what JDBC does; it might be different.
But in any case, yes, it'd be more reliable to check pg_database.encoding
explicitly.
regards, tom lane
those RPMs.)
Look into /etc/yum.repos.d/ ... if you see a file for the PGDG repo,
fix it to be enabled, otherwise you need to download and install that
repo config file.
regards, tom lane
ut it is
what it is.
regards, tom lane
ebody at trustwave (not the actual
author of this "research") did reach out to the pgsql-security
list, and we discussed with him that it wasn't a violation of
Postgres' security model, and he agreed. But then they've
posted this anyway. Left hand doesn't talk to right hand there,
apparently.
regards, tom lane
Magnus Hagander writes:
> On Sat, Mar 30, 2019 at 10:16 PM Tom Lane wrote:
>> Yeah; this is supposing that there is a security boundary between
>> Postgres superusers and the OS account running the server, which
>> there is not. We could hardly have features like untrus
ertainly be a bug, but we'd need to reproduce it to fix it.
What are you doing that's different from everybody else? Can you
provide any other info to narrow down the problem?
regards, tom lane
o be getting transferred despite the complaint? If not,
what's missing on the slave?
regards, tom lane
to reproduce the error without a lot of guesswork.
regards, tom lane
(I'm sure you have a lot, if this table is big enough
to be worth troubling over), and FSM and VM files.
* The indexes on the table also need to be moved through the same
type of process.
I'd strongly counsel practicing on a test setup before you try to
do this to your live data.
Oh: and you have a backup, I trust.
regards, tom lane
probably out of luck if the table has a
TOAST table, unless the TOAST table is empty. There wouldn't be
any good way to keep TOAST pointers valid across the move.
(PG v12 will make that easier, but that's no help to you today.)
regards, tom lane
Alvaro Herrera writes:
> On 2019-Apr-03, Tom Lane wrote:
>> Actually, thinking about that a bit harder: there's one aspect of
>> what pg_upgrade does that's really hard to control from userspace,
>> and that's forcing tables to have the same OIDs as before. I
h gets accepted:
https://www.postgresql.org/message-id/flat/CAJrrPGcfqXhfPyMrny9apoDU7M1t59dzVAvoJ9AeAh5BJi%2BUzA%40mail.gmail.com
If you want to help move things along, you could review/test the patch.
regards, tom lane
way for a very very long time.
regards, tom lane
iled a dispute with Mitre about the CVE, and also
reached out to trustwave to try to find out why they filed the CVE
despite the earlier private discussion.
regards, tom lane
low that, if it did
indeed do anything. You don't want "--jobs=10" to suddenly turn into
100 sessions.
regards, tom lane
shows what ordering
is required for restore?
> The --link option to pg_upgrade would be so much more useful if it
> weren't still bound to serially dumping the schemas of half a million
> tables.
To be perfectly blunt, if you've got a database with half a million
tables, You&#
eltuples definitely does
matter to the planner, and some of the sibling counters like n_dead_tuples
drive autovacuum, but nothing is examining n_live_tuples AFAICS.
regards, tom lane
#x27;t be, for most). And,
having different behaviors in different "v11" installations is not really
all that nice, especially for something that's only debatably a bug.
So I concur with the decision not to back-patch.
regards, tom lane
[1] https://www.postgresql.org/docs/9.6/release-9-6-5.html
o back to table and remove the previously-found tuples
* if not end of table, repeat
So a larger work-mem setting means fewer passes over the indexes,
but a longer time until space is reclaimed.
regards, tom lane
64MB? I see only pluses )
Well, usually people prefer to minimize the number of passes over
the indexes.
regards, tom lane
dead tuples remained ... probably because you have
> long-running transactions preventing vacuum from removing them.
I think you misread it --- I'm pretty sure "N remain" is referring
to live tuples. Maybe we should adjust the wording to make that
clearer?
regards, tom lane
login
behavior.
regards, tom lane
Ron writes:
> On 4/11/19 9:12 PM, Tom Lane wrote:
>> PAM is the usual suggestion
> Can you be more specific?
I'm suggesting that you use PAM auth
https://www.postgresql.org/docs/current/auth-pam.html
and then configure the email behavior on the PAM side.
The PAM doc link
ndexes.html
regards, tom lane
Andres Freund writes:
> On 2019-04-12 09:51:51 -0400, Tom Lane wrote:
>> Tiffany Thang writes:
>>> Can someone explain the use of creating multiple indexes on the same
>>> column?
>> There is none, unless the indexes have different properties (e.g.
>&g
Igor Korot writes:
> igor@solaris:~/dbhandlerSol/postgresql/src/interfaces/libpq$ dmake
> dmake: Fatal error in reader: ../../../src/Makefile.global, line 45:
> Unexpected end of line seen
> What do I do?
Use gmake.
regards, tom lane
outer UPDATE, so it'll fail the inner WHERE test.
The way I'd recommend fixing it is to put the FOR UPDATE into a WITH
to guarantee single execution:
WITH dq(uid) AS (SELECT uid ... LIMIT 1)
UPDATE queue.some_queue q SET ...
FROM dq
WHERE q.uid = dq.uid
RETURNING q.uid;
regards, tom lane
use a default partition ...
regards, tom lane
ld be good to know what PG version this is.
regards, tom lane
27;d only recommend
using a domain when there is no other way to get the check you need.
PG just doesn't support domains very well (especially before the work
I did for v12...)
regards, tom lane
ases like out-of-memory,
but if your app is at the edge of OOM then giving up might be wise anyway.
regards, tom lane
r existing domain type, so maybe it's not bothering
you. But I'm worried that going from domain-without-check-constraint
to domain-with-check-constraint is going to bite you.)
regards, tom lane
re about tsearch2,
psql's "\dx" would tell you what extensions are installed in the
8.3 database.
regards, tom lane
base textual data should be fine, but if you've got derived
tsvector columns or indexes, you might need to recompute those.
regards, tom lane
vector'::regtype;
but you could also devise some more-portable query involving
the information_schema ...
regards, tom lane
ver reboot, so there's something
not very accurate about this description.
I suspect what the OP wants is quicker detection of client connection
loss, and yes, messing with TCP timeouts and/or keepalive is the only way.
regards, tom lane
ing about that in the server code proper,
we'd basically be reinventing TCP keepalives --- probably badly.
And we couldn't do it at all without a protocol version break,
because the client-side code would also need to know about it.
Just use the keepalive facility.
regards, tom lane
1601 - 1700 of 2962 matches
Mail list logo
