On Fri, Dec 25, 2015 at 8:57 PM, Craig Ringer wrote:
> On 25 December 2015 at 19:45, Michael Paquier
> wrote:
>>
>> On Thu, Dec 24, 2015 at 5:57 PM, Dave Page wrote:
>> > On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer
>> > wrote:
>> >> On 22 December 2015 at 23:48, Alex Ignatov
>> >> wrote:
>>
On Sun, Jan 3, 2016 at 10:26 PM, Masahiko Sawada wrote:
> On Fri, Dec 25, 2015 at 7:21 AM, Thomas Munro
> wrote:
>> On Fri, Dec 25, 2015 at 8:50 AM, Masahiko Sawada
>> wrote:
>>> On Wed, Dec 23, 2015 at 8:45 AM, Thomas Munro
>>> wrote:
On Wed, Dec 23, 2015 at 3:50 PM, Thomas Munro
w
On Wed, Dec 30, 2015 at 9:21 PM, Andreas Karlsson wrote:
> Hi,
>
> Here is a patch which adds the below missing tab completions for the FDW DDL
> commands. I noticed these were missing while playing around with FDWs a
> while ago.
>
> "ALTER SERVER " with "RENAME TO"
> "CREATE SERVER FOREIGN DATA
On Mon, Jan 4, 2016 at 3:22 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian wrote:
>>> Greg's lightning talk in Vienna about how he got the emulator working
>>> was priceless. I know he posted the VAX results, but how he got them
>>> was amazing.
>
Michael Paquier writes:
> On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian wrote:
>> Greg's lightning talk in Vienna about how he got the emulator working
>> was priceless. I know he posted the VAX results, but how he got them
>> was amazing.
> +1. The work of a pure hacker.
Is this available onl
On Sat, Jan 2, 2016 at 4:06 AM, Tom Lane wrote:
> I wrote:
>> Now, one line of thought here is that flatten_reloptions() is out of its
>> mind to not be worrying about quoting the reloption values. And perhaps
>> it is, but I think if we go that direction, we may be fighting similar
>> fires for
On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian wrote:
> On Wed, Dec 2, 2015 at 01:16:09AM +, Greg Stark wrote:
>>
>> On 1 Dec 2015 19:48, "Tom Lane" wrote:
>> >
>> > In passing, avoid possible calculation of log10(0). Probably that's
>> > harmless, given the lack of field complaints, but it
On Mon, Jan 4, 2016 at 4:49 AM, Robert Haas wrote:
>
> On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila
wrote:
> > LWLock *LWLockAssignFromTranche(const char *tranche_name) will
> > assign a lock for the specified tranche. This also ensures that no
> > more than requested number of LWLocks can be as
On Mon, Jan 4, 2016 at 3:09 PM, Tom Lane wrote:
> Michael Paquier writes:
>> Attached is an updated patch which passes
>> check-world in my environment.
>
> Pushed with trivial cosmetic changes to the code, and slightly more
> extensive work on the regression test cases.
>
> It strikes me that th
Michael Paquier writes:
> Attached is an updated patch which passes
> check-world in my environment.
Pushed with trivial cosmetic changes to the code, and slightly more
extensive work on the regression test cases.
It strikes me that there might be an argument for returning NULL
rather than raisi
On 1/3/16 11:24 PM, Michael Paquier wrote:
Sorry, didn't realize you were on it.
No worries. I know it's already late where you are.
And late where 9.5 is... ;)
I would use != 1 instead here, even if the function is strict.
Yeah, I effectively pulled the pattern from DeconstructQualifiedNa
On Mon, Jan 4, 2016 at 1:46 PM, Jim Nasby wrote:
> On 1/3/16 10:26 PM, Michael Paquier wrote:
>>
>> Thanks, this is more or less what I... just did..
>
>
> Sorry, didn't realize you were on it.
No worries. I know it's already late where you are.
>> A couple of tests in regproc.sql would be a goo
On 1/3/16 11:05 PM, Michael Paquier wrote:
I'll take a look, but Michael, if you have time to review, an extra set
>of eyeballs wouldn't hurt. There is no margin for error right now.
I'm just on it:) Will update in a couple of minutes, I noticed some
stuff in Jim's patch.
BTW, in case you mi
On Mon, Jan 4, 2016 at 2:01 PM, Tom Lane wrote:
> Jim Nasby writes:
>> On 1/3/16 10:26 PM, Michael Paquier wrote:
>>> Thanks, this is more or less what I... just did..
>
>> Sorry, didn't realize you were on it.
>
>>> A couple of tests in regproc.sql would be a good addition as well.
>
>> Added. I
Jim Nasby writes:
> On 1/3/16 10:26 PM, Michael Paquier wrote:
>> Thanks, this is more or less what I... just did..
> Sorry, didn't realize you were on it.
>> A couple of tests in regproc.sql would be a good addition as well.
> Added. I'm gonna call this good for now. Note this is just against
On 1/3/16 10:46 PM, Jim Nasby wrote:
Added. I'm gonna call this good for now. Note this is just against HEAD
since I don't have 9.5 setup yet. Presumably the patch should still
apply...
BTW, in case it's helpful...
https://github.com/decibel/postgres/tree/regquote
--
Jim Nasby, Data Architect
On 1/3/16 10:23 PM, Pavel Stehule wrote:
Hi
2016-01-03 22:49 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>:
On 1/3/16 2:37 PM, Pavel Stehule wrote:
+ /* num_nulls(VARIADIC NULL) is defined as NULL */
+ if (PG_ARGISNULL(0))
+
On 1/3/16 10:26 PM, Michael Paquier wrote:
Thanks, this is more or less what I... just did..
Sorry, didn't realize you were on it.
+result = get_namespace_oid(nsp_name, false);
This is incorrect, you should use strVal(linitial(names)) instead.
Yup. Dur.
+if (list_length(names) > 1
Jim Nasby writes:
> On 1/3/16 9:23 PM, Tom Lane wrote:
>> (Though at least in HEAD we ought to
>> fix them to take type text as input. Using cstring for ordinary functions
>> is just sloppy.)
> BTW, *all* the reg*in() functions do that...
Yeah, I noticed that. They're all broken. There are no
On Thu, Dec 31, 2015 at 4:26 PM, Noah Misch wrote:
> On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
>> * Noah Misch (n...@leadboat.com) wrote:
>> I disagree that we would. Having a single
>> set of default roles which provide a sensible breakdown of permissions
>> is a better appr
On 1/3/16 9:23 PM, Tom Lane wrote:
(Though at least in HEAD we ought to
fix them to take type text as input. Using cstring for ordinary functions
is just sloppy.)
BTW, *all* the reg*in() functions do that...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics,
On Mon, Jan 4, 2016 at 1:20 PM, Jim Nasby wrote:
> On 1/3/16 9:43 PM, Tom Lane wrote:
>>
>> Jim Nasby writes:
>>>
>>> On 1/3/16 9:23 PM, Tom Lane wrote:
>>> Another potential problem for regnamespace is that it doesn't allow an
>>> entry for the catalog. I'm not sure what the spec says about that
Jim Nasby writes:
> What I went with. Now to figure out why this is happening...
>SELECT regnamespace('pg_catalog');
> ! ERROR: schema "Y" does not exist
> ! LINE 1: SELECT regnamespace('pg_catalog');
Confusion between a C string and a string Value node, mayhap?
reg
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Dec 29, 2015 at 11:55 PM, Stephen Frost wrote:
> > I could go either way on that, really. I don't find namespace to be
> > confusing when used in that way, but I'll change it since others do.
>
> It seems to me that the way patch doe
On 1/3/16 10:20 PM, Jim Nasby wrote:
What I went with. Now to figure out why this is happening...
Nevermind, see my stupidity now. Should have full patch soon.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble?
Hi
2016-01-03 22:49 GMT+01:00 Jim Nasby :
> On 1/3/16 2:37 PM, Pavel Stehule wrote:
>
>> + /* num_nulls(VARIADIC NULL) is defined as NULL */
>> + if (PG_ARGISNULL(0))
>> + return false;
>>
>
> Could you add to the comment explaining why that's the
On 1/3/16 9:43 PM, Tom Lane wrote:
Jim Nasby writes:
On 1/3/16 9:23 PM, Tom Lane wrote:
Another potential problem for regnamespace is that it doesn't allow an
entry for the catalog. I'm not sure what the spec says about that, but
every other function allows dbname.schema.blah (dbname == catalog
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > As we don't want to end up with the same behavior-change-due-to-GUC that
> > we had with the original row_security implementation, we should change
> > the code as your patch does and update the regression tests accordingly.
>
> I
Stephen Frost writes:
> As we don't want to end up with the same behavior-change-due-to-GUC that
> we had with the original row_security implementation, we should change
> the code as your patch does and update the regression tests accordingly.
I think probably the tests need some adjustment rath
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > On Sunday, January 3, 2016, Tom Lane wrote:
> >> The fine manual says that when row_security is set to off, "queries fail
> >> which would otherwise apply at least one policy". However, a look at
> >> check_enable_rls() says that
Alvaro Herrera writes:
> Tom Lane wrote:
>> Well, I tried changing the code to act the way I gather it should, and
>> it breaks a whole bunch of regression test cases. See attached.
> I think this means we need to postpone 9.5.0 for a week.
I think the regression cases are not that big a deal t
I wrote:
> There's no real advantage to that anyway, compared with just doing
> stringToQualifiedNameList and then complaining if its list_length isn't 1.
Or just use SplitIdentifierString directly ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Sun, Jan 3, 2016 at 7:01 PM, Peter Geoghegan wrote:
> I would also advise only referencing a single relation within the
> SELECT FOR UPDATE.
To state what may be obvious: We should recommend that SELECT FOR
SHARE appear in the CREATE POLICY USING qual as part of this
workaround (not SELECT FOR
Jim Nasby writes:
> On 1/3/16 9:23 PM, Tom Lane wrote:
>> I'm inclined to leave to_regrole and to_regnamespace alone, though, since
>> they have no numeric-OID path, and they will provide an "out" for anyone
>> who wants to handle nonquoted names. (Though at least in HEAD we ought to
>> fix them
Tom Lane wrote:
> Stephen Frost writes:
> > On Sunday, January 3, 2016, Tom Lane wrote:
> >> The fine manual says that when row_security is set to off, "queries fail
> >> which would otherwise apply at least one policy". However, a look at
> >> check_enable_rls() says that that is a true stateme
On 1/3/16 9:23 PM, Tom Lane wrote:
Jim Nasby writes:
regrole and regnamespace don't run their output through quote_ident().
That's contrary to all the other reg* operators.
Worse, they also don't *allow* quoted input. Not only is that different
from reg*, it's the *opposite*:
BTW, there's a c
Jim Nasby writes:
> regrole and regnamespace don't run their output through quote_ident().
> That's contrary to all the other reg* operators.
> Worse, they also don't *allow* quoted input. Not only is that different
> from reg*, it's the *opposite*:
BTW, there's a concrete reason why this is br
On Sun, Jan 3, 2016 at 6:41 PM, Stephen Frost wrote:
> A security defined function could be used to address that, of course. That
> could have performance implications, naturally.
True.
I would also advise only referencing a single relation within the
SELECT FOR UPDATE.
--
Peter Geoghegan
--
Stephen Frost writes:
> On Sunday, January 3, 2016, Tom Lane wrote:
>> The fine manual says that when row_security is set to off, "queries fail
>> which would otherwise apply at least one policy". However, a look at
>> check_enable_rls() says that that is a true statement only when the user
>> i
Peter,
On Sunday, January 3, 2016, Peter Geoghegan wrote:
> On Sun, Jan 3, 2016 at 6:09 PM, Peter Geoghegan > wrote:
> >> I think we should get rid of it altogether (since I also agree with the
> >> upthread comment that it's in the wrong place) and instead put an
> example
> >> into section 5.
On Sun, Jan 3, 2016 at 6:09 PM, Peter Geoghegan wrote:
>> I think we should get rid of it altogether (since I also agree with the
>> upthread comment that it's in the wrong place) and instead put an example
>> into section 5.7 saying directly that sub-selects, or in general
>> references to rows o
Michael Paquier writes:
> On Mon, Jan 4, 2016 at 11:16 AM, Tom Lane wrote:
>> I'm inclined to think that you're right, and that this is something that
>> ought to be changed. It's not quite too late ...
> Well, I can send a patch with some tests if need be... Tom, I guess
> that you are already
On Mon, Jan 4, 2016 at 11:16 AM, Tom Lane wrote:
> Jim Nasby writes:
>> regrole and regnamespace don't run their output through quote_ident().
>> That's contrary to all the other reg* operators.
>
>> Worse, they also don't *allow* quoted input. Not only is that different
>> from reg*, it's the *o
Jim Nasby writes:
> regrole and regnamespace don't run their output through quote_ident().
> That's contrary to all the other reg* operators.
> Worse, they also don't *allow* quoted input. Not only is that different
> from reg*, it's the *opposite*:
I'm inclined to think that you're right, and
On Sun, Jan 3, 2016 at 6:09 PM, Tom Lane wrote:
>> Really? But the problem happens as a consequence of having a
>> subqueries within CREATE POLICY's USING quals
>
> If that's what we're talking about, let's say it in precisely that many
> words. With an example. The current text is 100% useless.
On Sun, Jan 3, 2016 at 6:04 PM, Tom Lane wrote:
> I'm going to state it as an incontrovertible fact that that paragraph
> is so vague as to be useless, because I sure misunderstood it, and in
> fact just copy-edited it to talk about changes to RLS policies. I now
> see that it did say "relations
Peter Geoghegan writes:
> On Sun, Jan 3, 2016 at 6:00 PM, Stephen Frost wrote:
>> I believe Tom's complaint was that the overall page is about CREATE POLICY,
>> technically, and that the text in attempting to address the concern might be
>> taken under the context of being a CREATE POLICY issue r
Hi
Like the docs say, vacuumdb is a "wrapper around the SQL command VACUUM"
which I used to use in dim-and-distant pre-autovacuum days came for cronjobs,
but until messing around with pg_upgrade recently I hadn't really had much
use for it. Anyway, the docs also say "There is no effective differen
On Sun, Jan 3, 2016 at 6:00 PM, Stephen Frost wrote:
>> I'm not sure what you mean. The CREATE POLICY changes in commit
>> 43cd468cf01007f3 specifically call out the issue illustrated in my
>> example test case. There are some other changes made in that commit,
>> but they don't seem to be attempt
Peter Geoghegan writes:
> On Sun, Jan 3, 2016 at 5:18 PM, Tom Lane wrote:
>> In any case, the text in create_policy.sgml seems to be a misleading
>> description of the problem, as it's talking about DDL modifications
>> which are *not* what's happening here.
> I'm not sure what you mean. The CRE
Peter,
On Sunday, January 3, 2016, Peter Geoghegan wrote:
> On Sun, Jan 3, 2016 at 5:18 PM, Tom Lane >
> wrote:
> > In any case, the text in create_policy.sgml seems to be a misleading
> > description of the problem, as it's talking about DDL modifications
> > which are *not* what's happening he
On Sun, Jan 3, 2016 at 5:18 PM, Tom Lane wrote:
> Hmm. I agree that this test case's behavior does not depend on CREATE
> POLICY's lock mismanagement. I think what is going on here is that the
> RLS quals are being checked with an older snapshot than what controls
> the output of the UPDATE RETU
Stephen Frost writes:
> On Sunday, January 3, 2016, Tom Lane wrote:
>> CREATE POLICY takes AccessExclusiveLock on the table a policy is being
>> added to -- good -- and then releases it when done -- bad. Correct
>> behavior is to hold the lock till commit, because otherwise there is
>> no guaran
I didn't see this discussed on the thread...
regrole and regnamespace don't run their output through quote_ident().
That's contrary to all the other reg* operators.
Worse, they also don't *allow* quoted input. Not only is that different
from reg*, it's the *opposite*:
select 'with spaces'::
Tom,
On Sunday, January 3, 2016, Tom Lane wrote:
> Peter Geoghegan > writes:
> > On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane > wrote:
> >> If we fix this, I believe we could also remove the weasel wording that
> was
> >> added to create_policy.sgml in commit 43cd468cf01007f3 about how the
> >> sys
Peter Geoghegan writes:
> On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane wrote:
>> If we fix this, I believe we could also remove the weasel wording that was
>> added to create_policy.sgml in commit 43cd468cf01007f3 about how the
>> system might transiently fail to enforce row security correctly.
> II
Tom, Peter,
On Sunday, January 3, 2016, Peter Geoghegan wrote:
> On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane >
> wrote:
> > CREATE POLICY takes AccessExclusiveLock on the table a policy is being
> > added to -- good -- and then releases it when done -- bad. Correct
> > behavior is to hold the lock
Tom,
On Sunday, January 3, 2016, Tom Lane wrote:
> The fine manual says that when row_security is set to off, "queries fail
> which would otherwise apply at least one policy". However, a look at
> check_enable_rls() says that that is a true statement only when the user
> is not table owner. If
On Sun, Jan 3, 2016 at 4:32 PM, Tom Lane wrote:
> CREATE POLICY takes AccessExclusiveLock on the table a policy is being
> added to -- good -- and then releases it when done -- bad. Correct
> behavior is to hold the lock till commit, because otherwise there is
> no guarantee that other backends w
Tom,
On Sunday, January 3, 2016, Tom Lane wrote:
> CREATE POLICY takes AccessExclusiveLock on the table a policy is being
> added to -- good -- and then releases it when done -- bad. Correct
> behavior is to hold the lock till commit, because otherwise there is
> no guarantee that other backend
The fine manual says that when row_security is set to off, "queries fail
which would otherwise apply at least one policy". However, a look at
check_enable_rls() says that that is a true statement only when the user
is not table owner. If the user *is* table owner, turning off
row_security seems t
CREATE POLICY takes AccessExclusiveLock on the table a policy is being
added to -- good -- and then releases it when done -- bad. Correct
behavior is to hold the lock till commit, because otherwise there is
no guarantee that other backends will see the updated catalog rows in
time, or indeed at al
On Wed, Dec 30, 2015 at 01:21:06PM +0100, Andreas Karlsson wrote:
> Hi,
>
> Here is a patch which adds the below missing tab completions for the FDW DDL
> commands. I noticed these were missing while playing around with FDWs a
> while ago.
>
> "ALTER SERVER " with "RENAME TO"
> "CREATE SERVER FO
On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila wrote:
> Going further on this work, I have written a patch for separating the
> tranches for extensions. The basic idea is to expose two new API's,
> first to request a new tranche and second to assign a lock from that
> tranche.
> RequestAddinLWLockT
The rule that gets executed if you do `make installcheck` with something
using PGXS is
pgxs.mk:$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
where $(pg_regress_installcheck) is set in Makefile.global.in to
pg_regress_installcheck = $(top_builddir)/src/test/regress/pg_regress
In case you've overlooked it, you have about two weeks to submit your proposal.
PGCon 2016 will be on 17-21 May 2016 at University of Ottawa.
* 17-18 (Tue-Wed) tutorials
* 19 & 20 (Thu-Fri) talks - the main part of the conference
* 17 & 21 (Wed & Sat) The Developer Unconference & the User Unconfe
On 1/3/16 2:37 PM, Pavel Stehule wrote:
+ /* num_nulls(VARIADIC NULL) is defined as NULL */
+ if (PG_ARGISNULL(0))
+ return false;
Could you add to the comment explaining why that's the desired behavior?
+ /*
+* N
Andreas Seltenreich writes:
> Shouldn't there be some validation of arguments now that the function is
> no longer marked strict? Currently, unprivileged users can crash the
> server calling binary_upgrade_create_empty_extension with null
> arguments. Found using sqlsmith.
Good catch, thanks!
Bruce Momjian writes:
> On Thu, Apr 16, 2015 at 11:29:07PM -0700, Jeff Janes wrote:
>> Of course after sending that it became obvious. The C function is not
>> getting
>> called because the SQL function is marked as being strict, yet is called with
>> NULL arguments.
>>
>> Trivial patch attache
2016-01-03 21:37 GMT+01:00 Pavel Stehule :
> Hi
>
>
> 2015-08-12 19:18 GMT+02:00 Marko Tiikkaja :
>
>> Hi,
>>
>> I'd like to suggest $SUBJECT for inclusion in Postgres 9.6. I'm sure
>> everyone would've found it useful at some point in their lives, and the
>> fact that it can't be properly implem
Hi
2015-08-12 19:18 GMT+02:00 Marko Tiikkaja :
> Hi,
>
> I'd like to suggest $SUBJECT for inclusion in Postgres 9.6. I'm sure
> everyone would've found it useful at some point in their lives, and the
> fact that it can't be properly implemented in any language other than C I
> think speaks for t
The usefulness of ->> operator is indisputable, but even with boolean or
numeric values, with good binary internal representation, it returns JSONB
value as text data type.
The simple *(myJSONB->>'myField')::expectedType* is not enough because:
1) there are no internal optimization, need two-s
Andres Freund writes:
> On January 3, 2016 7:04:29 PM GMT+01:00, Tom Lane wrote:
>> Um. For something that at least potentially has portability issues
>> (we think not, but we could be wrong), it's pretty scary to push only
>> a couple of hours before the wrap deadline. I'd like to get it done
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, failed
Applies cleanly on current master (b416c0bb622ce5d33fdbec3bbce0045113
On January 3, 2016 7:04:29 PM GMT+01:00, Tom Lane wrote:
>Andres Freund writes:
>> On January 3, 2016 6:23:20 PM GMT+01:00, Tom Lane
>wrote:
>>> Agreed. Let's do it and ship this puppy.
>
>> Unless somebody beats me to it, I'll push in the European morning.
>
>Um. For something that at least p
Andres Freund writes:
> On January 3, 2016 6:23:20 PM GMT+01:00, Tom Lane wrote:
>> Agreed. Let's do it and ship this puppy.
> Unless somebody beats me to it, I'll push in the European morning.
Um. For something that at least potentially has portability issues
(we think not, but we could be w
On January 3, 2016 6:23:20 PM GMT+01:00, Tom Lane wrote:
>> I really think we have a host of buggy code around the event handling
>-
>> but most of it has been used for a long while. So I think fixing the
>0
>> byte case for 9.5 is good enough.
>
>Agreed. Let's do it and ship this puppy.
Unless
Andreas Karlsson writes:
> psql's "\x auto" is a nice feature, but it is made much less useful in
> my opinion due to the expanded output format making query plans
> unreadable (and query plans often end up using expanded display due to
> their width). I think we should never use the expanded f
Robert Haas writes:
> On Dec 31, 2015, at 1:04 PM, Bruce Momjian wrote:
>> Let's hold this for 9.5.1 and all minor releases will get it at the same
>> time.
> I vote for going ahead with this at once. It seems low risk, and having 9.5.1
> install different files from 9.5.0 seems like an unneces
Andres Freund writes:
> On 2016-01-03 10:03:41 +0530, Amit Kapila wrote:
>> I think this true for a TCP socket, but this code-path is used for UDP
>> (SOCK_DGRAM) sockets as well and there is a comment below in
>> that function which seems to be indicating why originally 0 byte case
>> has not bee
On 21 December 2015 at 21:36, Tom Lane wrote:
> Alvaro Herrera writes:
> > I think the new comment that talks about Toast Index should explain
> > *why* we can skip the pinning in all cases except that one, instead of
> > just saying we can do it.
>
> I've not looked at that code in a long while
On 21 December 2015 at 21:28, Alvaro Herrera
wrote:
> Simon Riggs wrote:
> > During VACUUM of btrees, we need to pin all pages, even those where
> tuples
> > are not removed, which I am calling here the "pin scan". This is
> especially
> > a problem during redo, where removing one tuple from a 10
On Dec 31, 2015, at 1:04 PM, Bruce Momjian wrote:
>> On Thu, Dec 31, 2015 at 12:50:13AM -0500, Bruce Momjian wrote:
>>> On Wed, Dec 30, 2015 at 11:57:45PM -0500, Tom Lane wrote:
>>> Bruce Momjian writes:
Oops. Once this patch is applied, it is only going to take effect when
someone _in
On Fri, Dec 25, 2015 at 7:21 AM, Thomas Munro
wrote:
> On Fri, Dec 25, 2015 at 8:50 AM, Masahiko Sawada
> wrote:
>> On Wed, Dec 23, 2015 at 8:45 AM, Thomas Munro
>> wrote:
>>> On Wed, Dec 23, 2015 at 3:50 PM, Thomas Munro
>>> wrote:
If you got rid of SyncRepGetSyncStandbysOnePriority as s
> But is it? Is it impossible for the BRIN bitmap index scan to return 0 rows
> (say, if the value being matched is outside the min/max boundary for every
> block range?) Granted, if we document that it always returns 0 and should be
> ignored, then confusing the actual 0 with the 0 as a representa
On 2016-01-03 10:06, Magnus Hagander wrote:
On Sun, Jan 3, 2016 at 9:26 AM, Erik Rijkers wrote:
an erroneous ''. It should be ''.
Is there a particular thing you're trying to parse the data out for? As
in
is there some data that we should already be providing in a structured
format instead
On Sun, Jan 3, 2016 at 9:26 AM, Erik Rijkers wrote:
> Hi,
>
> I noticed (trying to parse out the "Latest patch" urls) that
> in the html of the commitfest pages, for instance in:
>
>https://commitfest.postgresql.org/8/
>
> all rows of the html-table (I think it is the "Committer"-column) cont
Hi,
psql's "\x auto" is a nice feature, but it is made much less useful in
my opinion due to the expanded output format making query plans
unreadable (and query plans often end up using expanded display due to
their width). I think we should never use the expanded format for
EXPLAIN output in
On 2016-01-03 10:03:41 +0530, Amit Kapila wrote:
> On Sun, Jan 3, 2016 at 3:01 AM, Andres Freund wrote:
> > Indeed it does use shutdown(). If I read the npgsql code that'll even be
> > done in the exception handling path. So fixing the 0 byte case might
> > already do the trick.
> >
>
> I think t
Hi,
I noticed (trying to parse out the "Latest patch" urls) that
in the html of the commitfest pages, for instance in:
https://commitfest.postgresql.org/8/
all rows of the html-table (I think it is the "Committer"-column)
contain an erroneous ''. It should be ''.
See example below, the ''
90 matches
Mail list logo
