On 7 May 2015 at 21:40, Michael Paquier wrote:
> Hi all,
>
> Coverity is complaining about the following assertion introduced in
> commit 924bcf4 (parallel stuff, SerializeSnapshot@snapmgr.c):
> + Assert(snapshot->xcnt >= 0);
>
> Now the thing is that this assertion does not make much sense
Hi,
Commit 63f1ccd got rid of src/tool/backend and hence
src/tool/backend/index.html. But lmgr README still directs reader to the
aforementioned file. Attached removes this obsolete reference.
Thanks,
Amit
diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README
index 6bc7ef
Gavin,
* Gavin Flower (gavinflo...@archidevsys.co.nz) wrote:
> What if I had a company with several subsidiaries using the same
> database, and want to prefix roles and other things with the
> subsidiary's initials? (I am not saying this would be a good
> architecture!!!)
If you admit that it's n
All,
Starting a new thread, as suggested by Robert, for consideration of
adding default roles for sets of administrative functions, therefore
removing the need for superuser-level roles in many use-cases.
This reserves the prefix 'pg_' as being for default roles.
Having these default roles also
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Now, if we can easily shove stuff back and forth between the main queue
> and the bug-fix queue, maybe that's not such a big deal. But it doesn't
> seem like the current CF app is really amenable to that; doesn't it for
> example want to leave an entry behi
On Fri, May 8, 2015 at 11:54 AM, Fabien COELHO wrote:
>
>> I'm fine to do this cleanup btw.
>
>
> ISTM that an additional "Duplicate" or "To remove" status could be a tag for
> admins to remove the entries?
This looks like an overkill to me. Entries with the same description
headline mean the sam
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> ... but I do agree with this. With our current methodology there's
>> not a lot of need to decide a-priori whether something is a feature
>> or a bug (in particular, the way it's categorized in the CF app is
>> not a high-stakes de
I'm fine to do this cleanup btw.
ISTM that an additional "Duplicate" or "To remove" status could be a tag
for admins to remove the entries?
Feel free to remove the stupid "Rejected" entries at the end of the 2015-06
CF: there are currently 11 "pgbench allow '=' in \set" (mine) and 2
"confi
v4, rebase (after pgbench moved to src) and use of the recently added
syntax_error function.
v5 which adds a forgotten header declaration for a new function, so as to
avoid a warning.
While playing around for adding other functions I noticed that with the
parsing rules I set unknown functi
> Robert Haas writes:
> > On Thu, Apr 30, 2015 at 5:21 PM, Kouhei Kaigai wrote:
> >> I wanted to submit the v14 after the above items get clarified.
> >> The attached patch (v14) includes all what you suggested in the previous
> >> message.
>
> > Committed, after heavily working over the documen
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > On 5/7/15 9:44 AM, Stephen Frost wrote:
> >> a) make sure we don't lose track of bug-fix patches
> >> b) make it clear where bug-fix patches should be submitted
> >> c) provide a view of bug-fix patches for people to look at out
On Fri, May 8, 2015 at 10:35 AM, Fabien COELHO wrote:
>
> Hello Michael,
>
>> It is possible to remove patches from the set, but administrator rights
>> are necessary.
>
>
> Good. Maybe this right could be granted to the person who as created the
> patch entry in the CF?
Er, well... #blamemagnus
Peter Eisentraut writes:
> On 5/7/15 9:44 AM, Stephen Frost wrote:
>> a) make sure we don't lose track of bug-fix patches
>> b) make it clear where bug-fix patches should be submitted
>> c) provide a view of bug-fix patches for people to look at outside of
>> CF time
>> d) continue to have a singl
Hi all,
Coverity is complaining about the following assertion introduced in
commit 924bcf4 (parallel stuff, SerializeSnapshot@snapmgr.c):
+ Assert(snapshot->xcnt >= 0);
Now the thing is that this assertion does not make much sense, because
SnapshotData defines subxcnt as uint32 in snapshot.
Robert Haas writes:
> On Thu, Apr 30, 2015 at 5:21 PM, Kouhei Kaigai wrote:
>> I wanted to submit the v14 after the above items get clarified.
>> The attached patch (v14) includes all what you suggested in the previous
>> message.
> Committed, after heavily working over the documentation, and wi
Hello Michael,
It is possible to remove patches from the set, but administrator rights
are necessary.
Good. Maybe this right could be granted to the person who as created the
patch entry in the CF?
If there are duplicated entries that you would like to get removed,
simply mention them her
On Thu, May 7, 2015 at 11:49 PM, Rui Hai Jiang wrote:
> Does anyone know when are charin(),int2in() and int4in() called?
Those are input functions for respectively the types char, smallint
and int. Look at the docs here for more details:
http://www.postgresql.org/docs/devel/static/sql-createtype.
On 5/7/15 9:44 AM, Stephen Frost wrote:
> a) make sure we don't lose track of bug-fix patches
> b) make it clear where bug-fix patches should be submitted
> c) provide a view of bug-fix patches for people to look at outside of
>CF time
> d) continue to have a single view which includes all acti
On 2015-05-07 PM 11:49, Rui Hai Jiang wrote:
>
> I'm trying to figure out when the following functions are called,
>
> charin()
> int2in()
> int4in()
> textin()
>
> create table abcin( id integer, name varchar(10), title text);
> insert into abcin( id, name, title ) values (1,'tom', 'manager
On Fri, May 8, 2015 at 4:17 AM, Fabien COELHO wrote:
> Then there is no way to remove a patch from the application. You end up
> marking them as "Rejected", which does not make much sense, see the bottom
> of the 2015-06 commitfest list...
> Maybe a "Duplicate" status would be better, and the abili
"David G. Johnston" writes:
> On Thu, May 7, 2015 at 4:19 PM, Tom Lane wrote:
>> pg_upgrade is okay in any case because it dumps and reloads the current
>> extension's components. Doesn't matter whether there's another version
>> that is not compatible.
> âFor clarity - which one is "current"
On Thu, May 7, 2015 at 4:19 PM, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, May 7, 2015 at 04:19:52PM -0400, Bruce Momjian wrote:
> >> Just a reality check but this will break a pg_upgrade, and will not be
> >> detected by --check.
>
> > Actually, pg_upgrade might be OK because the view
Bruce Momjian writes:
> On Thu, May 7, 2015 at 04:19:52PM -0400, Bruce Momjian wrote:
>> Just a reality check but this will break a pg_upgrade, and will not be
>> detected by --check.
> Actually, pg_upgrade might be OK because the views would be recreated
> with the new functions already install
On 5/7/15, Sawada Masahiko wrote:
> On Wed, May 6, 2015 at 5:42 AM, Robert Haas > wrote:
>> On Tue, May 5, 2015 at 11:10 AM, Sawada Masahiko > wrote:
>>> On Fri, May 1, 2015 at 9:04 PM, Robert Haas > wrote:
On Thu, Apr 30, 2015 at 11:05 PM, Sawada Masahiko
> wrote:
> VACUUM has b
All,
* Robert Haas (robertmh...@gmail.com) wrote (on the role attributes
* thread):
> I think this patch is too big and does too many things. It should be
> broken up into small patches which can be discussed and validated
> independently. The fact that your commit message is incredibly long
> i
On Thu, May 7, 2015 at 2:14 PM, Peter Geoghegan wrote:
> The only downside I see is that it might not work in preventing the
> statement from proceeding. In other words, you might have a partial
> unique index style inference clause (i.e. with a predicate) that
> infers a non-partial index, becaus
On Thu, May 7, 2015 at 11:32 AM, Andres Freund wrote:
> Hm. I don't really see a point in allowing it - it seems more likely to
> be a mistake by the user, expecting that the insertion now works
> conflict free. But I don't really care much.
The only downside I see is that it might not work in p
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, May 7, 2015 at 11:02 AM, Stephen Frost wrote:
> > I realize it's not going to be popular, but I'd love to have 'trust'
> > only allowed if a command-line option is passed to the postmaster or
> > something along those lines. It's really got n
Peter,
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 5/7/15 10:26 AM, Stephen Frost wrote:
> > Auditing is about "what happened" whereas
> > statement logging is "log whatever statement the user sent." pgAudit
> > bears this out by logging internal SQL statements and object
> > information, un
On Thu, May 7, 2015 at 11:02 AM, Stephen Frost wrote:
> I realize it's not going to be popular, but I'd love to have 'trust'
> only allowed if a command-line option is passed to the postmaster or
> something along those lines. It's really got no business being an
> option for a network service li
On 5/7/15 10:26 AM, Stephen Frost wrote:
> Auditing is about "what happened" whereas
> statement logging is "log whatever statement the user sent." pgAudit
> bears this out by logging internal SQL statements and object
> information, unlike what we do with statement logging today.
I don't think t
On Thu, May 7, 2015 at 04:19:52PM -0400, Bruce Momjian wrote:
> On Tue, May 5, 2015 at 02:07:08PM -0300, Alvaro Herrera wrote:
> > Tom Lane wrote:
> >
> > > * We can't use CREATE OR REPLACE FUNCTION in the upgrade script because
> > > that intentionally doesn't let you change the result type of
On Tue, May 5, 2015 at 02:07:08PM -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > * We can't use CREATE OR REPLACE FUNCTION in the upgrade script because
> > that intentionally doesn't let you change the result type of an existing
> > function. I considered doing a manual UPDATE of the pg_p
On 05-05-2015 16:36, Peter Eisentraut wrote:
> 1. I like copying and pasting the "postgres" line during development.
> That's not a reason to keep it, necessarily.
>
I prefer pg_ctl because of symmetry (start, stop, restart, reload and
even init).
> 2. If you're saying, most people shouldn't run
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, May 7, 2015 at 10:26:55AM -0400, Stephen Frost wrote:
> > * Peter Eisentraut (pete...@gmx.net) wrote:
> > > On 5/4/15 8:37 PM, Stephen Frost wrote:
> > > > I don't follow this logic. The concerns raised above are about changing
> > > > o
Hello,
Some comments/bug report about the commitfest web app which just bite
me:-)
When creating a patch with the commitfest app, if the thread does not
exist the application seems to reject the creation, so you may resubmit
because you know the thread is going to exist soon... Well, this i
On Thu, May 7, 2015 at 11:53:21AM +0200, Volker Aßmann wrote:
> Yes in fact, it would be a way for organizations distributing their own
> PostgreSQL packages to enforce authentication restrictions within the package
> instead of having to educate all users about the options.
>
>
> I don't n
Would "colon-equal" be more acceptable - like in pl/pgsql?
Hmmm... I would tend to think that is even clearer as a separator than a
mere "=". Too much Pascal in my youth? :-)
Although ":" means beginning of variable name in pgbench, I would not
think that it is an issue because = is not a
Hello Tom,
I've got doubts about this too: it introduces fundamental inconsistency
in pgbench itself, which may come back to bite us later. Who's to say
that '=' will never be a meaningful operator in pgbench expressions?
Hmmm... it would not be an issue as long as '=' is not a unary operato
On Thu, May 7, 2015 at 11:43 AM, Fabien COELHO wrote:
>
> Hello,
>
> \set id = 1 + abs((:id * 1021) % (10 * :scale))
>>>
>>> seems slightly better than:
>>>
>>>\set id 1 + abs((:id * 1021) % (10 * :scale))
>>>
>>
>> It is question :( - it break a consistency with psql
>>
>
> It ac
Hello,
\set id = 1 + abs((:id * 1021) % (10 * :scale))
seems slightly better than:
\set id 1 + abs((:id * 1021) % (10 * :scale))
It is question :( - it break a consistency with psql
It actually "breaks" nothing as it is purely cosmectic:-)
More seriously, I'm not sure that
On Thu, May 7, 2015 at 10:26:55AM -0400, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
> > On 5/4/15 8:37 PM, Stephen Frost wrote:
> > > I don't follow this logic. The concerns raised above are about changing
> > > our in-core logging. We haven't got in-core auditing and so
Pavel Stehule writes:
> 2015-05-07 20:18 GMT+02:00 Fabien COELHO :
>> The attached patch just ignores a leading '=' in a pgbench expression.
> It is question :( - it break a consistency with psql
I've got doubts about this too: it introduces fundamental inconsistency
in pgbench itself, which may
On 2015-05-07 11:16:12 -0700, Peter Geoghegan wrote:
> On Tue, May 5, 2015 at 8:52 AM, Heikki Linnakangas wrote:
> > postgres=# create table foo (id int4);
> > CREATE TABLE
> > postgres=# create unique index foo_y on foo (id) where id > 0;
> > CREATE INDEX
> > postgres=# insert into foo values (-1
2015-05-07 20:18 GMT+02:00 Fabien COELHO :
>
> Hello devs,
>
> Since an expression syntax has been added to pgbench, I find that the
> readability of expressions is not great. An extra '=' improves the
> situation for me:
>
>\set id = 1 + abs((:id * 1021) % (10 * :scale))
>
> seems slightl
Etsuro Fujita writes:
> BTW, I revised docs a bit. Attached is an updated version of the patch.
I started to look at this and realized that it only touches the core code
and not postgres_fdw, which seems odd --- doesn't that mean the new
feature can't be tested?
regards,
On Tue, May 5, 2015 at 8:52 AM, Heikki Linnakangas wrote:
> Why not? I would understand if the specified arbiter constraint is deferred,
> but why does it matter if one of the other constraints is?
This has been fixed since, BTW. We now support relations that happen
to have deferred constraints.
Hello devs,
Since an expression syntax has been added to pgbench, I find that the
readability of expressions is not great. An extra '=' improves the
situation for me:
\set id = 1 + abs((:id * 1021) % (10 * :scale))
seems slightly better than:
\set id 1 + abs((:id * 1021) % (1
On Tue, May 5, 2015 at 8:52 AM, Heikki Linnakangas wrote:
> I've read through all the error messages in the patch. Some comments:
I'll work through this feedback.
> postgres=# create table foo (id int4);
> CREATE TABLE
> postgres=# create unique index foo_y on foo (id) where id > 0;
> CREATE IND
On Thu, May 7, 2015 at 10:37 AM, Andres Freund wrote:
> I don't see a problem at all, with one exception: If we want the AS to
> be optional like in a bunch of other places, we have to either promote
> VALUES to a reserved keyword, only accept unreserved keywords, or play
> precedence games. I thi
On 2015-05-07 16:15:18 +0300, Heikki Linnakangas wrote:
> On 05/07/2015 12:01 AM, Andres Freund wrote:
> >6. The tablename and EXCLUDED? Possibility with the ability to specify
> >an AS for INSERT INTO foo AS whatever?
>
> If we don't allow "AS whatever", and you create a table called "exclude
Emre Hasegeli wrote:
> > After looking at 05 again, I don't like the "same as %" business.
> > Creating a whole new class of exceptions is not my thing, particularly
> > not in a regression test whose sole purpose is to look for exceptional
> > (a.k.a. "wrong") cases. I would much rather define th
On 5/7/15 8:26 AM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> On 5/4/15 8:37 PM, Stephen Frost wrote:
>>> I don't follow this logic. The concerns raised above are about changing
>>> our in-core logging. We haven't got in-core auditing and so I don't see
>>> how they app
* Josh Berkus (j...@agliodbs.com) wrote:
> On 05/06/2015 02:13 PM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> (Personally I think there's a very good case for completely ripping out
> >> RFC1413 ident auth. I've not seen it used in a great long while, and
> >> it's always been a security ri
Hello,
I'm trying to figure out when the following functions are called,
charin()
int2in()
int4in()
textin()
I used GDB for debuging. I set break points at each function and I did
following testing.
create table abcin( id integer, name varchar(10), title text);
insert into abcin( id, na
On Thu, May 7, 2015 at 10:17:18AM -0400, Andrew Dunstan wrote:
>
> On 05/07/2015 09:58 AM, Bruce Momjian wrote:
>
> >
> >Frankly, I am not sure how they are starting the server as the
> >/etc/init.d startup files don't handle multiple clusters well, and I
> >have never seen instructions on how m
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 5/4/15 8:37 PM, Stephen Frost wrote:
> > I don't follow this logic. The concerns raised above are about changing
> > our in-core logging. We haven't got in-core auditing and so I don't see
> > how they apply to it.
>
> How is session "auditing" su
On 05/07/2015 09:58 AM, Bruce Momjian wrote:
Frankly, I am not sure how they are starting the server as the
/etc/init.d startup files don't handle multiple clusters well, and I
have never seen instructions on how multi-cluster users are supposed to
set things up. I assume they are copying
On Tue, May 5, 2015 at 03:36:07PM -0400, Peter Eisentraut wrote:
> > BTW, why are we advocating postgres binary use at all? AFAICS the main
> > postgres (or postmaster) uses are (i) startup script (which also
> > advocate for 'pg_ctl -w') and (ii) disaster/debugging purposes. None of
> > those use
On Thu, May 7, 2015 at 3:09 AM, Noah Misch wrote:
>> Each individual queue has only a single reader and a single writer.
>> In your example, there would be three queues, not just one. Of
>> course, one could design a new shared memory data structure
>> representing a collection of related queues,
All,
Starting a new thread, as suggested by Magnus.
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, May 5, 2015 at 3:47 PM, Robert Haas wrote:
>
> > On Fri, May 1, 2015 at 1:16 PM, Stephen Frost wrote:
> > > We really need to segregate the two.. By that what I mean is this: I
> > > w
On Thu, Apr 30, 2015 at 3:08 PM, Michael Paquier
wrote:
> On Thu, Apr 30, 2015 at 9:53 PM, Robert Haas
> wrote:
> > On Sat, Mar 21, 2015 at 9:00 AM, Michael Paquier
> > wrote:
> >> On Fri, Mar 20, 2015 at 9:48 PM, Bruce Momjian
> wrote:
> >>> On Tue, Oct 28, 2014 at 07:02:41AM +, krystian.
On 05/07/2015 12:01 AM, Andres Freund wrote:
6. The tablename and EXCLUDED? Possibility with the ability to specify
an AS for INSERT INTO foo AS whatever?
If we don't allow "AS whatever", and you create a table called
"excluded", you're stuck with the ambiguity in the DO UPDATE statement
On Wed, May 6, 2015 at 5:42 AM, Robert Haas > wrote:
> On Tue, May 5, 2015 at 11:10 AM, Sawada Masahiko > wrote:
>> On Fri, May 1, 2015 at 9:04 PM, Robert Haas > wrote:
>>> On Thu, Apr 30, 2015 at 11:05 PM, Sawada Masahiko > wrote:
VACUUM has both syntax: with parentheses and without parenthes
On 05/07/2015 12:01 AM, Andres Freund wrote:
How about
6. The tablename and EXCLUDED? Possibility with the ability to specify
an AS for INSERT INTO foo AS whatever?
From an implementation pov that'd be simple ;)
I did this, because as you say it's simple to implement, and it resolves
the
The problem is here:
> [root@ps-test5:/etc/puppet/modules/postgresql/files] pg_controldata
> /mnt/ebs/pgsql/data
> pg_control version number:922
> Catalog version number: 201302181
The catversion for 9.2 is 201204301; you have modified it with your
patches in a way that
2015-05-06 19:26 GMT+02:00 Jeff Janes :
> On Wed, May 6, 2015 at 6:16 AM, Pavel Stehule
> wrote:
>
>>
>>
>> 2015-05-06 15:15 GMT+02:00 Alvaro Herrera :
>>
>>> Pavel Stehule wrote:
>>> > Hi
>>> >
>>> > I am working on preparation the migration from 9.2 to 9.4
>>> >
>>> > pg_upgrade fails
>>> >
>>>
2015-05-06 19:40 GMT+02:00 Jeff Janes :
> On Wed, May 6, 2015 at 10:26 AM, Jeff Janes wrote:
>
>> On Wed, May 6, 2015 at 6:16 AM, Pavel Stehule
>> wrote:
>>
>>>
>>>
>>> 2015-05-06 15:15 GMT+02:00 Alvaro Herrera :
>>>
Pavel Stehule wrote:
> Hi
>
> I am working on preparation t
On Wed, May 6, 2015 at 4:47 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>
> > I frankly find that a bit difficult to swallow. You think that
> > everyone knows that bad passwords are a problem, but some people might
> > not realize that an authentication method called "trust" might not be
> >
On Mon, May 4, 2015 at 6:45 AM, Michael Paquier
wrote:
> Hi all,
>
> Coverity complained about a small indentation issue in ruleutils.c:
> + appendStringInfoString(buf, "\n TRANSFORM ");
> + for (i = 0; i < ntypes; i++)
> + {
> + if
On Mon, May 4, 2015 at 6:34 AM, Michael Paquier
wrote:
> Hi all,
>
> Coverity is complaining that getTransforms in pg_dump.c leaks a
> PQExpBuffer allocation.
> Please find attached a patch to fix the leak.
>
Applied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.
On 6 May 2015 at 22:30, Heikki Linnakangas wrote:
> On 05/07/2015 12:01 AM, Andres Freund wrote:
>
>> On 2015-05-06 23:48:18 +0300, Heikki Linnakangas wrote:
>>
>>> I'll see about fixing that. It's not just a matter of creating another
>>> alias
>>> for the same rel, I'm afraid: "foo.t" is suppos
On Wed, May 6, 2015 at 7:10 PM, Robert Haas wrote:
>
> On Wed, May 6, 2015 at 7:55 AM, Amit Kapila
wrote:
> >>> - I believe the separation of concerns between ExecFunnel() and
> >>> ExecEndFunnel() is not quite right. If the scan is shut down before
> >>> it runs to completion (e.g. because of L
On Tue, May 05, 2015 at 01:05:38PM -0400, Robert Haas wrote:
> On Sat, May 2, 2015 at 12:35 PM, Noah Misch wrote:
> > Perhaps, rather than model it as master M waiting on worker list W1|W2|W3,
> > model it with queue-nonempty and queue-nonfull events, one pair per queue.
That comment of mine was
74 matches
Mail list logo
