[GENERAL] ftell mismatch with expected position

I am getting the following warning when our program runs pg_dump.exe and the output is in custom format and send to standard out which is connected to a pipe (Windows platform). pg_dump: [custom archiver] WARNING: ftell mismatch with expected position -- ftell used The output of pg_dump is receiv

Re: [GENERAL] ftell mismatch with expected position

ning for every table in the database while it is dumping the data in the tables. Eelke Klein 2015-10-30 14:53 GMT+01:00 Adrian Klaver : > On 10/29/2015 02:51 AM, Eelke Klein wrote: > >> I am getting the following warning when our program runs pg_dump.exe and >> the output is in

Re: [GENERAL] ftell mismatch with expected position

> > Presumably it doesn't happen without the use of the pipe notation. > Indeed, it only happens when a pipe is involved. > > I suspect that what's happening is that stdout isn't getting put into > binary mode, so that Microsoft's CR/NL translation corrupts the data. > If that's true, though, th

Re: [GENERAL] Postgres and timezones

2016-01-20 12:10 GMT+01:00 Steve Rogerson : > Hi, this is wrong: > > # select to_char('2016-01-20 00:00'::timestamp at time zone > 'Europe/Lisbon', > 'TZ'); > to_char > - > GMT > (1 row) > > > It should be WET, "Western European Time". Is there something I'm doing > wrong? > > Actually y

[GENERAL] postgresql_fdw issues with triggers on the foreign tables

I'm experimenting with using foreign data wrappers to get data from one database to another. Most things work perfectly but I am encountering two issues with triggers on the foreign tables. The first one is when a query triggers a trigger on the foreign table the trigger doesn't have any search_pa

[GENERAL] Wrong estimate in query plan

In a complex query I have query I noticed that the planner made a bad estimate for a join between two tables in the query (I made sure statistics were up to date). The join was on a single column. In the first table are about 985 rows. All rows except one have a NULL value in the join column the

Re: [GENERAL] Work table

2013/10/27 Robert James > On 10/27/13, Thomas Kellerer wrote: > > Robert James wrote on 27.10.2013 20:47: > >> I'm using Postgres for data analysis (interactive and batch). I need > >> to focus the analysis on a subset of one table, and, for both > >> performance and simplicity, have a function

Re: [GENERAL] Natural key woe

ake some. >> >> A VACUUM FULL table2 would have made the CLUSTER unnecesary. A normal VACUUM only marks dead rows as free but does not shrink the table. A VACUUM FULL removes all the free space from the table and returns it to the OS. Eelke Klein

[GENERAL] Out of memory error

GROUP BY artikel.productnr HAVING MAX(product_voorraad) > 0 ORDER BY volgnr asc LIMIT 50 OFFSET 0 Regards, Eelke Klein Bolt Afrekensystemen Mplus Software