le for an IOS. As a
small consolation prize, it might let you get an IOS on cases where you
*do* need x as 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
pg_dump -t '*' ...
although this will result in *all* non-schema-named objects being
excluded, I believe, which might be 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
Andreas Joseph Krogh writes:
> What I'm looking for is "inverse -b" in an otherwise complete dump. Any plans
> to add that?
[ shrug... ] Nobody ever asked for it before.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@po
27;t try to dump system catalogs
as tables, even if the switches seem to ask it to.
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
7;s safe or not. (It does, on the other hand, know very well that
SQL equality operators don't necessarily guarantee bitwise identity.)
So I'd suggest just modifying your queries to write out both constraints
explicitly.
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
he extension
will properly look like it's 1.1 after pg_upgrade'ing.
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
ftware
development work.
Here's what I have bookmarked about turning it off:
http://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/
If turning off SIP doesn't fix things, we'll need to look closer.
rega
Chris Ruprecht writes:
> no such luck (no easy fix). I turned SIP off and rebuilt PG 9.5.1, copied
> libpq.5.8.dylib to /usr/lib, bent the two sym links to the new library but
> I'm still getting "Bus error: 10". You owe somebody a nickel, Tom ;).
Oh well.
Personally
ly there is some documentation included with the homebrew PG
package that explains that. But if not, perhaps a look into the
launch-agent script mentioned above would tell you. Look for something
like a -l argument to pg_ctl, or a redirection of stderr into a file.
regards, to
Hello:
With JDBC, how can I tell which row is for which grouping sets or rollup
using result sets
Thanks
(a,b) or (c,d) group? All rows
> will contain (a,b,c,d) but (a,b) will be NULL for the (c,d) grouping
> sets, and vice-versa.
>
> Jim
>
> On 03/13/2016 09:45 PM, Tom Smith wrote:
> > Hello:
> >
> > With JDBC, how can I tell which row is for which groupi
>> On 03/13/2016 10:07 PM, Tom Smith wrote:
>>> It would help if the resultset has some param to mark which is which
>>> with the grouping sets index.
I think you're looking for the GROUPING() function. See
http://www.postgresql.org/docs/9.5/st
exactly what I am looking for. very nice. Thx
On Sun, Mar 13, 2016 at 10:44 PM, Tom Lane wrote:
> >> On 03/13/2016 10:07 PM, Tom Smith wrote:
> >>> It would help if the resultset has some param to mark which is which
> >>> with the grouping sets index.
&
it masks any normal table of the same name
(unless you use a schema-qualified reference to the normal 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
David Steele writes:
> On 3/17/16 7:00 PM, Tom Lane wrote:
>> The message I saw was post-1-March. If it was in fact submitted in
>> time for 2016-03, then we owe it a review.
> I meant to add the CF record and forgot:
> https://commitfest.postgresql.org/9/480
> It
Michael Paquier writes:
> On Fri, Mar 18, 2016 at 9:00 AM, Tom Lane wrote:
>> Hmm ... I can't find the string "insufficient data in the message"
>> anywhere in the Postgres sources. And not "pgsql_pexec" either.
>> 2016-03-16 17:35:07 BRT ERRO:
ect of some previous 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
ing: No such file or directory
Offhand I do not believe that any part of the core PG code would attempt
to access such a file. Maybe you've got some extensions in there that
would do so?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@post
c" either.
So this must be coming from some client-side code you're using (not
libpq). It's unlikely we can help you much here; you need to chat with
the author of the client-side library that's emitting that error.
regards, tom lane
--
Sent via pgsql-gene
post-1-March. If it was in fact submitted in
time for 2016-03, then we owe it a review.
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
need to repeat the magic constant 50 in several
places. Also, I think the patch makes do_watch return the wrong result
code for the (typical) case where we exit because of query cancel not
PSQLexecWatch failure.
So on the whole, I'd do it as attached.
regards, tom lane
y
My Title (5 s) Mon Mar 21 13:39:25 2016
repeat
--
xyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzy
(1 row)
But I don't care enough to veto it.
Anyone else have an o
than setting it manually in red hat family
> systems?
You could make your own symlink, though I'm unsure whether it'd survive
tzdata package updates.
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
ere available in 9.3.)
Worthy of note here is that the max pending list size is governed by
work_mem, so a large work_mem can make this effect worse. (We got
smart and made it an independent setting, but not till 9.5.)
regards, tom lane
--
Sent via pgsql-general mailing
> when the last one ran and how often it is supposed to run is useful info to
> have at ones fingertips.
That's not unreasonable. I just want it to look less weirdly different
between the two cases.
regards, tom lane
--
Sent via pgsql-general mailing list (
Alvaro Herrera writes:
> (I'll also use this opportunity to complain again about not being able
> to use floating point sleep time.)
That's not unreasonable either, though it seems like material for a
separate patch.
regards, tom lane
--
Sent via pgsql
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 G. Johnston" writes:
> On Monday, March 21, 2016, Tom Lane wrote:
>> What about just discarding the old format entirely, and printing one of
>> these two things:
>>
>> Timestamp (every Ns)
>>
>> User Given Title Timestamp (every Ns)
>
already found one good way: if it doesn't have
a pg_proc entry then it's a special case of some sort or other.
Have you considered only quoting the function name if it actually
needs it, ie, contains special characters?
regards, tom lane
--
Sent via pgsql-general
licit casts explicitly to ensure
that the expression is parsed the same way next time. It might be
overly conservative to do so, but we've found that erring in this
direction tends to avoid breakage when the result is loaded into another
server version; it's a bit like the intentional overpare
"David G. Johnston" writes:
> On Tue, Mar 29, 2016 at 2:45 PM, Tom Lane wrote:
>> It's not really different. What you're seeing is pg_dump (or actually
>> ruleutils.c) choosing to dump some implicit casts explicitly to ensure
>> that the expression is
--- but that's not the same as telling
the remote planner to prefer a fast-start plan.
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
"p_a_check" CHECK (a::text = ANY (ARRAY['a'::text, 'b'::text, 'c'::text]))
I wonder why you don't get an array of text constants in the IN 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
ex entry.
Concerns like this are exactly why there is no ALTER TYPE DELETE VALUE,
and probably never will be. If you need a non-fixed set of key values,
you're much better off using a foreign key instead of an enum type.
regards, tom lane
--
Sent via pgsql-ge
cure. So my guess is that psql is trying to configure OpenSSL with some
inadequately-secure settings. Not sure why it'd be different from the
server though. Are you sure psql and the libpq it's using are same
version as the apparently-working server?
regards
s
determined by the code in the opclass support functions (primarily,
what the "consistent" function knows how to do). You'd have to go
fiddle with that C code before you could add a new operator to the
opclass.
regards, tom lane
--
Sent via pgsql-g
"Feld, Michael (IMS)" writes:
> Thanks for the assist Tom. That worked for us. Noticing a different
> issue following the pg_upgrade. If we take a pg_dump of a database on
> this upgraded instance with the hstore extension and try to pg_restore
> it back up to the sa
Alex Ignatov writes:
> My question is: is there any option(s) to log non-default
> postgresql.conf values to log file?
No, but you can easily find all the non-default settings by querying
the pg_settings view.
regards, tom lane
--
Sent via pgsql-general mailin
onfiguration file settings, so I'm not buying the "historical info"
angle at all.)
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
explicitly-represented state
stack.
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 report.
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
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 produce a session ID.
I think we should just leave things as they are; people for whom
timestamp + PID is good enough as a session ID already have a solution,
and we should not mislead those for whom it isn't.
regards, tom lane
--
Sent via pgsql-general mailing list
uld look like a single hstore literal to the parser, and be
processed much more quickly.
If you insist on emitting SQL statements that have operators nested
to such depths, then yes you'll need to increase max_stack_depth to
whatever it takes to allow it.
regards, tom lane
re". It's quite a different concept
from the => notation inside an hstore literal. That is:
'foo'::text => 'bar'::text
is not like
'"foo" => "bar"'::hstore
even though they have the same end result.
with time-dependent behavior. As an example, you might
accidentally write code that expects two successive transactions to
see identical values of now(), and such a testbed wouldn't detect
the problem.
regards, tom lane
--
Sent via pgsql-general mailin
7;;
SET
regression=# select timeofday();
timeofday
--
Sun Apr 17 18:01:58.293623 2016 +120
(1 row)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
"Feld, Michael (IMS)" writes:
> Thanks for the reply Tom. template1 is definitely empty and does not contain
> any hstore objects. I did a little debugging and placed the below SQL before
> and after the hstore creation in the file produced by the pg_dump and
> determin
it
with "localtimestamp" (no parens) instead of "now()" to see how
it performs with a non-tz timestamp.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgr
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
ially not in your originally posted case where the
up-conversion happens on the variable not the pseudo-constant.
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
FWIW, the Jargon File (a/k/a Hackers Dictionary) says that "foo" can be
traced back further than "fubar", making the OP's claim rather backwards.
In any case, it's an old enough term that nobody is going to give it up
on such grounds.
http://www.catb.org/jargon/html/F/
t's marked STABLE or IMMUTABLE will see the same snapshot
as the calling query, but a function that's VOLATILE will take a new
snapshot for each query it contains.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
ure is that the auto_explain build is seeing a different value for
PG_USE_INLINE than the main server build did. So probably your include
path is picking up a pg_config.h that does not match the postgres
executable the link is happening against.
regards, tom lane
--
"abi" BYTEA, "anu" NUMERIC, "ate" TEXT,
> "ati" TIMESTAMP, UNIQUE ( "abo", "abi", "anu", "ate", "ati" ) );
> COMMIT;
> INSERT INTO "V6" ( "abo", "abi", "anu", &quo
writes:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> Define "executes". You could shove those lines in via the wire protocol,
>> sure, but SPI won't take them.
> Now you really have me puzzled. What I provided is an extract from the log
> of generated SQ
ation situations, and then you realize that the required semantics
are far from clear. In practice, audit logs (which is a class of feature
that we are working on) are a far better solution.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@p
e attribute value' = ANY (current_attributes()))
It seems like you're going out of your way to complicate matters.
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
Karl Czajkowski writes:
> On Apr 20, Tom Lane modulated:
>> Just out of curiosity, why are you doing it like that, and not simply
>> USING ('example attribute value' = ANY (current_attributes()))
>> It seems like you're going out of your way to complicat
whether that worked and kept working across releases.
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
ant the setting
to be local to this function. SET LOCAL/set_config(true) inside an
exception block might work --- and you may well want an exception block
anyway, to trap bad timezone names. Or you could explicitly save and
restore the previous setting, which is more code but might be faster
than a
omething similar.
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
eviation
and '.' being the DST zone abbreviation.
If you wanted to restrict input to be the Olson-style zone names,
you could do some kind of precheck, maybe insist on only letters/
slashes/underscores.
regards, tom lane
--
Sent via pgsql-general mailing list
now it should look through such a node. That's a bug. Will fix 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
is to restart postgres service.
Or maybe the exit(3) is in an extension that is preloaded into all
processes via shared_preload_libraries or similar?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subs
oncern about whether you can crash
the system with 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 use them on a
production database.
I'm not sure what else we should do, short of writing "HERE BE DRAGONS"
set in blackletter type.
(Having said that, we could change "This is used by initdb." to "This
is meant only for use by initdb". But I don't kno
dards compliant!" going for it. So I doubt we'd accept such a patch
even if someone managed to create 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
#x27;t particularly approve of because it piled
another hack on top of that mess without doing a thing to make it cleaner.
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
queries that are running against the master or
> the standby, and the delay only subsides when the vacuum completes.
What PG version might this be?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your sub
JSONB implementation, both common use
cases
(one is global doc indexing, the other is fast retrieval of individual
values)
would work out and make postgresql unbeatable.
On Tue, Jan 19, 2016 at 8:51 PM, Bruce Momjian wrote:
> On Mon, Jan 11, 2016 at 09:01:03PM -0500, Tom Smith wrote
in the storage,
all keys starting with "a" is in first segment, etc.
On Sun, May 1, 2016 at 4:14 PM, Oleg Bartunov wrote:
>
>
> On Sun, May 1, 2016 at 6:46 AM, Tom Smith
> wrote:
>
>> Hello:
>>
>> I'd like to bring this JSONB performance issue a
ply cannot truncate the file while other queries are scanning 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
text?
Any mismatch of typmod will result in the merged column being considered
to have no typmod. There is no provision for identifying a "common
superset" typmod. It would have to be some type-specific API, since the
encoding of typmod is type-specific; and we don't have one.
an over-aggressive packet filter.
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 false, probably there isn't
anything in pg_locks. Still, it'd be better to do
"select * from pg_stat_activity where pid = 3990" and be sure.
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
pe
with multiple challenges, which seems like a large assumption.)
I don't have much of a feeling for how hard it would be to do in the
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
Robert Anderson writes:
> Only one line returned:
> postgres=# select * from pg_stat_activity where pid=3990;
Aaah, sorry, that was a brain fade. I meant to ask about rows in
pg_locks with that pid.
regards, tom lane
--
Sent via pgsql-general mailing list
"D'Arcy J.M. Cain" writes:
> On Mon, 09 May 2016 17:12:22 -0400
> Tom Lane wrote:
>> If the same user id + database combinations might be valid in both
>> cases (from both PHP and manual connections) I think your only other
>> option for distinguishing w
t specified by signal(7).
A bit of googling suggests that at least one such case used to exist
in btrfs but has been fixed:
http://linux-btrfs.vger.kernel.narkive.com/CbodH9VP/patch-btrfs-don-t-return-eintr
I wonder what kernel version the OP was using.
regards, tom lane
27;d say the problem is at the end: elephant trunks don't curve that
direction. Instead of
> | v | | v |
> |\__/|
maybe
> | v | | v |
> ||__||
or even
> | v | | v |
> | |/\
Hello:
Is there a plan for 9.7 to enable using the two aggregate function
as non-window function? i.e. enabling getting the first/last row
in single sql without using window features.
There is actually a C-extension for first()/last().
I am wondering if 9.7 would make them built-in function
are the first / last in your set
> based on whatever column you order on.
> On May 18, 2016 8:47 PM, "Tom Smith" wrote:
>
>> Hello:
>>
>> Is there a plan for 9.7 to enable using the two aggregate function
>> as non-window function? i.e. enabling
It would really save all the troubles for many people if postgresql has a
built-in first/last function along with sum/avg.
There is already a C extension and a wiki sample and implemented for
window function.
I am curious why these two functions were not added along their window
implementation
e:
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
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 than it fixes, considering the
evident rarity of the problem. The race condition hazard that the recv()
is trying to prevent is definitely real: we used to not have that, and
we got bug reports, cf
http://www.postgresql.org/message-id/flat/20030915070801.gd23...@opencloud.com
"David G. Johnston" writes:
> On Thu, May 19, 2016 at 3:32 PM, Tom Lane wrote:
>> I do not recall anyone ever reporting something similar --- and that code
>> has been like that for a long time.
> âI'd take Tom's word over mine :)â
Well, my memory is
prepared
statements. I'm a bit surprised that you could have gotten up to 12GB
worth of prepared statements in an application that sends DISCARD ALL
periodically.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
nix.com/man-page/opensolaris/3c/atomic_cas/
http://docs.oracle.com/cd/E23824_01/html/821-1465/atomic-cas-3c.html
I see that the first of those mentions it's for SunOS 5.11 whereas your
machine says it's 5.10 ... is it possible the functions were new in 5.11?
Alex Ignatov writes:
> Why we have no warnings or errors about that we have no such grant
> after first revoke?
Yes, that's intentional. There's no warning about granting twice in
a row, either.
regards, tom lane
--
Sent via pgsql-general mai
tack is being unwound.
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
Venkata Balaji N writes:
> On Sat, May 21, 2016 at 1:04 AM, Tom Lane wrote:
>> http://www.unix.com/man-page/opensolaris/3c/atomic_cas/
>> http://docs.oracle.com/cd/E23824_01/html/821-1465/atomic-cas-3c.html
>>
>> I see that the first of those mentions it's for Su
er transaction control
command; it should give you back a SPI_ERROR_TRANSACTION result code
instead. Maybe you're not checking for failure results and expecting
the command to have done something?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-g
eck?
Assuming that the application's already been optimized for pre-9.0
Postgres, turning off enable_material might not be a disastrous long
term solution for it, though certainly it'd be better if you can move
away from that eventually.
regards, tom lane
--
complaints you'd
get during a restore.
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
riginal *definitely* matter, because by default
AND binds more tightly than OR. The larger number of rows in the second
query are perfectly plausible given the parenthesis-omission.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
fire immediately before a particular row is operated on, while
row-level AFTER triggers fire at the end of the statement (but before
any statement-level AFTER triggers). ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.
d expending
lots of cycles on such cases. I'm not sure offhand whether there would
be implications in the planner, or what it would take to fix them if so.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to yo
it's not very surprising that reducing that would tend to bias the
planner away from using parallel plans. See parallel_setup_cost and
parallel_tuple_cost.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
hubert depesz lubaczewski writes:
> Does that help us in any way?
Not terribly. That confirms that the processes are contending for a
spinlock, but we can't tell which one. Can you collect a few stack traces
from those processes?
regards, tom lane
--
Sent v
l reproduce it on
current 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
801 - 900 of 14353 matches
Mail list logo
