Hi all,
I noticed that SET STATISTICS was not in a block in alter_table.sgml:
- SET STATISTICS acquires a SHARE UPDATE EXCLUSIVE lock.
+ SET STATISTICS acquires a
+ SHARE UPDATE EXCLUSIVE lock.
That's a small detail, still.. Patch is attached.
Regards,
--
Michael
dif
On Mon, Jan 12, 2015 at 05:16:40PM -0500, Stephen Frost wrote:
> Alright, here's an updated patch which doesn't return any detail if no
> values are visible or if only a partial key is visible.
I browsed this patch. There's been no mention of foreign key constraints, but
ri_ReportViolation() dese
On Sun, Jan 11, 2015 at 3:36 AM, Michael Paquier
wrote:
>> My understanding is that once you get a successful PREPARE that should mean
>> that it's basically impossible for the transaction to fail to commit. If
>> that's not the case, I fail to see how you can get any decent level of
>> sanity out
On Thu, Jan 8, 2015 at 1:00 PM, Kevin Grittner wrote:
>> Clearly, all the nodes other than the local one need to use 2PC. I am
>> unconvinced that the local node must write a 2PC state file only to
>> turn around and remove it again almost immediately thereafter.
>
> The key point is that the dis
On Wed, Jan 14, 2015 at 9:12 AM, Amit Kapila
wrote:
> On Tue, Jan 13, 2015 at 4:55 PM, John Gorman
> wrote:
> >
> >
> >
> > On Sun, Jan 11, 2015 at 6:00 PM, Robert Haas
> wrote:
> >>
> >> On Sun, Jan 11, 2015 at 6:01 AM, Stephen Frost
> wrote:
> >> > So, for my 2c, I've long expected us to par
On Tue, Jan 13, 2015 at 4:55 PM, John Gorman wrote:
>
>
>
> On Sun, Jan 11, 2015 at 6:00 PM, Robert Haas
wrote:
>>
>> On Sun, Jan 11, 2015 at 6:01 AM, Stephen Frost
wrote:
>> > So, for my 2c, I've long expected us to parallelize at the
relation-file
>> > level for these kinds of operations. Thi
Would anyone object to modifying configure.in like this:
if test "$GCC" = yes -a "$ICC" = no; then
- CFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wpointer-arith"
+ CFLAGS="-Wall $CFLAGS -Wmissing-prototypes -Wpointer-arith"
# These work in some but not all gcc versions
PGAC_PROG_CC_CFLAGS
2014-12-18 19:35 GMT+07:00 Fujii Masao :
> On Mon, Dec 15, 2014 at 2:38 PM, Andrew Gierth
> wrote:
> > I was thinking something like this, added just after that para:
> >
> >
> >
> > While the actual arguments to the function remain unchanged between
> > calls, if you detoa
On 2015-01-13 20:21:55 +0100, Andres Freund wrote:
> On 2015-01-13 11:10:06 -0800, Magnus Hagander wrote:
> > EXEC_BACKEND on Windows doesn't actually use a tempfile though, so I'm
> > guessing that's it.
>
> Ah! Then this really is fairly harmless. Will fix and backpatch anyway,
> but the number
On Tue, Jan 13, 2015 at 3:54 PM, Merlin Moncure wrote:
> Some more information what's happening:
> This is a ghetto logical replication engine that migrates data from
> sql sever to postgres, consolidating a sharded database into a single
> set of tables (of which there are only two). There is onl
I wrote:
> Heikki Linnakangas writes:
>> But do we really need to backpatch any of this?
> Alexey's example consumes only a couple hundred MB in 9.2, vs about 7GB
> peak in 9.3 and up. That seems like a pretty nasty regression.
I did a bit more measurement of the time and backend memory consump
On Tue, Jan 13, 2015 at 3:54 PM, Andres Freund wrote:
>> I don't remember seeing _bt_moveright() or _bt_compare() figuring so
>> prominently, where _bt_binsrch() is nowhere to be seen. I can't see a
>> reference to _bt_binsrch() in either profile.
>
> Well, we do a _bt_moveright pretty early on,
On Tue, Jan 13, 2015 at 4:05 PM, Tom Lane wrote:
> I'm not convinced that Peter is barking up the right tree. I'm noticing
> that the profiles seem rather skewed towards parser/planner work; so I
> suspect the contention is probably on access to system catalogs. No
> idea exactly why though.
I
On 2015-01-13 19:05:10 -0500, Tom Lane wrote:
> Merlin Moncure writes:
> > On Tue, Jan 13, 2015 at 5:54 PM, Peter Geoghegan wrote:
> >> In case it isn't clear, I think that the proximate cause here may well
> >> be either one (or both) of commits
> >> efada2b8e920adfdf7418862e939925d2acd1b89 and/
Merlin Moncure writes:
> On Tue, Jan 13, 2015 at 5:54 PM, Peter Geoghegan wrote:
>> In case it isn't clear, I think that the proximate cause here may well
>> be either one (or both) of commits
>> efada2b8e920adfdf7418862e939925d2acd1b89 and/or
>> 40dae7ec537c5619fc93ad602c62f37be786d161. Probably
On Tue, Jan 13, 2015 at 5:54 PM, Peter Geoghegan wrote:
> On Tue, Jan 13, 2015 at 3:50 PM, Merlin Moncure wrote:
>>> I don't remember seeing _bt_moveright() or _bt_compare() figuring so
>>> prominently, where _bt_binsrch() is nowhere to be seen. I can't see a
>>> reference to _bt_binsrch() in ei
On Tue, Jan 13, 2015 at 5:42 PM, Andres Freund wrote:
> On 2015-01-13 17:39:09 -0600, Merlin Moncure wrote:
>> On Tue, Jan 13, 2015 at 5:21 PM, Andres Freund
>> wrote:
>> > On 2015-01-13 15:17:15 -0800, Peter Geoghegan wrote:
>> >> I'm inclined to think that this is a livelock, and so the proble
On Tue, Jan 13, 2015 at 3:50 PM, Merlin Moncure wrote:
>> I don't remember seeing _bt_moveright() or _bt_compare() figuring so
>> prominently, where _bt_binsrch() is nowhere to be seen. I can't see a
>> reference to _bt_binsrch() in either profile.
>
> hm, this is hand compiled now, I bet the sym
On 2015-01-13 15:49:33 -0800, Peter Geoghegan wrote:
> On Tue, Jan 13, 2015 at 3:21 PM, Andres Freund wrote:
> > My guess is rather that it's contention on the freelist lock via
> > StrategyGetBuffer's. I've seen profiles like this due to exactly that
> > before - and it fits to parallel loading q
On Tue, Jan 13, 2015 at 5:49 PM, Peter Geoghegan wrote:
> On Tue, Jan 13, 2015 at 3:21 PM, Andres Freund wrote:
>> My guess is rather that it's contention on the freelist lock via
>> StrategyGetBuffer's. I've seen profiles like this due to exactly that
>> before - and it fits to parallel loading
On Tue, Jan 13, 2015 at 3:21 PM, Andres Freund wrote:
> My guess is rather that it's contention on the freelist lock via
> StrategyGetBuffer's. I've seen profiles like this due to exactly that
> before - and it fits to parallel loading quite well.
I'm not saying you're wrong, but the breakdown of
On 2015-01-13 17:39:09 -0600, Merlin Moncure wrote:
> On Tue, Jan 13, 2015 at 5:21 PM, Andres Freund wrote:
> > On 2015-01-13 15:17:15 -0800, Peter Geoghegan wrote:
> >> I'm inclined to think that this is a livelock, and so the problem
> >> isn't evident from the structure of the B-Tree, but it ca
On Tue, Jan 13, 2015 at 5:21 PM, Andres Freund wrote:
> On 2015-01-13 15:17:15 -0800, Peter Geoghegan wrote:
>> I'm inclined to think that this is a livelock, and so the problem
>> isn't evident from the structure of the B-Tree, but it can't hurt to
>> check.
>
> My guess is rather that it's conte
Tom Lane writes:
> [blah]
> (This is another reason for "_safe" not being the mot juste :-()
My wording was definitely incorrect but I sure you got it: I should
have said "safe on error". noerror or error_safe would are definitely
more correct.
> In that light, I'm not really convinced that there
On 2015-01-13 15:17:15 -0800, Peter Geoghegan wrote:
> I'm inclined to think that this is a livelock, and so the problem
> isn't evident from the structure of the B-Tree, but it can't hurt to
> check.
My guess is rather that it's contention on the freelist lock via
StrategyGetBuffer's. I've seen p
On Tue, Jan 13, 2015 at 2:29 PM, Merlin Moncure wrote:
> On my workstation today (running vanilla 9.4.0) I was testing some new
> code that does aggressive parallel loading to a couple of tables.
Could you give more details, please? For example, I'd like to see
representative data, or at least th
On Tue, Jan 13, 2015 at 4:33 PM, Andres Freund wrote:
> Hi,
>
> On 2015-01-13 16:29:51 -0600, Merlin Moncure wrote:
>> On my workstation today (running vanilla 9.4.0) I was testing some new
>> code that does aggressive parallel loading to a couple of tables. It
>> ran ok several dozen times and fr
Hi,
On 2015-01-13 16:29:51 -0600, Merlin Moncure wrote:
> On my workstation today (running vanilla 9.4.0) I was testing some new
> code that does aggressive parallel loading to a couple of tables. It
> ran ok several dozen times and froze up with no external trigger.
> There were at most 8 active
On my workstation today (running vanilla 9.4.0) I was testing some new
code that does aggressive parallel loading to a couple of tables. It
ran ok several dozen times and froze up with no external trigger.
There were at most 8 active backends that were stuck (the loader is
threaded to a cap) -- eac
There are two ways in which access control for replication connections
is separate:
- replication pseudo-database in pg_hba.conf
- replication role attribute
If someone has a restrictive setup for replication and pg_basebackup,
and then pg_rewind enters, they will have to
- add a line to pg_hba
On 1/7/15 3:19 PM, Robert Haas wrote:
> On Tue, Jan 6, 2015 at 4:33 PM, Peter Eisentraut wrote:
>> Currently, when you unpack a tarred basebackup with tablespaces, the
>> symlinks will tell you whether you have unpacked the tablespace tars at
>> the right place. Otherwise, how do you know? Secon
Andres Freund writes:
> On 2015-01-13 11:10:06 -0800, Magnus Hagander wrote:
>> EXEC_BACKEND on Windows doesn't actually use a tempfile though, so I'm
>> guessing that's it.
> Ah! Then this really is fairly harmless. Will fix and backpatch anyway,
> but the number of affected people should be pre
On 2015-01-13 11:10:06 -0800, Magnus Hagander wrote:
> EXEC_BACKEND on Windows doesn't actually use a tempfile though, so I'm
> guessing that's it.
Ah! Then this really is fairly harmless. Will fix and backpatch anyway,
but the number of affected people should be pretty much zero.
Greetings,
And
On Tue, Jan 13, 2015 at 10:23 AM, Andres Freund
wrote:
> Hi,
>
> Currently the combination from $subject fails for me with "could not
> read from backend variables file ...".
>
> The origin for that problem seems to be b94ce6e80 which moved
> RemovePgTempFiles() to after SysLogger_Start(). Unless
Hi,
Currently the combination from $subject fails for me with "could not
read from backend variables file ...".
The origin for that problem seems to be b94ce6e80 which moved
RemovePgTempFiles() to after SysLogger_Start(). Unless the syslogger
starts up very quickly RemovePgTempFiles() will have d
On 01/13/2015 12:11 PM, Vladimir Borodin wrote:
05 янв. 2015 г., в 18:15, Vladimir Borodin написал(а):
Hi all.
I have a simple script for planned switchover of PostgreSQL (9.3 and 9.4)
master to one of its replicas. This script checks a lot of things before doing
it and one of them is that
Heikki Linnakangas writes:
> On 01/13/2015 07:24 PM, Tom Lane wrote:
>> In hindsight, that's a bad API and we should change it to something like
>> ExplainState *es = NewExplainState();
>> so that the sizeof the struct isn't embedded in extension code. But we
>> definitely can't do that in back b
On 01/13/2015 06:04 PM, Timmer, Marius wrote:
-malloc() (StringInfo is used as suggested now).
There really shouldn't be any snprintf() calls in the patch, when
StringInfo is used correctly...
@@ -1187,6 +1187,7 @@ explain (verbose, costs off) select * from matest0 order
by 1-id;
Sort
On 01/13/2015 07:24 PM, Tom Lane wrote:
It is, but FDWs are not at risk here: they merely reference ExplainStates
that were allocated by core backend code. So as long as we add the new
field at the end it's not a problem for them. Problematic usage would be
like what auto_explain does:
Hi,
we removed
-malloc() (StringInfo is used as suggested now).
-leftover commented out code
-the splitting of existing declaration and initialization in show_group_keys().
Missing tests and documentation are WIP and will follow with the next patch
version.
Best regards
Marius
---
Mariu
Alvaro Herrera writes:
> Tom Lane wrote:
>> A difficulty with either your patch or my idea is that they require adding
>> another field to ExplainState, which is an ABI break for any third-party
>> code that might be declaring variables of that struct type. That's fine
>> for HEAD but would be ri
Tom Lane wrote:
> A difficulty with either your patch or my idea is that they require adding
> another field to ExplainState, which is an ABI break for any third-party
> code that might be declaring variables of that struct type. That's fine
> for HEAD but would be risky to back-patch. Any thoug
I wrote:
> Heikki Linnakangas writes:
>> Hmm, something like the attached? Seems reasonable...
> This looks pretty unsafe to me: it assumes, without much justification,
> that there is no memory allocated during show_expression() that will be
> needed later.
> I suspect the O(N^2) consumption co
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> One improvement we could trivially make is to only do this for
> multi-column indexes. If there is only one column there is no danger
> of information leakage, right?
That's an interesting thought. If there's only one column then to have
a confli
Il 13/01/15 12:53, Gabriele Bartolini ha scritto:
> Hi Marco,
>
> could you please send an updated version the patch against the current
> HEAD in order to facilitate reviewers?
>
Here is the updated patch for incremental file based backup.
It is based on the current HEAD.
I'm now working to
On 11/30/14 11:45 AM, Tom Lane wrote:
> The "API break" isn't a big issue imo. The net effect would be that eg
> hstore 9.3.6 wouldn't work against a 9.3.5 server. We do that sort of
> thing *all the time* --- at least twice in the past year, according to
> a quick scan of the commit logs. If yo
Heikki Linnakangas writes:
> On 01/13/2015 02:08 PM, Alexey Bashtanov wrote:
>> By varying the parameters and reading source code I determined that
>> memory usage linearly depends on (plan nodes count)*(overall columns
>> count), thus it quadratically depends on number of tables unionized.
>>
>>
I wrote:
> Michael Paquier writes:
>> Attached is a patch adding the following set of functions for frontend
>> and backends returning NULL instead of reporting ERROR when allocation
>> fails:
>> - palloc_safe
>> - palloc0_safe
>> - repalloc_safe
> Unimpressed with this naming convention. "_unsa
Hi,
I just noticed that authentication_timeout is ineffective for
replication=true type connections. That's because walsender doesn't
register a SIGINT handler and authentication_timeout relies on having
one.
There's no problem with reading the initial startup packet
(ProcessStartupPacket/Backend
On 13.01.2015 16:47, Heikki Linnakangas wrote:
Hmm, something like the attached? Seems reasonable...
- Heikki
yes, i have tested something like this, it stopped eating memory
Just one small notice to the patch you attached: maybe it would be more
safe to switch to oldcxt before calling
Expl
On 13 January 2015 at 13:50, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> On 12 January 2015 at 22:16, Stephen Frost wrote:
>> > Alright, here's an updated patch which doesn't return any detail if no
>> > values are visible or if only a partial key is visible.
>> >
>
On Sat, Jan 10, 2015 at 04:41:16PM -0800, David Fetter wrote:
> On Sat, Jan 10, 2015 at 09:30:57AM +0100, Erik Rijkers wrote:
> > On Fri, January 9, 2015 20:15, David Fetter wrote:
> > > [psql_fix_uri_service_003.patch]
> >
> > Applies on master; the feature (switching services) works well but a \
On 13/01/15 13:24, Tomas Vondra wrote:
On 12.1.2015 22:33, Petr Jelinek wrote:
On 15/12/14 11:36, Petr Jelinek wrote:
On 10/12/14 03:33, Petr Jelinek wrote:
On 24/11/14 12:16, Heikki Linnakangas wrote:
About the rough edges:
- The AlterSequence is not prettiest code around as we now have to
c
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 12 January 2015 at 22:16, Stephen Frost wrote:
> > Alright, here's an updated patch which doesn't return any detail if no
> > values are visible or if only a partial key is visible.
> >
> > Please take a look. I'm not thrilled with simply retu
On 01/13/2015 02:08 PM, Alexey Bashtanov wrote:
I found that EXPLAIN command takes very much memory to execute when huge
unions are used.
For example the following sql
-- begin sql
create table t (a000 int, a001 int, ... a099 int);
explain select * from (
select a001 a from t
union al
On 12 January 2015 at 22:16, Stephen Frost wrote:
> Alright, here's an updated patch which doesn't return any detail if no
> values are visible or if only a partial key is visible.
>
> Please take a look. I'm not thrilled with simply returning an empty
> string and then checking that for BuildInd
On 01/13/2015 01:09 PM, Michael Paquier wrote:
On Tue, Jan 13, 2015 at 5:36 PM, Heikki Linnakangas
wrote:
You'll need to use "(void) pushJsonbValue(...)", otherwise you'll just get a
different warning. See commit c8315930.
Oh, I see. So this portion in contrib/ has been visibly missing.
Attach
On 12.1.2015 22:33, Petr Jelinek wrote:
> On 15/12/14 11:36, Petr Jelinek wrote:
>> On 10/12/14 03:33, Petr Jelinek wrote:
>>> On 24/11/14 12:16, Heikki Linnakangas wrote:
>>>
>>> About the rough edges:
>>> - The AlterSequence is not prettiest code around as we now have to
>>> create new relation w
On 2015-01-12 00:40:50 +0100, Andres Freund wrote:
> Fixed in what I've since pushed (as Heikki basically was ok with the
> patch sent a couple months back, modulo some fixes)...
I'd not actually pushed that patch... I had pushed some patches
(barriers, atomics), but had decided to hold off on thi
Hello!
I found that EXPLAIN command takes very much memory to execute when huge
unions are used.
For example the following sql
-- begin sql
create table t (a000 int, a001 int, ... a099 int);
explain select * from (
select a001 a from t
union all
select a001 a from t
union all
On Tue, Jan 13, 2015 at 7:25 AM, John Gorman wrote:
>
>
> On Sun, Jan 11, 2015 at 6:00 PM, Robert Haas
> wrote:
>
>> On Sun, Jan 11, 2015 at 6:01 AM, Stephen Frost
>> wrote:
>> > So, for my 2c, I've long expected us to parallelize at the relation-file
>> > level for these kinds of operations.
Hi Marco,
could you please send an updated version the patch against the current
HEAD in order to facilitate reviewers?
Thanks,
Gabriele
--
Gabriele Bartolini - 2ndQuadrant Italia - Managing Director
PostgreSQL Training, Services and Support
gabriele.bartol...@2ndquadrant.it | www.2ndQuadra
Hello. This is a version 3 patch.
- PgFdwConnState is removed
- PgFdwConn is isolated as a separate module.
- State transition was simplicated, I think.
- Comment about multiple scans on a connection is added.
- The issue of PREPARE is not addressed yet.
- It is to show how the new style look
On Sun, Jan 11, 2015 at 6:00 PM, Robert Haas wrote:
> On Sun, Jan 11, 2015 at 6:01 AM, Stephen Frost wrote:
> > So, for my 2c, I've long expected us to parallelize at the relation-file
> > level for these kinds of operations. This goes back to my other
> > thoughts on how we should be thinking
Il 08/01/15 20:18, Jim Nasby ha scritto:
> On 1/7/15, 3:50 AM, Marco Nenciarini wrote:
>> The current implementation tracks only heap LSN. It currently does not
>> track any kind of indexes, but this can be easily added later.
>
> Would it make sense to do this at a buffer level, instead of at the
On 12 January 2015 at 15:57, Robert Haas wrote:
> On Thu, Jan 8, 2015 at 6:31 AM, David Rowley wrote:
> > I'd be keen to know what people's thoughts are about the
> nodeAlternativePlan
> > only surviving until the plan is initialised.
>
> I find it scary, although sometimes I am easily frightene
On Tue, Jan 13, 2015 at 5:45 PM, Heikki Linnakangas
wrote:
> This looks like a false positive to me. PQgetCopyData() will only return a
> buffer if its return value is > 0
Right. Sorry for the noise.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On Tue, Jan 13, 2015 at 5:36 PM, Heikki Linnakangas
wrote:
> You'll need to use "(void) pushJsonbValue(...)", otherwise you'll just get a
> different warning. See commit c8315930.
Oh, I see. So this portion in contrib/ has been visibly missing.
Attached is a new patch.
--
Michael
*** a/contrib/hs
On 13 January 2015 at 11:29, Jim Nasby wrote:
> On 12/3/14 1:08 PM, Tom Lane wrote:
>
>> Heikki Linnakangas writes:
>>
>>> >Do you need to plan for every combination, where some joins are removed
>>> >and some are not?
>>>
>> I would vote for just having two plans and one switch node. To exploi
05 янв. 2015 г., в 18:15, Vladimir Borodin написал(а):
> Hi all.
>
> I have a simple script for planned switchover of PostgreSQL (9.3 and 9.4)
> master to one of its replicas. This script checks a lot of things before
> doing it and one of them is that all data from master has been received b
On 01/13/2015 10:18 AM, Michael Paquier wrote:
receivelog.c is leaking memory in CopyStreamReceive when receiving COPY data.
The issue has been spotted by coverity. The patch attached fixes the
problem, and contains as well improved comments.
*** a/src/bin/pg_basebackup/receivelog.c
--- b/src/bi
On 01/13/2015 09:39 AM, Michael Paquier wrote:
On Tue, Jan 13, 2015 at 4:34 PM, Michael Paquier
wrote:
Attached is a patch to fix that.
Oh, actually that's as well the case of hstore_to_jsonb_loose. Updated
patch is attached.
You'll need to use "(void) pushJsonbValue(...)", otherwise you'll
Thanks for the review.
Here is a new version of the patch with updated isolation tests and
documentation.
--
Andreas Karlsson
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index a0d6867..459e86d 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -908,9 +908,10 @
Hi all,
receivelog.c is leaking memory in CopyStreamReceive when receiving COPY data.
The issue has been spotted by coverity. The patch attached fixes the
problem, and contains as well improved comments.
Regards,
--
Michael
*** a/src/bin/pg_basebackup/receivelog.c
--- b/src/bin/pg_basebackup/rece
74 matches
Mail list logo
