Hi,
Patch attached to fix some sillyness in pgp_expect_packet_end() and
pgp_skip_packet(). Will add to the next commitfest unless someone picks
this one up before that.
.marko
*** a/contrib/pgcrypto/pgp-decrypt.c
--- b/contrib/pgcrypto/pgp-decrypt.c
***
*** 1069,1075 pgp_sk
On Sun, Nov 2, 2014 at 12:59 PM, Josh Berkus wrote:
> All,
>
> While there's argument about hash indexes, it looks like nobody minds if
> the MONEY type goes bye-bye. So, time for a patch ...
>
>
Will the patch move the feature to a contrib module?
Or will our release notes state that all MONEY
On Sat, Nov 1, 2014 at 5:38 PM, Andres Freund wrote:
> That's just a mislabeled function. It's obviously not parallel safe at
> all. I see absolutely no problem with erroring out.
I disagree. It's entirely parallel-safe, as long as you don't
arbitrarily decide to have the lock manager break it.
Hi,
Every now and then I've noticed that glibc's stdio functions show up
prominently in profiles. Which seems somewhat odd, given they pretty
much should delegate all work to the kernel and memcpy(). By accident I
looked at a the disassembly and oops: A large part is due to
locking. Especially in
All,
While there's argument about hash indexes, it looks like nobody minds if
the MONEY type goes bye-bye. So, time for a patch ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On 2014-11-01 16:59:34 -0400, Robert Haas wrote:
> > I completely fail to see why you'd generally think it's safe for two
> > backends to hold the same self conflicting lock. Yes, within carefully
> > restricted sections of code that might be doable. But I don't think you
> > can fully enforce that
On Sat, Nov 1, 2014 at 1:09 AM, Simon Riggs wrote:
> What are the specific restrictions you are suggesting we place on
> parallel workers? We need that definition clear so we can decide how
> to mark the functions. If we don't know, which is easily
> understandable, then the best way to find that
On Sat, Nov 1, 2014 at 5:06 PM, Andres Freund wrote:
> On 2014-11-01 17:00:59 -0400, Robert Haas wrote:
>> On Sat, Nov 1, 2014 at 1:55 PM, Andres Freund wrote:
>> > I doubt it. There's a whole bunch of problems that just exist by virtue
>> > of having a group leader. What if the leader dies but t
On 2014-11-01 17:00:59 -0400, Robert Haas wrote:
> On Sat, Nov 1, 2014 at 1:55 PM, Andres Freund wrote:
> > I doubt it. There's a whole bunch of problems that just exist by virtue
> > of having a group leader. What if the leader dies but the worker backend
> > isn't in a section of code that does
On Sat, Nov 1, 2014 at 1:55 PM, Andres Freund wrote:
> I doubt it. There's a whole bunch of problems that just exist by virtue
> of having a group leader. What if the leader dies but the worker backend
> isn't in a section of code that does a CHECK_FOR_INTERRUPTS()?
In between all of the heat abo
On Sat, Nov 1, 2014 at 1:55 PM, Andres Freund wrote:
>> Where will those preexisting cache entries come from, exactly? The
>> postmaster is forking the parallel worker, not the user backend.
>
> Several things:
> 1) The relcache init files load a fair bit
> 2) There's cache entries made just duri
On Sat, Nov 1, 2014 at 12:40 PM, Andres Freund wrote:
> I'm not all that excited about unlogged hash indexes. Yes, that'll
> remove a annoying hazard, but I probably won't use them anyway. I am
> somewhat excited about the more general unlogged indexes feature.
I strongly agree.
--
Peter Geogh
Andres Freund writes:
> On 2014-11-01 15:33:27 -0400, Tom Lane wrote:
>> With current usage of hash indexes, nobody would ever construct such an
>> arrangement
> Do you think this should only be implemented for hash indexes? I'd think
> we'd do it for all existing index AMs?
I think we should ev
On 2014-11-01 15:33:27 -0400, Tom Lane wrote:
> With current usage of hash indexes, nobody would ever construct such an
> arrangement
Do you think this should only be implemented for hash indexes? I'd think
we'd do it for all existing index AMs?
I'm not all that excited about unlogged hash indexe
Andres Freund writes:
> On 2014-11-01 15:11:40 -0400, Tom Lane wrote:
>> I don't see how HS has anything to do with this discussion.
> Consider:
> SELECT * FROM tbl WHERE active AND value = $1;
> that can be satisfied by two indexes. One on (value), and an unlogged
> index on (value) WHERE active
Hi
good idea. Mix of these both strategies can be a base for global temp
tables implementation.
Pavel
2014-10-31 15:53 GMT+01:00 Simon Riggs :
> While investigating how to reduce logging of AccessExclusiveLocks for
> temp tables, I came up with the attached patch.
>
> My feeling was "that's an
On 2014-11-01 15:11:40 -0400, Tom Lane wrote:
> Andres Freund writes:
> > One argument in that direction imo is HS. We certainly would just
> > generally ignore unlogged indexes for querying while InRecovery, right?
> > Because otherwise HS would become pretty useless. And I think it'd be
> > pret
Andres Freund writes:
> One argument in that direction imo is HS. We certainly would just
> generally ignore unlogged indexes for querying while InRecovery, right?
> Because otherwise HS would become pretty useless. And I think it'd be
> pretty wierd if things worked on HS and not on the primary (
Andrew Dunstan writes:
> The real question here is whether the table should continue to be usable
> in a degraded state until it's reindexed.
It certainly will be, as long as your notion of "usable in a degraded
state" doesn't include issuing queries that would prefer to use the broken
index. T
Andres Freund writes:
> On 2014-11-01 14:48:20 -0400, Tom Lane wrote:
>> Sure. And as long as you aren't issuing queries that would want to scan
>> the crashed index, it won't matter either way. The question is whether
>> you'd rather that your "inessential reporting queries" fail without the
>>
On 2014-11-01 14:56:35 -0400, Andrew Dunstan wrote:
>
> On 11/01/2014 02:39 PM, Tom Lane wrote:
> >Andres Freund writes:
> >>A REINDEX is imo unlikely to be acceptable. It takes long (why would you
> >>bother on a small table?) and locks the relation/indexes.
> >I think the goalposts just took a
On 11/01/2014 02:39 PM, Tom Lane wrote:
Andres Freund writes:
A REINDEX is imo unlikely to be acceptable. It takes long (why would you
bother on a small table?) and locks the relation/indexes.
I think the goalposts just took a vacation to Acapulco.
What exactly do you think is going to make
On 2014-11-01 14:48:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-11-01 14:39:21 -0400, Tom Lane wrote:
> >> What exactly do you think is going to make a crashed unlogged index valid
> >> again without a REINDEX? Certainly the people who are currently using
> >> hash indexes in th
Andrew Dunstan writes:
> It's a bit of a pity we don't have REINDEX CONCURRENTLY.
Well, that's an entirely different thread. Let's not get distracted
by that topic.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 2014-11-01 14:45:47 -0400, Andrew Dunstan wrote:
>
> On 11/01/2014 02:34 PM, Andres Freund wrote:
> >>Yeah, if we were trying to duplicate the behavior of indisvalid, there'd
> >>need to be a way to detect the invalid index at plan time and not use it.
> >>But I'm not sure that that's actually
Andres Freund writes:
> On 2014-11-01 14:39:21 -0400, Tom Lane wrote:
>> What exactly do you think is going to make a crashed unlogged index valid
>> again without a REINDEX? Certainly the people who are currently using
>> hash indexes in the way Andrew describes are expecting to have to REINDEX
On 11/01/2014 02:34 PM, Andres Freund wrote:
Yeah, if we were trying to duplicate the behavior of indisvalid, there'd
need to be a way to detect the invalid index at plan time and not use it.
But I'm not sure that that's actually an improvement from the user's
standpoint: what they'd see is quer
On 2014-11-01 14:39:21 -0400, Tom Lane wrote:
> Andres Freund writes:
> > A REINDEX is imo unlikely to be acceptable. It takes long (why would you
> > bother on a small table?) and locks the relation/indexes.
>
> I think the goalposts just took a vacation to Acapulco.
I think that might be cause
Andres Freund writes:
> A REINDEX is imo unlikely to be acceptable. It takes long (why would you
> bother on a small table?) and locks the relation/indexes.
I think the goalposts just took a vacation to Acapulco.
What exactly do you think is going to make a crashed unlogged index valid
again wit
On 2014-11-01 14:23:07 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-11-01 13:58:02 -0400, Tom Lane wrote:
> >> maybe we don't have to. What about having the init-fork mechanism restore
> >> a hash index into a state with the metapage marked as invalid? hashinsert
> >> etc could sim
Andres Freund writes:
> On 2014-11-01 14:19:22 -0400, Andrew Dunstan wrote:
>> Isn't the planner still going to try to use the index in that case? If it's
>> not then I'd be OK with it, but if it's going to make the table largely
>> unusable until it's reindexed that would be rather sad.
> Both t
On 2014-11-01 14:19:22 -0400, Andrew Dunstan wrote:
> Isn't the planner still going to try to use the index in that case? If it's
> not then I'd be OK with it, but if it's going to make the table largely
> unusable until it's reindexed that would be rather sad.
Both the planner (for querying) and
Andres Freund writes:
> On 2014-11-01 13:58:02 -0400, Tom Lane wrote:
>> maybe we don't have to. What about having the init-fork mechanism restore
>> a hash index into a state with the metapage marked as invalid? hashinsert
>> etc could simply do nothing when they see this metapage state.
>> has
On 11/01/2014 01:58 PM, Tom Lane wrote:
Andres Freund writes:
On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
Yes, and I'm arguing that is the wrong decision. If hash indexes are
"discouraged", then they shouldn't be in core in the first place.
Last time we discussed it there were people (
On 2014-11-01 14:13:02 -0400, Andrew Dunstan wrote:
> Yes, although there might not be much reason to use them either. I think
> Tom's first step of making hash indexes automatically unlogged makes sense.
> Longer term I'd like to see unlogged as an option for all AMs - especially
> btree.
If we i
On 11/01/2014 01:26 PM, Andres Freund wrote:
On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
On 10/31/2014 03:07 PM, Tom Lane wrote:
I don't care one way or the other about the money type, but I will defend
hash indexes, especially seeing that we've already added a pretty
in-your-face warning
On 2014-11-01 13:58:02 -0400, Tom Lane wrote:
> Yeah. When we last discussed this, the difficulty was around how to make
> that combination work. An unlogged index on an unlogged table is no
> problem: the init-fork mechanism is able to make them both go to empty
> after a crash. But for an unlo
Andres Freund writes:
> On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
>> Yes, and I'm arguing that is the wrong decision. If hash indexes are
>> "discouraged", then they shouldn't be in core in the first place.
> Last time we discussed it there were people (IIRC Andrew was one of
> them) comm
On 2014-10-31 21:25:02 -0400, Robert Haas wrote:
> On Fri, Oct 31, 2014 at 4:10 PM, Andres Freund wrote:
> >> I don't think that's correct. We only need to process local
> >> invalidation messages after CommandCounterIncrement(), which I
> >> anticipate prohibiting during parallel execution (shor
On 2014-11-01 14:41:02 +0100, Petr Jelinek wrote:
> On 01/11/14 14:00, Michael Paquier wrote:
> >
> >More comments:
> >- Heikki already mentioned it, but after reading the code I see little
> >point in having the extra field implementing like that in core for many
> >reasons even if it is *just* 4
On 2014-11-01 22:00:40 +0900, Michael Paquier wrote:
> On Sat, Nov 1, 2014 at 1:45 PM, Michael Paquier
> wrote:
>
> > I am still planning to do more extensive tests, and study a bit more
> > committs.c (with even more comments) as it is the core part of the feature.
> >
> More comments:
> - Heikk
On 2014-11-01 13:45:44 +0900, Michael Paquier wrote:
> 14) I'd put the two checks in the reverse order:
> + Assert(xid != InvalidTransactionId);
> +
> + if (!commit_ts_enabled)
> + return;
Please don't. The order is correct right now. Why you ask? This way the
correctness
On 2014-11-01 14:04:05 +, Mikko Tiihonen wrote:
> I created a proof of concecpt patch for postgresql JDBC driver that
> allows the caller to do pipelining of requests within a
> transaction. The pipelining here means same as for HTTP: the client
> can send the next execution already before wait
Josh Berkus writes:
> On 10/31/2014 03:07 PM, Tom Lane wrote:
>> I don't care one way or the other about the money type, but I will defend
>> hash indexes, especially seeing that we've already added a pretty
>> in-your-face warning as of 9.5:
>>
>> regression=# create table foo(f1 int);
>> CREATE
On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
> On 10/31/2014 03:07 PM, Tom Lane wrote:
> > I don't care one way or the other about the money type, but I will defend
> > hash indexes, especially seeing that we've already added a pretty
> > in-your-face warning as of 9.5:
> >
> > regression=# cr
On 2014-11-01 12:57:40 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-10-31 18:48:45 -0400, Tom Lane wrote:
> >> While the basic idea is sound, this particular implementation seems
> >> pretty bizarre. What's with the "md_seg_no" stuff, and why is that
> >> array typed size_t?
>
> >
Alvaro Herrera writes:
> Tom Lane wrote:
>> Not entirely sure what to do about this. It seems like for the purposes
>> of contrib/chkpass, it's a good thing that chkpass_in() won't reuse the
>> same salt. Weak as a 12-bit salt might be nowadays, it's still better
>> than no salt. Nonetheless, t
On 10/31/2014 03:07 PM, Tom Lane wrote:
> I don't care one way or the other about the money type, but I will defend
> hash indexes, especially seeing that we've already added a pretty
> in-your-face warning as of 9.5:
>
> regression=# create table foo(f1 int);
> CREATE TABLE
> regression=# create
Andres Freund writes:
> On 2014-10-31 18:48:45 -0400, Tom Lane wrote:
>> While the basic idea is sound, this particular implementation seems
>> pretty bizarre. What's with the "md_seg_no" stuff, and why is that
>> array typed size_t?
> It stores the length of the array of _MdfdVec entries.
Oh.
Mikko Tiihonen writes:
> I created a proof of concecpt patch for postgresql JDBC driver that allows
> the caller to do pipelining of requests within a transaction. The pipelining
> here means same as for HTTP: the client can send the next execution already
> before waiting for the response of t
On 10/13/14 3:16 PM, Bruce Momjian wrote:
> Where are we on this?
I think we discovered that the pros and cons of the different options
are not as clear-cut, and it's better to leave the default as is until
additional features make one option a clear winner.
--
Sent via pgsql-hackers mailing l
Hi,
I created a proof of concecpt patch for postgresql JDBC driver that allows the
caller to do pipelining of requests within a transaction. The pipelining here
means same as for HTTP: the client can send the next execution already before
waiting for the response of the previous request to be f
On 10/11/14 6:54 PM, Bruce Momjian wrote:
>> Are we going to unrevert this patch for 9.5?
> Seems no one is thinking of restoring this patch and working on the
> issue.
I had postponed work on this issue and set out to create a test
infrastructure so that all the subtle behavioral dependencies men
On 01/11/14 14:00, Michael Paquier wrote:
More comments:
- Heikki already mentioned it, but after reading the code I see little
point in having the extra field implementing like that in core for many
reasons even if it is *just* 4 bytes:
1) It is untested and actually there is no direct use for
On Sat, Nov 1, 2014 at 1:45 PM, Michael Paquier
wrote:
> I am still planning to do more extensive tests, and study a bit more
> committs.c (with even more comments) as it is the core part of the feature.
>
More comments:
- Heikki already mentioned it, but after reading the code I see little
point
On Sat, Nov 1, 2014 at 9:04 PM, Petr Jelinek wrote:
> On 01/11/14 12:19, Petr Jelinek wrote:
>
>> Hi,
>>
>> thanks for review.
>>
>> On 01/11/14 05:45, Michael Paquier wrote:
>>
>>> Now here are a couple of comments at code level, this code seems not
>>> enough baked for a commit:
>>> 1) The foll
On 01/11/14 12:19, Petr Jelinek wrote:
Hi,
thanks for review.
On 01/11/14 05:45, Michael Paquier wrote:
Now here are a couple of comments at code level, this code seems not
enough baked for a commit:
1) The following renaming should be done:
- pg_get_transaction_committime to pg_get_transactio
Hi,
thanks for review.
On 01/11/14 05:45, Michael Paquier wrote:
Now here are a couple of comments at code level, this code seems not
enough baked for a commit:
1) The following renaming should be done:
- pg_get_transaction_committime to pg_get_transaction_commit_time
- pg_get_transaction_extra
On 10/20/14 8:53 PM, Wim Lewis wrote:
> Apple has published their changes to Postgres (since they ship it in recent
> versions of OSX) here, fwiw, including the launchd plist they use:
> http://www.opensource.apple.com/source/PostgreSQL/
>
> One thing I noticed is that Apple also used the label
Hi,
On Sat, Nov 1, 2014 at 1:21 PM, Eric Ridge wrote:
> On Fri, Oct 31, 2014 at 6:07 PM, Tom Lane wrote:
>>
>> I don't know if/when that will happen as such, but Simon was making noises
>> about writing code to treat hash indexes as unlogged automatically, which
>> would more or less fix the wor
On 31 October 2014 17:46, Michael Banck wrote:
> I wonder whether that is pilot error (fair enough), or whether something
> could be done about this?
When originally written the constraints were tighter, but have since
been relaxed.
Even so a CIC waits until all snapshots that can see it have g
61 matches
Mail list logo
