Обсуждение: postgres sometimes returns no data
Hi. We have a postgres 9.1 query in a pentaho job (table input component contains the query and is followed by various switches) that runs nightly. More and more frequently (about half the time now), the query returns no data (or appears to return no data, see last paragraph) when there is clearly data to be extracted. And pentaho continues as if nothing is wrong. Whenever I simply rerun the component manually, the query returns data and I am able to complete the job. I'm looking at what I think is a postgres log around one of the times this last happened. And trying to correlate it to the time I see in the pentaho job's log when this component starts up. Around that time I just see a bunch of "checkpoints are occurring too frequently...". About a minute later and coincidentally around the time the pentaho job ends, I see "unexpected eof...could not receive data..target machine actively refused it.". The reason this last item interests me is that this component is the last postgres item to run in the job. And the next/last component wouldn't run long when there is an empty file created by the problematic component. The file is empty whenever this behavior occurs. I'm torn not knowing if this is a postgres issue or pentaho issue. The fact that the pentaho log doesn't show the switches as having "finished processing" makes me think either pentaho wouldnt execute those switches when there is no data or pentaho is the problem. The fact that its happening more often makes me think the db is somehow involved in the problem. I did a reindex and vacuum recently hoping it would alleviate the problem. Not so. Any advice would be appreciated. -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
On Fri, Nov 13, 2015 at 6:49 AM, db042190 <stanteitelbaum@roadrunner.com> wrote:
Hi. We have a postgres 9.1 query in a pentaho job (table input component
contains the query and is followed by various switches) that runs nightly.
More and more frequently (about half the time now), the query returns no
data (or appears to return no data, see last paragraph) when there is
clearly data to be extracted. And pentaho continues as if nothing is wrong.
Whenever I simply rerun the component manually, the query returns data and I
am able to complete the job.
I'm looking at what I think is a postgres log around one of the times this
last happened. And trying to correlate it to the time I see in the pentaho
job's log when this component starts up.
Around that time I just see a bunch of "checkpoints are occurring too
frequently...". About a minute later and coincidentally around the time the
pentaho job ends, I see "unexpected eof...could not receive data..target
machine actively refused it.". The reason this last item interests me is
that this component is the last postgres item to run in the job. And the
next/last component wouldn't run long when there is an empty file created by
the problematic component. The file is empty whenever this behavior occurs.
When checkpoints are occurring too frequently, then, it is important that you tune the checkpoint parameters to ensure optimal checkpoint behavior. Do you see any IO spike on the postgres server ?
As the above message says "could not receive data" ...
I suspect, the query is returning the rows at the postgres end without any issues. Did you execute the query on the Postgres database and see if that is returning rows ? if yes, then it is not a query related issue, it has something to do with the performance. Do you notice any other activities on the database when this query is running which are possibly generating High CPU / High IO which can block or abort the application connections ?
I'm torn not knowing if this is a postgres issue or pentaho issue. The fact
that the pentaho log doesn't show the switches as having "finished
processing" makes me think either pentaho wouldnt execute those switches
when there is no data or pentaho is the problem. The fact that its
happening more often makes me think the db is somehow involved in the
problem.
I did a reindex and vacuum recently hoping it would alleviate the problem.
Not so. Any advice would be appreciated.
The first thing to do is to tune the checkpoint parameters.
Regards,
Venkata B N
Fujitsu Australia
On 11/12/2015 11:49 AM, db042190 wrote: > Hi. We have a postgres 9.1 query in a pentaho job (table input component > contains the query and is followed by various switches) that runs nightly. > More and more frequently (about half the time now), the query returns no > data (or appears to return no data, see last paragraph) when there is > clearly data to be extracted. And pentaho continues as if nothing is wrong. > Whenever I simply rerun the component manually, the query returns data and I > am able to complete the job. > > I'm looking at what I think is a postgres log around one of the times this > last happened. And trying to correlate it to the time I see in the pentaho > job's log when this component starts up. > > Around that time I just see a bunch of "checkpoints are occurring too > frequently...". About a minute later and coincidentally around the time the > pentaho job ends, I see "unexpected eof...could not receive data..target > machine actively refused it.". The reason this last item interests me is > that this component is the last postgres item to run in the job. And the > next/last component wouldn't run long when there is an empty file created by > the problematic component. The file is empty whenever this behavior occurs. > > I'm torn not knowing if this is a postgres issue or pentaho issue. The fact > that the pentaho log doesn't show the switches as having "finished > processing" makes me think either pentaho wouldnt execute those switches > when there is no data or pentaho is the problem. The fact that its > happening more often makes me think the db is somehow involved in the > problem. > > I did a reindex and vacuum recently hoping it would alleviate the problem. > Not so. Any advice would be appreciated. The client(Pentaho) and server on the same machine, network, or remotely connected? What OS and version, on either end if appropriate? What does the Postgres log show just before and after ""unexpected eof...could not receive data.." ? What do the OS system logs show around the time of the error? What is/are the job(s) doing? > > > > -- > View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720.html > Sent from the PostgreSQL - general mailing list archive at Nabble.com. > > -- Adrian Klaver adrian.klaver@aklaver.com
thx both for responding. Because the checkpoint settings probably haven't changed in a long long time and we see as many of those warnings on good nights as bad I'm going to make those priority 2. Unless there is a cause and effect u can explain between checkpointing and what we are experiencing. I'll have to find the config setting too. Yes, client and server are on the same machine. Windows 7 professional, sp1, 32 gb, 64 bit. Before unexpected eof, lots of checkpoint warnings back to and prior to what I am presuming is the start up time for this component. After are a bunch more unexpected eofs followed by more checkpoint warnings. I haven't looked at the os logs but will post back here what I find. The job is loading a bunch of postgres tables but in this component which follows all of that, a postgres extract query is supposed to run, feed 3 switches in parallel which in turn direct or divert certain text file writes to occur. The component that follows this one does a remote call that causes an app to import one of the files this problem component creates. -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873730.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
thx, the fact that the query runs under pentaho at least half of the time (used to be most of the time) makes me think it will run on the db. I'll try to get a handle on the cpu/handle info u requested. -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873731.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
there is something i need to correct. Coming out of one of the 3 switches are two branches that cause updates to the same "interaction log" table in postgres. Not text files like the other 2 switches. -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873732.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
On 11/12/2015 12:07 PM, Venkata Balaji N wrote: > Around that time I just see a bunch of "checkpoints are occurring too > frequently...". About a minute later and coincidentally around the > time the > pentaho job ends, I see "unexpected eof...could not receive data..target > machine actively refused it.". The reason this last item interests me is > that this component is the last postgres item to run in the job. And the > next/last component wouldn't run long when there is an empty file > created by > the problematic component. The file is empty whenever this behavior > occurs. the too frequent checkpoint thing is purely a warning, that you probably want to increase the checkpoint_segments count, I usually set it to 30 or 50 or something on a server that sees these warnings during heavy activity. I've never known it to cause data loss. the unexpected EOF, that means the socket between the client and the database server was closed unexpectedly, usually this means the client application exited ungracefully. HOWEVER, if this is a Linux server, I'd go looking in the system logs for signs that the evil 'OOM Killer' has been active. OOM Killer is an abomination on a database server, it randomly kills processes that use high memory, this can cause all sorts of problems. If this is happening, you should A) tune OOM Killer to be MUCH less active, and B) reduce your postgresql memory usage to better suit your system environment. -- john r pierce, recycling bits in santa cruz
On 11/12/2015 12:54 PM, db042190 wrote: > there is something i need to correct. Coming out of one of the 3 switches > are two branches that cause updates to the same "interaction log" table in > postgres. Not text files like the other 2 switches. Could you show a sample of the actual log error messages? Not sure what the log line prefix is, you might want to take a look here: http://www.postgresql.org/docs/9.1/interactive/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT log_line_prefix and add escapes that would help identify who is doing what. > > > > -- > View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873732.html > Sent from the PostgreSQL - general mailing list archive at Nabble.com. > > -- Adrian Klaver adrian.klaver@aklaver.com
On 11/12/2015 11:49 AM, db042190 wrote: > I see "unexpected eof...could not receive data..target > machine actively refused it.". That sounds like the same error message as discussed here: http://www.postgresql.org/message-id/4D75289D.9020904@techbaza.pl Could it be a problem of too many open connections? Possibly some hanging around longer than they should? Paul
pls remember that since the switches didn't run, this all (or mostly) could be related to an unknown process. My bad component appears to have started around 54 seconds into nov 10. The overall job appears to have ended around 01:01:44 which makes me wonder if a lot of the EOFs are related to some sort of cleanup effort between pentaho and postgres. I'm poking around for info on how to run perfmon unattended, how big its footprint would be if monitoring for an extended period of time unattended , and how to look at what the os might have told me that day at that time. I took a peek at available disk space, and while I don't know what postgres might be allowed to take, there is a ton of available space. I closed out about a handful of idle queries on pg admin iii left by programmers. I'll post more soon. 2015-11-10 00:54:03 EST LOG: checkpoints are occurring too frequently (116 seconds apart) 2015-11-10 00:54:03 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:54:24 EST LOG: checkpoints are occurring too frequently (21 seconds apart) 2015-11-10 00:54:24 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:54:46 EST LOG: checkpoints are occurring too frequently (22 seconds apart) 2015-11-10 00:54:46 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:55:11 EST LOG: checkpoints are occurring too frequently (25 seconds apart) 2015-11-10 00:55:11 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:55:36 EST LOG: checkpoints are occurring too frequently (25 seconds apart) 2015-11-10 00:55:36 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:56:07 EST LOG: checkpoints are occurring too frequently (31 seconds apart) 2015-11-10 00:56:07 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:56:38 EST LOG: checkpoints are occurring too frequently (31 seconds apart) 2015-11-10 00:56:38 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:57:15 EST LOG: checkpoints are occurring too frequently (37 seconds apart) 2015-11-10 00:57:15 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:57:53 EST LOG: checkpoints are occurring too frequently (38 seconds apart) 2015-11-10 00:57:53 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:58:35 EST LOG: checkpoints are occurring too frequently (42 seconds apart) 2015-11-10 00:58:35 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:59:12 EST LOG: checkpoints are occurring too frequently (37 seconds apart) 2015-11-10 00:59:12 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 00:59:34 EST LOG: checkpoints are occurring too frequently (22 seconds apart) 2015-11-10 00:59:34 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 01:00:15 EST LOG: checkpoints are occurring too frequently (41 seconds apart) 2015-11-10 01:00:15 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 01:00:46 EST LOG: checkpoints are occurring too frequently (31 seconds apart) 2015-11-10 01:00:46 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 01:01:15 EST LOG: checkpoints are occurring too frequently (29 seconds apart) 2015-11-10 01:01:15 EST HINT: Consider increasing the configuration parameter "checkpoint_segments". 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection 2015-11-10 01:01:44 EST LOG: could not receive data from client: No connection could be made because the target machine actively refused it. 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873824.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
it looks like a lot of the log attributes ion the config are defaulting, probably to NOTICE. I see a # in front of many. If the community can advise on better choices and how bad the footprint would be for me to change these, pls let me know. I'm guessing the log excerpt I posted isn't telling us much. -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873828.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
On 11/13/2015 07:56 AM, db042190 wrote: > pls remember that since the switches didn't run, this all (or mostly) could > be related to an unknown process. My bad component appears to have started > around 54 seconds into nov 10. The overall job appears to have ended around Actually 54 minutes, which makes the below occur over a roughly 7 minute time frame. > 01:01:44 which makes me wonder if a lot of the EOFs are related to some sort > of cleanup effort between pentaho and postgres. I'm poking around for info Well without an indication of what the actual commands are that are being run, this is going to be difficult to troubleshoot from this end. What needs to be sorted out(besides increasing checkpoint_segments) is the source of this: unexpected EOF on client connection could not receive data from client: No connection could be made because the target machine actively refused it. I would spend some time here: http://www.postgresql.org/docs/9.4/interactive/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT Enable log_connections and log_disconnections. Look at log_line_prefix and add at least %u and %p Look at log_statement. Though this can fill up a log in a hurry, especially if you do all. You will need to reload(not restart) the server to have the settings changes take effect. > on how to run perfmon unattended, how big its footprint would be if > monitoring for an extended period of time unattended , and how to look at > what the os might have told me that day at that time. I took a peek at > available disk space, and while I don't know what postgres might be allowed > to take, there is a ton of available space. I closed out about a handful of > idle queries on pg admin iii left by programmers. I'll post more soon. > > 2015-11-10 00:54:03 EST LOG: checkpoints are occurring too frequently (116 > seconds apart) > 2015-11-10 00:54:03 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:54:24 EST LOG: checkpoints are occurring too frequently (21 > seconds apart) > 2015-11-10 00:54:24 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:54:46 EST LOG: checkpoints are occurring too frequently (22 > seconds apart) > 2015-11-10 00:54:46 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:55:11 EST LOG: checkpoints are occurring too frequently (25 > seconds apart) > 2015-11-10 00:55:11 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:55:36 EST LOG: checkpoints are occurring too frequently (25 > seconds apart) > 2015-11-10 00:55:36 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:56:07 EST LOG: checkpoints are occurring too frequently (31 > seconds apart) > 2015-11-10 00:56:07 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:56:38 EST LOG: checkpoints are occurring too frequently (31 > seconds apart) > 2015-11-10 00:56:38 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:57:15 EST LOG: checkpoints are occurring too frequently (37 > seconds apart) > 2015-11-10 00:57:15 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:57:53 EST LOG: checkpoints are occurring too frequently (38 > seconds apart) > 2015-11-10 00:57:53 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:58:35 EST LOG: checkpoints are occurring too frequently (42 > seconds apart) > 2015-11-10 00:58:35 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:59:12 EST LOG: checkpoints are occurring too frequently (37 > seconds apart) > 2015-11-10 00:59:12 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 00:59:34 EST LOG: checkpoints are occurring too frequently (22 > seconds apart) > 2015-11-10 00:59:34 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 01:00:15 EST LOG: checkpoints are occurring too frequently (41 > seconds apart) > 2015-11-10 01:00:15 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 01:00:46 EST LOG: checkpoints are occurring too frequently (31 > seconds apart) > 2015-11-10 01:00:46 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 01:01:15 EST LOG: checkpoints are occurring too frequently (29 > seconds apart) > 2015-11-10 01:01:15 EST HINT: Consider increasing the configuration > parameter "checkpoint_segments". > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > 2015-11-10 01:01:44 EST LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2015-11-10 01:01:44 EST LOG: unexpected EOF on client connection > > > > -- > View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873824.html > Sent from the PostgreSQL - general mailing list archive at Nabble.com. > > -- Adrian Klaver adrian.klaver@aklaver.com
currently, log line prefix is log_line_prefix = '%t '. Not sure what the blank following the t does. u probably want me to change it to log_line_prefix = '%t%a%u%d%r%h%p% ' or something like that? -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873831.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
a couple of these say cant be changed after session start. Is that the same as reload? Can I change it back if I do a reload? -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873832.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
On 11/13/2015 08:39 AM, db042190 wrote:
> currently, log line prefix is log_line_prefix = '%t '.
>
> Not sure what the blank following the t does.
The blank is so this happens:
2015-11-10 00:55:11 EST HINT
^
It is a literal space to separate the log prefix from the log message to
make things clearer.
>
> u probably want me to change it to log_line_prefix = '%t%a%u%d%r%h%p% ' or
> something like that?
That may be a bit much. %a probably does not do what you think it does.
It returns a name that has to be set and may not be set by a connecting
client. %r and %h are somewhat redundant with %r just adding the port to %h
>
>
>
> --
> View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873831.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
run this on pg admin III to reload SELECT pg_reload_conf() ? Also, I now see the format for multiple log line prefixes...blank after each choice including last. I will try that once i'm comfortable with how I'll be reloading postgres. -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873834.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
I looked at event viewer in both Application and System. Neither shows anything unusual around that time, just Volume Shadow Copy service stopping. -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873841.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
ok, I poked around and see a reload config option in pg admin iii. I guess i'm ready to go. -- View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873846.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
On 11/13/2015 09:56 AM, db042190 wrote: > I looked at event viewer in both Application and System. Neither shows > anything unusual around that time, just Volume Shadow Copy service stopping. Hmm, is something trying to run a backup over your Postgres data directory at the same time you are running the Pentaho task? I am not that much of Windows user anymore, so the below is coming from possibly faulty memory. Check Windows Backup and Scheduler for backup jobs. > > > > -- > View this message in context: http://postgresql.nabble.com/postgres-sometimes-returns-no-data-tp5873720p5873841.html > Sent from the PostgreSQL - general mailing list archive at Nabble.com. > > -- Adrian Klaver adrian.klaver@aklaver.com