Noah Misch n...@leadboat.com 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
On Sun, Jun 14, 2015 at 6:43 PM, David Kamholz lautges...@gmail.com 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
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 limits,
... 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
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
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 tables
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 like
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
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
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 ...
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 handy
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.
--
On Thu, Jun 11, 2015 at 9:55 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Wed, Jun 10, 2015 at 12:09 PM, Fujii Masao masao.fu...@gmail.com
wrote:
On Tue, Jun 9, 2015 at 3:29 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Tue, Jun 9, 2015 at 10:56 AM, Fujii Masao
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 tumbleweed/ response to my original email,
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 tumbleweed/ response
Noah Misch n...@leadboat.com 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
Andrew Dunstan and...@dunslane.net 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,
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
On Tue, 16 Jun 2015 at 05:36 Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Brendan Jurd wrote:
However, given the tumbleweed/ response to my original email,
it's likely that effort would be a waste of time.
I
On Fri, Jun 12, 2015 at 7:27 PM, Steve Kehlet steve.keh...@gmail.com 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
On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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 the
On Mon, Jun 15, 2015 at 3:16 PM, Brendan Jurd dire...@gmail.com wrote:
On Tue, 16 Jun 2015 at 05:36 Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Brendan Jurd wrote:
However, given the tumbleweed/ response to my
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
On Wed, Jun 10, 2015 at 10:09:38AM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
I can reproduce this with initdb --locale=C,
postgresql-9.4.3-1-windows-binaries.zip (32-bit), Windows 7 x64, and the
Windows ANSI code page set to CP936. (Choose Chinese (Simplified, PRC) in
On Tue, 16 Jun 2015 at 07:52 Merlin Moncure mmonc...@gmail.com 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.
On Mon, Jun 15, 2015 at 9:33 PM, Michael Meskes mes...@postgresql.org 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
27 matches
Mail list logo
