[GENERAL] Invalid field size

I've implemented a backup procedure in C# with Npgsql (using COPY TO I dump all tables in a compressed file) that's been working well in the last 5 years (and it's still working, since this is a single, isolated case). OS: Windows 7 PG: 9.1.6 (I know, it's EOL, but I think it's not matter

Re: [GENERAL] Invalid field size

>On Tuesday, 4 July 2017, 12:16:57 GMT+1, Moreno Andreo > wrote: > > > Any ideas? As for many error I got in the past I assume we are trying to > COPY FROM corrupted data (when using cheap pendrives we get often this > error). Should it be reasonable or I have to

Re: [GENERAL] Invalid field size

Il 04/07/2017 16:30, Glyn Astill ha scritto: >On Tuesday, 4 July 2017, 12:16:57 GMT+1, Moreno Andreo wrote: > > > Any ideas? As for many error I got in the past I assume we are trying to

Re: [SPAM] Re: [GENERAL] Invalid field size

Il 04/07/2017 16:36, Adrian Klaver ha scritto: On 07/04/2017 04:16 AM, Moreno Andreo wrote: I've implemented a backup procedure in C# with Npgsql (using COPY TO I dump all tables in a compressed file) that's been working well in the last 5 years (and it's still working, since this is a single,

Re: [GENERAL] Invalid field size

On 07/04/2017 04:16 AM, Moreno Andreo wrote: I've implemented a backup procedure in C# with Npgsql (using COPY TO I dump all tables in a compressed file) that's been working well in the last 5 years (and it's still working, since this is a single, isolated case). OS: Windows 7 PG: 9.1.6 (I

Re: [GENERAL] Invalid field size

Moreno Andreo writes: > I've implemented a backup procedure in C# with Npgsql (using COPY TO I > dump all tables in a compressed file) that's been working well in the > last 5 years (and it's still working, since this is a single, isolated > case). > OS: Windows 7 >

Re: [GENERAL] Invalid field size

Il 04/07/2017 16:51, Tom Lane ha scritto: Moreno Andreo writes: I've implemented a backup procedure in C# with Npgsql (using COPY TO I dump all tables in a compressed file) that's been working well in the last 5 years (and it's still working, since this is a single,

Re: [GENERAL] Invalid field size

Moreno Andreo writes: > Il 04/07/2017 16:51, Tom Lane ha scritto: >> Pushing binary data around on Windows is always a hazardous proposition. > So what you are saying is "in the last 5 years you've been extremely > lucky?" :-) Yup, particularly now that you mention

Re: [GENERAL] Invalid field size

Moreno Andreo wrote: > As you can see I have 2 bytea fields, blob and thumbnail (the one it > seems it's giving the error), but AFAIK the former is never used, so it > should be always null. > Googling around did not help. In COPY BINARY, NULL is represented as -1 (all bits set) in the

Re: [SPAM] Re: [SPAM] Re: [GENERAL] Invalid field size

Il 04/07/2017 18:25, Adrian Klaver ha scritto: On 07/04/2017 09:02 AM, Moreno Andreo wrote: Il 04/07/2017 17:39, Adrian Klaver ha scritto: So what you are saying is "in the last 5 years you've been extremely lucky?" :-) Your original post went back and forth on whether you where lucky in

Re: [SPAM] Re: [SPAM] Re: [GENERAL] Invalid field size

On 07/04/2017 10:13 AM, Moreno Andreo wrote: Il 04/07/2017 18:25, Adrian Klaver ha scritto: On 07/04/2017 09:02 AM, Moreno Andreo wrote: Il 04/07/2017 17:39, Adrian Klaver ha scritto: So what you are saying is "in the last 5 years you've been extremely lucky?" :-) Your original post went

Re: [SPAM] Re: [GENERAL] Invalid field size

Il 04/07/2017 17:39, Adrian Klaver ha scritto: On 07/04/2017 08:19 AM, Moreno Andreo wrote: Il 04/07/2017 16:51, Tom Lane ha scritto: Moreno Andreo writes: I've implemented a backup procedure in C# with Npgsql (using COPY TO I dump all tables in a compressed file)

Re: [GENERAL] Invalid field size

On 07/04/2017 08:37 AM, Moreno Andreo wrote: Il 04/07/2017 17:25, Tom Lane ha scritto: Moreno Andreo writes: Il 04/07/2017 16:51, Tom Lane ha scritto: Pushing binary data around on Windows is always a hazardous proposition. So what you are saying is "in the last 5

Re: [GENERAL] Invalid field size

Il 04/07/2017 18:55, Daniel Verite ha scritto: I don't quite see from your posts whether that particular file to import was tried and failed only once or retried and failed again. Only once, and until the user will not return from holidays I'll not be able to reproduce it. Cheers Moreno

Re: [GENERAL] Invalid field size

On 07/04/2017 08:19 AM, Moreno Andreo wrote: Il 04/07/2017 16:51, Tom Lane ha scritto: Moreno Andreo writes: I've implemented a backup procedure in C# with Npgsql (using COPY TO I dump all tables in a compressed file) that's been working well in the last 5 years (and

Re: [SPAM] Re: [GENERAL] Invalid field size

Il 04/07/2017 17:42, Adrian Klaver ha scritto: On 07/04/2017 08:37 AM, Moreno Andreo wrote: Il 04/07/2017 17:25, Tom Lane ha scritto: Moreno Andreo writes: Il 04/07/2017 16:51, Tom Lane ha scritto: Pushing binary data around on Windows is always a hazardous

Re: [GENERAL] Invalid field size

Il 04/07/2017 17:42, Daniel Verite ha scritto: Moreno Andreo wrote: As you can see I have 2 bytea fields, blob and thumbnail (the one it seems it's giving the error), but AFAIK the former is never used, so it should be always null. Googling around did not help. Despite the

[GENERAL] pg_start/stop_backup non-exclusive scripts to snapshot

Hi there, I’ve previously done ZFS snapshot backups like this: psql -c “select pg_start_backup(‘snapshot’);” zfs snapshot TANK/postgresql@`date ‘+%Ymd’` psql -c “select * from pg_stop_backup();” Reading the PostgreSQL9.6 documentation, the advice/future is to use the non-exclusive method,

Re: [GENERAL] Invalid field size

Moreno Andreo wrote: > So if it's the case (hardware error), recalling a new backup should > reproduce the error, right? If the error happened when writing the file, I wouldn't expect any other backup having the same error (assuming an error in the bit-flip category). And if it was a

Re: [GENERAL] pg_start/stop_backup non-exclusive scripts to snapshot

Greetings, * hvjunk (hvj...@gmail.com) wrote: > I’ve previously done ZFS snapshot backups like this: > > psql -c “select pg_start_backup(‘snapshot’);” > zfs snapshot TANK/postgresql@`date ‘+%Ymd’` > psql -c “select * from pg_stop_backup();” Hopefully you are also doing WAL archiving... >

Re: [GENERAL] pg_start/stop_backup non-exclusive scripts to snapshot

On Tue, Jul 4, 2017 at 5:55 PM, Stephen Frost wrote: > Greetings, > > * hvjunk (hvj...@gmail.com) wrote: > > I’ve previously done ZFS snapshot backups like this: > > > > psql -c “select pg_start_backup(‘snapshot’);” > > zfs snapshot TANK/postgresql@`date ‘+%Ymd’` > > psql -c

Re: [GENERAL] Re: have trouble understanding xmin and xmax with update operations from two different sessions

On Mon, Jul 3, 2017 at 10:39 AM, rajan wrote: > Thanks, Jeff. > > Now I am going back to my old question. > > Even though *Session 2* fails to update with UPDATE 0 message, its txid is > saved in xmax of updated(by *Session 1*) tuple. > > As it becomes an old txid, how come

Re: [SPAM] Re: [SPAM] Re: [GENERAL] Invalid field size

Il 04/07/2017 19:28, Tom Lane ha scritto: Moreno Andreo writes: So the hint is to abandon manual COPY and let pg_dump do the hard work? If it is a newline-conversion problem, compressed pg_dump archives would be just as subject to corruption as your binary COPY file

Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12

Tom Lane writes: > r...@bb-c.de (Rainer J.H. Brandt) writes: > > I got this initdb error for a 64bit-build on macOS El Capitan and Sierra: > > > creating conversions ... FATAL: could not load library > > "/opt/bb/170704/lib/postgresql/ascii_and_mic.so": > >

Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12

On 07/04/2017 01:29 PM, Rainer J.H. Brandt wrote: Tom Lane writes: r...@bb-c.de (Rainer J.H. Brandt) writes: This makes little sense to me. 64-bit builds have been the default on macOS for some time. Good to know. I removed those options and tried again. Did you run make clean before

Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12

Adrian Klaver writes: > On 07/04/2017 01:29 PM, Rainer J.H. Brandt wrote: > > Tom Lane writes: > >> r...@bb-c.de (Rainer J.H. Brandt) writes: > > >> > >> This makes little sense to me. 64-bit builds have been the default on > >> macOS for some time. > > Good to know. I removed those options and

Re: [SPAM] Re: [SPAM] Re: [GENERAL] Invalid field size

On 07/04/2017 10:57 AM, Moreno Andreo wrote: Il 04/07/2017 19:28, Tom Lane ha scritto: Moreno Andreo writes: So the hint is to abandon manual COPY and let pg_dump do the hard work? If it is a newline-conversion problem, compressed pg_dump archives would be just as

Re: [GENERAL] Using 'WITH SELECT' Results Do Not Match 'SELECT FROM ' Results

Adrian, Thank you for your reply! I apologize in advance for not being detailed below. Hard to do from my phone. I did have to move the 'ORDER BY', but not outside the 'WITH'. My first workaround parenthesized the select containing the 'ORDER BY', forcing it to be evaluated before the

Re: [GENERAL] Invalid field size

Il 04/07/2017 17:25, Tom Lane ha scritto: Moreno Andreo writes: Il 04/07/2017 16:51, Tom Lane ha scritto: Pushing binary data around on Windows is always a hazardous proposition. So what you are saying is "in the last 5 years you've been extremely lucky?" :-) Yup,

Re: [GENERAL] Invalid field size

On 07/04/2017 08:37 AM, Moreno Andreo wrote: Il 04/07/2017 17:25, Tom Lane ha scritto: Moreno Andreo writes: Il 04/07/2017 16:51, Tom Lane ha scritto: Pushing binary data around on Windows is always a hazardous proposition. So what you are saying is "in the last 5

Re: [SPAM] Re: [GENERAL] Invalid field size

On 07/04/2017 09:02 AM, Moreno Andreo wrote: Il 04/07/2017 17:39, Adrian Klaver ha scritto: So what you are saying is "in the last 5 years you've been extremely lucky?" :-) Your original post went back and forth on whether you where lucky in the past: "... that's been working well in the

Re: [SPAM] Re: [SPAM] Re: [GENERAL] Invalid field size

Moreno Andreo writes: > So the hint is to abandon manual COPY and let pg_dump do the hard work? If it is a newline-conversion problem, compressed pg_dump archives would be just as subject to corruption as your binary COPY file is. I'd say the hint is to be more careful

Re: [GENERAL] Invalid field size

Tom Lane wrote: > Moreno Andreo writes: > > So the hint is to abandon manual COPY and let pg_dump do the hard work? > > If it is a newline-conversion problem, compressed pg_dump archives would > be just as subject to corruption as your binary COPY file is.

[GENERAL] 64bit initdb failure on macOS 10.11 and 10.12

Hi, I got this initdb error for a 64bit-build on macOS El Capitan and Sierra: initdb -D /data/pg/hawk -E UTF8 --locale=C" The files belonging to this database system will be owned by user "rjhb". This user must also own the server process. The database cluster will be initialized with locale

Re: [GENERAL] Invalid field size

"Daniel Verite" writes: > Tom Lane wrote: >> If it is a newline-conversion problem, compressed pg_dump archives would >> be just as subject to corruption as your binary COPY file is. > It's mentioned in [1] that the signature at the beginning of these files >

Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12

r...@bb-c.de (Rainer J.H. Brandt) writes: > I got this initdb error for a 64bit-build on macOS El Capitan and Sierra: > creating conversions ... FATAL: could not load library > "/opt/bb/170704/lib/postgresql/ascii_and_mic.so": > dlopen(/opt/bb/170704/lib/postgresql/ascii_and_mic.so, 10):

[GENERAL] Strange case of database bloat

Hi; First, I haven't seen major problems of database bloat in a long time which is why I find this case strange. I wanted to ask here what may be causing it. Problem: == Database is in the 100GB to 200GB size range, running on btrfs (not my choice) with nodatacow enabled (which I set up

Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12

Adrian Klaver writes: > On 07/04/2017 01:29 PM, Rainer J.H. Brandt wrote: >> Good to know. I removed those options and tried again. > Did you run make clean before re-running ./configure? Personally I do "make distclean" before changing any configure options. I'm not

Re: [GENERAL] Imperative Query Languages

(copying the list) On Wed, Jul 5, 2017 at 12:22 AM, Jason Dusek wrote: > Are there any “semi-imperative” query languages that have been tried in > the past? > not particularly relevant to the Unix or Windows worlds, but on OpenVMS there's Datatrieve:

[GENERAL] Imperative Query Languages

Hi All, This more of a general interest than specifically Postgres question. Are there any “semi-imperative” query languages that have been tried in the past? I’m imagining a language where something like this: for employee in employees: for department in department: if

Re: [GENERAL] Using 'WITH SELECT' Results Do Not Match 'SELECT FROM ' Results

Adrian, Working from my phone wasn't such a good idea! When I said 'INSERT' I meant 'WITH'. My excuse is that the 'WITH' statement is building a temporary table ( at least logically ) so there is at least an implicit 'INSERT' there. /s/jr Sent from my iPhone > On Jul 3, 2017, at 23:12,