t've had issues
with setting this up wrong, but anything in current support ought to
get it right ...
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
ollixed?
As a temporary workaround, you could probably set
dynamic_shared_memory_type = none in postgresql.conf (I'm assuming
it's set to posix now). I do not think that disables any very
critical functionality in 9.5, but it's a hack not a solution.
rega
x27;;
You definitely want to reindex after the data cleanup, since presumably
it's corruption of a unique index that got you into this mess in the
first place. But as long as it's only the index and not the table that's
damaged, recovery is pretty straightforward.
2}, {"labeltext":
> "Other", "labelvalue": 3}, {"labeltext": "Don''t know", "labelvalue": 4}],
> "target": {"place": "Sweden"}, "askfreq": "once", "whydesc
r trigger undoing its work? (psql's \d command on the table
should show these things.)
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
es
from applications because they invariably drop notices on the floor.
I'd try RAISE LOG instead, and again watch the server log to see what
the application is really doing.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make c
ined symbol: oid_hash
Looks like you built against a set of backend headers that is older than
the server you're trying to run 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
or that, it just hasn't gotten the
love the other PLs have.
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
initely has lots to recommend it --- eg, it
probably won't break when you find out your initial spec for the transport
format was too simplistic.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your su
;, 'attacking other
> users');
Hm? That would be passing a timestamp not an interval.
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
idn't last I heard, I might be out of date.)
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
member of PUBLIC.
IOW, revoke only revokes a previous matching grant, and there was
no such grant in this case. What there was was a grant to PUBLIC;
see the relevant bit in initdb.c:
"GRANT CREATE, USAGE ON SCHEMA public TO PUBLIC;\n\n",
regar
x27;t do
"create table foo (f1 int, f1 int)". They can be reading the same
values, 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
;2016-08-10')
> but it doesn't work.. I get 0 rows... what am I doing wrong?
Are you sure you're not getting an error? The query is specifying fields
in "tasks" but the FROM clause only lists "jobs".
Either one of those two cast-to-date syntaxes should work, so
161817.go1...@alvh.no-ip.org
which would suggest that you're trying to build some fairly old PG version
with some fairly new C compiler. Whether that's actually the case, well,
you didn't give enough info to tell.
regards, tom lane
--
Sent via pgsql
s exactly
zero impact on the number of rows produced; it just stops execution.
I think you can say RETURNS RECORD with a few OUT parameters
to get the effect you're looking for.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.or
bably not understanding the significance of this
warning. I think what's wrong is you have not #include'd "fmgr.h" which
is where PG_MODULE_MAGIC is defined. It's not exactly clear to me why
that's resulting in a warning rather than an error, but certainly this
is indic
an 8.* headers.
Hm, where are you reading that? I forget when the requirement was added,
but it's certainly never been dropped.
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
nothing new has been
submitted, I wouldn't hold my breath.
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
at most other browsers don't present that
message :-(
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
so why? A plain old bigint
column is smaller, cheaper to index, and the natural mechanism for
generating it (ie a sequence) will tend to preserve ordering for free.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to
do is, eg,
regression=# select * from plr(23,45);
ERROR: a column definition list is required for functions returning "record"
LINE 1: select * from plr(23,45);
^
because the parser has no basis on which to expand the "*". The column
definition list is exac
getting
taken as arguments, not quotes.
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
> How would you recommend to fix my declaration problem please?
I think you are looking for the RETURNS TABLE syntax.
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
ade. Or I guess
you could turn off enable_hashagg when using array_agg() plus GROUP BY,
though you'd want to remember to undo that whenever you do upgrade.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes t
pathological behavior. Can you put
together 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
derr directed to a file, not to /dev/null.)
That would provide a better clue about what's eating space.
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
ouching more and more of the shared buffer arena. (If your
shared_buffers settings is not somewhere near 100MB, then this theory
breaks down.)
It would be worth using plain old top to watch this process. We have
enough experience with that to be pretty sure how to interpret its
numbers: "RES mi
If the same query, repeated over and over, causes memory to continue
to grow, I'd call it a leak (ie bug). If repeat executions consume
no additional memory then it's probably intentional caching behavior.
regards, tom lane
--
Sent via pgsql-general mailing
e this. But I think the
problem is that you're required to specify a netmask or masklen;
so "127.0.0.1/32" not just "127.0.0.1".
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your su
e same set of users as the source. Or just ignore these errors.
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 it got me to thinking, so:
You'd need additional parens around the whole thing, like
create unique index on "user"(((google_user).email));
The UNIQUE-constraint syntax will never work, because per SQL standard
such constraints can only name simple columns. But you can make
a unique
7;m not sure if any of the subsequent work on the regex engine would
make it any easier to fix than it seemed at the 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
Jim Nasby writes:
> On 8/11/16 8:45 AM, Tom Lane wrote:
>> What were you doing to "get ten keys out"? If those were ten separate
>> JSON operators, they'd likely have done ten separate decompressions.
>> You'd have saved something by having the TOAST da
doing to "get ten keys out"? If those were ten separate
JSON operators, they'd likely have done ten separate decompressions.
You'd have saved something by having the TOAST data already fetched into
shared buffers, but it'd still hardly be free.
rega
ransform modules.
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
es both an XID and WAL entries. The same goes for most database
alterations, really. There are very limited cases where you can produce
WAL without assigning an XID or vice versa, but I'm not sure it's worth
your while to distinguish.
regards, tom lane
--
ue available to look at.
You could possibly alleviate some of the speed issue by storing the column
uncompressed (see ALTER TABLE ... SET STORAGE EXTERNAL), but that would
bloat your disk space requirements so I'm not really sure it'd be a win.
regards, tom lane
-
l)
implements "IS NOT DISTINCT FROM" semantics rather than "=" semantics.
I dunno that we want to make the documentation use that wording though,
it'd probably confuse more people than it helped.
regards, tom lane
--
Sent via pgsql-general ma
ml
Having said that, I'm pretty skeptical of the notion of redefining what
your PK is on performance grounds. With this definition, you'd allow
two entries with the same work_session_id, if they chanced to have
different customer_ids. Is that really OK?
reg
Alexander Farber writes:
> Thank you, so should I maybe switch to cardinality then?
Yeah, that should work.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
egards, 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
will be transformed by upper/lower.
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
and COMMITs get issued.
(Well, I guess that only exhausts the possibilities as long as this is
happening on a single database server. If the reader is reading from
a hot-standby slave then replication delays might explain your problem.
But that would be a rather material omission of fact
hours). Why is that ?
Probably because there's no background process to issue auto-checkpoints
and thereby recover WAL space.
I'd try doing a control-C on the VACUUM, then a CHECKPOINT, then start
over. You might have to vacuum large tables individually and checkpoint
after ea
gh I do not think they're
exposed at the SQL level.
> Another thing I should have mentioned is that I don't consider incrementing
> a sequence to be a modification.
Things might not work the way you want on that...
regards, tom lane
--
Sent via pgsql-general m
Alex Ignatov writes:
> On 05.08.2016 17:51, Tom Lane wrote:
>> Sure. Just like it reserves space for ordinary tables right away,
>> long before there's any need to push the data out of shared_buffers.
>> Otherwise, you might find yourself having to throw an "ou
k-space while flushing a buffer, that's
what we'd risk. So we allocate the disk space before accepting the
INSERT in the first place.
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 any need to push the data out of shared_buffers.
Otherwise, you might find yourself having to throw an "out of disk
space" error after having already committed the relevant INSERTs.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgre
re process-local in all flavors of Unix. The above only
proves that all of these processes had FDs 0..12 open already, which
doesn't seem terribly surprising.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
on
updates to rows in the child tables. To get that effect, attach the same
trigger procedure to all the children.
Don't recall offhand what the rules are for per-statement triggers.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@post
e may not be any version that
works well.
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
is happening or not. It'd
manifest as one join input node showing an actual number of rows returned
that's less than you'd expect.
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
enefit of approaching things this way is it doesn't have to
be all-or-nothing: the gating function can apply checks on what it
will allow.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
ht
ifoo($1,$2)"
PL/pgSQL function ifoo2(integer,text) line 1 at PERFORM
STATEMENT: select ifoo2(1,'foo');
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
like "duplicate key" (or a function raise exception) or
> other similar problems that wont allow the database to execute the SQL
> command,the strack trace will bring the complete list of function call.
Uh, doesn't the CONTEXT field of error messages give you that already?
or pg_upgrade for the new version
anyway because of other catalog changes.
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
;0|UPDATE|A|" received from server
process with PID 19442.
Asynchronous notification "foo" with payload "0|DELETE|A|" received from server
process with PID 19442.
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
ps://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=1d2fe56e4
We did not back-patch those changes because they seemed rather
invasive/risky compared to the value for average users.
If you still see misbehavior in 9.6, it'd be worth trying to extract
a self-contained exa
e drudgery out of it, if you have
the template database set up properly.
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 when PG wasn't running, but it was pretty foolish to do it to
a running system without even looking to see if any IPV6 connections were
open :-(
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.
It might be nice to have some sort of tool that could check compatibility
of the doc synopses with the actual grammar. But I doubt that trying to
auto-generate either one from the other would be a win.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-ge
ce? You could at least confirm whether it's receiving anything.
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
action commits.
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'd be
impossible to have clean semantics for failures: the sending transaction
would have committed all right, but some of the recipients wouldn't get
the notification.
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
Andrew Geery writes:
> Is it possible to define functions in SQL (as opposed to C) to do the same
> thing -- create an operator class -- for a gin index?
Afraid not; several of those APIs are C-specific.
regards, tom lane
--
Sent via pgsql-general mailing list
ts only measures
the executor runtime, omitting parse/plan times as well as network
transmission times. pgbench is reporting the overall time as seen
from the client side.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
Alex Ignatov writes:
> Is there any way to make pg_dump(9.5) to dump table (with data) without
> any SET command in the header of output plain sql file?
No, but if all you want is the table data in a file, why not just use COPY?
regards, tom lane
--
Sent via
n setting up new slave instances, pg_basebackup's
--tablespace-mapping option would help you with that. For an existing
slave instance, you'd need to shut it down while manually moving the
tablespace directory(s) and re-pointing the symlink(s).
regards, tom l
o put the socket) as the host location.
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
obvious showstoppers like a FROM clause. This wouldn't
constitute a general solution to your problem, of course, but it would
save some useless cycles in planning.
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
on our webservers,
but in any case you could easily check out that tag from our git server
to recover the matching source 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
ot;--quote-all-identifiers" was invented to address. But if you don't use
that option, you're at risk for that regardless of whether you dumped with
the older or new pg_dump.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.
ith log_min_messages to 'notice'.
OK.
> I suppose log_statement to 'all' is no longer necessary?
I agree; we already know which statement is failing.
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
somewhere, else you'd not have gotten this far.
> To make the problem more interesting, I can bring the DB engine up if I use
> pg_ctl ⦠but only if Iâm in the data dir.
Possibly you have "data_directory = ." or something like that in the
config file?
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
derr (hopefully
you are starting the postmaster in such a way that that gets captured
to a log file rather than sent to /dev/null). Save that. Wait until
you see bloat, reattach and repeat, compare the memory maps. Let us
know what you see. If possible, compare maps taken at points where
the sess
or across a network --- and if the latter, how fast is the network?
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 in the scripts you already have. You may spend more
time dealing with useless-to-you changes than you save by not doing your
own research on what changed in Postgres.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
T
at's a contributing factor.
I'm still suspicious that this might be some sort of NOTICE-processing-
related buffer bloat. Could you try loading the data with the server's
log_min_messages level cranked down to NOTICE, so you can see from the
postmaster log whether any NOTICEs are
plete example for
anyone to diagnose it. Also, what PG versions are in use exactly,
both local and remote?
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
at
is being worked on when the error happens.
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
Miguel Ramos writes:
> Às 15:40 de 12-07-2016, Tom Lane escreveu:
>> Unless you're running pg_restore under a really small ulimit, this would
>> seem to suggest some kind of memory leak in pg_restore itself. I wonder
>> how many objects in your dump (how long
> That should work. Are you sure you haven't spelled it "... WHERE d IS TRUE"?
It does work for me, but I think it probably only started working after
this as-yet-unreleased patch:
Author: Tom Lane
Branch: master [26e66184d] 2016-05-11 16:20:23 -0400
Branch: REL
ompiled to get 32kB blocks
9.1.8 is pretty old ...
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
culations, but we leave it to
* distribute_qual_to_rels to get rid of such clauses.
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
subselects seem to be
pretty expensive. If you don't want to rewrite the query in a wholesale
fashion like he suggests, you might be able to make the MAX's cheaper by
providing an index on sed_uttak(avlsnr, dato); but I'm not sure how much
that will help.
re
o a conclusion not supported by this evidence;
we can't tell whether the postmaster started at all. Did you
look into pg_upgrade_server.log as suggested?
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
pg_upgrade -b /usr/lib64/pgsql/postgresql-9.4/bin -B /usr/bin -d
> /db/pgsql/data.old -D /db/pgsql/data
Why are you not using "postgresql-setup upgrade", as documented in
/usr/share/doc/postgresql-NNN/README.rpm-dist ?
regards, tom lane
--
Sent vi
r local TCP connections not remote ones. You typically want
listen_addresses set to "*" if you intend to allow remote connections.
When you start getting complaints phrased along the lines of "no
pg_hba.conf entry" then it'll be time to fix pg_hba.conf.
dline uses to do completion.
> Doesn't 'cat | psql ' disable it?
Sure, but you could as well use 'psql -n'. I think the point is to be
able to turn it on and off without starting a fresh session. (Admittedly,
maybe there's not a lot of usability gain there.)
Alvaro Herrera writes:
> Tom Lane wrote:
>> You might have better luck with "psql -n", or maybe not.
> I've wished sometimes for a "\set READLINE off" psql metacommand for
> this kind of thing. It's pretty annoying when the text being pasted
>
ith "psql -n", or maybe 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
or libc routines.
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 which you might store values that aren't
canonical.
I have some recollection that we discussed this when range types
were being invented, and didn't think of any nice solution.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postg
is a bad guess about the size of the recursive
union result, which is unsurprising since it is only a guess. If you've
heard of ways to estimate recursive union sizes more plausibly, maybe we
could do something about that.
regards, tom lane
--
Sent via pgsql-gener
y enforcement trigger). So any other transaction that is
accessing any two of those tables in a different order than this does
creates a deadlock hazard.
> Have you looked at separating the FK creation and validation?:
I think it'd likely be enough to add the FKs one at a time, rather
than a
he algorithm.
> I do not know the exact syntax.
You would need to write a plpgsql function in order to have a loop like
that; there's no loops in bare SQL.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make ch
onsiderations
mean that the odd byte would just be wasted in most or all of 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
n, for quite a long time. AFAICS this
error would only be possible if plruby had been compiled against postgres
header files from 9.0 or before, which would be a packaging mistake.
Suggest complaining to whoever the package builder is.
regards, tom lane
--
Sent via pgsq
ackend functions it calls can tell, and they throw errors.
There are various ways this might be rejiggered, but none of them
entirely remove all risk of failure in the presence of concurrent DDL.
Personally I'd recommend just retrying the pg_dump until it succeeds.
rega
601 - 700 of 13966 matches
Mail list logo
