On 6/14/15 10:22 AM, Alvaro Herrera wrote:
>To me, it feels like there are two different features here that would
>be better separated. First, there's the idea of having a table that
>gets auto-joined to other tables whenever you access it, so that the
>user sees one really wide table but really
On 6/8/15 3:26 PM, Joel Jacobson wrote:
So I've heard from Magnus Hagander today IRL at our Stockholm PostgreSQL
User Group meeting where we discussed this idea. He told me the overhead
in the statistics collector is mainly when reading from it, not that
much when writing to it.
I've heard enou
On 6/14/15 9:50 AM, Alvaro Herrera wrote:
+ values[0] = MultiXactState->oldestMultiXactId;
What about oldestOffset and offsetStopLimit? Seems those would be useful
too. Looks good other than that.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in
On Fri, Jun 12, 2015 at 9:02 PM, Fujii Masao wrote:
>> You want to draft a patch? Should I?
>
> Please feel free to try that! :)
OK, so attached are a patch and a test case able to trigger easily the
error. Apply the patch and run the test case to reproduce the
following failure:
$ ERROR: could n
Hi,
@Avaro Herrera, Thanks for quick reply. I was on leave and hence not able
to reply soon.
This issue was observed on customer site. However after long discussion and
digging into what happened around the date 2nd May 2015, we got to know
that NTP server suddenly went back in time to 1995. It r
Hi,
Thank you for comments. and Sorry for my late response.
>>
>> pg_stat_vacuum view
>>
>>
>> I understand it is not good to simply add more counters in
>> pg_stat_*_tables. For now, I'd like to suggest an extension
>> which can confirm vacuum statistics
In XidInMVCCSnapshot, it will check xid from tuple if is in snapshot->subxip.
It means tuple store subtransaction?
But in PushTransaction, I see TransactionState.subTransaction will assign
currentSubTransactionId, currentSubTransactionId will reinitialize in
StartTransaction. So I think tuple s
>
> Well, for starters you're looking at an estimation miss. The
> exhaustive search found the 'cheaper' plan than what geqo came up
> with, but that did not correlate to execution time. This is a common
> and frustrating problem. Generally to try and avoid it it's good to
> avoid things in tabl
On Mon, Jun 15, 2015 at 9:33 PM, Michael Meskes wrote:
> On Sun, Jun 14, 2015 at 08:43:13PM +0900, Michael Paquier wrote:
>> point out that there is still a leak in connect.c. Per se the attached
>> patch, that does not check for a NULL pointer before ecpg_free because
>> other code paths in the r
On Tue, 16 Jun 2015 at 07:52 Merlin Moncure wrote:
> It goes back to the adage, 'Everyone wants to be an author but nobody
> wants to write'.
A more accurate version would be "Everyone wants to be an author, some want
to write, but nobody likes being rejected by publishers".
> For posterity,
http://vldb.org/pvldb/vol5/p1790_andrewlamb_vldb2012.pdf
In sketch:
There is the concept of a Write-Optimized-Store (WOS) and
Read-optimized-store (ROS), and a TupleMover that moves records from WOS to
ROS (some what like vacuum), and from ROS to WOS for updates. It seems to
me that heap is natur
On Mon, Jun 15, 2015 at 3:16 PM, Brendan Jurd wrote:
> On Tue, 16 Jun 2015 at 05:36 Merlin Moncure wrote:
>>
>> On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera
>> wrote:
>> > Brendan Jurd wrote:
>> >> However, given the response to my original email,
>> >> it's likely that effort would be a was
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
> pg_stat_reset_single_table_counters(). All of th
On Fri, Jun 12, 2015 at 7:27 PM, Steve Kehlet wrote:
> Just wanted to report that I rolled back my VM to where it was with 9.4.2
> installed and it wouldn't start. I installed 9.4.4 and now it starts up just
> fine:
>
>> 2015-06-12 16:05:58 PDT [6453]: [1-1] LOG: database system was shut down
>>
On Tue, 16 Jun 2015 at 05:36 Merlin Moncure wrote:
> On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera
> wrote:
> > Brendan Jurd wrote:
> >> However, given the response to my original email,
> >> it's likely that effort would be a waste of time.
> >
> > I think tumbleweed responses are more in li
On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera
wrote:
> Brendan Jurd wrote:
>> Hi Kevin,
>>
>> I never found a direct solution to this problem. I still feel that a
>> function to find the size of the notification queue would be a handy
>> feature to have, and I would be willing to take a shot at
Brendan Jurd wrote:
> Hi Kevin,
>
> I never found a direct solution to this problem. I still feel that a
> function to find the size of the notification queue would be a handy
> feature to have, and I would be willing to take a shot at writing such a
> feature. However, given the response to my
On Thu, Jun 11, 2015 at 9:55 AM, Amit Kapila
wrote:
>
> On Wed, Jun 10, 2015 at 12:09 PM, Fujii Masao
wrote:
> >
> > On Tue, Jun 9, 2015 at 3:29 PM, Amit Kapila
wrote:
> > > On Tue, Jun 9, 2015 at 10:56 AM, Fujii Masao
wrote:
> > >> Or what about removing tablespace_map file at the beginning of
On 04/29/15 18:33, Tomas Vondra wrote:
OK, I do understand that. So what about pull_varnos_walker and
pull_varattnos_walker - what about teaching them about RestrictInfos?
Attached is a patch fixing the issue by handling RestrictInfo in
pull_varnos_walker and pull_varattnos_walker.
--
Tom
Thanks for the timely response!
On Mon, Jun 15, 2015 at 2:07 PM Brendan Jurd [via PostgreSQL] <
ml-node+s1045698n5853928...@n5.nabble.com> wrote:
> Hi Kevin,
>
> I never found a direct solution to this problem. I still feel that a
> function to find the size of the notification queue would be a
v3 rebase (after pgbench moved to src/bin) and minor style tweaking.
v4 adds a fix to another progress timing issue:
Currently if pgbench/postgres get stuck somewhere, the report catches up
by repeating progresses several time in a row, which looks like that:
progress: 10.0 s ...
progr
Hi Kevin,
I never found a direct solution to this problem. I still feel that a
function to find the size of the notification queue would be a handy
feature to have, and I would be willing to take a shot at writing such a
feature. However, given the response to my original email,
it's likely tha
Hi BJ,
What approach did you end up using?
Thanks,
Kevin
--
View this message in context:
http://postgresql.nabble.com/Function-to-get-size-of-notification-queue-tp5738461p5853923.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mail
Andrew Dunstan writes:
> However, there doesn't appear to be any such animal as FunctionLookup().
> Shouldn't it say fmgr_info() instead?
Hmmm ... I think there may have been at the time the comment was written,
but yeah, please change that.
regards, tom lane
--
Sent
Noah Misch writes:
> A faster test is to set LC_CTYPE=C in the environment and run "postgres
> --version". The root cause is a bug my commit 5f538ad introduced at the start
> of the 9.4 cycle. pg_perm_setlocale() now calls pg_bind_textdomain_codeset(),
> which calls setlocale(LC_CTYPE, NULL). P
Andres Freund wrote:
> A first version to address this problem can be found appended to this
> email.
>
> Basically it does:
> * Whenever more than MULTIXACT_MEMBER_SAFE_THRESHOLD are used, signal
> autovacuum once per members segment
> * For both members and offsets, once hitting the hard limi
... has this comment (fmgr.h:506):
/* These are for invocation of a function identified by OID with a
* directly-computed parameter list. Note that neither arguments
nor result
* are allowed to be NULL. These are essentially FunctionLookup()
followed
* by FunctionCallN()
While reviewing the seqam patches, I noticed that psql has tab
completion for ALTER SEQUENCE, but not for CREATE SEQUENCE.
The attached trivial patch fixes that.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation e
On Sun, Jun 14, 2015 at 6:43 PM, David Kamholz wrote:
> I've encountered a query with 11 joins whose execution time (i.e., the time
> not taken up by planning) is significantly faster with geqo on rather than
> off. This is surprising to me and seems like it might be a bug in the
> planner, so I a
Noah Misch writes:
> On Wed, Jun 10, 2015 at 10:09:38AM -0400, Tom Lane wrote:
>> Hm. I could understand getting encoding difficulties in that environment,
>> but it's hard to see why they'd manifest like this. Can you trace through
>> pg_perm_setlocale and figure out why it's reporting failure?
On Sun, Jun 14, 2015 at 08:43:13PM +0900, Michael Paquier wrote:
> point out that there is still a leak in connect.c. Per se the attached
> patch, that does not check for a NULL pointer before ecpg_free because
> other code paths in the routine patched don't do so. So you get
> something locally co
On 06/15/2015 12:50 AM, Petr Jelinek wrote:
> Hi,
>
> I am getting tired installing manually required extensions manually. I
> was wondering if we might want to add option to CREATE SEQUENCE that
> would allow automatic creation of the extensions required by the
> extension that is being installed
I've been looking at these patches a bit and here are some comments:
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? Not sure.
In the docs for pg_class, there is no mention that relam refers
On Fri, Jun 12, 2015 at 10:58 PM, Alvaro Herrera
wrote:
>
> Amit Kapila wrote:
> > On Fri, Jun 12, 2015 at 4:33 AM, Alvaro Herrera <
alvhe...@2ndquadrant.com>
> > wrote:
> > > One critical detail is what will be used to identify a heap row when
> > > talking to a CS implementation. There are two
34 matches
Mail list logo
