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
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
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
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
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
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
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
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
-
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
--
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
;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
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
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
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
;, '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
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
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
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
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
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
2}, {"labeltext":
> "Other", "labelvalue": 3}, {"labeltext": "Don''t know", "labelvalue": 4}],
> "target": {"place": "Sweden"}, "askfreq": "once", "whydesc
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.
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
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
ther shared structures that grow at runtime.
So there's room for the lock table to grow a bit beyond its nominal
capacity.
Having said that, the amount of slop involved is only enough for a
few hundred lock entries. Not sure how you're managing to get to
nearly 20000 extra entries.
Jeff Janes writes:
> On Tue, Sep 13, 2016 at 6:21 AM, Tom Lane wrote:
>> Having said that, the amount of slop involved is only enough for a
>> few hundred lock entries. Not sure how you're managing to get to
>> nearly 2 extra entries.
> The code assumes ev
successful checkpoint, that will
take quite a while, so it's a last resort ... but it ought to work.
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 and re-create
it from template1. Otherwise, pg_dumpall/initdb/reload would seem to be
called for. A cautious person might want to do the latter anyway in case
there's more problems than just this one.
regards, tom lane
--
Sent via pgsql-general mailing list (pgs
but I would not be surprised if
having lots of those is pretty destructive to the index's ability to be
selective about && searches.
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
here are some other things I could criticize here, like labeling the
function IMMUTABLE when its results depend on table contents, but
they probably aren't causing your crashes.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
th it is you're
blocking any other function in the same query from using SPI, since
you're leaving your own connection active when returning. Sooner
or later that's gonna be a problem.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@post
he second arrival would get a SPI_ERROR_CONNECT failure from
SPI_connect when there's already an open connection. For the nested-
calls case you can prevent that with SPI_push/SPI_pop around a call that
might wish to use SPI, but that fix doesn't work in a coroutine situation.
Charles Clavadetscher writes:
> Honestly I still don't understand why this happened this way.
I wonder if you have standard_conforming_strings turned off, or
did when that data was inserted. That would change the behavior
of backslashes in string literals.
rega
trace to crystal-clear application requirements. varchar(n) where
n has been plucked from the air is a good sign of bad database design.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://ww
that you skipped ANALYZE'ing the partition
parent tables in your first pass, but I'm betting on the all-visible
fractions as being the issue.
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
Postgres. So for
example anyplace you apply a concatenation operator, varchar inputs have
to be casted to text, and the result has to be casted to varchar if it's
being stored into a varchar field. I've never seen any serious attempt
to quantify how much that costs, but it'
SELECT unnest(Array[1,2,3,4,5,6,7,8,9,10]) num OFFSET 0) AS foo WHERE
random() > 0.5;
num
-
1
4
7
9
(4 rows)
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
most recent
related bugfix I can find in the 9.2 commit history was in libpq, and
it came out in 9.2.8.
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
bution.
Fix pushed to HEAD only. Thanks 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
out of WAL space. Hitting a limit
on table size per se behaves a bit more sanely, though even there you
can get into trouble --- for instance, in some situations VACUUM will
try to allocate additional disk space, making recovery harder.
regards, tom lane
--
Sent via pgsq
COPY are documented.
And probably we should strip out all but the historical options from
the list that we claim works with it.
A more aggressive answer would be to drop the old-style CREATE AGGREGATE
syntax altogether ... but seeing that we're still supporting pre-7.3 COPY
syntax, probably th
et an up-to-date version of
libpq and see if that doesn't make things better.
Note that I never heard of "Adobe Campaign" before, and have no idea what
it would take to link it against a newer libpq. You might have to get
Adobe involved, unless it goes through DBD::Pg.
eem to be taking the trouble to open the files in binary mode.
Could that lead to the reported failure? Not sure, but it seems
like at the least it could result in corrupted VM files.
Has anyone tested vismap upgrades on Windows, and made an effort
to validate that the output wasn't garbage?
y. We should rewrite these functions to just error out internally,
which will make it much easier to provide decent error reporting
indicating which call failed.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes t
dependent.
Somebody will need to trace through this on Windows and see where it's
going off the rails.
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
why
you're running *any* java application with root privileges, which is
what I think would be needed to let this happen.
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
David Rowley writes:
> On 1 October 2016 at 05:47, Tom Lane wrote:
>> Somebody will need to trace through this on Windows and see where it's
>> going off the rails.
> I tried the test case on 9.6.0 on a Windows 8.1 machine, and it works
> fine for me.
Hm, but if we a
Rich Shepard writes:
> On Fri, 30 Sep 2016, Tom Lane wrote:
>> Wrong permissions on /dev/shm, perhaps?
>Yes. I keep forgetting about this since I don't reboot this
> server/workstation often.
You ought to do some investigation and figure out what is causing
it to co
1"
> Output in psql
>
> \x4130303030303030303030303030303030303030303030303030303030303031
> is there some setting in psql output I need to take care of.
See "bytea_output" parameter.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
op that operator from the source
database, as "=>" isn't a legal operator name anymore. This appears
to be left over from a pre-9.0 version of hstore.
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
Benedikt Grundmann writes:
> On 3 October 2016 at 14:12, Tom Lane wrote:
>> You're going to need to manually drop that operator from the source
>> database, as "=>" isn't a legal operator name anymore. This appears
>> to be left over from a pre-9.
E conrelid = 'js_activity_20110101'::regclass;
and likewise for the parent 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
you
something like "16MB" in the unit column, I think.
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
ns out to be,
it might be something we choose to fix only in HEAD.
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 writes:
> Darren Lafreniere wrote:
>> We found a pgsql-hackers thread from about a year ago about optimizing
>> ORDER BY for BRIN indexes. Tom Lane suggested that he was working on it:
>> https://www.postgresql.org/message-id/11881.1443393360%40sss.pgh.pa.
;t exist.
Is there more DDL going on that you have not shown us?
regards, tom lane
[1] at least, since PG 9.2 or thereabouts.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
enabled on the server
> Is it normal to still have this error ? Adding sslmode param will not
> change anything as it is ignored for Unix domain socket communication.
That message isn't coming out of libpq; I can't find any such string
in the community git repo.
the
aggregate/windowfunction area. Possibly me :-(. Haven't found
exactly where things are going off the rails, but it's clearly
a PG bug. Thanks for the report!
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
Adrian Klaver writes:
> On 10/09/2016 08:46 AM, Tom Lane wrote:
>> Clearly a bug --- the wrong type OIDs are being passed down to
>> array_append. It should be told that it's getting called as
> For my edification, why does this work?:
On closer inspection, the error i
"Sebastian P. Luque" writes:
> Tom Lane wrote:
>> On closer inspection, the error is only in the
>> aggregate-used-as-window-function case, not plain aggregation.
> Yes, I see the same phenomenon. Could someone suggest a workaround
> until this is fixed? I&#
target some database process. You need to do something to
reduce memory pressure and/or disable memory overcommit so that that
doesn't happen.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your s
Postgres.
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
en't already expecting the
children to die, it would have reacted differently.
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
eems pretty fishy to me; I don't know what would be causing it.
[ digs in code... ] One theory is that PGSharedMemoryDetach is getting
called more than once, but I'm not sure how that would happen. Can you
characterize where this happens more precisely? What nondefault settings
hav
Andres Freund writes:
> On 2016-10-10 18:21:48 -0400, Tom Lane wrote:
>> Chris Richards writes:
>>> LOG: munmap(0x7fff8000) failed: Invalid argument
>> [ digs in code... ] One theory is that PGSharedMemoryDetach is getting
>> called more than once, but I&#x
implied CTE just
has the base name of the view; but since CTE names can't be qualified,
that's not that hard to guess. Short answer is that you don't qualify the
view's internal self-reference, even if you are using a schema name in the
CREATE.
rega
nts to log in as mailman,
and likewise mattermost needs to specify mmuser.
If it's not practical to make the client applications send non-default
user names, you'll need to rename the Postgres roles to match the
external user names.
regards, tom lane
--
Sent via
ge size,
but I've not heard that mmap() might succeed and then munmap() fail.
That seems like what's happening to you 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
execution. Use the || operator instead.
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
aterange-first
index is faster, and I'd tend to believe that over any other evidence.
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
ht as to
why the server's not running.
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
Sebastian Luque writes:
> Tom Lane wrote:
>> Are you in a position to apply patches? It's a one-line fix:
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=dca25c2562199ce1e7e26367613912a8eadbbde8
> I'd like to try this by obtaining the Debian
; parser of our own will do? Googling found no candidates.
Personally, I'd try looking in pg_depend to see if the column's default
expression has a dependency on a relation of type sequence. That avoids
all the fun of parsing the expression and turns it into a simple SQL
join problem.
Thomas Kellerer writes:
> Tom Lane schrieb am 18.10.2016 um 15:20:
>> Personally, I'd try looking in pg_depend to see if the column's default
>> expression has a dependency on a relation of type sequence. That avoids
>> all the fun of parsing the expression and tur
method, since the rows it grabs will be consecutive.
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
Simon Riggs writes:
> On 18 October 2016 at 19:34, Tom Lane wrote:
>> If you don't want to have an implicit bias towards earlier blocks,
>> I don't think that either standard tablesample method is really what
>> you want.
>>
>> The contrib/tsm_system_
://www.postgresql.org/docs/9.6/static/role-removal.html
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: Perl not found
> Why does it say, "Perl version 5.8 or later is required, but this is ."?
It's trying to extract the Perl version number from the output of
"perl -v", and evidently failing to find one. What does "perl -v"
print with that version of Perl?
Python. Looking into config.log to see what the stderr
output of this test was might be informative.
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
301 - 400 of 13966 matches
Mail list logo
