tems$inv_lines_rt composite type, that type
is what determines the column names.
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
d, for
example. (I'd bet that adding oracle_fdw to shared_preload_libraries
would fail badly, though perhaps not with this exact error message.)
So I'd call this an oracle_fdw bug. It needs to postpone what it's
doing here to the first normal FDW function call in a session.
,
declare myarray rowtypename[];
...
select array(select row(col1, ...)::rowtypename from ...) into myarray;
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postg
..
Hm, so that's another angle David didn't report on: is it possible that
his workload could have resulted in a very large volume of incomplete
in-progress log messages?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.o
Andres Freund writes:
> On 2017-11-16 21:39:49 -0500, Tom Lane wrote:
>> What might be worth thinking about is allowing the syslogger process to
>> inherit the postmaster's OOM-kill-proofness setting, instead of dropping
>> down to the same vulnerability as the postmast
Andres Freund writes:
> On 2017-11-06 15:35:03 -0500, Tom Lane wrote:
>> David Pacheco writes:
>>> I ran into what appears to be a deadlock in the logging subsystem. It
>>> looks like what happened was that the syslogger process exited because it
>>>
iscussed at
https://www.postgresql.org/message-id/flat/20171110185747.31519.28038%40wrigleys.postgresql.org
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
erent results.
Stephen, you put some filtering logic in the wrong place in pg_dump.
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;t want to change it, you could try
select reset_val from pg_settings where name = 'TimeZone';
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
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
ant to just raise the timeout, I could get behind a more
thorough rethinking of the behavior 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
our first.
It has only one SRF in the SELECT list, so there's not much doubt
about what ought to 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
g need to change that default,
but if you have a surrounding script that is going to take adverse action
after a timeout then you need to use a larger value ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscr
ut.
Agreed, but I think Peter has a point: why is there a timeout at all,
let alone one as short as 30 seconds? Since systemd doesn't serialize
service starts unnecessarily, there seems little value in giving up
quickly. And we know that cases such as crash recovery may take more
than that.
province of the typecast docs to explain
the weirdnesses of index 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
> http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main
> I was assuming someone in the Postgres project was involved in
> packaging it. Do you know who I should reach out to in that case?
Christoph's probably a good place to start.
regards, tom lane
--
Sen
ted on signal [SIGTERM]
... pg_ctl itself wouldn't decide to forcibly shut down the server
if the timeout expired. It merely stops waiting and tells you so.
It seems like this must represent misdesign of whatever start script
you're using. I think you need to complain to the Debian packager
x27;s a postmaster-wide
setting; there is not a provision for letting it be set per-user.
Since the SSL handshake necessarily occurs before we find out which
user is trying to connect, it'd be hard to do differently.
regards, tom lane
--
Sent via pgsql-general
ou is that the query is not testing
packettime, it's testing packettime::float8, because date_part() returns
float8. You could cast the result of date_part() to bigint, or whatever
type the packettime column actually is, so that the comparison is to
the unadorned variable.
ve side
> effects to that?
Well, it's imprecise. Most people don't like that when it comes to
monetary amounts.
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 key. relfilenode isn't guaranteed unique across directories.
The fork number can matter, too.
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 timeout'
in the existing PG sources (and I sure hope no committer would have
thought that such an ambiguous message text was satisfactory).
So I think your error is coming from client-side or third-party code.
What other moving parts have you got in there?
regards, to
when the process
> exited.)
Could we see the exact log message(s) involved? It's pretty hard to
believe that the logger would have consumed much memory.
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
ave to guess about the latter: the pg_settings view will tell
you exactly where the active value came from. See the source, sourcefile,
sourceline columns.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subsc
hink about the confusion
factor of having different naming styles in different places.
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
example doesn't show
> any. Or maybe you have event triggers.
I can reproduce the example if I "\set ON_ERROR_ROLLBACK on" in psql.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subsc
ocket servers, NUMA effects across sockets can be a big
headache too.
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 and see where I am at then.
Well, that's pretty interesting in itself. Any chance of attaching to one
of those unkillable backends with gdb and getting a stack trace?
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
regards, to
;tab_id_seq" does not exist
> LINE 1: ...OLUMN table_id SET DEFAULT nextval('||quote_ident(tab_id_seq...
You want quote_literal, not quote_ident, because you're trying to produce
a single-quoted literal.
regards, tom lane
--
Sent via pgsql-general m
nner having trouble trying to determine the
extreme values of an indexed column, in cases where there are a lot of
uncommitted or recently-dead entries at the end of the index --- it does
a lot of work trying to verify the commit status of each entry in turn.
So I wonder if that might apply.
;t help you more than 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
nd this see
https://www.postgresql.org/message-id/flat/A737B7A37273E048B164557ADEF4A58B539300BD%40ntex2010a.host.magwien.gv.at
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
ne deletion of the system
catalog entries for the toast table as well.
I'm not likely to work on this idea myself in the near future,
but if anyone else is feeling motivated to attack the problem,
have at it ...
regards, tom lane
--
Sent via pgsql-general mailing list
o long and has only been reported
a couple of times is the main reason why I'm loath to take a brute
force duplicate-the-data approach to fixing it. Such a fix would
penalize many more people than it would help.
regards, tom lane
--
Sent via pgsql-general mailing list
fix it at some point, but the
sticking point is how to cover this corner case without causing a
performance drop for normal cases. In the meantime, maybe you could
make the temp tables be ON COMMIT DROP instead of dropping them
explicitly mid-transaction.
regards, tom lane
t; down. It seems that walsender process was preventing the shutdown of the
> master database - until timeout was reached, a behavior we didn't experience
> before.
9.6.what?
There were several possibly-relevant bug fixes in 9.6.3 and 9.6.4,
notably this one:
Author: Tom Lane
Bran
de from the difficulty of documenting it clearly,
that seems like a great recipe for security hazards.
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 multi-column
> syntax if you're only updating a single column. Was this intentional?
You still can, but you have to write ROW() explicitly. This conforms
to the standard, which our old behavior didn't.
It was probably an oversight not to list this change as a compatibility
i
; if it did regenerate the problem.
It's possible you could duplicate the failure with synthetic data
generated by a not-very-long script. That would beat uploading
a large data file, not to mention possibly needing to sanitize
your data.
regards, tom lane
--
Sent
mediately see anything broken about this definition,
so it seems like it should've worked.
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
only matters if
you're running multiple postmasters). Otherwise it's better to leave
as much as you can to postgresql.conf.
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 inlining has happened.)
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
umn of a composite type, you probably don't need all
that notation anyway --- seems like array[data_comp::my_type] or
array[data_comp]::my_type[] 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
27;c')::mytype,row('d','e','f')::mytype];
INSERT 0 1
or just cast the whole ARRAY[] construct:
regression=# insert into t_array select
array[row('a','b','c'),row('d','e','f')]::mytype[];
INSERT 0 1
alt
es where you really need to do this should be the minority,
I'd think, otherwise you're talking about enough SQL behavioral change
that your users will probably be unhappy with you.)
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
rocess) or is something else unusual?
I believe the configure script *does* pay attention to environment
variables, particularly CPPFLAGS and CFLAGS. Most likely you had
version-specific values in those when you ran configure, and they
got absorbed into src/Makefile.global.
re
I wrote:
> Or maybe what we should do is to avoid @> in favor of using
> ('d' = any(stxkind))
Pushed that way.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http:/
Justin Pryzby writes:
> On Sun, Oct 22, 2017 at 02:36:12PM -0400, Tom Lane wrote:
>> ... Possibly we could use
>> (stxkind @> '{d}'::pg_catalog."char"[])
>> That works for me without parray_gin installed, but I wonder whether
>> it fails du
for me without parray_gin installed, but I wonder whether
it fails due to ambiguity if you do have parray_gin installed. In
principle this'd still match the text[] @> text[] operator, and I'm
not sure whether we have an ambiguity resolution rule that would
prefer one over the
a factor of 100 at the scan level is never a good start for a
join plan. Turn on use_remote_estimate (assuming these are postgres_fdw
tables). Also try explicitly ANALYZE'ing the foreign tables. I do not
believe auto-analyze will touch foreign tables ...
regards,
ecifically, you can assume it's the "extension" subdirectory of
whatever SHAREDIR is. "pg_config --sharedir" will tell you that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to you
forever)
every little special-purpose function somebody might want.
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 Thu, Oct 19, 2017 at 12:14 PM, Tom Lane wrote:
>> FROM products,
>> (values ('red widget'::text)) consts(target)
>> WHERE similarity(target, item_name) > 0.25
>> ORDER BY target <<-> item_name
>>
_name <<-> target
, target <<-> item_name
FROM products,
(values ('red widget'::text)) consts(target)
WHERE similarity(target, item_name) > 0.25
ORDER BY target <<-> item_name
PG 9.5 and up will flatten out cases like this to be exactly what you
wrote out longhand.
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 instead push the password into the PGPASSWORD
> environment variable, avoiding creating .pgpass in any form?
On many platforms, it's possible for other users to see the environment
variables of a process. So PGPASSWORD is really quite insecure.
re
le we can't avoid).
I cannot get excited about that proposed use-case, though. How is a pipe
any more secure than a plain file with the same permissions?
My thought is that you shouldn't be depending on passwords at all, but
on SSL credentials or Kerberos auth, both of which libpq suppor
such a workload-dependent thing that there's no general answer.
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
pt the connection.
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
ate query is very careful to stay in an id range. [1]
> * I do have some exotic indexes [2]. gist, gin, postgis, fillfactor...
I'd bet on the last one, especially since you found that the problem
was a page-level lock. Did you look to see which relation the page
lock was in?
hich rows
the update depends on, or perhaps some other corner case. We'd need
more info about the schema and the Postgres version to tell for sure.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
x27; to '1.000' requires a change
in the actually-stored value.
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
oesn't seem like enough to cause any obvious problem from a mere
O(N^2) behavior.
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
re it's correct. "Doesn't get into
an infinite loop" is not a sufficiently high bar.
And I'm still wondering exactly what Christophe actually saw ...
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:
> Tom Lane wrote:
>> Hmm, I tried to reproduce this and could not. I experimented with
>> various permutations of this:
> This problem is probably related to commit 9b013dc238c, which AFAICS is
> only in pg10, not 9.5.
You're right, I was test
Peter Geoghegan writes:
> Just a guess, but do you disable autovacuum on your dev machine? (I know I
> do.)
Nope.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgres
was the standby process consuming anywhere
near as much CPU as the master's backend.
What am I missing to reproduce the 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
riginally, but they allow
it as of SQL:2008 or thereabouts. It might be interesting to see if
the spec says anything concrete about the semantics of that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subsc
Christophe Pettus writes:
>> On Oct 9, 2017, at 13:26, Tom Lane wrote:
>> My bet is that the source server did something that's provoking O(N^2)
>> behavior in the standby server's lock management. It's hard to say
>> exactly what, but I'm wonde
Christophe Pettus writes:
>> On Oct 9, 2017, at 13:01, Tom Lane wrote:
>> Is that number changing at all?
> Increasing:
> AccessExclusiveLock | 8810
Oh, that's really interesting. So it's not *just* releasing locks but
also acquiring them, which says that it is
r N in
the low thousands it's hard to see that loop taking so long that
you'd think things were stuck.
> # select mode, count(*) from pg_locks where pid=5882 group by mode;
> AccessExclusiveLock | 7133
Is that number changing at all?
regards, tom lane
; Suggestions on further diagnosis?
Attach to startup process with gdb, and get a stack trace?
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
ins to the view to be optimized, you don't
want an ORDER BY in 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
being able to simplify "a IN somelist AND
a IN someotherlist". If we wanted to do that, making the
"lists" be treatable as eclass members would be a good
place to start, because that would naturally result in
intersect-able lists ending up in the same eclass.
any principles of
programming language syntax design that emerged later than the COBOL
era. Their capacity to invent new and non-orthogonal syntax for every
new feature seems boundless.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
ilding the core code first.
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
wn
failure modes. Anyway nobody's tried it yet.
You can find more discussion of this problem in the -hackers archives.
As for workarounds, the only short-term fix I can suggest is to use
EXECUTE for this query in your function, thus preventing caching of
a plan for it.
re
;,--enable-new-dtags
(That's what I see when building with a stock Linux Perl configuration and
rpath enabled.) If there's no such switch, or if it doesn't point to
where the libperl.so that you want to use is, then there's your problem.
regards, tom lan
it? Also, 9.3.what exactly?
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 the possibilities of needing to convert a exception into a branch
> instead of allowing it to be fatal.
Yeah, it's about the overhead of setting up and ending a subtransaction.
That's a fairly expensive mechanism, but we don't have anything cheaper
that is able to recover from
inlined, loop-unrolled
memcpy().
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
four different Cyrillic-specific character sets
available already:
https://www.postgresql.org/docs/current/static/multibyte.html#CHARSET-TABLE
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
ht
ting new schemas is not directly connected to
ownership anyway --- it's a question of whether you have the CREATE
privilege on the database. The owner should have that privilege
by default, but it could be revoked, or granted to others.
regards, tom lane
--
Sent via pgsql
hink that it's worth your time to write unsafe/unportable code? Do
you know that your compiler doesn't turn Float8GetDatum into a no-op
already? (Mine does, on a 64-bit machine.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general
27;OTHER ERRORS: %,%', sqlstate,sqlerrm;
END$$;
NOTICE: Error E0001 raised - going to do something about it
Or you could do
RAISE EXCEPTION SQLSTATE v_sqlstate USING message = v_msg;
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postg
heard about a commercial fork
of PG that is less bad for this type of data, but the community code
is not the weapon you want.
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
re 1=0;
QUERY PLAN
--
Result (cost=0.00..0.00 rows=0 width=8)
One-Time Filter: false
(2 rows)
In this case the answer is "pretty far" --- you get a valid but
dummy plan, which will just exit without returnin
-+-+---
> unknown | unknown |
As of v10, this will produce a table with a column of type text,
not type unknown, again as a result of more aggressively forcing
unknown to be something else.
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
releases?.
Not particularly. You can do that sort of thing already via PAM,
for example.
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 Mon, Sep 18, 2017 at 12:36 PM, Tom Lane wrote:
>> I wouldn't say it's desired behavior, exactly, but there's no very
>> good way to improve it. pg_ctl has no visibility into what the postmaster
>> is thin
mprove it. pg_ctl has no visibility into what the postmaster
is thinking.
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
gt; fails to consider that the join condition may contain RelabelTypes
> instead of plain Vars.
>
> The attached fixes.
Looks like a good fix to me (except for the copied-and-pasted,
not-quite-on-point comment ;-)). Pushed.
regards, tom lane
--
Sent via pgs
r
variable as part of a DECLARE CURSOR SQL-level command. They're not
the same thing at all. In particular, there isn't any concept of
parameters in the SQL DECLARE CURSOR command.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@
ocale name. Or if you want
to make a new database within an existing installation, use CREATE
DATABASE directly, setting the LC_COLLATE and LC_CTYPE options
(and selecting a matching ENCODING).
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
this you need to increase join_collapse_limit, not
from_collapse_limit. (Usually, though, there's little reason not to keep
them the same.)
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 didn't dump that function, or
it did but pg_restore isn't restoring it, perhaps because of the --schema
restriction. I'm not sure why the function name isn't showing up as
schema-qualified, though, if it isn't in the public schema.
regards
ide enough to require toasting. That would save a few
microseconds during table creation and drop ... but an unused toast table
that's just sitting there is surely not much overhead.
For every other purpose, PG just pays attention to the actual column
values' lengths.
uot;."id" IS NULL
should be understood as an anti-join? The planner doesn't get that
at the moment, for implementation reasons that needn't concern us here.
But it would get it if you said
WHERE ... "report_submission"."skill_type_id" IS NULL
i.e. constrain the join
pped to, for example, VARCHAR(256)?
No.
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
Ron Johnson writes:
> On 09/07/2017 09:08 AM, Tom Lane wrote:
>> Manual cleanup shouldn't be very hard, fortunately. Run pg_controldata
>> to see where the last checkpoint is, and delete WAL files whose names
>> indicate they are before that (but not the one includin
ush all the
.ready files (and .done if any) without much thought.
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
1 - 100 of 13966 matches
Mail list logo
