On 2015-10-31 12:52:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Another angle would be trying to reduce the effects of longrunning
> > transaction. Right now holding a snapshot open for 100 seconds results
> > in profiles like this: ...
> > which is pretty extreme. It's not such a seldom
Andres Freund writes:
> Another angle would be trying to reduce the effects of longrunning
> transaction. Right now holding a snapshot open for 100 seconds results
> in profiles like this: ...
> which is pretty extreme. It's not such a seldom thing to hold a snapshot
> (e.g. pg_dump...) open for a
Hi,
I previously complained about analyze keeping a snapshot while running in:
http://archives.postgresql.org/message-id/20141018174909.GA5790%40alap3.anarazel.de
since then I've been bitten by that, and I've seen other people being
bitten by it.
on a scale 400 database (so analyze actually take
Tom Lane wrote:
> Thom Brown writes:
> > On 29 January 2011 11:12, Magnus Hagander wrote:
> >> Any idea why this is happening?
>
> > I don't know what's causing that since I can see both of those IDs are
> > present, but I should also mention that the identities those linkends
> > point to shoul
On Sat, Jan 29, 2011 at 18:33, Tom Lane wrote:
> Magnus Hagander writes:
>> The snapshot builds are failing with:
>> openjade:installation.sgml:1010:58:X: reference to non-existent ID
>> "UUID-OSSP"
>> openjade:installation.sgml:1044:54:X: reference to non-existent ID "XML2"
>> openjade:/usr/loc
On 29 January 2011 17:58, Tom Lane wrote:
> Thom Brown writes:
>> On 29 January 2011 11:12, Magnus Hagander wrote:
>>> Any idea why this is happening?
>
>> I don't know what's causing that since I can see both of those IDs are
>> present, but I should also mention that the identities those linke
Thom Brown writes:
> On 29 January 2011 11:12, Magnus Hagander wrote:
>> Any idea why this is happening?
> I don't know what's causing that since I can see both of those IDs are
> present, but I should also mention that the identities those linkends
> point to should have xreflabel attributes.
Magnus Hagander writes:
> The snapshot builds are failing with:
> openjade:installation.sgml:1010:58:X: reference to non-existent ID "UUID-OSSP"
> openjade:installation.sgml:1044:54:X: reference to non-existent ID "XML2"
> openjade:/usr/local/share/sgml/docbook/dsssl/modular/html/dblink.dsl:203:1:
On 29 January 2011 11:12, Magnus Hagander wrote:
> The snapshot builds are failing with:
>
> openjade:installation.sgml:1010:58:X: reference to non-existent ID "UUID-OSSP"
> openjade:installation.sgml:1044:54:X: reference to non-existent ID "XML2"
> openjade:/usr/local/share/sgml/docbook/dsssl/mod
The snapshot builds are failing with:
openjade:installation.sgml:1010:58:X: reference to non-existent ID "UUID-OSSP"
openjade:installation.sgml:1044:54:X: reference to non-existent ID "XML2"
openjade:/usr/local/share/sgml/docbook/dsssl/modular/html/dblink.dsl:203:1:E:
XRef LinkEnd to missing ID 'U
I just checked:
ftp://ftp.us.postgresql.org/dev/postgresql-base-snapshot.tar.gz
and the snapshot has the proper file contents, showing doc/TODO with a
date of October 19th.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 8
Kovacs Baldvin <[EMAIL PROTECTED]> writes:
> Could somebody explain me the mechanism in the backend,
> which is responsible for the followings. (I tried to
> look around snapshots, but couldnt figure out th answer).
> In a transaction, isol. read comitted, a select from a
> table can see the comi
Hello.
Could somebody explain me the mechanism in the backend,
which is responsible for the followings. (I tried to
look around snapshots, but couldnt figure out th answer).
In a transaction, isol. read comitted, a select from a
table can see the comitted changes by others, but
a previously decl
The Hermit Hacker writes:
> ... should be working again. I hard coded the path so that it finds
> bison, which appears to be what was killing it ...
That sounds suspiciously like the respective cron user not having
/usr/local/bin is its path.
--
Peter Eisentraut [EMAIL PROTECTED] h
... should be working again. I hard coded the path so that it finds
bison, which appears to be what was killing it ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebs
15 matches
Mail list logo