Solved: Scheduled refresh failing for postgresSQL

Knelly037 · ‎07-27-2026

Hi all, hoping you can help. I have a model connection to an zure postgresSQL database. This is working fine in desktop to refresh but when I try and set up a scheduled refresh using the same credentials I am getting an error I don't understand, any advice would be gratefully received!
DataSource.Error: PostgreSQL: Exception while reading from stream. Microsoft.Data.Mashup.ErrorCode = 10478. Microsoft.Data.Mashup.ValueError.DataSourceKind = PostgreSQL. DataSourcePath = postgndcd1mandash03.postgres.database.azure.com;datalake. Message = Exception while reading from stream. Microsoft.Data.Mashup.ValueError.ErrorCode = -2147467259. . The exception was raised by the IDataReader interface. Please review the error message and provider documentation for further information and corrective action.

PauReis · ‎07-28-2026

Thanks, and that 50 minutes is the most useful thing anyone has said in this thread. It changes my answer slightly.

Start with point 2, because you can hand this straight back to Security and give them their afternoon back: it isn't the firewall. A refresh that runs for 50 minutes is a connection that was accepted, authenticated, and streaming rows the whole time. Those firewall rules get evaluated when the connection opens so they can't reach in and kill a session 50 minutes later. And on a cloud connection you shouldn't expect to see your own IP in that list at all. The refresh runs from the Power BI service, not from your machine, so your office IP only ever mattered for Desktop. Whatever's configured is already letting the service through.

Point 1 is settled too, postgndcd1mandash03 is an Azure-hosted server, so a cloud connection is the right answer and the connector supports it directly. You don't need the on-premises gateway. Don't spend another evening on the install that failed.

So this isn't connectivity any more, it's duration. Worth ruling one thing out immediately: Power BI itself isn't what's giving up. Shared capacity allows two hours, Premium five, so at 50 minutes you're nowhere near either ceiling. Something between the service and Postgres is dropping the session mid-read, which is precisely what "exception while reading from stream... raised by the IDataReader interface" is describing.

Two things I would look at to make sure:

First, look at what's actually in the M for that query rather than assuming. The connector's CommandTimeout defaults to ten minutes and cancels the server-side query, and the fact you're getting 50 tells you the default isn't what's biting, so either a longer value is already set or the query finished and you're dying in the row streaming after it. That's worth knowing before you change anything. The advanced-options box only exists in Desktop, but the value gets written into the M and the service honours it, so set it explicitly there and republish:

PostgreSQL.Database("postgndcd1mandash03.postgres.database.azure.com", "datalake", [CommandTimeout=#duration(0,2,0,0)])

Second, get whoever owns the flexible server to read the Postgres logs at the minute it dies. If Postgres terminated the session, it'll be in there and you're looking at a server parameter, statement_timeout or idle_in_transaction_session_timeout. If the logs show nothing at all, the connection got dropped somewhere between the two and it's a different fix entirely. That split decides everything else, and it's five minutes of someone's time.

With only the one table there's nothing left to isolate, so the number I'd actually want next is the other side of the comparison: how long does that same table take to refresh in Desktop? Microsoft's own troubleshooting advice is to time it there. If Desktop is also sitting around 45 to 50 minutes, you're simply at the edge of what this will bear and the fix is to make the read smaller. Drop columns you don't use, filter at the source, then incremental refresh. But if Desktop pulls it in five minutes and the service takes fifty, then the service is doing far more work than Desktop is, and that gap is the actual bug rather than any timeout itself.

https://learn.microsoft.com/en-us/powerquery-m/postgresql-database

https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-data

View solution in original post

v-abhinavmu · ‎08-06-2026

Hi @Knelly037,

May I check if this issue has been resolved? If not, Please feel free to contact us if you have any further questions.

Thank you

v-abhinavmu · ‎08-03-2026

Hi @Knelly037,

Thanks for reaching out to Microsoft fabric community. and thanks to @PauReis for sharing valuable insights.

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.

Thank you.

PauReis · ‎07-27-2026

Hi @Knelly037, the "works fine in Desktop, fails on the schedule with the same credentials" part is very useful. Same credentials working in Desktop does rule out the credentials themselves, so I'd stop looking there. What changes between the two is what is doing the connecting and from where: Desktop connects from your machine, on your network. The scheduled refresh connects from the Power BI service, either directly or through a gateway, and that's a completely different source. @arvindsingh802 is pointing the right way with reachability. One thing worth noticing in your error text first though, before you start changing firewall
rules. "Exception while reading from stream" reads like the connection got opened and then died partway through the read, rather than never being allowed through at all. If postgndcd1mandash03.postgres.database.azure.com were simply unreachable from the service, you'd normally get a connect or timeout error rather than something raised by the IDataReader interface mid-read. Not conclusive on its own, but it changes what I'd look at first.

Two things that would pin it down:

1. Semantic model > Settings, look at the data source under gateway and cloud connections. Is this going through an on-premises gateway, or a cloud connection? That decides whose IP has to be allowed on the Postgres side, the gateway machine's outbound address or the service's.

2. On the Azure Database for PostgreSQL server, under Networking, check the firewall rules and whether the "allow access from Azure services" toggle is on. The exact wording differs a bit between Single Server and Flexible Server. A rule that only covers your office range would explain Desktop working and nothing else working.

The question that splits it: does the scheduled refresh fail straight away, or does it run for a little while first? And is it always the same table in datalake, or does it move around? Fails fast and every time points at reachability. Runs a bit and then dies, especially on a bigger table, points at the connection being dropped mid-read, which is a different fix.

Happy to investigate further if needed!

Knelly037 · ‎07-28-2026

Thanks that's super helpful, I have asked the Security to check on point 2, it is toggled on but I can't see my IP address added as an approved connector

In terms of point 1, I tried to set up on-premises but it failed. I have setup a cloud connection successfully and it does run for about 50 mins before then failing. It is always the same table I am sourcing, never changes.

Pulendar1

I'd start by creating a simple Power BI report with 1-2 tables from the same PostgreSQL database and configuring refresh using the same Cloud Connection.

If that refreshes successfully, you can rule out connectivity, firewall, and Power BI Service connection issues. The problem is then likely specific to the semantic model.

I recently fixed a similar issue where the report worked in Desktop but failed in the Service. The root cause was a column stored as text in the source that Power BI automatically converted to DateTime. A few invalid date values caused refresh failures in the Service. Changing the column back to text and handling the invalid values resolved the issue.

It may be worth checking for data type mismatches, invalid dates, schema changes, or transformations that behave differently during Service refresh.

Regards,

Pulendar

PauReis · ‎07-28-2026

Thanks, and that 50 minutes is the most useful thing anyone has said in this thread. It changes my answer slightly.

Start with point 2, because you can hand this straight back to Security and give them their afternoon back: it isn't the firewall. A refresh that runs for 50 minutes is a connection that was accepted, authenticated, and streaming rows the whole time. Those firewall rules get evaluated when the connection opens so they can't reach in and kill a session 50 minutes later. And on a cloud connection you shouldn't expect to see your own IP in that list at all. The refresh runs from the Power BI service, not from your machine, so your office IP only ever mattered for Desktop. Whatever's configured is already letting the service through.

Point 1 is settled too, postgndcd1mandash03 is an Azure-hosted server, so a cloud connection is the right answer and the connector supports it directly. You don't need the on-premises gateway. Don't spend another evening on the install that failed.

So this isn't connectivity any more, it's duration. Worth ruling one thing out immediately: Power BI itself isn't what's giving up. Shared capacity allows two hours, Premium five, so at 50 minutes you're nowhere near either ceiling. Something between the service and Postgres is dropping the session mid-read, which is precisely what "exception while reading from stream... raised by the IDataReader interface" is describing.

Two things I would look at to make sure:

First, look at what's actually in the M for that query rather than assuming. The connector's CommandTimeout defaults to ten minutes and cancels the server-side query, and the fact you're getting 50 tells you the default isn't what's biting, so either a longer value is already set or the query finished and you're dying in the row streaming after it. That's worth knowing before you change anything. The advanced-options box only exists in Desktop, but the value gets written into the M and the service honours it, so set it explicitly there and republish:

PostgreSQL.Database("postgndcd1mandash03.postgres.database.azure.com", "datalake", [CommandTimeout=#duration(0,2,0,0)])

Second, get whoever owns the flexible server to read the Postgres logs at the minute it dies. If Postgres terminated the session, it'll be in there and you're looking at a server parameter, statement_timeout or idle_in_transaction_session_timeout. If the logs show nothing at all, the connection got dropped somewhere between the two and it's a different fix entirely. That split decides everything else, and it's five minutes of someone's time.

With only the one table there's nothing left to isolate, so the number I'd actually want next is the other side of the comparison: how long does that same table take to refresh in Desktop? Microsoft's own troubleshooting advice is to time it there. If Desktop is also sitting around 45 to 50 minutes, you're simply at the edge of what this will bear and the fix is to make the read smaller. Drop columns you don't use, filter at the source, then incremental refresh. But if Desktop pulls it in five minutes and the service takes fifty, then the service is doing far more work than Desktop is, and that gap is the actual bug rather than any timeout itself.

https://learn.microsoft.com/en-us/powerquery-m/postgresql-database

https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-data