; ERROR: could not read block 12281 in file "base/16384/29153": read only 0
> of 8192 bytes
> ginopino=# select * from stato where id=409; <<< IT WORKS FINE
--
Brian Sutherland
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Tue, May 31, 2016 at 04:49:26PM +1000, Venkata Balaji N wrote:
> On Mon, May 30, 2016 at 11:37 PM, Brian Sutherland
> wrote:
>
> > I'm running a streaming replication setup with PostgreSQL 9.5.2 and have
> > started seeing these errors on a few INSERTs:
> >
checksums switched on so am suspecting a streaming
replication bug. Anyone know of a recent bug which could have caused
this?
--
Brian Sutherland
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Feb 18, 2015 at 10:34:33AM -0500, Tom Lane wrote:
> Brian Sutherland writes:
> > If I run this set of commands against PostgreSQL 9.4.1 I pg_restore
> > throws an error with a permission problem. Why it does so is a mystery
> > to me, given that the user perfor
or relation x
Command was: REFRESH MATERIALIZED VIEW myview;
In pg_hba I am using the "trust" method for everything (this is a test
cluster).
Is this expected behaviour or a bug?
--
Brian Sutherland
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
On Thu, Jan 17, 2013 at 01:25:54PM +0100, Alban Hertroys wrote:
> On 17 January 2013 12:30, Brian Sutherland wrote:
>
> > > (we use buildout for our Python code, but our plpythonu stored
> > > procedures use the stock standard Python environment, as provided by
&
On Thu, Jan 17, 2013 at 03:18:09PM +0700, Stuart Bishop wrote:
> On Mon, Jan 14, 2013 at 11:30 PM, Brian Sutherland
> wrote:
> > Hi,
> >
> > I have a plpython stored procedure which sometimes fails when I run my
> > applications automated test suite. The procedure i
On Mon, Jan 14, 2013 at 09:05:09AM -0800, Adrian Klaver wrote:
> On 01/14/2013 08:30 AM, Brian Sutherland wrote:
> >Hi,
> >
> >I have a plpython stored procedure which sometimes fails when I run my
> >applications automated test suite. The procedure is called hundreds o
On Wed, Jan 16, 2013 at 08:10:26AM +1100, Chris Angelico wrote:
> On Tue, Jan 15, 2013 at 4:55 AM, Brian Sutherland
> wrote:
> > I'm guessing that it's some kind of race condition, but I wouldn't know
> > where to start looking.
>
> Look for a recursive i
On Mon, Jan 14, 2013 at 09:05:09AM -0800, Adrian Klaver wrote:
> On 01/14/2013 08:30 AM, Brian Sutherland wrote:
> >Hi,
> >
> >I have a plpython stored procedure which sometimes fails when I run my
> >applications automated test suite. The procedure is called hundreds o
hange or disappear. The behaviour is
the same with PostgreSQL versions 9.2.2 and 9.1.7.
I have tried (but failed) to reproduce this error in a simple .sql
script. Outside of the tests, it always seems to work.
Having run into a brick wall debugging this, I'm hoping there's someone
here
11 matches
Mail list logo
