On Sat, Oct 11, 2014 at 7:02 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Sat, Oct 11, 2014 at 6:40 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-10-11 07:26:57 +0530, Amit Kapila wrote:
On Sat, Oct 11, 2014 at 7:00 AM, Andres Freund and...@2ndquadrant.com
And since
On Tue, Oct 7, 2014 at 8:38 AM, Ali Akbar the.ap...@gmail.com wrote:
2014-10-06 22:51 GMT+07:00 Marti Raudsepp ma...@juffo.org:
the one that tests values just before numeric overflow
Actually I don't know if that's too useful. I think you should add a
test case that causes an error to be
On 10/14/2014 04:18 AM, Shigeru Hanada wrote:
I found a minor typo in bgworker.sgml. Patch attached. It should be
applied to 9.4 too.
Fixed, thanks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Oct 14, 2014 at 6:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
Well. Unless I miss something it doesn't resolve the problem that
started this thread. Namely that it's currently impossible to write
regression using EXPLAIN (ANALYZE, TIMING
On 10/13/2014 06:57 PM, Heikki Linnakangas wrote:
Hmm, we could set releaseOK in LWLockWaitForVar(), though, when it
(re-)queues the backend. That would be less invasive, for sure
(attached). I like this better.
Committed this.
- Heikki
--
Sent via pgsql-hackers mailing list
On Mon, Oct 13, 2014 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote:
IMHO, putting some prototypes for a .c file in one header and others
in another header is going to make it significantly harder to figure
out which files you need to #include when. Keeping a simple rule there
seems
On Mon, Oct 13, 2014 at 11:31 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I'm going to move the remaining patches to the next commitfest, and close
the August one.
Many thanks for managing commit fest in a best possible
way. I think it is big bonanza for all the authors who have
On 2014-10-13 21:01:57 +0300, Heikki Linnakangas wrote:
The August commitfest is still Open, with a few more patches left. The
patches that remain have stayed in limbo for a long time. It's not realistic
to expect anything to happen to them.
I'm going to move the remaining patches to the
If we remove --fsync-interval, resoponse time to user will not
be
delay.
Although, fsync will be executed multiple times in a short period.
And there is no way to solve the problem without
--fsync-interval, what
should we do about it?
I'm sorry, I didn't understand that.
On Thu, Oct 9, 2014 at 6:17 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, Sep 26, 2014 at 7:04 PM, Robert Haas robertmh...@gmail.com
wrote:
On another point, I think it would be a good idea to rebase the
bgreclaimer patch over what I committed, so that we have a
clean patch
On 2014-10-14 15:24:57 +0530, Amit Kapila wrote:
After that I observed that contention for LW_SHARED has reduced
for this load, but it didn't help much in terms of performance, so I again
rechecked the profile and this time most of the contention is moved
to spinlock used in dynahash for buf
(2014/09/12 16:30), Etsuro Fujita wrote:
(2014/09/11 20:51), Heikki Linnakangas wrote:
On 09/11/2014 02:30 PM, Etsuro Fujita wrote:
So, should I split the patch into the two?
Yeah, please do.
OK, Will do.
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
Hi.
As before, the pgaudit code is at https://github.com/2ndQuadrant/pgaudit
I did a quick round of testing to make sure things still work.
I'll re-add it to the next CF now.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
At 2014-10-14 18:05:00 +0530, a...@2ndquadrant.com wrote:
As before, the pgaudit code is at
https://github.com/2ndQuadrant/pgaudit
Sorry, I forgot to attach the tarball.
-- Abhijit
pgaudit.tar.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list
From: Heikki Linnakangas hlinnakan...@vmware.com
Committed this.
Thank you very much. I didn't anticipate such a difficult complicated
cause. The user agreed to try the patch tonight. I'll report back the
result as soon as I got it from him.
BTW, in LWLockWaitForVar(), the first line of
Abhijit,
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
As before, the pgaudit code is at https://github.com/2ndQuadrant/pgaudit
I did a quick round of testing to make sure things still work.
Thanks!
I had a very interesting discussion about auditing rules and the need to
limit what gets
A few years ago I started working on a concurrent hash table for
PostgreSQL. The hash table part of it worked, but I never did
anything with it, really. Amit mentioned to me earlier this week that
he was seeing contention inside the dynahash machinery, which inspired
me to go back and update the
Hi all,
I found that the statistics are still remained after it's truncated.
In addition, the analyzing ignores table does not have any tuple.
After table truncated, the entry of statistics continues to remain
unless insertion and analyzing are executed.
There is reason why statistics are
On Fri, Oct 10, 2014 at 11:00 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-10-10 16:41:39 +0200, Andres Freund wrote:
FWIW, the profile always looks like
- 48.61% postgres postgres [.] s_lock
- s_lock
+ 96.67% StrategyGetBuffer
+ 1.19%
On 2014-10-14 08:40:49 -0500, Merlin Moncure wrote:
On Fri, Oct 10, 2014 at 11:00 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-10-10 16:41:39 +0200, Andres Freund wrote:
FWIW, the profile always looks like
- 48.61% postgres postgres [.] s_lock
- s_lock
Sawada Masahiko sawada.m...@gmail.com writes:
I found that the statistics are still remained after it's truncated.
In addition, the analyzing ignores table does not have any tuple.
After table truncated, the entry of statistics continues to remain
unless insertion and analyzing are executed.
On 2014-10-14 09:30:58 -0400, Robert Haas wrote:
A few years ago I started working on a concurrent hash table for
PostgreSQL. The hash table part of it worked, but I never did
anything with it, really. Amit mentioned to me earlier this week that
he was seeing contention inside the dynahash
I extracted Emre's diagram adjustments from the patch and applied it,
and no tabs now. Emre, I assume your regression changes did not affect
the diagram contents.
Thank you for looking at it. I wanted to make the tests consistent
with the diagrams. Now they look better but they still don't
On 2014-10-14 09:30:58 -0400, Robert Haas wrote:
I took the basic infrastructure from before and used it to replace the
buffer table. Patch is attached.
Hm. Unless I missed something you pretty much completely eradicated
locks from the buffer mapping code? That'd be pretty cool, but it's also
On 22/09/14 02:24, Michael Paquier wrote:
On Thu, Sep 4, 2014 at 11:33 PM, Michael Paquier
Taking a dump consistent with a replication slot is useful for online
upgrade cases first, because you can simply run pg_dump, have a slot
created, and get as well a state of the database consistent with
On Tue, Oct 14, 2014 at 7:55 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-10-14 09:30:58 -0400, Robert Haas wrote:
A few years ago I started working on a concurrent hash table for
PostgreSQL. The hash table part of it worked, but I never did
anything with it, really. Amit
On Tue, Oct 14, 2014 at 05:40:06PM +0300, Emre Hasegeli wrote:
I extracted Emre's diagram adjustments from the patch and applied it,
and no tabs now. Emre, I assume your regression changes did not affect
the diagram contents.
Thank you for looking at it. I wanted to make the tests
If this communication is in fact intended to be protected by some
legal privilege, or to remain company confidential, you have
definitely sent it to the wrong place.
Sadly I don't control my company's email server. They however don't control my
gmail account. I'll switch to that.
eric
On 2014-10-14 20:30:45 +0530, Amit Kapila wrote:
On Tue, Oct 14, 2014 at 7:55 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-10-14 09:30:58 -0400, Robert Haas wrote:
A few years ago I started working on a concurrent hash table for
PostgreSQL. The hash table part of it worked,
On Tue, Oct 14, 2014 at 10:47 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-10-14 09:30:58 -0400, Robert Haas wrote:
I took the basic infrastructure from before and used it to replace the
buffer table. Patch is attached.
Hm. Unless I missed something you pretty much completely
On Tue, Oct 14, 2014 at 8:38 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-10-14 20:30:45 +0530, Amit Kapila wrote:
On Tue, Oct 14, 2014 at 7:55 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-10-14 09:30:58 -0400, Robert Haas wrote:
A few years ago I started
On Tue, Oct 14, 2014 at 11:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Sawada Masahiko sawada.m...@gmail.com writes:
I found that the statistics are still remained after it's truncated.
In addition, the analyzing ignores table does not have any tuple.
After table truncated, the entry of
On Tue, Oct 14, 2014 at 10:25 AM, Andres Freund and...@2ndquadrant.com wrote:
The key idea here is that lookups are done without any locks, only
memory barriers; and inserts and deletes are done using atomic ops.
Hm. I quickly looked and I see that you use two full barriers for every
lookup.
On 2014-10-14 11:08:08 -0400, Robert Haas wrote:
On Tue, Oct 14, 2014 at 10:47 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-10-14 09:30:58 -0400, Robert Haas wrote:
I took the basic infrastructure from before and used it to replace the
buffer table. Patch is attached.
Hm.
On Tue, Oct 14, 2014 at 11:31 AM, Andres Freund and...@2ndquadrant.com wrote:
It doesn't look particularly dangerous to me. Famous last words.
Basically, I think what we're doing right now is holding the buffer
mapping lock so that the buffer can't be renamed under us while we're
pinning it.
Hello,
I changed the buffer manager code in order to generate a trace of page
requests from the buffer manager perspective. In summary, whenever
ReleaseBuffer() or ReleaseAndReadBuffer() are called, I print the page
currently being released which is identified by the tuple (tableSpace,
dbNode,
On Mon, Oct 13, 2014 at 12:11 PM, Bruce Momjian br...@momjian.us wrote:
I looked into this, and came up with more questions. Why is
checkpoint_completion_target involved in the total number of WAL
segments? If checkpoint_completion_target is 0.5 (the default), the
calculation is:
* Lucas Lersch (lucasler...@gmail.com) wrote:
Unfortunately, in the generated trace with over 2 million buffer requests,
only ~14k different pages are being accessed, out of the 800k of the whole
database. Am I missing something here?
What do you have shared_buffers set to..?
Thanks,
Sorry, I do not understand the question.
But I forgot to give an additional information: I am printing the page id
for the trace file in ReleaseBuffer() only if it is a shared buffer, I am
not considering local buffers. I assumed that local buffers were used only
for temporary tables.
On Tue,
On Sat, Oct 11, 2014 at 3:40 AM, Simon Riggs si...@2ndquadrant.com wrote:
As soon as you issue the above query, you have clearly indicated your
intention to steal. Receiving information is no longer accidental, it
is an explicit act that is logged in the auditing system against your
name. This
On Wed, Oct 1, 2014 at 9:17 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Hi all,
We already have IF NOT EXISTS for CREATE TABLE. There are some reason to
don't have to CREATE TABLE AS and CREATE MATERIALIZED VIEW??
Patch attached to add CINE support to:
- CREATE TABLE AS
-
shared_buffers is 128MB and the version of pgsql is 9.3.5
On Tue, Oct 14, 2014 at 6:31 PM, Lucas Lersch lucasler...@gmail.com wrote:
Sorry, I do not understand the question.
But I forgot to give an additional information: I am printing the page id
for the trace file in ReleaseBuffer() only
On Thu, Oct 9, 2014 at 2:41 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I think the theory for track_io_timing being PGC_SUSET is that if the
superuser turned it on, no one should be able to turn it off.
But I don't see an argument for the other way around, that no one should be
able to turn
* Lucas Lersch (lucasler...@gmail.com) wrote:
shared_buffers is 128MB and the version of pgsql is 9.3.5
I suspect you're not tracking what you think you're tracking, which is
why I brought up shared_buffers.
~14k * 8192 (page size) = ~110MB
What it sounds like you're actually tracking are
On 10/14/2014 10:01 AM, Robert Haas wrote:
Hmm. IIRC, there are only two use cases for I/O timing at present:
pg_stat_statements (which really only makes sense if it's turned on or
off system-wide) and EXPLAIN. Rather than inventing more GUC
machinery, I think we could just add an explain
Aren't heap and index requests supposed to go through the shared buffers
anyway?
On Tue, Oct 14, 2014 at 7:02 PM, Stephen Frost sfr...@snowman.net wrote:
* Lucas Lersch (lucasler...@gmail.com) wrote:
shared_buffers is 128MB and the version of pgsql is 9.3.5
I suspect you're not tracking
Hi Hackers,
following the advices gathered on the list I've prepared a third partial
patch on the way of implementing incremental pg_basebackup as described
here https://wiki.postgresql.org/wiki/Incremental_backup
== Changes
Compared to the previous version I've made the following changes:
*
* Lucas Lersch (lucasler...@gmail.com) wrote:
Aren't heap and index requests supposed to go through the shared buffers
anyway?
Sure they do, but a given page in shared_buffers can be used over and
over again for different heap and index pages..
Thanks,
Stephen
On Tue, Oct 14, 2014 at 09:20:22AM -0700, Jeff Janes wrote:
On Mon, Oct 13, 2014 at 12:11 PM, Bruce Momjian br...@momjian.us wrote:
I looked into this, and came up with more questions. Why is
checkpoint_completion_target involved in the total number of WAL
segments? If
On Wed, Oct 8, 2014 at 6:32 PM, Andres Freund and...@2ndquadrant.com wrote:
/*
+ * Arrange to remove a dynamic shared memory mapping at cleanup time.
+ *
+ * dsm_keep_mapping() can be used to preserve a mapping for the entire
+ * lifetime of a process; this function reverses that decision,
On Tue, Oct 14, 2014 at 1:04 PM, Joshua D. Drake j...@commandprompt.com wrote:
On 10/14/2014 10:01 AM, Robert Haas wrote:
Hmm. IIRC, there are only two use cases for I/O timing at present:
pg_stat_statements (which really only makes sense if it's turned on or
off system-wide) and EXPLAIN.
I see this... but ReleaseBuffer() simply decrements the reference count of
page the buffer currently holds. Assuming that a ReadBuffer() -
ReleaseBuffer() pattern is used for interacting with the shared_buffers,
there will be a ReleaseBuffer() call for any page (heap or index) loaded
into the
* Lucas Lersch (lucasler...@gmail.com) wrote:
I see this... but ReleaseBuffer() simply decrements the reference count of
page the buffer currently holds. Assuming that a ReadBuffer() -
ReleaseBuffer() pattern is used for interacting with the shared_buffers,
there will be a ReleaseBuffer() call
I have pushed this, thanks.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Oct 14, 2014 at 8:58 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-10-14 08:40:49 -0500, Merlin Moncure wrote:
On Fri, Oct 10, 2014 at 11:00 AM, Andres Freund and...@2ndquadrant.com
wrote:
Which is nearly trivial now that atomics are in. Check out the attached
WIP patch
On 14 October 2014 13:57, Stephen Frost sfr...@snowman.net wrote:
Create an 'audit' role.
Every command run by roles which are granted to the 'audit' role are
audited.
Every 'select' against tables which the 'audit' role has 'select' rights
on are audited. Similairly for every insert,
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 14 October 2014 13:57, Stephen Frost sfr...@snowman.net wrote:
Create an 'audit' role.
Every command run by roles which are granted to the 'audit' role are
audited.
Every 'select' against tables which the 'audit' role has 'select'
At 2014-10-14 20:09:50 +0100, si...@2ndquadrant.com wrote:
I think that's a good idea.
We could have pg_audit.roles = 'audit1, audit2'
Yes, it's a neat idea, and we could certainly do that. But why is it any
better than ALTER ROLE audit_rw SET pgaudit.log = … and granting that
role to the
Hi fellow hackers,
Please find attached to this email a patch to implement a new Event
Trigger, fired on the the table_rewrite event. As attached, it's meant
as a discussion enabler and only supports ALTER TABLE (and maybe not in
all forms of it). It will need to grow support for VACUUM FULL and
On 2014-10-14 11:19:16 -0400, Robert Haas wrote:
On Tue, Oct 14, 2014 at 10:25 AM, Andres Freund and...@2ndquadrant.com
wrote:
The key idea here is that lookups are done without any locks, only
memory barriers; and inserts and deletes are done using atomic ops.
Hm. I quickly looked and
On 09/10/14 00:32, Andres Freund wrote:
From c835a06f20792556d35a0eee4c2fa21f5f23e8a3 Mon Sep 17 00:00:00 2001
From: Robert Haas rh...@postgresql.org
Date: Fri, 11 Jul 2014 09:53:40 -0400
Subject: [PATCH 6/6] pg_background: Run commands in a background worker, and
get the results.
The
On 09/09/14 17:37, Pavel Stehule wrote:
Ada is language with strong character, and PLpgSQL is little bit strange
fork - so it isn't easy to find some form, how to solve all requirements.
My requests:
* be consistent with current PLpgSQL syntax and logic
* allow some future extensibility
*
It seems we left this in broken state. Do we need to do more here to
fix narwhal, or do we want to retire narwhal now? Something else? Are
we waiting on someone in particular to do something specific?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On Tue, Oct 14, 2014 at 4:42 PM, Andres Freund and...@2ndquadrant.com wrote:
The code in CHashSearch shows the problem there: you need to STORE the
hazard pointer before you begin to do the LOAD operations to scan the
bucket, and you must finish all of those LOADs before you STORE the
NULL
On Tue, Oct 14, 2014 at 11:55 PM, Petr Jelinek p...@2ndquadrant.com wrote:
On 22/09/14 02:24, Michael Paquier wrote:
On Thu, Sep 4, 2014 at 11:33 PM, Michael Paquier
Taking a dump consistent with a replication slot is useful for online
upgrade cases first, because you can simply run pg_dump,
Robert Haas wrote:
On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Robert Haas wrote:
I'm not really very convinced that it's a good idea to expose this
instead of just figuring out a way to parse the object identity.
That's the first thing I tried. But
I wrote:
I got interested in the problem discussed in
http://www.postgresql.org/message-id/20714.1412456...@sss.pgh.pa.us
to wit:
It's becoming clear to me that our existing design whereby zone
abbreviations represent fixed GMT offsets isn't really good enough.
I've been wondering whether we
Alvaro Herrera alvhe...@2ndquadrant.com writes:
It seems we left this in broken state. Do we need to do more here to
fix narwhal, or do we want to retire narwhal now? Something else? Are
we waiting on someone in particular to do something specific?
I think we're hoping that somebody will
On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
It seems we left this in broken state. Do we need to do more here to
fix narwhal, or do we want to retire narwhal now? Something else? Are
we waiting on someone in particular
Hi list,
I happened to notice that there are no less than 14 places in the code
that check whether a relation is a system catalog and throwing the
error permission denied: foo is a system catalog
The attached patch factors all of those into a single
ForbidSystemTableMods() function. Is this
On 10/14/2014 06:44 PM, Dave Page wrote:
On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
It seems we left this in broken state. Do we need to do more here to
fix narwhal, or do we want to retire narwhal now? Something
Dave Page dp...@pgadmin.org writes:
On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we're hoping that somebody will step up and investigate how
narwhal's problem might be fixed. However, the machine's owner (Dave)
doesn't appear to have the time/interest to do
Marti Raudsepp ma...@juffo.org writes:
I happened to notice that there are no less than 14 places in the code
that check whether a relation is a system catalog and throwing the
error permission denied: foo is a system catalog
The attached patch factors all of those into a single
Tom Lane wrote:
Marti Raudsepp ma...@juffo.org writes:
I happened to notice that there are no less than 14 places in the code
that check whether a relation is a system catalog and throwing the
error permission denied: foo is a system catalog
The attached patch factors all of those into
On Wed, Oct 15, 2014 at 12:06 AM, Merlin Moncure mmonc...@gmail.com wrote:
A while back, I submitted a minor tweak to the clock sweep so that,
instead of spinlocking every single buffer header as it swept it just
did a single TAS as a kind of a trylock and punted to the next buffer
if the
Robert Haas robertmh...@gmail.com writes:
For parallelism, I think we need a concept of group locking. That is,
suppose we have a user backend and N worker backends collaborating to
execute some query. For the sake of argument, let's say it's a
parallel CLUSTER, requiring a full table lock.
On Tue, Oct 14, 2014 at 07:07:17PM -0400, Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we're hoping that somebody will step up and investigate how
narwhal's problem might be fixed.
I have planned to look at
On 2014-10-15 07:09:10 +0900, Michael Paquier wrote:
whatever replication solution you use and just have pg_dump accept the
snapshot as input parameter? I am not sure how much I like pg_dump creating
the slot. I am aware that you need to have the replication connection open
but that's IMHO
Greetings,
The attached patch for review implements a few additional role
attributes (all requested by users or clients in various forums) for
common operations which currently require superuser privileges. This
is not a complete solution for all of the superuser-only privileges we
On Wed, Oct 15, 2014 at 2:06 PM, Andres Freund and...@2ndquadrant.com
wrote:
I think that's completely the wrong way to go at this. The time it takes
to create a replication slot under write load is far larger than the
time it takes to start pg_dump and load. This really doesn't add any
On 2014-10-15 14:28:16 +0900, Michael Paquier wrote:
On Wed, Oct 15, 2014 at 2:06 PM, Andres Freund and...@2ndquadrant.com
wrote:
I think that's completely the wrong way to go at this. The time it takes
to create a replication slot under write load is far larger than the
time it takes to
On 10/15/2014 12:53 PM, Noah Misch wrote:
Windows Server 2003 isn't even EOL yet. I'd welcome a buildfarm member with
that OS and a modern toolchain.
It's possible to run multiple buildfarm animals on a single Windows
instance, each with a different toolchain.
There's the chance of
82 matches
Mail list logo
