2015-12-13 8:14 GMT+01:00 Pavel Stehule :
>
>
> 2015-12-10 19:29 GMT+01:00 Pavel Stehule :
>
>>
>>
>>
>>> postgres=# \crosstabview 4 +month label
>>>
>>
>> Maybe using optional int order column instead label is better - then you
>> can do sort on client side
>>
>> so the syntax can be "\crosstabvi
2015-12-10 19:29 GMT+01:00 Pavel Stehule :
>
>
>
>> postgres=# \crosstabview 4 +month label
>>
>
> Maybe using optional int order column instead label is better - then you
> can do sort on client side
>
> so the syntax can be "\crosstabview VCol [+/-]HCol [[+-]HOrderCol]
>
here is patch - support
On Sun, Dec 13, 2015 at 1:16 AM, Jaime Casanova <
jaime.casan...@2ndquadrant.com> wrote:
> indexrelid = 'indexname'::regclass;
This works, but might bloat system catalog.
Mark Dilger writes:
>> On Dec 12, 2015, at 3:42 PM, Tom Lane wrote:
>> ... In general, though, I'd rather not try to
>> teach InteractiveBackend() such a large amount about SQL syntax.
> I use CREATE RULE within startup files in the fork that I maintain. I have
> lots of them, totaling perhaps
On Sat, Dec 12, 2015 at 9:48 AM, Corey Huinker wrote:
>
>
> What, if any, other load should be placed on the underlying table during the
> test?
>
> I ask because CIC statements that run in seconds on our staging machine can
> take many hours on our production machine, when most of the access is j
On Sun, Dec 13, 2015 at 4:24 AM, Tomas Vondra
wrote:
>
>
> On 12/12/2015 11:39 PM, Andres Freund wrote:
>
>> On 2015-12-12 23:28:33 +0100, Tomas Vondra wrote:
>>
>>> On 12/12/2015 11:20 PM, Andres Freund wrote:
>>>
On 2015-12-12 22:14:13 +0100, Tomas Vondra wrote:
> this is the seco
On Sun, Dec 13, 2015 at 12:07 AM, Tomas Vondra wrote:
> Hi,
>
> attached is a patch adding a function pg_current_xlog_flush_location(),
> which proved quite useful when investigating the ext4 data loss bug. It's
> mostly what was already sent to that thread, except for docs that were
> missing in
On Sat, Dec 12, 2015 at 12:02 PM, Andres Freund wrote:
> Noah, Robert, All
>
> On 2015-12-11 11:20:21 -0500, Robert Haas wrote:
>> On Thu, Dec 10, 2015 at 9:32 AM, Robert Haas wrote:
>> >> Adding a 'prevOffsetStopLimit' and using it seems like a ~5 line patch.
>> >
>> > So let's do that, then.
>>
> On Dec 12, 2015, at 3:42 PM, Tom Lane wrote:
>
> Joe Conway writes:
>> On 12/12/2015 02:31 PM, Tom Lane wrote:
>>> I'm not particularly wedded to this rule. In principle we could go so
>>> far as to import psql's code that parses commands and figures out which
>>> semicolons are command term
On Sat, Dec 12, 2015 at 4:35 PM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> On 12/11/15 4:12 PM, Stephen Frost wrote:
>> > As with ACLs, the DROP OWNED BY caller must have permission to modify
>> > the policy or a WARNING is thrown and no change is made to the policy.
>>
On Fri, Dec 11, 2015 at 4:42 PM, David Rowley
wrote:
> On 12 December 2015 at 04:00, Robert Haas wrote:
>> I'd like to commit David Rowley's patch from the other thread first,
>> and then deal with this one afterwards. The only thing I feel
>> strongly needs to be changed in that patch is CFUNC
On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de wrote:
> On 2015-11-15 16:24:24 -0500, Robert Haas wrote:
>> I think what we should do about the buffer locks is polish up this
>> patch and get it applied:
>>
>> http://www.postgresql.org/message-id/20150907175909.gd5...@alap3.anarazel.de
>>
>>
Greg Stark writes:
> On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich
> wrote:
> When you hit the timeout is this implemented in your fuzzer or using
> statement_timeout? If the former, can you add a statement_timeout of
> just short of the timeout in the fuzzer and find cases where the
> pl
Paul Ramsey writes:
> The attached patch changes web references to PostGIS to point to the actual
> community site (postgis.net) which is active, rather than the historical site
> (postgis.org).
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Andres Freund writes:
> That's cool too. Besides processing the .bki files, and there largely
> reg*_in, the many restarts are the most expensive parts of initdb.
BTW, in case anyone is doubting it, I did a little bit of "perf" tracing
and confirmed Andres' comment here: more than 50% of the runt
On Sun, Dec 13, 2015 at 12:04:34AM +, Greg Stark wrote:
> On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich
> wrote:
> Did you publish the source already? I haven't been following all
> along, sorry if these are all answered questions.
Either he has, or the following is a truly astonishin
On Sat, Dec 12, 2015 at 2:28 PM, Peter Geoghegan wrote:
> On Sat, Dec 12, 2015 at 12:10 AM, Jeff Janes wrote:
>> I have a question about the terminology used in this patch. What is a
>> tuple proper? What is it in contradistinction to? I would think that
>> a tuple which is located in its own
The attached patch changes web references to PostGIS to point to the actual
community site (postgis.net) which is active, rather than the historical site
(postgis.org).
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
postgis_doc.patch
Description: Binary data
--
Sent via pgsq
On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich wrote:
> I currently set statement_timeout to 1s to avoid wasting time letting
> postgres crunch numbers. Less than 0.5% of the queries run into this
> timeout.
I wonder if any of these timeouts would be interesting to look at.
Some may just
Joe Conway writes:
> On 12/12/2015 02:31 PM, Tom Lane wrote:
>> I'm not particularly wedded to this rule. In principle we could go so
>> far as to import psql's code that parses commands and figures out which
>> semicolons are command terminators --- but that is a pretty large chunk
>> of code, a
On Fri, Dec 11, 2015 at 9:13 AM, Robert Haas wrote:
> Also, I'd be in favor of you updating the patch to reflect the
> comments from Tom and Simon on November 17th.
Attached revision:
* Has more worked out comments on encoding, per Simon's request.
* Uses Tom's preferred formulation for encodin
Andres Freund writes:
> On 2015-12-12 17:31:49 -0500, Tom Lane wrote:
>> Does anyone know of people using standalone mode other than
>> for initdb?
> Unfortunately yes. There's docker instances around that configure users
> and everything using it.
Hm, that means that we *do* have to worry about
On Sat, Dec 12, 2015 at 10:31 PM, Andres Freund wrote:
> On 2015-12-12 12:52:21 +0100, Andres Freund wrote:
>> On 2015-12-12 20:49:52 +0900, Michael Paquier wrote:
>> > Should we consider this bug a 9.5 blocker?
>>
>> I don't think so. But either way, I'm right now working on getting it
>> fixed a
On 12/12/2015 02:31 PM, Tom Lane wrote:
> I'm not particularly wedded to this rule. In principle we could go so
> far as to import psql's code that parses commands and figures out which
> semicolons are command terminators --- but that is a pretty large chunk
> of code, and I think it'd really be
On 2015-12-12 17:31:49 -0500, Tom Lane wrote:
> I thought this sounded like a nice lazy-Saturday project, so I started
> poking at it, and attached is a WIP patch.
Not bad, not bad at all.
> After some experimentation, I came up with the idea of executing any
> time that a semicolon followed by
On 12/12/2015 11:39 PM, Andres Freund wrote:
On 2015-12-12 23:28:33 +0100, Tomas Vondra wrote:
On 12/12/2015 11:20 PM, Andres Freund wrote:
On 2015-12-12 22:14:13 +0100, Tomas Vondra wrote:
this is the second improvement proposed in the thread [1] about ext4 data
loss issue. It adds another
On 2015-12-12 13:28:28 -0500, Tom Lane wrote:
> BTW, there's another thing I'd like to see improved in this area, which is
> a problem already but will get a lot worse if we push more work into the
> post-bootstrap phase of initdb. That is that the post-bootstrap phase is
> both inefficient and im
On 2015-12-12 23:28:33 +0100, Tomas Vondra wrote:
> On 12/12/2015 11:20 PM, Andres Freund wrote:
> >On 2015-12-12 22:14:13 +0100, Tomas Vondra wrote:
> >>this is the second improvement proposed in the thread [1] about ext4 data
> >>loss issue. It adds another field to control file, tracking the las
I wrote:
> BTW, there's another thing I'd like to see improved in this area, which is
> a problem already but will get a lot worse if we push more work into the
> post-bootstrap phase of initdb. That is that the post-bootstrap phase is
> both inefficient and impossible to debug. If you've ever ha
On 12/12/2015 11:20 PM, Andres Freund wrote:
Hi,
On 2015-12-12 22:14:13 +0100, Tomas Vondra wrote:
this is the second improvement proposed in the thread [1] about ext4 data
loss issue. It adds another field to control file, tracking the last known
WAL segment. This does not eliminate the data
On Sat, Dec 12, 2015 at 12:10 AM, Jeff Janes wrote:
> I have a question about the terminology used in this patch. What is a
> tuple proper? What is it in contradistinction to? I would think that
> a tuple which is located in its own palloc'ed space is the "proper"
> one, leaving a tuple allocat
Hi,
On 2015-12-12 22:14:13 +0100, Tomas Vondra wrote:
> this is the second improvement proposed in the thread [1] about ext4 data
> loss issue. It adds another field to control file, tracking the last known
> WAL segment. This does not eliminate the data loss, just the silent part of
> it when the
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 12/11/15 4:12 PM, Stephen Frost wrote:
> > As with ACLs, the DROP OWNED BY caller must have permission to modify
> > the policy or a WARNING is thrown and no change is made to the policy.
>
> That warning doesn't tell the user anything about how to
Hi,
this is the second improvement proposed in the thread [1] about ext4
data loss issue. It adds another field to control file, tracking the
last known WAL segment. This does not eliminate the data loss, just the
silent part of it when the last segment gets lost (due to forgetting the
rename
Greg Stark writes:
> There may be other errors that would be surprising for Tom or Robert. What
> I did with the string argument fuzzer was printed counts for each sqlstate
> for the errors and watched for errors that only occurred occasionally or
> didn't make sense to me.
>
> Also, do you have
On 12/11/15 4:12 PM, Stephen Frost wrote:
> As with ACLs, the DROP OWNED BY caller must have permission to modify
> the policy or a WARNING is thrown and no change is made to the policy.
That warning doesn't tell the user anything about how to fix the
situation or whether or why the situation is a
On Sat, Dec 12, 2015 at 9:48 AM, Corey Huinker wrote:
> I ask because CIC statements that run in seconds on our staging machine can
> take many hours on our production machine, when most of the access is just
> reads, though those reads may have been part of a larger transaction that
> did updates
On Sat, Dec 12, 2015 at 7:42 PM, Ants Aasma wrote:
> As the open coding doesn't help with eliminating control flow
> dependencies, so my idea is to encode the sort network comparison
> order in an array and use that to drive a simple loop. The code size
> would be pretty similar to insertion sort
On Sat, Dec 12, 2015 at 12:41 AM, Greg Stark wrote:
> On Wed, Dec 9, 2015 at 2:44 AM, Peter Geoghegan wrote:
>> On Tue, Dec 8, 2015 at 6:39 PM, Greg Stark wrote:
>>
>> I guess you mean insertion sort. What's the theoretical justification
>> for the change?
>
> Well my thinking was that hard codi
On 11 December 2015 at 22:03, Joshua D. Drake wrote:
> On 12/11/2015 06:25 PM, Tatsuo Ishii wrote:
>
>> What about inventing a new SET command something like:
>>
>> SET disabled_index to
>>
>> This adds to "disabled index list". The disabled index
>> list let the planner to disregard the indexes
Hi,
attached is a patch adding a function pg_current_xlog_flush_location(),
which proved quite useful when investigating the ext4 data loss bug.
It's mostly what was already sent to that thread, except for docs that
were missing in the initial version.
I'll put this into 2016-01 CF.
regards
Mark Dilger writes:
>> On Dec 11, 2015, at 2:54 PM, Caleb Welton wrote:
>> Compare:
>> CREATE FUNCTION lo_export(oid, text) RETURNS integer LANGUAGE internal
>> STRICT AS 'lo_export' WITH (OID=765);
>>
>> DATA(insert OID = 765 ( lo_export PGNSP PGUID 12 1 0 0 0 f f f
>> f t f v
On 2015-12-09 15:09, Alexander Korotkov wrote:
Patch was rebased against current master.
Any notes about current version of patch?
It would be nice to commit it and continue work on other parts of am
extendability.
The rebase seems broken, there are things missing in this version of the
pa
On 2015-11-15 16:24:24 -0500, Robert Haas wrote:
> I think what we should do about the buffer locks is polish up this
> patch and get it applied:
>
> http://www.postgresql.org/message-id/20150907175909.gd5...@alap3.anarazel.de
>
> I think it needs to be adapted to use predefined constants for the
On Fri, Dec 11, 2015 at 5:35 PM, Peter Geoghegan wrote:
> On Fri, Dec 11, 2015 at 2:26 PM, Corey Huinker
> wrote:
> > Sure, the machine we called "ninefivealpha", which incidentally, failed
> to
> > find a single bug in alpha2 thru beta2, is currently idle, and concurrent
> > index creation time
Michael Paquier writes:
> Should we consider this bug a 9.5 blocker? I feel uneasy with the fact
> of releasing a new major version knowing that we know some bugs on it,
> and this one is not cool so I have added it in the list of open items.
> We know the problem and there is a patch, so this is
Noah, Robert, All
On 2015-12-11 11:20:21 -0500, Robert Haas wrote:
> On Thu, Dec 10, 2015 at 9:32 AM, Robert Haas wrote:
> >> Adding a 'prevOffsetStopLimit' and using it seems like a ~5 line patch.
> >
> > So let's do that, then.
>
> Who is going to take care of this?
Here's two patches:
1) Th
> Oleg and Teodor announced some time ago an extension for this exact use
> case, see
> http://www.postgresql.org/message-id/pine.lnx.4.64.0910062354510.6...@sn.sai.msu.ru
>
> This also has the advantage of not needing an exclusive lock on the index.
Thanks for the info. I will try out them.
Bes
On 2015-12-12 12:52:21 +0100, Andres Freund wrote:
> On 2015-12-12 20:49:52 +0900, Michael Paquier wrote:
> > Should we consider this bug a 9.5 blocker?
>
> I don't think so. But either way, I'm right now working on getting it
> fixed anyway.
And done. Took a bit longer than predicted - I had to
On Sat, Dec 12, 2015 at 8:42 AM, David Rowley
wrote:
> On 12 December 2015 at 04:00, Robert Haas wrote:
>>
>> I'd like to commit David Rowley's patch from the other thread first,
>> and then deal with this one afterwards. The only thing I feel
>> strongly needs to be changed in that patch is CFU
On Wed, Dec 9, 2015 at 1:02 AM, Robert Haas wrote:
>
> On Thu, Dec 3, 2015 at 1:48 AM, Amit Kapila
wrote:
> > I think the way to address is don't add backend to Group list if it is
> > not intended to update the same page as Group leader. For transactions
> > to be on different pages, they have
On 2015-12-11 16:54:45 +0900, Michael Paquier wrote:
> + if (rel->rd_rel->relpersistence ==
> RELPERSISTENCE_PERMANENT ||
> + (rel->rd_rel->relpersistence ==
> RELPERSISTENCE_UNLOGGED &&
> +forkNum == INIT_FORKNUM))
On Wed, Dec 9, 2015 at 8:17 PM, Thomas Munro wrote:
> Thanks for looking at this Michael. It's probably not much fun to
> review! Here is a new version with that bit removed. More responses
> inline below.
Could this patch be rebased? There are now conflicts with 8b469bd7 and
it does not apply
On Sat, Dec 12, 2015 at 12:00 AM, Tom Lane wrote:
> Greg Stark writes:
>> So I don't think it makes sense to hold up improvements today hoping
>> for something like this.
>
> Yeah, it's certainly a wishlist item rather than something that should
> block shorter-term improvements.
OK, hence it se
Hi all,
I just bumped into the following thing while looking again at Thomas'
patch for psql tab completion:
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-complete.c
@@ -1040,7 +1040,7 @@ psql_completion(const char *text, int start, int end)
pg_strcasecmp(prev5_
On 2015-12-12 20:49:52 +0900, Michael Paquier wrote:
> Should we consider this bug a 9.5 blocker?
I don't think so. But either way, I'm right now working on getting it
fixed anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
On Fri, Dec 11, 2015 at 4:54 PM, Michael Paquier
wrote:
> On Fri, Dec 11, 2015 at 4:27 AM, Andres Freund wrote:
>> On 2015-12-10 18:36:32 +0100, Andres Freund wrote:
>>> On 2015-12-10 12:19:12 -0500, Robert Haas wrote:
>>> > > The real problem there imo isn't that the copy_relation_data() doesn't
On Sat, Dec 12, 2015 at 11:37 AM, Noah Misch wrote:
> On Fri, Dec 11, 2015 at 09:34:34PM +0900, Michael Paquier wrote:
>> On Fri, Dec 11, 2015 at 8:48 PM, Alvaro Herrera
>> wrote:
>> > Michael Paquier wrote:
>> >> On Fri, Dec 11, 2015 at 5:35 AM, Alvaro Herrera
>> >> wrote:
>> >> I guess that to
> Tatsuo Ishii wrote:
>>> Wouldn't something like:
>>>
>>> ALTER INDEX foo SET DISABLED;
>>>
>>> See more in line with our grammar?
>>
>> But this will affect other sessions, no?
>
> Not if it is used in a transaction that ends with a ROLLBACK,
> but then you might as well use DROP INDEX, except
>
On 12/12/2015 11:42, Albe Laurenz wrote:
> Tatsuo Ishii wrote:
>>> Wouldn't something like:
>>>
>>> ALTER INDEX foo SET DISABLED;
>>>
>>> See more in line with our grammar?
>>
>> But this will affect other sessions, no?
>
> Not if it is used in a transaction that ends with a ROLLBACK,
> but then y
On 12 December 2015 at 02:24, Robert Haas wrote:
> On Fri, Dec 11, 2015 at 5:16 AM, Andres Freund wrote:
> > On 2015-12-11 18:12:55 +0800, Craig Ringer wrote:
> >> On 10 December 2015 at 03:19, Robert Haas
> wrote:
> >> > On Sun, Dec 6, 2015 at 10:24 PM, Craig Ringer
> >> > wrote:
> >> > > * A
Tatsuo Ishii wrote:
>> Wouldn't something like:
>>
>> ALTER INDEX foo SET DISABLED;
>>
>> See more in line with our grammar?
>
> But this will affect other sessions, no?
Not if it is used in a transaction that ends with a ROLLBACK,
but then you might as well use DROP INDEX, except
that DROP INDEX
On Sun, Dec 6, 2015 at 4:25 PM, Peter Geoghegan wrote:
> Maybe we should consider trying to get patch 0002 (the memory
> pool/merge patch) committed first, something Greg Stark suggested
> privately. That might actually be an easier way of integrating this
> work, since it changes nothing about t
63 matches
Mail list logo
