maybe the bad value for
TCLSH is somehow causing this, though I'm not sure how.
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
cts depend on it
> DETAIL: privileges for default privileges on new types belonging to role
> role_main
See DROP OWNED BY.
https://www.postgresql.org/docs/9.6/static/role-removal.html
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgres
he *current* database. You need to do DROP OWNED BY
in that database (and maybe other ones, but start there).
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
EX on whatever table equates to
> "base/1029860192/1029863651"? If so how do I determine the db and table
> for "base/1029860192/1029863651"?
1029860192 is the OID of the database's pg_database row.
1029863651 is the relfilenode in the relation's pg_class row.
it's starting to sound like that system has
got major problems. You'd be well advised to focus all your efforts
on getting a valid dump, not bringing it back into production.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgre
g about it right now.
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 PostGIS's configure even pays attention to what
pg_config says for INCLUDEDIR. I've not checked.)
Is there a good reason why you're not building Postgres on the same
machine where you're building PostGIS? It seems like a recipe for
trouble, with little to be gained.
certainly does no such thing. Maybe it's being done in
some wrapper script you're using?
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's probably making some progress but not much. You need to fix 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
ent/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS
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
information about it in the postmaster log.
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
which
is blocking whatever the "update t_unit_status_log" command wants to do
with t_unit. Looks like a classic lock-strength-upgrade mistake to me.
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
CTE twice; but since you're evaluating that CTE elsewhere in the
query, I think the additional follower node isn't worth trying to get
rid of.
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
Steve Clark writes:
> On 10/28/2016 09:48 AM, Tom Lane wrote:
>> Retrying might be a usable band-aid, but really this is an application
>> logic error. The code that is trying to do "lock table t_unit in
>> exclusive mode" must already hold some lower-level lock
null.
The bigger picture here is that if you've designed a data representation
that requires that a null be considered "equal to" another null, you're
really going to be fighting against the basic semantics of SQL. You'd
be best off to rethink the representation. We've not see
ormance, but have started a thread about it on -hackers:
https://www.postgresql.org/message-id/6315.1477677885%40sss.pgh.pa.us
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
x27;ve no idea what DBMS they're using (but suspect Oracle). My
> web search used in-effective terms so I could not find the answer there.
>What does U1 represent?
Unique constraint, perhaps? I'm just guessing.
regards, tom lane
--
Sent via pgsql-ge
he
> policy check.
Join cases with RLS aren't optimized very well at the moment. There's
work afoot to improve this - see
https://www.postgresql.org/message-id/flat/8185.1477432701%40sss.pgh.pa.us
- but it won't be in production before v10.
regards, t
't think plpgsql coped
with that very well before 9.1.
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
exp_matches(observacao, '\d\d/\d\d/\d\d\d\d'))
from ...
As of v10 there will be a less confusing solution: use regexp_match()
instead.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscri
d probably get away with all that as long as your application
isn't doing anything that makes it matter critically which semantics
get applied while the changeover is being made.
But test on a scratch database ...
regards, tom lane
--
Sent via pgsql-general mailing
s. I speculate that you need to ANALYZE this table.
If there are a lot of distinct possible values in the arrays, increasing
the statistics target for the column might be needed.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.or
any real estimation logic until 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
It's not something we'd think of back-patching, though.
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(pg_catalog.@>)"),
or you could upgrade to 9.6 (don't forget to do ALTER EXTENSION ... UPDATE
afterwards).
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
Jeff Janes writes:
> On Thu, Nov 10, 2016 at 7:11 AM, Tom Lane wrote:
>> If you are using that contrib module, and it's capturing this operator
>> reference, that would probably explain the bad estimate. You could
>> drop the extension if you're not dependin
with dummy as (select * from pg_class c limit 10)
insert into test select * from dummy;
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
x27;id';
That WILL break your table.
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
being significantly hurt by
inadequate work_mem.
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
ient it's also directly available
from PQparameterStatus().
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 still be the case that A can't be restored
before C).
If you think neither of those cases apply, please provide a self-contained
test 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
:\temp.dump"
> fails.
[ squint... ] That does look like it ought to work. I wonder if postgis
is doing something weird? But again, it's impossible to debug this at
this level of detail. If you can make a test case I'd be happy to look
into it.
re
to not assume
that the underlying tables have primary keys. It looks like in
view_temp_export_geo_recherche_extra_sites_projets you need to add
c.official_language_id to the GROUP BY, and similarly in
view_temp_export_geo_recherche_offtrad_sites.
regards, tom lane
--
Sent vi
ts of comparisons for common values.
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
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
uld just ignore the errors relating to plpgsql, but if you have
C-language functions that you need to migrate, there is no way to
install those without superuser privileges.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make ch
d, the given INSERT request fails due
to not-null constraints that are unrelated to what the ON CONFLICT clause
tests for.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgres
random sample came up quite a bit different).
And I'm a little suspicious that these tests weren't all done with the
same work_mem setting.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to
on
just to see, but I doubt it's a promising avenue.
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
Poul Kristensen writes:
> When I use this in my code I get
> "undefined reference to `PQexecParms'
> when compiling.
IIRC, it's PQexecParams not PQexecParms
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
looks like Poul is hoping to use a parameter as a table name,
which doesn't work. Parameters can only represent values (constants).
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,
which leads me to wonder if the parallel calls are likely to be fighting
over inserting/updating the same row in the group_history partition
tables. Or are you certain that they should be hitting different rows?
regards, tom lane
--
Sent via pgsql-general mailing lis
u're going to do if it doesn't,
though, since you still haven't got enough data to do an INSERT.
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 out-of-line parameter.
Don't know how hard it might be to arm-wrestle ActiveRecord into doing
it like 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
s that
cause breakage of extensions. But we try hard to avoid such changes
in minor releases, particularly in long-stable branches.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postg
2234: INSERT INTO table1 ( id , unique_id )VALUES( '1', '4')
> Process 4111: REINDEX TABLE table1
Offhand I would not expect those two commands to deadlock in isolation.
Are they parts of larger transactions that take additional locks?
regards, tom
pened and no others.
There are other scenarios where file access would occur, of course, but
this seems like a plausible explanation.
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
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
for an indexscan
on it to be faster than a seqscan.
I think however that the "half" may be a default estimate occasioned
by the other tables being empty and therefore not having any statistics.
Another rule of thumb is that the plans you get for tiny tables have
little to do with what
Whether the OP's particular
query is being hit by that is impossible to tell, though, since there
isn't any actual RLS usage in the doubtless-oversimplified example.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
on. An example:
Personally, I'd try to convert everything to new style, and put a shim
function into pre-9.6 deployments only. This seems to work:
create function to_regclass(text) returns regclass
language sql as 'select to_regclass($1::cstring)';
rega
so there is a way
to make connections without relying on DNS.
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
uplicate that behavior, without success. What PG version is
that, exactly? Have you vacuumed and/or analyzed those two tables? What
do you get for
select * from pg_stats where tablename = 'wg3ppbm_userpartner';
and likewise for wg3ppbm_partner?
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
George writes:
> On Thu, Dec 1, 2016 at 6:58 PM, Tom Lane wrote:
>> What
>> do you get for
>> select * from pg_stats where tablename = 'wg3ppbm_userpartner';
>> and likewise for wg3ppbm_partner?
> It is a wide table. Do you want me to dump csv here?
Sho
plication is causing that and take steps to
mitigate 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
there's also backwards
compatibility to worry about.
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
ectly to tsquery rather than passing it through to_tsquery(),
though likely that would just have a different set of failure modes
with queries where you do wish stemming would occur.
The problem with "no" seems to be the same.
regards, tom lane
--
Sent via pgs
t it
just dies without saying anything.
Hmm ... a different take on that is that maybe psql is crashing
because it's linking to an ABI-incompatible libpq. You should try
"ldd" on the psql executable and see if it's resolving the libpq
dependency to the copy you intended.
semicolons --- does the
psql prompt change to match?
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
o
that the WHERE condition never succeeds. You could set log_statement=all
and look in the postmaster log to see what the server thinks it's getting.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your su
s behave normally and which don't. Of course, the other two
would have to be told --host=/tmp to talk to the handbuilt 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
sing arrays or multiple tables).
Yeah, this is a bug, but fortunately the fix is pretty trivial. See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=da05d0ebc637a84ba41a172b32552557ebad199f
regards, tom lane
--
Sent via pgsql-general mailing list (pg
n index matching one
but not the other. Right now we're very stupid and only consider x,y,
but if there were room to consider more than one set of target pathkeys
it would be fairly simple to make that better.
regards, tom lane
--
Sent via pgsql-general mailing l
at the moment what are the user-visible cases where this happens.)
You can find probably more than you want to know about deadlock handling
in src/backend/storage/lmgr/README.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
works.
Ah! So, most likely, there is something wrong with the local installation
of "more", or whatever the environment variable PAGER is set to. If you
say "more somefile", does it behave reasonably? Check "echo $PAGER"
as well.
regards,
at some remove from the popen call, but if it's not
unreasonably hairy we should 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
to go into
parsing and network round-trip overhead, so one statement is going
to handily beat N statements whether they're in a transaction block
or not.
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
nique
doesn't scale well to user-defined types. Take your choice.
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
that if PAGER is empty or all white space
then we should not try to use it as a shell command; we can either
treat the case as "pager off" or as "use default pager". Everything
else we can leave to the invoked shell to complain about.
Comments?
regards,
hat you need to write/read
it in chunks rather than all at once, the large-object APIs are what
you want.
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
#x27;s irrelevant here, because it
can easily be shown that psql doesn't behave nicely if PAGER is set to
empty when it does try to use the pager.
regards, tom lane
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 261652a..9915731 100
ee
https://wiki.postgresql.org/wiki/Systemd
or the longer discussion at
https://www.postgresql.org/message-id/flat/57828C31.5060409%40gmail.com
or a couple of other discussions you can find by searching the PG mail
archives for "systemd semaphores".
regards
ffling
> behavior if I were using an xterm: with a blank PAGER your output
> would disappear only if the select exceeded a certain number of
> lines...
Yeah, that was exactly the behavior I was seeing before fixing it
(the fix is pushed btw).
regards, tom lane
--
OM API is preferred
or deprecated. It's probably just cosmetic anyway, so I'd say ignore it.
9.5 and up have a better design for this, in which the behavior is
determined on the fly rather than being hard-wired at build time.
regards, tom lane
--
Sent via pgsql-gene
y detailed help, but
I believe that's possible.
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
socket.
Also, you can use -h /path/to/socket/dir to specify connecting
using a socket file in a specific directory.
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
END LOOP;
> But Eg[i] is assigning null to array_value
I think you want
array_value = Eg[i][array_lower(Eg, 2):array_upper(Eg, 2)]
As of 9.6 you could use the shorthand
array_value = Eg[i][:]
regards, tom lane
--
Sent via pgsql-general mai
uspicious that this might be related to commit 2b3a8b20c,
which went into 9.3.6, but it's probably premature to blame 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
osts if none of the out-of-line values change.
I don't remember offhand what corner cases might exist to prompt the
weasel wording "normally". Maybe that just reflects the possibility
that one of the newly updated values would need toasting.
regards, tom
t)) select
> max(x) from (select x from i union all select y from j) b;
> ERROR: could not find plan for CTE "i"
Yup, sure looks like a bug to me, especially since it seems to work as
expected before 9.5. No idea offhand what broke it.
regards, tom lane
-bash-4.1$ pg_dump -d postgres -t '"Statuses"'
> pg_dump: no matching tables were found
> -bash-4.1$ pg_dump -d postgres -t 'public."Statuses"'
> pg_dump: no matching tables were found
These cases work for me. Maybe your shell
nks for the report!
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 writes:
> Tom Lane schrieb am 13.12.2016 um 18:02:
>> These cases work for me. Maybe your shell is doing something weird
>> with the quotes?
> Hmm, that's the default bash from CentOS 6 (don't know the exact version)
I'm using bash from curren
pg_typeof(1::uint4);
:: binds tighter than minus, so you would need to write these like
"(-1)::uint4" to get the behavior you're expecting. See
https://www.postgresql.org/docs/9.5/static/sql-syntax-lexical.html#SQL-PRECEDENCE
regards, tom lane
--
Sent via
It might shed some light if you put "echo" in front of that
to see what gets printed:
$ echo pg_dump -d postgres -t "\"Statuses\""
pg_dump -d postgres -t "Statuses"
regards, tom lane
--
Sent via pgsql-general mai
Thomas Kellerer writes:
> Tom Lane schrieb am 15.12.2016 um 16:20:
>> Hmm. It might shed some light if you put "echo" in front of that
>> to see what gets printed:
>> $ echo pg_dump -d postgres -t "\"Statuses\""
>> pg_dump -d postgres -
that it will issue a checksum complaint
not a version-number complaint if started against a 9.4.x pg_control.
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
trictions.
That doesn't seem to be your problem, at least not yet.
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
ou could use different pg_hba.conf files on master and slave. Or there's
always packet filtering...
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
nt library makes those accessible.
(In the spirit of full disclosure, I should point out that those
fields have only been provided since PG 9.3. So older installations
may not have the ability to do this in the Right Way. But still,
you should be evangelizing for doing it the Right Way, no?)
NG *;
Another option is COALESCE:
...
DO UPDATE SET campaigns = EXCLUDED.campaigns,
facts = COALESCE(fan.facts, '{}'::jsonb) || EXCLUDED.facts
...
I'd argue though that if you think this is okay, then you're abusing
NULL; that's supposed to mean "unknown", no
gres parser doesn't have any special knowledge about
the meaning of the -> and || operators, it gives them the same precedence,
causing what you wrote to be parsed as
((extra_values->'nested1') || extra_values)->'nested2'
giving the result you show. The COALES
two independent columns to select the rows you care about.
That would improve the odds of getting a decent rowcount estimate.
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
h only this much info.
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
u8=# select *, length(string) from unicode;
id | string | length
++
1 || 0
(1 row)
I'd have expected a syntax error along the line of "incomplete Unicode
surrogate pair". Peter, I think this was your code to begin with ---
was it inte
connect
anywhere, just emit the restore script on stdout. At least, that's
what happens for me. It's weird that you don't see any printout.
(To be clear: it's -d that triggers a connection attempt in pg_restore.
Without that, -h and -p are just noise.)
r
's operator precedence rules were set long before the JSON types ever
existed. Even if we wanted to treat -> specially, we couldn't for fear
of breaking existing queries that used custom operators named that.
regards, tom lane
--
Sent via pgsql-general mailing
re certainly missing the pg_depend
linkages, not to mention attribute inheritance counts in pg_attribute,
and there may be other things I'm not remembering offhand.
Why can't you use the normal ALTER TABLE approach?
regards, tom lane
--
Sent via pgsql-general mailing
James Zhou writes:
> The format U&'\03B1' only works for chars between -
Kyotaro-san already pointed you to the right answer on that:
you have to use "\+nn" for six-digit code points in the U&
string syntax.
regards, tom la
m-wide consistency standpoint, it's rather unfortunate that
inet's default conversion to text type does not behave the same as the
inet output function. But it's been like that for umpteen years and
the costs of breaking backwards compatibility would outweigh any benefit
of changing
401 - 500 of 13966 matches
Mail list logo
