On Wed, Jul 5, 2017 at 8:42 AM, Jason Dusek wrote:
>
>
> If we imagine network databases have one layer:
>
> Imperative Plan
>
> And SQL databases have two:
>
> Declarative Query -> Imperative Plan
>
> It seems reasonable to say, LINQ, &al. have three:
>
> Imperative Syntax -> Declarative
Tom Lane writes:
> 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'
On Wed, Jul 5, 2017 at 7:18 AM, Chris Travers
wrote:
> 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, r
On Tue, 4 Jul 2017 at 23:01 Tom Lane wrote:
> I'm pretty sure that that is the model that relational databases (and the
> SQL language in particular) replaced, back in the 70s or so. Look up
> "network" databases (eg CODASYL) and "hierarchical" DBs (eg IMS) for some
> ancient history here. Yeah
On Wed, Jul 5, 2017 at 8:34 AM, Jason Dusek wrote:
>
>
> I can not argue these points with you; but Fortress is a good example of
> imperative looking code that translates to a functional/declarative core;
> as indeed is monadic or applicative code. LINQ is a more recent and
> widespread example
On Tue, 4 Jul 2017 at 23:22 Chris Travers wrote:
> Having done a lot of SQL optimisation stuff I have doubts that this is
> possible. The problem is that it is much easier to go from a declarative
> to an imperative plan than it is to go the other way. In fact sometimes we
> use SQL the way yo
On Wed, Jul 5, 2017 at 7:22 AM, Jason Dusek wrote:
> 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 emplo
Jason Dusek writes:
> 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:
>
(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:
https://en.wikipedia.org/wiki/DATATRIEVE
-Jo
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 employee.depar
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
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 sure how much difference th
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, Adrian
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 “select * from pg_st
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...
> Readi
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
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
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":
> > dlopen(/opt/bb/170704/lib/postgresql/
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 'INSERT
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 subject to corruption as you
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): Symbol
"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
> embed a CRLF to detect this ne
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 "C"
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.
It's mentioned in [1] that th
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 is. I'd say
the hint is to
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 new txids are able to
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 about how you do the cross
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 b
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
t
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
-
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 tr
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, whe
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
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 years you've been extremely
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 auto-correc
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
proposition.
So what you are sayi
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) that's been working well in
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
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 years you've been extremely
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 it's still working, since
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, particularly now that you m
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 moving the files between mach
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, isolated
case).
OS: Windows
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,
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
> PG: 9.1.6 (I know, it's EOL,
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
> COPY FROM corrupte
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 kn
>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 search elsewhere?
I'd start by
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 here
49 matches
Mail list logo
