e
ap.validate_crtr_line_items$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
s wrong if the library is preloaded, 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.
You probably need an explicit cast to the rowtype. That is,
declare myarray rowtypename[];
...
select array(select row(col1, ...)::rowtypename from ...) into myarray;
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresq
t make the problem worse...
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@postg
Andres Freund <and...@anarazel.de> 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 vulner
Andres Freund <and...@anarazel.de> writes:
> On 2017-11-06 15:35:03 -0500, Tom Lane wrote:
>> David Pacheco <d...@joyent.com> writes:
>>> I ran into what appears to be a deadlock in the logging subsystem. It
>>> looks like what happened was that the syslogge
me issue being discussed 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
rent 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
'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
f you can still 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
sh.
While I don't want 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.
othing to do with your 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.postgre
d 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 subscription:
h
recovery may take 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
ike the 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
m this repo:
> 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, to
think you need to complain to the Debian packagers
about 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
u can adjust ssl_ciphers, it'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 pg
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.
regards, tom la
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
the
grouping 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
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
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
ming from.
You don't have 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)
T
t then you have to think 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
th EXCEPTION blocks, but your 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@postgres
n Debian though.
In multi-socket 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
, implement a vacuum 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
regar
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 mailing list (pgsql-g
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
n'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
ory around 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.post
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 (pgsql-general@postg
so 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 mailin
d enough to 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.
re
tabase finally shut
> 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
pending on
syntax --- quite aside 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
a compatibility
issue. I'll go fix 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
ds, 200M input file even
> 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, to
diately 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
listings (of course, this 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 subscrip
tput
whether 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
meaning of "name".*
If data_comp is a column 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 mailin
ion=# insert into t_array select
array[row('a','b','c'),row('d','e','f')]::mytype[];
INSERT 0 1
although I think the latter only works in relatively late-model
Postgres, and it might make parsing a bit slower too.
regards, tom lane
--
Sent via pgsql-general ma
ough 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
ild process) 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.
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://www.postg
Justin Pryzby <pry...@telsasoft.com> 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
>
hout 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 other.
re
=79,853 loops=1)
Being off by 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 ...
rrent/static/app-pgconfig.html ) is what
> you are looking for.
specifically, 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 mail
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" <david.g.johns...@gmail.com> writes:
> On Thu, Oct 19, 2017 at 12:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> FROM products,
>> (values ('red widget'::text)) consts(target)
>> WHERE similarity(target, item_name) > 0.25
>>
nsts(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
password(s) in clear text.
> Can'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.
> it's an industry rule 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 whic
improvements. But this
is 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
ore the line that would normally accept 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
hich relation the page
lock was 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
f one of its approximations as to which 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.o
anging '1.00' 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
al production
>> situation, the only symptom was that the startup process just stopped.
>> There were no log messages or any other indication of what was going wrong.
> Which indicates it was making progress, just slowly.
> Tom says "This is pretty easy to diagnose though
> bec
ntly 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 <alvhe...@alvh.no-ip.org> 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.
Peter Geoghegan <p...@bowt.ie> 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 subscr
he 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.postg
that was true originally, 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
Christophe Pettus <x...@thebuild.com> writes:
>> On Oct 9, 2017, at 13:26, Tom Lane <t...@sss.pgh.pa.us> 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
>> e
Christophe Pettus <x...@thebuild.com> writes:
>> On Oct 9, 2017, at 13:01, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Is that number changing at all?
> Increasing:
> AccessExclusiveLock | 8810
Oh, that's really interesting. So it's not *just* releasing locks but
a
an O(N^2) situation, though for 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?
re
WAL segment.
> 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
f you'd like joins 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
l.gmail.com
which suggests 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.
acquainted with 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-gen
.h:
> No such file or directory
Try building 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
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.
regards, tom lane
--
Sent via
(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 lane
--
Sent via pgsql-general mailing
EXPLAIN ANALYZE
output for 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
time overhead to
> deal 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 recov
suspiciously like an 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
.
Or there's about 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
Note that creating 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
--
on is the root of all evil". Do you have good reason
to think 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
qlstate,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@postgresql.org)
To make changes to yo
ecall having 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
st1 (x int, y int);
CREATE TABLE
regression=# explain select x,y from test1 where 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
+-+---
> 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
rofiles in feature
> 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" <david.g.johns...@gmail.com> writes:
> On Mon, Sep 18, 2017 at 12:36 PM, Tom Lane <t...@sss.pgh.pa.us> 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 in
to improve 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
t looks like the code to check for distinctness in the subquery
> 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.
the plpgsql syntax for a cursor
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 (pgsq
but with a Windows-style locale 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
ing FROM_COLLAPSE_LIMIT, but it made no difference.
For 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.o
t likely theory is that pg_dump 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, tom lan
able, because no row in the table could
ever be wide 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
va
. constrain the join column to be null. Any chance of whacking your
ORM upside the head to the point where it would emit 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
ngs more efficient if it were dropped 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 <ron.l.john...@cox.net> 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
.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 14105 matches
Mail list logo
