On Wed, Jul 1, 2015 at 12:39 PM, Fujii Masao wrote:
> WAL-related tools, i.e., pg_archivecleanup, pg_resetxlog and
> pg_xlogdump don't seem to properly handle .paritial WAL file.
> I think that we should fix at least pg_archivecleanup, otherwise,
> in the system using pg_archivecleanup to clean up
On 2015-07-01 PM 02:37, Amit Kapila wrote:
>
> In terms of completeness, I think we should add some documentation
> for this patch, one way is to update about the execution mechanism in
> src/backend/access/transam/README.parallel and then explain about
> new configuration knobs in documentation (
Hello Pavel.
I looked through the patch. Sources are OK. However I didn't find any docs
and test cases. Would you please provide me with short description on this
feature and why it is important. Because I didn't manage to find the old
Andrew Dunstan's post either.
On Sat, Apr 11, 2015 at 12:26 A
On Wed, Jul 1, 2015 at 2:38 PM, Peter Geoghegan wrote:
> On Tue, Jun 30, 2015 at 10:35 PM, Peter Geoghegan wrote:
>> The regression tests have zero coverage for this
>> tuplesort_performsort() "btspool2" case. That's a fairly common case
>> to have no coverage for, and that took me all of 5 minut
On Wed, Jul 1, 2015 at 9:09 AM, Fujii Masao wrote:
>
> Also regarding pg_xlogdump, we can just document, for example,
> "please get rid of .paritial suffix from the WAL file name if
> you want to dump it by pg_xlogdump".
>
Can't we skip such files in pg_xlogdump?
With Regards,
Amit Kapila.
Ente
On Tue, Jun 30, 2015 at 10:35 PM, Peter Geoghegan wrote:
> The regression tests have zero coverage for this
> tuplesort_performsort() "btspool2" case. That's a fairly common case
> to have no coverage for, and that took me all of 5 minutes to find.
BTW, I looked here because I added a bunch of so
On Tue, Jun 30, 2015 at 4:00 AM, Jeff Davis wrote:
>
> [Jumping in without catching up on entire thread.
No problem.
> Please let me know
> if these questions have already been covered.]
>
> 1. Can you change the name to something like ParallelHeapScan?
> Parallel Sequential is a contradiction.
On Tue, Jun 30, 2015 at 10:25 PM, Peter Geoghegan wrote:
> It would be nice to always have a html report from gcov always
> available on the internet. That would be something useful to automate,
> IMV. Watching that regress over time might provide useful insight, but
> I only use gcov a couple of
On Tue, Jun 30, 2015 at 9:39 PM, Michael Paquier
wrote:
>> There is no real testing of sorting in the regression tests. It would
>> be nice to have a way of generating a large and varied selection of
>> sort operations programmatically, to catch this kind of thing.
>> pg_regress is not really up t
On Wed, Jul 1, 2015 at 9:36 AM, Peter Geoghegan wrote:
> On Tue, Jun 30, 2015 at 5:25 PM, Jim Nasby wrote:
>> Isn't this the kind of thing Coverty's supposed to find?
>
> I don't know, but in general I'm not very excited about static
> analysis tools. The best things that they have going for them
Hi,
WAL-related tools, i.e., pg_archivecleanup, pg_resetxlog and
pg_xlogdump don't seem to properly handle .paritial WAL file.
I think that we should fix at least pg_archivecleanup, otherwise,
in the system using pg_archivecleanup to clean up old archived
files, the archived .paritial WAL file wil
On Wed, Jul 1, 2015 at 10:58 AM, Fujii Masao wrote:
> On Tue, Jun 9, 2015 at 10:09 AM, Michael Paquier wrote:
>> That's a valid concern. What about the attached then? I think that it
>> is still good to keep upto to copy only data up to the switch point at
>> recovery exit. InstallXLogFileSegment()
On Tue, Jun 9, 2015 at 10:09 AM, Michael Paquier
wrote:
> On Tue, Jun 9, 2015 at 6:25 AM, Heikki Linnakangas wrote:
>> I'm still not sure if I should've just reverted that refactoring, to make
>> XLogFileCopy() look the same in master and back-branches, which makes
>> back-patching easier, or keep
On 5/21/15 8:42 AM, Peter Eisentraut wrote:
> I wonder why pg_basebackup doesn't have any support for replication slots.
>
> When relying on replication slots to hang on to WAL data, there is a gap
> between when pg_basebackup finishes and streaming replication is started
> where WAL data could be
On Tue, Jun 30, 2015 at 5:25 PM, Jim Nasby wrote:
> Isn't this the kind of thing Coverty's supposed to find?
I don't know, but in general I'm not very excited about static
analysis tools. The best things that they have going for them is that
they're available, and don't require test coverage in t
On 6/29/15 6:47 PM, Peter Geoghegan wrote:
As we all know, the state of automated testing is pretty lamentable.
This is the kind of thing that we could catch more easily in the
future if better infrastructure were in place. I caught this by
eyeballing bttext_abbrev_convert() with slightly fresher
Franck Verrot writes:
> As far as I know, there is currently no way to find which column is triggering
> an error on an INSERT or ALTER COLUMN statement. Example:
Indeed ...
> Given my very restricted knowledge of PG's codebase I am not sure whether my
> modifications are legitimate or not, so p
Josh Berkus writes:
> The question is: how many folks out there are running PostgreSQL on
> Solaris 10? And are they at all likely to upgrade to PostgreSQL 9.5?
That's only the pertinent question if the bug exists on Solaris 10,
which I don't think we know do we? Oskari Saarenmaa's results upth
Jeff Janes writes:
> On Tue, Jun 30, 2015 at 2:46 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>> pg_trgm--1.1.sql andpg_trgm--1.1--1.2.sql are useful for debug, but do you
>> expect them in final commit? As I can see in other contribs we have only
>> last version and upgrade scrip
On 06/29/2015 07:53 PM, Robert Haas wrote:
> On Mon, Jun 29, 2015 at 6:07 PM, Josh Berkus wrote:
>> On 06/29/2015 02:08 PM, Tom Lane wrote:
>>> Josh Berkus writes:
Joyent confirms that the bug is fixed on SmartOS:
>>>
>>> The more interesting bit of information would be *when* it was fixed.
On Tue, Jun 30, 2015 at 2:46 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Sun, Jun 28, 2015 at 1:17 AM, Jeff Janes wrote:
>
>> This patch implements version 1.2 of contrib module pg_trgm.
>>
>> This supports the triconsistent function, introduced in version 9.4 of
>> the server
On 2015-06-30 22:19:02 +0300, Heikki Linnakangas wrote:
> >Hm. Right. A recheck of the value after the queuing should be sufficient
> >to fix? That's how we deal with the exact same scenarios for the normal
> >lock state, so that shouldn't be very hard to add.
>
> Yeah. It's probably more efficien
Hi all,
As far as I know, there is currently no way to find which column is triggering
an error on an INSERT or ALTER COLUMN statement. Example:
# create table foo(bar varchar(4), baz varchar(2));
CREATE TABLE
# insert into foo values ('foo!', 'ok');
INSERT 0 1
# insert into f
On 06/30/2015 10:09 PM, Andres Freund wrote:
On 2015-06-30 21:08:53 +0300, Heikki Linnakangas wrote:
/*
* XXX: We can significantly optimize this on platforms
with 64bit
* atomics.
*/
On 2015-06-30 21:08:53 +0300, Heikki Linnakangas wrote:
> > /*
> > * XXX: We can significantly optimize this on platforms
> > with 64bit
> > * atomics.
> > */
> > value = *valptr;
> >
I've gone through the release notes and added comments referencing
commits as discussed earlier. Additionally I've improved and added a
bunch of items.
Further stuff that came up while looking:
* 2014-09-25 [b0d81ad] Heikki..: Add -D option to specify data directory to
pg_c..
new options, shoul
On 06/11/2015 02:19 AM, Peter Geoghegan wrote:
Currently, speculative insertion (the INSERT ... ON CONFLICT DO UPDATE
executor/storage infrastructure) uses checkUnique ==
UNIQUE_CHECK_PARTIAL for unique indexes, which is a constant
originally only used by deferred unique constraints. It occurred
On 06/30/2015 07:37 PM, Alvaro Herrera wrote:
Jeff Janes wrote:
I've gotten the LWLock deadlock again. User backend 24841 holds the
WALInsertLocks 7 and is blocked attempting to acquire 6 . So it seems to
be violating the lock ordering rules (although I don't see that rule
spelled out in xlog
On 06/30/2015 07:05 PM, Jeff Janes wrote:
On Mon, Jun 29, 2015 at 11:28 PM, Jeff Janes wrote:
On Mon, Jun 29, 2015 at 5:55 PM, Peter Geoghegan wrote:
On Mon, Jun 29, 2015 at 5:37 PM, Jeff Janes wrote:
Is there a way to use gdb to figure out who holds the lock they are
waiting
for?
Hav
On 06/29/2015 09:44 AM, Michael Paquier wrote:
On Mon, Jun 29, 2015 at 4:55 AM, Heikki Linnakangas wrote:
But we'll still need to handle the pg_xlog symlink case somehow. Perhaps it
would be enough to special-case pg_xlog for now.
Well, sure, pg_rewind does not copy the soft links either way.
Petr Jelinek writes:
> On 2015-06-30 09:10, Michael Paquier wrote:
>> If the expression argstate is NULL when calling ExecInitExpr(), argstate
>> is going to be NULL and dereferenced afterwards, see execQual.c for more
>> details. Hence I think that the patch attached should be applied. Thoughts?
Jeff Janes wrote:
> I've gotten the LWLock deadlock again. User backend 24841 holds the
> WALInsertLocks 7 and is blocked attempting to acquire 6 . So it seems to
> be violating the lock ordering rules (although I don't see that rule
> spelled out in xlog.c)
Hmm, interesting -- pg_stat_statemen
Oskari Saarenmaa wrote:
> I configured the dingo and binturong Solaris 10 animals to build 9.3
> some time ago but apparently they always failed the configure phase.
> Turns out this is caused by thread_test's usage of sched_yield which is
> in librt on Solaris but which is not pulled in by anythin
On Mon, Jun 29, 2015 at 11:28 PM, Jeff Janes wrote:
> On Mon, Jun 29, 2015 at 5:55 PM, Peter Geoghegan wrote:
>
>> On Mon, Jun 29, 2015 at 5:37 PM, Jeff Janes wrote:
>> > Is there a way to use gdb to figure out who holds the lock they are
>> waiting
>> > for?
>>
>> Have you considered building
Hi
I am sending a review of this trivial patch.
1.This patch enables the possibility to restore only selected view, mat.
view, foreign table or sequence. Currently the option -t works with tables
only. All other relation like objects are quietly ignored. With this patch,
the check on type is enha
On Thu, Jun 4, 2015 at 5:49 PM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
> On Tue, Jun 2, 2015 at 2:23 PM, Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de> wrote:
> >
> > Hello,
> >
> > I've submitted a patch to psycopg2 to support streaming replication
> protocol (COPY_BOTH):
Noah Misch writes:
> On Sun, Jun 28, 2015 at 07:00:14PM -0400, Tom Lane wrote:
>> Another idea would be to make a test during postmaster start to see
>> if this bug exists, and fail if so. I'm generally on board with the
>> thought that we don't need to work on systems with such a bad bug,
>> but
Barring objections, I'll create the REL9_5_STABLE branch and stamp HEAD
as 9.6devel sometime this afternoon, maybe around 1800 UTC.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
On Fri, Jun 26, 2015 at 6:26 PM, Robert Haas wrote:
>
> On Thu, Jun 25, 2015 at 11:57 PM, Amit Kapila
wrote:
> >> >> 3. Add new view 'pg_stat_wait_event' with following info:
> >> >> pid - process id of this backend
> >> >> waiting - true for any form of wait, false otherwise
> >> >> wait_event
Hello,
>There's no need to add those curly braces, or to subsequent if blocks
Yes, those are added by mistake.
>Also, is this patch taking the visibility map into account for its
>calculations?
Yes, it subtracts skippable/all-visible pages from total pages to be scanned.
For each page processed
Review:
1. Discussion - I read all discussion and majority opinion is positive to
this patch. I am for this patch too. I had to solve same issues with Orafce
project. More - this patch is terrible simple - it is just the publishing
already prepared value.
2. There was not any problem with patchi
Hi,
On 2015-06-30 21:53:07 +0900, Michael Paquier wrote:
> In the category of nitpicky-code-style-issues, FreeSpaceMapTruncateRel
> is doing a NULL-pointer check for something that has been dereferenced
> on all the code paths leading to this check.
> (Yes, that's not interesting for common humans
On Tue, Jun 30, 2015 at 9:45 PM, Michael Paquier
wrote:
> timestamp2tm is called close to 40 times in the backend source code,
> returning -1 in case of failure. However, there are two places in datetime.c
> where we do not check for its return value: GetCurrentDateTime and
> GetCurrentTimeUsec.
>
Hi all,
In the category of nitpicky-code-style-issues, FreeSpaceMapTruncateRel
is doing a NULL-pointer check for something that has been dereferenced
on all the code paths leading to this check.
(Yes, that's not interesting for common humans, Coverity sees things
based on correctness).
Regards,
-
Hi all,
timestamp2tm is called close to 40 times in the backend source code,
returning -1 in case of failure. However, there are two places in
datetime.c where we do not check for its return value: GetCurrentDateTime
and GetCurrentTimeUsec.
This does not really matter much in practice as the times
On 2015-06-30 09:10, Michael Paquier wrote:
Hi all,
(Petr in CC)
Coverity is complaining about the following pointer dereference in
tablesample_init@tablesample.c:
+ ExprState *argstate = ExecInitExpr(argexpr, (PlanState
*) scanstate);
+
+ if (argstate == NULL)
+
On 06/30/2015 02:18 AM, Jeff Janes wrote:
On Mon, Jun 29, 2015 at 2:08 PM, Heikki Linnakangas wrote:
I just pushed a fix for this, but unfortunately it didn't make it
9.5alpha1.
Thanks. I think that that fixed it. It survived for over an hour this
time.
Thanks. I grepped through all the
On 30 June 2015 at 14:33, Jeff Davis wrote:
> I was going to rebase my HashAgg patch, and got some conflicts related
> to the grouping sets patch. I could probably sort them out, but I think
> that may be the tipping point where we want to break up nodeAgg.c into
> nodeSortedAgg.c and nodeHashAgg
Hi,
On 2015-06-29 19:33:58 -0700, Jeff Davis wrote:
> I was going to rebase my HashAgg patch, and got some conflicts related
> to the grouping sets patch. I could probably sort them out, but I think
> that may be the tipping point where we want to break up nodeAgg.c into
> nodeSortedAgg.c and node
On Sun, Jun 28, 2015 at 1:17 AM, Jeff Janes wrote:
> This patch implements version 1.2 of contrib module pg_trgm.
>
> This supports the triconsistent function, introduced in version 9.4 of the
> server, to make it faster to implement indexed queries where some keys are
> common and some are rare.
On 2015-06-29 23:05:55 -0400, Robert Haas wrote:
> Personally, I have found that _Asm_double_magic_xyzzy makes is not
> nearly as cromulent as _Asm_triple_magic_plugh. But then, trying to
> figure out compiler intrinsics on strange platforms makes me feel very
> much like I'm in a maze of twisty l
On 2015-06-29 22:58:05 -0400, Tom Lane wrote:
> So personally, I would be inclined to put back the volatile qualifier,
> independently of any fooling around with _Asm_double_magic_xyzzy
> calls.
I'm not sure. I think the reliance on an explicit memory barrier is a
lot more robust and easy to under
On 30 June 2015 at 08:37, Rahila Syed wrote:
> Hello Hackers,
>
> Following is a proposal for feature to calculate VACUUM progress.
>
> Use Case : Measuring progress of long running VACUUMs to help DBAs make
> informed decision
> whether to continue running VACUUM or abort it.
>
> Design:
>
> A s
On 2015-06-30 PM 04:37, Rahila Syed wrote:
>
> Design:
>
> A shared preload library to store progress information from different
> backends running VACUUM, calculate remaining time for each and display
> progress in the
> in the form a view.
>
>
> [...]
>
> Reporting :
>
> A view named 'pg_m
On 30 June 2015 at 08:52, Pavel Stehule wrote:
> I though about the possibilities of progress visualization - and one
> possibility is one or two special column in pg_stat_activity table - this
> info can be interesting for VACUUM started by autovacuum too.
>
Yes, I suggest just a single column
On Tue, Jun 30, 2015 at 12:52 PM, Simon Riggs wrote:
>
> On 30 June 2015 at 08:13, Michael Paquier
wrote:
>>
>>
>> Could it be possible to see some performance numbers? For example with a
simple pgbench script doing a bunch of tiny transactions, with many
concurrent sessions (perhaps hundreds).
>
On Tue, Jun 30, 2015 at 1:07 PM, Rahila Syed wrote:
> Hello Hackers,
>
> Following is a proposal for feature to calculate VACUUM progress.
>
> Use Case : Measuring progress of long running VACUUMs to help DBAs make
> informed decision
> whether to continue running VACUUM or abort it.
>
> +1
I am
On Tue, Jun 30, 2015 at 7:37 PM, Rahila Syed wrote:
> Hello Hackers,
>
> Following is a proposal for feature to calculate VACUUM progress.
>
> Use Case : Measuring progress of long running VACUUMs to help DBAs make
> informed decision
> whether to continue running VACUUM or abort it.
+1
I was th
Hi
2015-06-30 9:37 GMT+02:00 Rahila Syed :
> Hello Hackers,
>
> Following is a proposal for feature to calculate VACUUM progress.
>
interesting idea - I like to see it integrated to core.
>
> Use Case : Measuring progress of long running VACUUMs to help DBAs make
> informed decision
> whether
On 30 June 2015 at 08:22, Simon Riggs wrote:
> This contention is masked by contention elsewhere, e.g. ProcArrayLock, so
> the need for testing here should come once other patches ahead of this are
> in.
>
Let me explain more clearly.
Andres' patch to cache snapshots and reduce ProcArrayLock w
On 30 June 2015 at 08:13, Michael Paquier wrote:
>
>
> On Tue, Jun 30, 2015 at 4:02 PM, Simon Riggs
> wrote:
>
>> ClogControlLock contention is high at commit time. This appears to be due
>> to the fact that ClogControlLock is acquired in Exclusive mode prior to
>> marking commit, which then get
Hi all,
Coverity is pointing out that a couple of return value checks are
missing for JsonbIteratorNext in jsonfuncs.c. Patch is attached to
append (void) to them, as far as I am guessing we want skip the value
iterated on.
Regards,
--
Michael
diff --git a/src/backend/utils/adt/jsonfuncs.c b/src/
On Tue, Jun 30, 2015 at 4:02 PM, Simon Riggs wrote:
> ClogControlLock contention is high at commit time. This appears to be due
> to the fact that ClogControlLock is acquired in Exclusive mode prior to
> marking commit, which then gets starved by backends running
> TransactionIdGetStatus().
>
> P
Hi all,
(Petr in CC)
Coverity is complaining about the following pointer dereference in
tablesample_init@tablesample.c:
+ ExprState *argstate = ExecInitExpr(argexpr, (PlanState *)
scanstate);
+
+ if (argstate == NULL)
+ {
+ fcinfo.ar
ClogControlLock contention is high at commit time. This appears to be due
to the fact that ClogControlLock is acquired in Exclusive mode prior to
marking commit, which then gets starved by backends running
TransactionIdGetStatus().
Proposal for improving this is to acquire the ClogControlLock in S
65 matches
Mail list logo
