Wen Yi writes:
> When I read the makefile,I can't find the '/src/Makefile.global'
> Can someone provide a suggestion?
Makefile.global is made from Makefile.global.in by the configure script.
regards, tom lane
regards, tom lane
need to initialize the field to
happens to be bitwise zeros or something else.
People have complained about this practice off-and-on, but no one has
provided any evidence that there's a significant performance cost.
The maintenance benefits are real though.
regards, tom lane
Thorsten Glaser writes:
> On Sat, 22 Apr 2023, Tom Lane wrote:
>> The maintenance benefits are real though.
> Oh, interesting ;-) Thanks for this explanation.
> Another data point is: calloc is not correct for pointer fields,
> you have to manually assign NULL to them afterwa
ession takes 20 seconds (this has been resolved by answer from David
> Rowley)
Hmm ...
> Is it possible to use indices to create check expressions?
No.
> Why is 2. twice as long as 1.?
Good question. Could you provide a concrete test case?
regards, tom lane
ALTER TABLE ONLY
> public.iplocation
> ADD CONSTRAINT overlap EXCLUDE USING spgist (network WITH &&);
Hm, there's a fair amount of new code in SP-GIST in v11, so maybe you've
hit a memory leak in that. Can you create a self-contained test case?
regards, tom lane
e for download,
or point to some accessible dataset somewhere, that'd work.
regards, tom lane
cks on multiple
tables. That's always hazardous. It might be easier to retry the
DDL than try to guarantee no deadlock. Or break it up into separate
transactions for each table.
regards, tom lane
x_endscan to see which ones might also need their own
temp contexts. So that would surely end up being more invasive than
just adding some pfree's to spgendscan would be. Maybe in the long run
it'd be worth it, but probably not in the short run, or for back-patching.
Thoughts?
regards, tom lane
Amit Langote writes:
> On 2018/10/26 18:16, Tom Lane wrote:
>> A quick review of the other index AM endscan methods seems to indicate
>> that they all try to clean up their mess. So maybe we should just make
>> spgendscan do likewise. Alternatively, we could decide that
Amit Langote writes:
> On 2018/10/26 18:59, Tom Lane wrote:
>> After a quick look around, I think that making systable_begin/endscan
>> do this is a nonstarter; there are just too many call sites that would
>> be affected. Now, you could imagine specifying that indexes on s
Bruno Wolff III writes:
> Tom Lane wrote:
>> Hmm, in my hands this produces the same size leak (~28GB) in either v10
>> or v11. In HEAD, somebody's made it even worse (~43GB). So this is
>> certainly pretty broken, but I'm not sure why it seems worse to you
Alvaro Herrera writes:
> On 2018-Oct-26, Tom Lane wrote:
>> After a quick look around, I think that making systable_begin/endscan
>> do this is a nonstarter; there are just too many call sites that would
>> be affected. Now, you could imagine specifying that indexes on s
unts you trust. You may also need to move the log directory
out from under $PGDATA to make that work, since PG doesn't like
world-readable data directories.
regards, tom lane
Igor Korot writes:
> On Mon, Oct 29, 2018 at 1:56 PM Tom Lane wrote:
>> You can set up the log files as readable by the OS group of the server
>> (see log_file_mode), and then grant membership in that group to whichever
>> OS accounts you trust. You may also need to m
tables
> _were_ vacuumed. Why the discrepancy?
The pg_stats mechanism is designed to drop messages when under sufficient
load, so if there was a whole lot going on besides the VACUUM, maybe
that would explain it.
regards, tom lane
tack trace would be helpful, self-contained test case even better.
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
regards, tom lane
to \d output, could we see
select * from pg_trigger where tgrelid = 'ref.auto_hint'::regclass;
regards, tom lane
Karsten Hilbert writes:
> On Thu, Nov 01, 2018 at 11:43:56AM -0400, Tom Lane wrote:
>> Yeah, apparently we've passed a null OLD tuple to an RI_FKey_cascade_del
>> trigger, which surely shouldn't happen. It'd be interesting to look at
>> the set of triggers on
Karsten Hilbert writes:
> On Fri, Nov 02, 2018 at 11:56:58PM -0400, Tom Lane wrote:
>> I was feeling baffled about this, but it suddenly occurs to me that maybe
>> the bug fixed in 040a1df61/372102b81 explains this.
> So, I guess I can work around the issue by the above
>
however: could the same problem arise from an UPDATE
> statement (also on a table with an AFTER trigger), or would that be another
> bug (technical details below)?
Same bug.
regards, tom lane
#x27;s apparent VM consumption may
be shared buffers ... what have you got shared_buffers set to on the old
server? If it's more than half a GB or so, maybe reducing it would help.
regards, tom lane
.
Try knocking it down to a tenth of that and see if it makes a difference.
regards, tom lane
hint bits on the
newly loaded rows. The first access to any such row will set that bit,
whether it's a select or a VACUUM or whatever.
regards, tom lane
ur
times the size, depending on the contents. pg_dump is agnostic about this
and will just dump using the prevailing bytea_output setting, so you might
be able to get it to work by changing that setting.
regards, tom lane
Michael Nolan writes:
> On Tue, Nov 6, 2018 at 11:40 AM Tom Lane wrote:
>> That represents setting the yes-this-row-is-committed hint bits on the
>> newly loaded rows. The first access to any such row will set that bit,
>> whether it's a select or a VACUUM or whatever.
ld be really helpful.
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
regards, tom lane
anged is getting the wrong value for
the index column's typbyval, but how could that be?
regards, tom lane
7;ve got btree_gist installed?
regards, tom lane
+ 7;
Interestingly, it doesn't crash if I change the index type to btree,
which I was not expecting because the crashing code seems pretty
independent of the index type.
Haven't traced further than that yet.
regards, tom lane
s identical to the type of the source
datum for it, which is not true for any opclass making use of the
opckeytype property.
Ondřej, as a short-term workaround you could prevent the crash
by setting that index's recheck_on_update property to false.
regards, tom lane
e reloptions code. Looks like somebody forgot to list
RELOPT_KIND_GIST in RELOPT_KIND_INDEX, but is that the
fault of commit c203d6cf8 or was it busted before?
regards, tom lane
Andres Freund writes:
> On 2018-11-06 16:47:20 -0500, Tom Lane wrote:
>> Looks like somebody forgot to list
>> RELOPT_KIND_GIST in RELOPT_KIND_INDEX, but is that the
>> fault of commit c203d6cf8 or was it busted before?
> Looks new:
> + RELOPT_KIND_INDEX =
> RELO
sor gets a different
portal name. I'm too lazy to check the details right now, but at the
very least there's a way to do it by declaring the variable as "refcursor"
and assigning it a different name at each nesting depth. There might be
some more elegant solution, too.
regards, tom lane
Andrew Gierth writes:
> [ nice summary ]
Should we try to improve the docs in this area?
regards, tom lane
David writes:
> I have some experience with different versions of Postgres, but I'm just
> getting around to using pg_restore, and it's not working for me at all.
> ...
> But a matching pg_restore command does nothing.
> pg_restore -U postgres -f predata.sql -v
This command expects to read from s
ump formats (typically, you'd
use -Fc or -Fd).
The situation in which you'd want to use "pg_restore -f" is if you
want to reconstruct a plain-text SQL script from one of the non-text
dump formats, rather than just restoring directly into a database.
regards, tom lane
ecause these operations are
> optimized
>> to fetch only the required parts of the out-of-line value when it is not
> compressed. "
> So my question is how does it work, how easy would it be to implement for
> pgpointcloud?
See PG_DETOAST_DATUM_SLICE and users of that macro.
regards, tom lane
lsof on one of them to see what its current working
directory is (or on Linux, examine /proc/NN/cwd). lsof on whichever
one(s) is/are postmasters would also tell you what sockets they're
listening on.
regards, tom lane
Maybe I'm missing something, but doesn't this solve your problem
as stated?
ALTER DEFAULT PRIVILEGES IN SCHEMA myschema GRANT SELECT ON TABLES TO public;
regards, tom lane
vilege attributes, and archive TOC entries
--- it's really the per-BLOB TOC entries that are causing the issue
for you here. That model is fine as long as BLOBs are, uh, large.
If you're using them as replacements for bytea, the overhead is going
to be prohibitive.
regards, tom lane
also use for its remote transaction). Which you
didn't say, but it's hard to see how it'd fail otherwise.
regards, tom lane
r.
Yeah, it's hard to see how you could allow such a command to anybody
but a superuser.
regards, tom lane
nition to ensure it runs with a predictable path.
regards, tom lane
Merlin Moncure writes:
> On Mon, Nov 19, 2018 at 11:56 AM Tom Lane wrote:
>> The search_path in the trigger probably doesn't include public.
>> You could add a "SET search_path = whatever" clause to the trigger
>> function definition to ensure it runs with a
e setting.) I'm pretty sure
either timestamp = timestamp or timestamptz = timestamptz would be
pushable.
regards, tom lane
another 64 bits to tuple headers would be
a painful space cost, not to mention the storage compatibility issues.
regards, tom lane
=?UTF-8?B?w4Fkw6FtIE1hcmFjc2th?= writes:
> I would like to ask you whether is it possible to compile the PostgreSQL
> 9.6.5 version with VS17?
Looking at our git history, patches to make that work cleanly were
added in 9.6.6.
regards, tom lane
nsaction
The only reference I could find in the SGML docs is in the maintenance
chapter.
regards, tom lane
nning up against lock conflicts
against other activity in the DB, and that the "hang" is just waiting
for other transactions to release their table locks. Looking into
the pg_locks view could be informative.
regards, tom lane
'd written "WHERE ctx = 1::int8". Without
the cast, what you'll have is "int8 = int4", and I suspect that
btree_gist doesn't include cross-type operators in its opclasses.
regards, tom lane
hings
concurrently.
If you're feeling paranoid, you could always do
begin;
drop ... cascade;
and then look at the reported list of objects before deciding whether
to commit or roll back.
regards, tom lane
uot;integer" data type, which some do not.
Anyway, the bottom line here is that we're balancing surprise factor
for novices against twenty-plus years of backwards compatibility,
and the latter is going to win.
regards, tom lane
e, but we don't implement
that feature.
regards, tom lane
spelling of ALTER TABLE DROP COLUMN.
regards, tom lane
but short
and easy to port across versions.
regards, tom lane
ure. The general belief among pgsql-hackers is that
shoddy antivirus products tend to cause this, but I don't know details.
regards, tom lane
as needed.
Otherwise such tables will bloat, which could contribute to excessive
use of temporary-table buffers.
regards, tom lane
c where proisagg and proacl is not null;
and see what you get.
It's likely that the affected row(s) have more problems than this,
in which case deleting them altogether might be your best bet.
regards, tom lane
Thomas Carroll writes:
>On Monday, December 10, 2018, 3:45:33 PM EST, Tom Lane
> wrote:
>> I imagine you checked this already, but ... what is temp_buffers set to?
> Thanks for your reply! temp_buffers is the default 8MB, and I should have
> included that in my first
Thomas Carroll writes:
> On Monday, December 10, 2018, 5:50:22 PM EST, Tom Lane
> wrote:
>> Also, as mentioned upthread, it'd be interesting to see if there's
>> a memory context dump showing up in your server log.
> There are many memory context dumps, a
mp schema you're really using.
regards, tom lane
w old this cluster is ...
> How to REVOKE that non-existing user so pg_upgrade can proceed?
The safest way to clean it up manually would be to set the pg_proc.proacl
field for that function to NULL. If there are other grants about the
function, you could try removing the bad entry, but it would lik
;s right: t2-on-the-left has 10x more rescanning
to do per outer tuple, but it stops after scanning only 10% of the
outer relation, canceling that out.
I'm not sure whether to back-patch this. It's a pretty clear thinko,
but there's the question of whether we'd risk destabilizing
date_trunc('month', now());
date_trunc
2018-12-01 00:00:00+01
(1 row)
If you want immutability, you need to be working with timestamp-without-tz
or date input, so that timezone isn't a factor.
regards, tom lane
io_id are all highly
correlated, but the planner doesn't know that and thinks the additional
conditions will remove way more rows than they actually do.
In PG10 and later, you can probably fix that by creating
functional-dependency statistics on those pairs of columns.
regards, tom lane
database was, that'd help.
Also, was text search working for your colleague in the old installation?
regards, tom lane
starting a new session has a lot of overhead --- so you
don't want to kill a session that was just about to start doing some
useful work.
regards, tom lane
se
> basic. Thanks for reading!
Maybe you've found a bug. Can you extract a self-contained case
exhibiting this behavior? Is this 11.0 or 11.1?
regards, tom lane
iendly than "syntax error" if someone tries to use
the nonexistent feature, and (3) making provision for future enhancements.
regards, tom lane
g that we've fixed any related bugs since 9.6.10, so if this
just appeared then we've still got a problem :-(. Did anything
interesting happen since your last successful autovacuum on that table?
Database crashes, WAL-related parameter changes, that sort of thing?
regards, tom lane
->'id');
j
--
{"a": 3, "people": [{"id": 2003}, {"id": 2005}]}
(1 row)
It's not too efficient though :-(
regards, tom lane
dIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(targtuple.t_data)))
deadrows += 1;
else
+ {
+ sample_it = true;
liverows += 1;
+ }
with suitable adjustment of the adjacent comment.
Thoughts?
regards, tom lane
than what we're doing now.
> I'm going to rework the application so there is less time between the
> DELETE and the COMMIT so I will only see the problem if ANALYZE runs during
> this smaller time window.
Yeah, that's about the best you can do from the application side.
regards, tom lane
y be the creation date of the table,
not the insertion date of any particular row.
So CURRENT_DATE or one of its sibling functions is what you want
here. On the other hand, something like
INSERT INTO my_table VALUES ('today', ...);
might be perfectly sensible code.
regards, tom lane
[ please don't re-quote the entire thread when replying ]
Thomas Carroll writes:
> On Monday, December 10, 2018, 7:45:07 PM EST, Tom Lane
> wrote:
>> You said you'd been able to reproduce this problem outside production.
>> Any chance you could boil that
e of that.
So I'm a bit inclined to accept this behavior change and adjust
the documentation to say that OLD/NEW are "null" rather than
"unassigned" when not relevant.
Thoughts?
regards, tom lane
.4). I'm guessing that we're
doing the ALTER steps in the wrong order, but haven't looked closer than
that.
Interestingly, in v11 and HEAD it works if you use a constant default,
suggesting that the fast-default feature is at least adjacent to the
problem.
regards, tom lane
regards, tom lane
lot more like a
table than it is like a view, so we don't treat it the same. I think
if you compare the text for the CREATE VIEW and CREATE MATVIEW man pages,
you'll agree that a merged version would be pretty confusing. All the
options are different.
Admittedly, this is all judgment calls
rong here",
and a report of a cascaded drop is not that.
regards, tom lane
| 11 | 10 | i
> | -1 | az | az | 153.88.34
That's an ICU collation, so you're out of luck: there is no ICU
support in 9.6.
regards, tom lane
--- possibly for security reasons. Are you going
to promise immediate updates anytime glibc gets patched, across all
the platforms you're proposing to support this on?
regards, tom lane
external resources, so
we might find there are some bugs to fix there.)
Take a look at
src/include/utils/expandeddatum.h
src/backend/utils/adt/expandeddatum.c
src/backend/utils/adt/array_expanded.c
src/backend/utils/adt/expandedrecord.c
regards, tom lane
resentation independent of server
endianness and alignment rules.
The point of the comment you're looking at is that the "flat" varlena
representation that you have to translate to/from is the same as what
will be on-disk if the datum gets stored someplace.
regards, tom lane
ot try
to give it one (mainly because of fear of cross-version compatibility
issues).
regards, tom lane
ibly worth looking at. See
src/include/utils/expandeddatum.h
src/backend/utils/adt/expandeddatum.c
for the basic APIs and
src/backend/utils/adt/array_expanded.c
src/backend/utils/adt/expandedrecord.c
for two examples of use.
regards, tom lane
at did the calculation client-side had side effects you weren't
expecting --- what uses that value client-side, exactly?
regards, tom lane
ble to prevent that error.) So you might as well
just "rm -rf ./10", not only its biggest subdirectory.
regards, tom lane
the pages are all-visible (see
pg_class.relallvisible).
regards, tom lane
today
might have their bacon saved tomorrow.
regards, tom lane
always put out a shell CREATE TYPE first.
By any chance, if you attempt a "pg_dump -s" from the problematic database,
does it emit any warnings (about dependency loops, perhaps)?
regards, tom lane
, table_func.
Hmph. Would you be willing to send me a schema-only dump (off-list!)
of the problematic database? The best format would be an "-Fc -s"
pg_dump output, because that would show what pg_dump thinks the
dependencies are. Be sure you make it with the newer pg_dump.
this example is looking at
a type "public.widget", but of course what you want to look at is
sde.st_envelope. If you don't see links to st_envelope_in and
st_envelope_out in both queries, then we've found the problem.
Fixing it is a bit trickier, but in principle you could manually
insert the missing row(s) once you know what they need to be.
regards, tom lane
ues (
'pg_proc'::regclass,
'sde.st_envelope_in(cstring)'::regprocedure,
0,
'pg_type'::regclass,
'sde.st_envelope'::regtype,
0,
'n');
insert into pg_depend (classid, objid, objsubid,
refclassid, refobjid, refobjsubid, deptype)
values (
'pg_proc'::regclass,
'sde.st_envelope_out(sde.st_envelope)'::regprocedure,
0,
'pg_type'::regclass,
'sde.st_envelope'::regtype,
0,
'n');
I suppose the evidence about what happened to those rows is long gone,
so there's not much point in doing anything but patching things up to
the point where you can run pg_upgrade.
regards, tom lane
of the core files, that'd
be pretty helpful too.
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
We might need to ask for a self-contained test case, if the stack
trace doesn't make it clear what's failing.
regards, tom lane
ate, will free up some internal resources for other connections.
> Is this accurate?
No.
regards, tom lane
re you on the latest minor release of whichever
release series you're using? (And which one is that?) If it is latest,
please see if you can make a self-contained test case that triggers this.
regards, tom lane
#x27;d likely be better off to join pg_class and pg_attribute to
pg_description, rather than working with proxies for them.
https://www.postgresql.org/docs/current/catalogs.html
regards, tom lane
. If your table is mostly-not-null, that would fit the
observation that it only crashes on a few rows.
Can you try REL_11_STABLE branch tip and see if it works for you?
regards, tom lane
1501 - 1600 of 2962 matches
Mail list logo
