xt versions of Pg?
You'd need to make a case for it that's a lot stronger than "I wish"
before anyone would consider this.
regards, tom lane
use it opens you up to backup/restore problems
("oh, we needed that file too?"), replication problems, yadda yadda.
And what are you buying by doing it like that? Better to keep it inside
the DB instead.
regards, tom lane
, maybe it'd make
sense to grant privileges to the predefined role pg_monitor, which
exists in v10 and up. v11 has some additional predefined roles that
perhaps would fit in, too.
regards, tom lane
d be nice to have a more coherent theory about what needs to be copied
or not, and not fail on files that could simply be ignored. Up to now
we've resisted having any centrally defined knowledge of what can be
inside a PG data directory, but maybe that bullet needs to be bitten.
I'm not sure how well that will work.
Probably, the worst-case scenario would be for the database to shut
down because it thinks it's in XID wraparound trouble. But it's hard
to see how you get to that without lots of write traffic, so maybe
you can get away with this.
regards, tom lane
things that tend to not actually be very
large (which they aren't, if you've got hundreds of millions of 'em)
is an antipattern, I'm afraid. You could get away with it before we
added per-largeobject permissions, but now it's a problem for pg_dump.
regards, tom lane
that
aren't valid per your encoding, so you might as well go with bytea's
solution.
regards, tom lane
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Unless there are substantial objections, or nontrivial changes as a result
>> of this round of comments, we anticipate making the CoC official as of
>> July 1 2018.
> We seem to be a bit past that tim
at \s matches U+2006).
9.x is not, but we're not going to back-patch such a large change.
regards, tom lane
believe). In plain old C locale, nothing
beyond the standard ASCII whitespace characters will match \s. I'm not
sure how universal it is for other locales to treat characters like
U+2006 as whitespace.
regards, tom lane
anner
knows it!), finding a way to index that is clearly the right answer.
regards, tom lane
you can't use PGXS, which will deal
with a lot of these fine points for you.
regards, tom lane
ou out of trouble?
Also, if that isn't 9.6.10, I'd suggest updating --- we have fixed
some data corruption issues since 9.6.0.
regards, tom lane
ry. But it might be better to turn it into a .so in its own right.
regards, tom lane
some entries from pg_proc. Have
you had any system crashes or suchlike?
> Any suggestions, If I run pg_upgrade to 10, will these errors be corrected?
No, pg_upgrade can't magically restore data that's not there.
regards, tom lane
t's scaling), so the problem is somewhere else. Given this C
declaration, the type probably needs to be size 16, double alignment,
pass-by-reference; maybe you messed up part of that?
> HFSize *sum= new_HFSize();
What is new_HFSize?
regards, tom lane
double alignment too; IIRC the default
assumption is only "int" alignment. Intel processors will usually let you
get away with being sloppy about that, but it's still wrong (and there
*are* cases where Intel will complain too).
regards, tom lane
JOIN relation_c
ON (relation_c.id_p = relation_b.id_p))
ON (relation_a.id_c = relation_b.id_c AND relation_a.id_v = relation_b.id_v);
There's no other valid way to parenthesize it, so that's what
the parser does.
regards, tom lane
essions like
>
> and you have a column refrence on the right side.
"constant" is a bit too strong here, but it definitely can't be
"expression using another column from the same table". It has to
be an expression that will hold stable throughout a scan of the
table you wish to index.
regards, tom lane
Thomas Kellerer writes:
> Maybe I am missing something, but:
>select id, data[1], data[2]
>from the_table;
> will work just fine.
If the arrays are of varying length, unnest() might be what the OP
is looking for.
regards, tom lane
> What we need to do to PGSQL see that collation? Would you or other member
> decribe the steps, please?
Did you add the language pack after PG was already installed? If so,
you could re-initdb, or if that's inconvenient maybe you could run
pg_import_system_collations().
regards, tom lane
xt
columns and then build an array of those, or else decide to return a
two-dimensional array to represent this case. In any case, you must
use Postgres functions to construct the return value; the C++ library
is completely useless for that.
regards, tom lane
TalGloz writes:
> Datum* elements[2];
Datum, not Datum*.
regards, tom lane
he ordering rules have changed materially since 8.4;
it's intended to be by object kind, and within that by name, except
where dependencies force doing something else.
But what are you thinking constitutes the "dump order" in a parallel dump?
regards, tom lane
bout that type name and doesn't realize you've replaced it with some
new definition.
regards, tom lane
Ron writes:
> On 08/26/2018 10:24 AM, Tom Lane wrote:
>> Ron writes:
>>> In what order does the 9.6 pg_dump dump tables?
>> I don't believe the ordering rules have changed materially since 8.4;
>> it's intended to be by object kind, and within that by
Ron writes:
> On 08/26/2018 01:42 PM, Tom Lane wrote:
>> Perhaps I don't understand *your* question. What concrete problem are you
>> having?
> I want to track the progress of pg_dump so as to estimate completion time.
Well, if you don't use --jobs then you shou
se schema change you made since
the last successful dump.
regards, tom lane
Tim Clarke writes:
> On 27/08/18 15:22, Tom Lane wrote:
>> That's not supposed to happen. Can you create a test case, by any chance?
> It wasn't the cross-tab/pivot, it was this materialized view:
Hm, could I trouble you for a self-contained test case? I tried to
flesh i
TalGloz writes:
> This is very strange, even if I comment all the loops in the function and
> leave only the INSERT INTO command the insert still doesn't happen.
Maybe you're rolling back the transaction after leaving the function?
regards, tom lane
fixed recently. You should update to current (9.6.10) sooner not
later. I don't think that will cure existing corruption for you, but
it should prevent things from getting worse.
regards, tom lane
not show up.
If this is on Ubuntu, I don't understand why you're talking
about Windows.
regards, tom lane
for TABLE DATA and
BLOB dump objects ... other stuff is just embedded in the toc.dat file.
regards, tom lane
Andres Freund writes:
> On 2018-09-02 19:29:49 -0400, Tom Lane wrote:
>> If this is on Ubuntu, I don't understand why you're talking
>> about Windows.
> The OP said "Ubuntu 18.04 as Windows bash" - so I assume this is
> postgres compiled as a linu
ng and I am much more use to Linux stack
> then ... gasp Windows :-)
Hmm, so maybe you should install Ubuntu as the native O/S, and when
you need Windows, run it inside a VM?
regards, tom lane
uccessfully
argued that that end of things could use a weaker lock. I find the
reasoning rather dubious myself.
regards, tom lane
there's somebody out there who's relying on
setting the search path to allow choosing among multiple "unaccent"
dictionaries. But there are way more people whose functions are
broken due to the recent search-path-tightening changes.
regards, tom l
lateral (select perl_sub_name, end_datetime from flow_step_events_view where
sqf_id = sr.sqf_id order by 2 limit 1) fse
where sr.userid='foo';
regards, tom lane
ty in libc). We used to think that 2 extra digits beyond the
nominal precision was enough to guarantee that, but there are cases where
you need 3, so it got changed.
regards, tom lane
g what remains is low.
Also notable is that the IOS isn't giving you any advantage over a
plain indexscan, which apparently is because none of the table's
pages are marked all-visible. If the table is static then a VACUUM
would help that.
regards, tom lane
rtition bound values illegal for the domain.
What would you expect to happen then?
We might at some point work out plausible semantics for this situation,
but it hasn't been done yet.
regards, tom lane
e that this recipe does not copy "global" objects (users and
tablespaces), nor does it restore any database-level properties.
You'd need to use pg_dumpall to transfer those things automatically.
(Possibly "pg_dumpall -g" would be a good starting point here.)
regards, tom lane
mbership of the
CoC committee, as well, but that should be a separate post.
regards, tom lane
;d have to
break this down into something involving simple timestamp comparison
operators for constraint exclusion to be able to prove anything.
Might be a reasonable future extension, perhaps...
regards, tom lane
are causing
so many autovacuum cancels.
regards, tom lane
#x27;d be
valid points to worry about as to whether a CoC might be used to
stifle free speech. But every example that's been given has been
not merely off-topic but wildly so, so I don't find the discussion
to be very realistic.
regards, tom lane
ly to make newcomers to the project feel that
it's a safe space.
It's also worth reminding people that this is v1.0 of the CoC document.
We plan to revisit it in a year or so, and thereafter as needed, to
improve anything that's causing problems or not working well.
regards, tom lane
ttrelid, pa.attnum)
from
pg_attribute pa, pg_attribute ta
where
pa.attrelid = 'persistent_view'::regclass and
ta.attrelid = 'temporary_view'::regclass and
pa.attname = ta.attname
order by pa.attnum;
If you were dealing with tables, it'd also be wise to add
"pa.attnum > 0 and not pa.attisdropped", but I think neither of
those conditions can fail for views.
regards, tom lane
"Sebastian P. Luque" writes:
> Tom Lane wrote:
>> Personally, I'd probably write it something like this:
>> select pa.attnum, pa.attname, col_description(pa.attrelid, pa.attnum)
>> from pg_attribute pa, pg_attribute ta where pa.attrelid =
>> &
ill keep a snapshot as of their
start time.
As Jerry mentioned, replication slots can also act like open transactions
for this purpose, though I don't recall how much of that behavior is
present in 9.2.x.
regards, tom lane
mplaint --- but then they'd have to recuse themselves
from dealing with that complaint, so there's an incentive not to.
regards, tom lane
e short answer here is that we've been debating CoC wording
for more than two years already, and it's time to stop debating and
just get it done. We're really not going to entertain "let's rewrite
this completely" suggestions at this point.
regards, tom lane
stant without any evidence to back up the change.
Let's see some test cases, at least.
regards, tom lane
ve already wasted fighting
this tooling version skew.
What I'd try doing is building a PG release that claims to support
VS2015 (9.6 or later), using the recommended process:
https://www.postgresql.org/docs/current/static/install-windows.html
Or you could just grab a prebuilt version from our download pages.
Then point GDAL at the libpq library from that.
regards, tom lane
%ROWTYPE;
BEGIN
SELECT * FROM billnumberrange WHERE ... INTO ranger;
Your example clearly wasn't selecting all the columns, and it
wasn't clear whether you paid any attention to column ordering;
but both of those matter.
regards, tom lane
t; it will be changed and amended as needed.
The change process is spelled out explicitly in the CoC document.
I believe though that the current plan is to wait awhile (circa 1 year)
and get some experience with the current version before considering
changes.
regards, tom lane
ld appear on the website.
regards, tom lane
be a bit more liberal.)
But anyway, this looks like a mighty inefficient usage pattern at best,
and maybe a memory leak at worst. Can you create a self-contained test
case that does this?
regards, tom lane
greigwise writes:
> If I have nearly 8 GB of memory left, why am I getting out of memory errors?
Probably the postmaster is running under restrictive ulimit settings.
regards, tom lane
the idea that there's a bug involved in that; but again
the question is exactly which textually identical expressions should
get unified and why.
regards, tom lane
greigwise writes:
> Is it possible that the fact that my stack size is limited is what is
> causing my issue?
No. If you were hitting that limit you'd get a message specifically
talking about stack.
regards, tom lane
, 'e1')
on conflict on constraint kv_key_value do update set extra=excluded.extra;
INSERT 0 1
regards, tom lane
y likely, but whatever it is has to
be weird ...
regards, tom lane
it might make the other choice.
As a testing measure (don't do it in production!), you could set
enable_sort = off, which will force the planner to pick a non-Sort
plan if possible. Then you could see whether that's actually faster
or slower, and by how much.
regards, tom lane
but I don't know where to look.
regards, tom lane
state: 57014
Hmm (pokes around) ... That error context message seems to only be
possible if we were blocked waiting for some other transaction.
I theorize that you have an uncommitted transaction someplace that
has created the same table name. Cancelling it would fix things.
regards, tom lane
gt; Server.
Not there as of v11, other than the refcursor approach you already know
about. We hope to have something nicer worked out for v12. There
are a lot of compatibility issues to sort through :-(
regards, tom lane
o prevent a recurrence.
regards, tom lane
ularly seeing that this
is a three-year-old point release in a branch that had more than its share
of data corruption issues. My suggestion is first update to 9.3.latest,
then reindex.
BTW, 9.3.x will be EOL next month, so you should be thinking about getting
onto a later release branch ...
regards, tom lane
the errors you showed the *only* ones you get?
regards, tom lane
e just one symbol you had to set manually ...
regards, tom lane
olumn width limits are a bad idea left over from the days of
punched cards. The reason the limit on N is much smaller than it
could theoretically be is that column declarations with very large
N are, without exception, violations of this principle.
regards, tom lane
This says the client disconnected first. What does the problem look
like from the client side?
regards, tom lane
regular joins, it still does sequential
> scans on at least one of the tables:
I think you're also expecting the system to deduce that it can apply an
inequality on one join column to the other one. It doesn't; only equality
constraints have any sort of transitivity logic.
So you'll need to write out the BETWEEN separately for each table,
and put it below the full join, which means you won't be able to
use those nice views :-(
regards, tom lane
e effect that adding columns to the underlying table does not add
columns to the view. Which, I'm sure, is exactly what you wished would
happen ... but they say not to.
regards, tom lane
ndset have to do with sui.segment ?
regards, tom lane
27;m not
really convinced that doing it like this rather than doing the
standard conversion is a good idea. You can't manufacture precision
where there is none --- so it might be better to do the standard
conversion and then go back and fix any values you can demonstrate
are wrong.
regards, tom lane
situation surely
isn't useful to anybody. Arguably, gettext() is being pretty
unhelpful here, but I doubt we could get them to change.
Peter, any thoughts?
regards, tom lane
"Peter J. Holzer" writes:
> On 2018-10-18 10:15:40 -0400, Tom Lane wrote:
>> You could ju-jitsu the system into duplicating that behavior by casting
>> to text (which invokes float4out) and then to numeric:
> I suggest casting first to float8 and then to numeric. The
But that could be fixed easily enough.)
In the meantime, the only answer I can think of offhand is to manually
do VACUUM FREEZE on each of your MVs, and then refresh anything that
shows up with an error.
regards, tom lane
indeed doing
something like
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
and not just hard-wiring where to look.
regards, tom lane
ayaho...@ibagroup.eu writes:
> Do you have any thoughts regarding this issue?
I do not think anybody thinks this is a bug. Setting wal_sender_timeout
too small is a configuration mistake.
regards, tom lane
th the identity-value-generating behavior.
regards, tom lane
of round tuits. I have
a vague feeling that there might be some compatibility issues
in there, though.
regards, tom lane
atch the syntactic structure of the FROM clause.
For instance "FROM a,b,c" will always be done by joining a to b first
then joining to c. The code will still consider all possible ways
to do each of those joins, though you can shut off consideration of
some possibilities with parameters like enable_hashjoin.
regards, tom lane
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Two I'd particularly draw your attention to are
> Tom> join_collapse_limit and from_collapse_limit --- if you set both to
> Tom> 1, that'll effectively disable searching for a good join order,
&g
est.test (col1 int);
> ERROR: permission denied for schema mytest
> LINE 1: create table mytest.test (col1 int);
I think you're shooting yourself in the foot with those event triggers,
ie trg_create_table is switching the role to something that lacks
permissions to do the CREATE.
regards, tom lane
>
>> /tmp/mydatabase_test.log
> This should work.
Yeah, on modern PG. But I think psql didn't support combinations of
-c and -f switches until 9.6. 9.5 would simply have dropped that -c
switch.
regards, tom lane
or is common or when doing "enable trigger all" PostgreSQL
> whould show me a error or a warning?
Well, yeah, DISABLE TRIGGER ALL defeats enforcement of FK constraints.
That's why you have to be superuser to use it[1]. Perhaps disabling
only user triggers would have been the way to
Adrian Klaver writes:
> On 7/12/19 7:04 AM, Tom Lane wrote:
>> Well, yeah, DISABLE TRIGGER ALL defeats enforcement of FK constraints.
>> That's why you have to be superuser to use it[1].
> The OP is probably trying to understand why the below happens:
> alter table a
t that says about removable and nonremovable rows.
regards, tom lane
d to update individually. That's never going to be great
for performance. SQL (or at least Postgres) is incapable of
updating portions of columns efficiently.
regards, tom lane
[1] https://www.postgresql.org/docs/current/storage-toast.html
a bad thing; it's postponing work that will need to be done
eventually.
regards, tom lane
Peter Geoghegan writes:
> On Wed, Jul 17, 2019 at 9:57 AM Tom Lane wrote:
>> It looks that way, but how would a broken non-shared index have held up
>> autovacuuming in other databases? Maybe, as this one's xmin horizon
>> got further and further behind, the l
aming it on a
particular index seems a bit chancy;
(c) automatically disabling constraint indexes seems less than desirable.
regards, tom lane
looking for set_ps_display() calls if you really
want to know.
regards, tom lane
ointing to a 9.2
> binary?
For quite some time, Red Hat shipped versions of 9.2.x that were patched
to understand unix_socket_directories not unix_socket_directory. I would
be suspicious that the source server was one of those, except that the
cited path doesn't match where the Red Hat RPMs put it.
regards, tom lane
hing 9.2 to have unix_socket_directories, they should
also patch pg_upgrade in later versions to understand that.
regards, tom lane
; As you can see, 100% of time goes to same SELECT query, there is no issues
> with INSERT-part
We can't see any such thing from what you posted.
regards, tom lane
-contained test case to verify that though.
regards, tom lane
201 - 300 of 2962 matches
Mail list logo
