On 2014-05-25 16:58:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-05-25 01:02:25 +0200, Tomas Vondra wrote:
> >> The cache invalidation bug was apparently fixed, but we're still getting
> >> failures (see for example markhor):
> >> http://www.pgbuildfarm.org/cgi-bin/show_history.pl
On 2014-05-25 16:58:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-05-25 01:02:25 +0200, Tomas Vondra wrote:
> >> The cache invalidation bug was apparently fixed, but we're still getting
> >> failures (see for example markhor):
> >> http://www.pgbuildfarm.org/cgi-bin/show_history.pl
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I don't really object to doing an unlocked check for another such
> database, but I'm not convinced that additional locking to try to
> prevent a race is worth its keep.
+1 on the nannyism, and +1 to ignoring the race.
Thanks,
Step
Hi,
On 2014-05-25 14:45:38 -0700, Jeff Janes wrote:
> You're welcome. If only I was as good at fixing things as at breaking
> them.
At the moment there seems to be a bigger shortage of folks being good at
breaking stuff - before the release! - than of people fixing the
resulting breakage...
Gre
Hi,
On 2014-05-25 16:59:24 -0600, Jeff Ross wrote:
> Could a check like this be added to pg_upgrade?
> Is there a downside to
> adding a column big enough to force a toast table and then dropping it for
> any table that is too large not to have a toast table but doesn't?
It can take time and perm
On Thu, May 22, 2014 at 9:51 AM, Robert Haas wrote:
>
> Suppose a user backend starts a background worker for some purpose;
> the background worker dies with an error. The infrastructure we have
> today is sufficient for the user backend to discover that the worker
> backend has died, but not why
On Sun, May 25, 2014 at 11:23:41PM +0200, Ronan Dunklau wrote:
> Le dimanche 25 mai 2014 12:41:18 David Fetter a écrit :
> > On Fri, May 23, 2014 at 10:08:06PM +0200, Ronan Dunklau wrote:
> > > Hello,
> > >
> > > Since my last proposal didn't get any strong rebuttal, please find
> > > attached a m
Hi all,
I noticed a couple of typos in Solution.pm, fixed by the patch
attached. Those things have been introduced by commits cec8394 (visual
2013 support) and 0a78320 (latest pgident run, not actually a problem
of pgident, because of a misuse of commas).
The tab problems should not be backpatched
Hi Tom,
thanks for the feedback.
On 25/05/2014 21:10, Tom Lane wrote:
> Matteo Beccati writes:
>> here's the latest version of my uuid changes patch, according to
>> proposal (2) from Tom in the thread about OSSP-UUID[1].
>
> Hmm ... this is not actually what I had in mind. Unless I'm misreadi
On Mon, May 26, 2014 at 2:01 AM, Andres Freund wrote:
> On 2014-05-25 22:35:24 +0900, Michael Paquier wrote:
>> Attached patch corrects that, reshuffling at the same time the option
>> letters parsed with getopt_long in alphabetical order.
>
> Hm. Not a big fan of this in isolation. In the attache
On 5/25/14, 11:44 AM, Andres Freund wrote:
Hi,
On 2014-05-23 08:23:57 -0600, Jeff Ross wrote:
UDB=# \x
Expanded display is on.
UDB=# SELECT attrelid::regclass, attname, attnum, attlen, *
FROM pg_attribute
WHERE attrelid = 'masterairportlist'::regclass
ORDER BY attnum ASC;
UDB=#
[ RECORD 1 ]-+
On Sunday, May 25, 2014, Heikki Linnakangas
>
wrote:
> While debugging the B-tree bug that Jeff Janes reported (
> http://www.postgresql.org/message-id/CAMkU=1y=VwF07Ay+Cpqk_
> 7fpihrctmssv9y99sbghitkxpb...@mail.gmail.com), a new issue came up:
>
> If you reach the xidStopLimit, and try to run VAC
On 05/25/2014 05:45 PM, Jeff Janes wrote:
On Sun, May 25, 2014 at 7:16 AM, Heikki Linnakangas
wrote:
On 05/21/2014 10:22 PM, Jeff Janes wrote:
Testing partial-write crash-recovery in 9.4 (e12d7320ca494fd05134847e30)
with foreign keys, I found some btree index corruption.
...
https://d
Here's an idea I tried to explain to Andres and Simon at the pub last
night, on how to reduce the spikes in the amount of WAL written at
beginning of a checkpoint that full-page writes cause. I'm just writing
this down for the sake of the archives; I'm not planning to work on this
myself.
Wh
On Sun, May 25, 2014 at 7:16 AM, Heikki Linnakangas wrote:
> On 05/21/2014 10:22 PM, Jeff Janes wrote:
>
>> Testing partial-write crash-recovery in 9.4 (e12d7320ca494fd05134847e30)
>> with foreign keys, I found some btree index corruption.
>>
>> ...
>
>> https://drive.google.com/folderview?id=0B
Le dimanche 25 mai 2014 12:41:18 David Fetter a écrit :
> On Fri, May 23, 2014 at 10:08:06PM +0200, Ronan Dunklau wrote:
> > Hello,
> >
> > Since my last proposal didn't get any strong rebuttal, please find
> > attached a more complete version of the IMPORT FOREIGN SCHEMA statement.
>
> Thanks!
>
Andres Freund writes:
> On 2014-05-25 01:02:25 +0200, Tomas Vondra wrote:
>> The cache invalidation bug was apparently fixed, but we're still getting
>> failures (see for example markhor):
>> http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=markhor&br=HEAD
>> I see there's a transaction (COMM
Tomas Vondra writes:
> Should we change the type of nxacts to int64 (thus allowing '-t' with
> 64-bit integers), or just the overflow in the printf call? I don't find
> it very practical to use -t with values not fitting into 32-bits (the -T
> seems better to do that), so I'm inclined to just fix
On Fri, May 23, 2014 at 10:08:06PM +0200, Ronan Dunklau wrote:
> Hello,
>
> Since my last proposal didn't get any strong rebuttal, please find attached a
> more complete version of the IMPORT FOREIGN SCHEMA statement.
Thanks!
Please to send future patches to this thread so people can track them
On 25.5.2014 20:32, Tom Lane wrote:
> Tomas Vondra writes:
>> On 25.5.2014 19:05, Andres Freund wrote:
>>> That's not right though. On windows a long (indicated by the %l) is only
>>> 4 bytes wide. Check INT64_FORMAT. That's generated by configure/platform
>>> template files and should always be c
Matteo Beccati writes:
> here's the latest version of my uuid changes patch, according to
> proposal (2) from Tom in the thread about OSSP-UUID[1].
Hmm ... this is not actually what I had in mind. Unless I'm misreading
the patch, this nukes the "uuid-ossp" extension entirely in favor of a
new ex
Tomas Vondra writes:
> On 25.5.2014 19:05, Andres Freund wrote:
>> That's not right though. On windows a long (indicated by the %l) is only
>> 4 bytes wide. Check INT64_FORMAT. That's generated by configure/platform
>> template files and should always be correct.
> Oh, right. v2 of the patch atta
On 25.5.2014 19:05, Andres Freund wrote:
>> printf("number of transactions per client: %d\n", nxacts);
>> -printf("number of transactions actually processed: %d/%d\n",
>> +printf("number of transactions actually processed: %ld/%d\n",
>> n
Jeff Davis writes:
> Idea:
> Let's say we have a routine PinBufferTag, that's like PinBuffer but it
> takes an additional BufferTag argument. When it locks the buffer header,
> it would also compare the argument to the buffer's tag, and if they
> don't match, return a status indicating that it's
Andres Freund writes:
> On 2014-05-25 09:17:24 +0200, Fabien COELHO wrote:
>> sql> CREATE COLLATION "french" (locale='fr_FR.utf8');
>> ERROR: could not create locale "fr_FR.utf8": Success
> This seems to be a glibc bug. If a nonexistant locale has already been
> asked for errno is set to 0 inste
Hi,
On 2014-05-23 08:23:57 -0600, Jeff Ross wrote:
> UDB=# \x
> Expanded display is on.
> UDB=# SELECT attrelid::regclass, attname, attnum, attlen, *
> FROM pg_attribute
> WHERE attrelid = 'masterairportlist'::regclass
> ORDER BY attnum ASC;
> UDB=#
> [ RECORD 1 ]-+--
> ...
A quic
Hi,
Here is my first report. You can also find it on my Gitlab [0].
Week 1 - 2014/05/25
For this first week, I have written a test script that generates some
simple datasets, and produces an image containing the output of the MADlib
clustering algorithms.
This script can be called like this:
./
On 2014-05-25 01:02:25 +0200, Tomas Vondra wrote:
> On 14.5.2014 15:17, Andres Freund wrote:
> The cache invalidation bug was apparently fixed, but we're still getting
> failures (see for example markhor):
>
> http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=markhor&br=HEAD
>
> I see there's
Hi,
On 2014-05-25 18:05:03 +0200, Tomas Vondra wrote:
> I've been running a few longer pgbench tests (~week), and I've run into
> this:
> number of transactions actually processed: -1785047856
> latency average: -10.846 ms
> tps = -2950.492090 (including connections establishing)
> tps = -2950.49
Hi,
On 2014-05-25 22:35:24 +0900, Michael Paquier wrote:
> As written in subject, pg_recvlogical does not work properly with
> option -I but it should:
> $ pg_recvlogical -I 0/0
> pg_recvlogical: invalid option -- I
> Try "pg_recvlogical --help" for more information.
> $ pg_recvlogical --help | gr
Hi,
I've been running a few longer pgbench tests (~week), and I've run into
this:
transaction type: SELECT only
scaling factor: 1250
query mode: simple
number of clients: 32
number of threads: 4
duration: 605000 s
number of transactions actually processed: -1785047856
latency average: -10.846 ms
On 2014-04-18 11:50:55 -0300, Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund
> > wrote:
> > > It's this (older) assertion in HeapTupleHeaderGetCmax():
> > >
> > >
> > > Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(
Context:
A patch from a while ago was rejected:
http://www.postgresql.org/message-id/1369886097.23418.0.camel@jdavis
Most of the objection seemed to be that extra page pins might happen in
some circumstances, such as this one mentioned by Heikki:
http://www.postgresql.org/message-id/50fd11c5.10
On 2014-05-25 11:40:09 -0400, Heikki Linnakangas wrote:
> So, vac_truncate_clog() tries to get a new transaction ID, which fails
> because we've already reached the stop-limit. vac_truncate_clog() doesn't
> really need a new XID to be assigned, though, it only uses it to compare
> against datfrozen
Hi,
On 2014-05-25 09:17:24 +0200, Fabien COELHO wrote:
> sql> CREATE COLLATION "french" (locale='fr_FR.utf8');
> ERROR: could not create locale "fr_FR.utf8": Success
>
> The collation creation fails, not sure why yet. However, the "error ..
> success" message is especially unhelpful.
This s
While debugging the B-tree bug that Jeff Janes reported
(http://www.postgresql.org/message-id/CAMkU=1y=vwf07ay+cpqk_7fpihrctmssv9y99sbghitkxpb...@mail.gmail.com),
a new issue came up:
If you reach the xidStopLimit, and try to run VACUUM, it fails with error:
jjanes=# vacuum;
ERROR: database i
On 05/21/2014 10:22 PM, Jeff Janes wrote:
Testing partial-write crash-recovery in 9.4 (e12d7320ca494fd05134847e30)
with foreign keys, I found some btree index corruption.
28807 VACUUM 2014-05-21 15:33:46.878 PDT:ERROR: right sibling 4044 of
block 460 is not next child 23513 of block 1264 in ind
Hi all,
As written in subject, pg_recvlogical does not work properly with
option -I but it should:
$ pg_recvlogical -I 0/0
pg_recvlogical: invalid option -- I
Try "pg_recvlogical --help" for more information.
$ pg_recvlogical --help | grep "\-I"
-I, --startpos=PTR where in an existing slot s
Hello David,
sorry for the late response. I will try out your changes from the view
of a user in mid-June. However, I can't do a trustworthy code review as
I'm not an experienced postgre-hacker (yet).
Best Regards
Thomas
Am 14.04.2014 13:19, schrieb David Rowley:
On 14 April 2014 03:31, To
Hi, hackers!
There are first results of my work on GSoC project "Index-only scans for
GIST".
1. Version of my project code is in forked repository
https://github.com/lubennikovaav/postgres/tree/indexonlygist2
Patch is in attachments
- This version is only for one-column indexes
- fetch() method is
On 05/20/2014 01:46 PM, Fujii Masao wrote:
> On Mon, Mar 17, 2014 at 1:16 PM, Haribabu Kommi
> wrote:
>> ...
>> I Implemented a proof of concept patch to see whether the buffer pool
>> split can improve the performance or not.
>>
>> Summary of the changes:
>> 1. The priority buffers are allocated
sh> lsb_release -d
Description: Ubuntu 14.04 LTS
Codename: trusty
sh> uname -a
Linux sto 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64
x86_64 x86_64 GNU/Linux
sh> locale -a
C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
42 matches
Mail list logo
