On Mon, Jun 15, 2015 at 8:26 AM, Michael Paquier wrote:
> hamster is legendary slow and has a slow disc, hence it improves
> chances of catching race conditions, and it is the only slow buildfarm
> machine enabling the TAP tests (by comparison dangomushi has never
> failed with the TAP tests) hence
On 6/17/15 3:35 PM, Keith Fiske wrote:
> The current HEAD of postgres in the git repo is not building when using
> "make world". It's been like this for about a month or so that I've been
> aware of. I didn't really need the world build so been making due
> without it. At PGCon now, though, so aske
On Thu, Jun 18, 2015 at 9:47 AM, Noah Misch wrote:
> On Wed, Jun 03, 2015 at 05:25:45PM +0900, Michael Paquier wrote:
>> On Tue, Jun 2, 2015 at 4:19 PM, Michael Paquier
>> wrote:
>> > On Sun, May 24, 2015 at 2:43 AM, Noah Misch wrote:
>> > > It would be good to purge the code of precisions on
On Wed, Jun 03, 2015 at 05:25:45PM +0900, Michael Paquier wrote:
> On Tue, Jun 2, 2015 at 4:19 PM, Michael Paquier
> wrote:
> > On Sun, May 24, 2015 at 2:43 AM, Noah Misch wrote:
> > > It would be good to purge the code of precisions on "s" conversion
> > > specifiers,
> > > then Assert(!point
Posting v2 of the patch, incorporating some helpful suggestions from Merlin.
Cheers,
BJ
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***
*** 14800,14805 SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS t(ls,n);
--- 14800,14811
+pg_noti
On 06/17/2015 01:07 PM, Tom Lane wrote:
Keith Fiske writes:
The current HEAD of postgres in the git repo is not building when using
"make world". It's been like this for about a month or so that I've been
aware of. I didn't really need the world build so been making due without
it. At PGCon no
On Thu, 18 Jun 2015 at 08:19 Merlin Moncure wrote:
>
> scratch that. that note already exists in sql-notify.html. Instead,
> I'd modify that section to note that you can check queue usage with
> your new function.
>
>
I have already done so. Under the paragraph about the queue filling up, I
ha
On Wed, Jun 17, 2015 at 01:43:55PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Jun 15, 2015 at 12:37:43PM -0400, Tom Lane wrote:
> >> It's mere chance that the order of calls to pg_perm_setlocale() is
> >> such that the code works now; and it's not hard to imagine future
> >> changes i
On Wed, Jun 17, 2015 at 5:15 PM, Merlin Moncure wrote:
> *) A note regarding the 50% (0.5) threshold raising warnings in the
> log might be appropriate here
scratch that. that note already exists in sql-notify.html. Instead,
I'd modify that section to note that you can check queue usage with
yo
On Wed, Jun 17, 2015 at 5:31 AM, Brendan Jurd wrote:
> Hello hackers,
>
> I present a patch to add a new built-in function
> pg_notify_queue_saturation().
>
> The purpose of the function is to allow users to monitor the health of their
> notification queue. In certain cases, a client connection l
On Thu, Jun 18, 2015 at 3:39 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> From 077d675795b4907904fa4e85abed8c4528f4666f Mon Sep 17 00:00:00 2001
>> From: Michael Paquier
>> Date: Sat, 19 Jul 2014 10:40:20 +0900
>> Subject: [PATCH 3/3] Buffer capture facility: check WAL replay consisten
Alvaro Herrera writes:
> Yeah, the case is pretty weird and I'm not really sure that the server
> ought to be expected to behave. But if this is actually the only part
> of the server that misbehaves because of sudden gigantic time jumps, I
> think it's fair to patch it. Here's a proposed patch.
On 6/15/15 4:45 PM, Peter Eisentraut wrote:
> On 6/8/15 3:16 PM, Peter Eisentraut wrote:
>> I'm looking at a case on 9.4.1 where the last_analyze and last_vacuum
>> stats for a handful of tables seem stuck. They don't update after
>> running an ANALYZE or VACUUM command, and they don't react to
>>
On 6/16/15 8:26 AM, Sawada Masahiko wrote:
I noticed while using gin function of pageinspect that there are some
inconsistency data types.
For example, data type of GinMetaPageData.head, and tail is
BlockNumber, i.g, uint32.
But in ginfunc.c, we get that value as int64.
You can't put a uint32
Keith Fiske writes:
> The current HEAD of postgres in the git repo is not building when using
> "make world". It's been like this for about a month or so that I've been
> aware of. I didn't really need the world build so been making due without
> it. At PGCon now, though, so asked Bruce and he sai
On 6/17/15 2:04 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
Related to idea of an 'auto join', I do wish we had the ability to access
columns in a referenced FK table from a referring key; something like SELECT
customer_id.first_name FROM invoice (which would be translated to SELECT
first_name F
Michael Paquier wrote:
> From 077d675795b4907904fa4e85abed8c4528f4666f Mon Sep 17 00:00:00 2001
> From: Michael Paquier
> Date: Sat, 19 Jul 2014 10:40:20 +0900
> Subject: [PATCH 3/3] Buffer capture facility: check WAL replay consistency
Is there a newer version of this tech?
--
Álvaro Herrera
On Thu, 18 Jun 2015 at 03:06 Gurjeet Singh wrote:
> I don't see this in the CF app; can you please add it there?
>
Done. I did try to add it when I posted the email, but for some reason I
couldn't connect to commitfest.postgresql.org at all. Seems fine now,
though.
Cheers,
BJ
Jim Nasby wrote:
> Related to idea of an 'auto join', I do wish we had the ability to access
> columns in a referenced FK table from a referring key; something like SELECT
> customer_id.first_name FROM invoice (which would be translated to SELECT
> first_name FROM invoice JOIN customer USING( cust
Hi,
I'm currently running some tests on a 3TB TPC-H data set, and I tripped
over a pretty bad n_distinct underestimate, causing OOM in HashAgg
(which somehow illustrates the importance of the memory-bounded hashagg
patch Jeff Davis is working on).
The problem is Q18, particularly this simple
Noah Misch writes:
> On Mon, Jun 15, 2015 at 12:37:43PM -0400, Tom Lane wrote:
>> It's mere chance that the order of calls to pg_perm_setlocale() is
>> such that the code works now; and it's not hard to imagine future
>> changes in gettext, or reordering of our own code, that would break it.
> pg
I don't see this in the CF app; can you please add it there?
Best regards,
On Wed, Jun 17, 2015 at 3:31 AM, Brendan Jurd wrote:
> Hello hackers,
>
> I present a patch to add a new built-in function
> pg_notify_queue_saturation().
>
> The purpose of the function is to allow users to monitor the
Haribabu Kommi writes:
> I can think of a case where the "launcher_determine_sleep" function
> returns a big sleep value because of system time change.
> Because of that it is possible that the launcher is not generating
> workers to do the vacuum. May be I am wrong.
I talked with Alvaro about th
Prakash Itnal wrote:
> Currently the issue is easily reproducible. Steps to reproduce:
> * Set some aggressive values for auto-vacuuming.
> * Run a heavy database update/delete/insert queries. This leads to invoking
> auto-vacuuming in quick successions.
> * Change the system time to older for eg.
On 2015-06-15 11:32, Vik Fearing wrote:
I've been looking at these patches a bit and here are some comments:
Thanks for looking at this.
Patch 1: seqam
I would like to see an example in the docs for CREATE SEQUENCE. That's
perhaps not possible (or desirable) with only the "local" seqam? N
Hi,
On 05/13/15 23:07, Jeff Janes wrote:
With the warning it is very hard to correlate the discrepancy you do
see with which column is causing it, as the warnings don't include
table or column names (Assuming of course that you run it on a
substantial database--if you just run it on a few toy ca
On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
wrote:
> We saw a rather extreme performance problem in a cluster upgraded from
> 9.1 to 9.3. It uses a largish number of child tables (partitions) and
> many columns. Planning a simple UPDATE via the base table started
> using a very large amount of
Hi
We saw a rather extreme performance problem in a cluster upgraded from
9.1 to 9.3. It uses a largish number of child tables (partitions) and
many columns. Planning a simple UPDATE via the base table started
using a very large amount of memory and CPU time.
My colleague Rushabh Lathia tracked
On Mon, Jun 15, 2015 at 12:37:43PM -0400, Tom Lane wrote:
> After further thought, ISTM that this bug is evidence that 5f538ad
> was badly designed, and the proposed fix has blinkers on. If
> pg_bind_textdomain_codeset() is looking at the locale environment,
> we should not be calling it from insi
On Wed, Jun 17, 2015 at 9:07 PM, Fujii Masao wrote:
> On Wed, Jun 17, 2015 at 4:57 PM, Vladimir Borodin wrote:
>>
>> 17 июня 2015 г., в 9:48, Michael Paquier
>> написал(а):
>>
>> On Wed, Jun 17, 2015 at 3:17 PM, Michael Paquier
>> wrote:
>>
>> As pointed by dev1ant on the original bug report, p
On Wed, Jun 17, 2015 at 4:57 PM, Vladimir Borodin wrote:
>
> 17 июня 2015 г., в 9:48, Michael Paquier
> написал(а):
>
> On Wed, Jun 17, 2015 at 3:17 PM, Michael Paquier
> wrote:
>
> As pointed by dev1ant on the original bug report, process_remote_file
> should ignore files named as pg_xlog/xlogt
Hello hackers,
I present a patch to add a new built-in function
pg_notify_queue_saturation().
The purpose of the function is to allow users to monitor the health of
their notification queue. In certain cases, a client connection listening
for notifications might get stuck inside a transaction, a
> 17 июня 2015 г., в 9:48, Michael Paquier
> написал(а):
>
> On Wed, Jun 17, 2015 at 3:17 PM, Michael Paquier
> wrote:
>> As pointed by dev1ant on the original bug report, process_remote_file
>> should ignore files named as pg_xlog/xlogtemp.*, and I think that this
>> is the right thing to do.
On Wed, Jun 17, 2015 at 2:17 PM, Prakash Itnal wrote:
> Hi,
>
> Currently the issue is easily reproducible. Steps to reproduce:
> * Set some aggressive values for auto-vacuuming.
> * Run a heavy database update/delete/insert queries. This leads to invoking
> auto-vacuuming in quick successions.
>
Hi,
Currently we observed that certain postgres child process, for eg.
autovacuum worker, are not working as expected if there is a system time
change. So I wanted to know if postgres already supports system time
changes or not.
Please confirm if postgres already handles system time changes or no
35 matches
Mail list logo
