kernels (~2009) might'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
the
permissions on /dev/shm are bollixed?
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.
';
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.
regards, t
t;: 2}, {"labeltext":
> "Other", "labelvalue": 3}, {"labeltext": "Don''t know", "labelvalue": 4}],
> "target": {"place": "Sweden"}, "askfreq": "once", "whydesc": "Because I
, and that there
isn't another 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
ries
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 chan
/lib/pgq_lowlevel.so: undefined 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 subscripti
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
ke JSON definitely 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
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
didn'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
ct on his being
a 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",
s, just like you can'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
rt) in ('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 y
817.GO1663%40alvh.no-ip.org#20150120161817.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
RETURN, per se, has 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@po
ly this
is indicating a problem.
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
ing
> against 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 subscriptio
s ago and 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
ound that 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
nd if 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
expand the "*". The column
definition list is exactly a hack for telling it 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
line. Those are 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
ds_games, words_moves AS
> 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
ve with it or upgrade. 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
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
the
postmaster with its stderr 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
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 minus SHR"
f 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 list (pgsql-
ould probably have helped you diagnose 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
urce. 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
> and that did not work, but 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
'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.
Jim Nasby <jim.na...@bluetreble.com> 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 somet
single key.
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 data already fetched into
shared buffers, but it'd still hardly be free.
of plpython transform 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
catalogs, which
requires 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
ce it's got
the value 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
eaking, array_remove (and I think array_replace as well)
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.
static/indexes-multicolumn.html
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?
Alexander Farber <alexander.far...@gmail.com> 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 subscript
sional in PG.
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
ale, only the standard ASCII letters
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
e a rather material omission of facts.)
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
les individually and checkpoint
after each one.
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 places, though 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-
Alex Ignatov <a.igna...@postgrespro.ru> 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 havi
suffer out-of-disk-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 subscript
ight away,
long before there'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 ma
e fd.
FD numbers are 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)
nt_table itself, but not 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
for Windows; there 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
early-stop 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
sults, but it's doable.)
The main benefit 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
CT 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
error messages give you that already?
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
ve had to do an initdb 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
ication "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
36
https://git.postgresql.org/gitweb/?p=postgresql.git=commitdiff=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 example.
WNED takes most of the 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
hen 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
ruct belong to the SELECT or the 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-ge
atistics collector is doing?
strace? 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
if and only if the sending
transaction 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
sible 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
Andrew Geery <andrew.ge...@gmail.com> 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
--
Se
urprises you. pg_stat_statements 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@po
Alex Ignatov <a.igna...@postgrespro.ru> 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?
ifferent
locations. When 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, t
rever you choose to 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
are 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
alls of 9.4beta1 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:/
which is what
"--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
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
ake 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 l
ster 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 session is idle and waiting for input.
cross 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
e whatever
changes you have 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.o
s are being issued to the pg_restore
session?
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
think you'll have to give a complete 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://
ent = all so that it's clear what
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 <org.postgre...@miguel.ramos.name> 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 obj
, I'm all ears.
> 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 <t...@sss.pgh.pa.us>
Branch: master [26e66184d] 2016-05-11 16:2
8 custom compiled 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
selectivity calculations, 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.
regards, tom lane
ion 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
with postgres off:
> $ 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
--
S
for 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.
ttedly,
maybe there's not a lot of usability gain 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
Alvaro Herrera <alvhe...@2ndquadrant.com> 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 w
quot;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
replacements
for 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
cted, 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@postgre
g 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-general mailing lis
FKs one at a time, rather
than all in one transaction.
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 I am just trying to explain the 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@postgr
ignment considerations
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
tion, 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 vi
of the
backend 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.
re
601 - 700 of 13723 matches
Mail list logo
