Thanks for all the answers.
Tom:
FWIW, I'd go with text results, especially if you already have code to
deal with that. PG's on-the-wire binary formats are more efficient to
process in some absolute sense, but they're hardly free: you need to
consider byte endianness for integers and
[ too tired to respond to the other points, but: ]
Shay Rojansky r...@roji.org writes:
It's also possible for a type not to have send/recv functions, i.e. to
support text-only use.
In that case, what would be the behavior of selecting such a type with an
extended query that specifies all
On Mon, Sep 29, 2014 at 9:04 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Do we need to match the prototype of wrapper function with callback?
Yes.
OK, I fixed up the patch part-2, to fit declaration of GetSpecialCustomVar()
with corresponding callback.
Also, a noise in the part-3 patch,
Thank you for reviewing. I'll look close to the patch tomorrow.
I must say this scares the heck out of me. The current code goes
through some trouble to not throw an error while in a recv()
send(). For example, you removed the DoingCommandRead check from
prepare_for_client_read(). There's an
Wow, thank you for the patch.
0001: Allows WaitLatchOrSocket(WL_WRITABLE) without WL_READABLE. I've
tested the poll() and select() implementations on linux and
blindly patched up windows.
0002: Put the socket the backend uses to communicate with the client
into
By the way,
Sorry, I missed this message and only cought up when reading your CF
status mail. I've attached three patches:
Could let me know how to get the CF status mail?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list
On 2014-09-26 21:02:16 +0300, Heikki Linnakangas wrote:
I propose the attached patch. It adds a new flag ImmediateDieOK, which is a
weaker form of ImmediateInterruptOK that only allows handling a pending
die-signal in the signal handler.
Robert, others, do you see a problem with this?
Per
On Tue, Sep 30, 2014 at 12:42 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-09-29 22:42:57 +1300, David Rowley wrote:
I've made a change to the patch locally to ignore foreign
keys that are marked as deferrable.
I have serious doubts about the general usefulness if this is onlyu
On 2014-09-30 23:25:45 +1300, David Rowley wrote:
On Tue, Sep 30, 2014 at 12:42 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-09-29 22:42:57 +1300, David Rowley wrote:
I've made a change to the patch locally to ignore foreign
keys that are marked as deferrable.
I have
On 2014-10-01 01:03:35 +1300, David Rowley wrote:
On Wed, Oct 1, 2014 at 12:01 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-09-30 23:25:45 +1300, David Rowley wrote:
I've not quite gotten my head around how we might stop the unneeded
relation from being the primary path
Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 29, 2014 at 3:08 PM, Kevin Grittner kgri...@ymail.com wrote:
Well, unless we abandon transactional semantics for other MERGE
statements, we should have a way that UPSERT logic continues to
work if you don't match a suitable index; it will just
On 09/29/2014 05:38 PM, Marko Tiikkaja wrote:
On 9/29/14 3:02 PM, Heikki Linnakangas wrote:
Is there any real life examples or tools out there to generate armors
with headers with duplicate keys? RFC 4880 says:
Note that some transport methods are sensitive to line length. While
On 9/30/14 4:37 PM, Heikki Linnakangas wrote:
On 09/29/2014 05:38 PM, Marko Tiikkaja wrote:
Maybe I just suck at $SEARCH_ENGINE, but extracting armor headers
programmatically doesn't seem to be very popular. I could only find one
example, which returned the last instance of the key. But that
On Wed, Sep 17, 2014 at 01:07:56PM +, Matthew Kelly wrote:
* Unless you keep _all_ of your clusters on the same OS, machines
from your database spare pool probably won't be the right OS when you
add them to the cluster because a member failed.
There has been discussion about having
On 09/30/2014 05:45 PM, Marko Tiikkaja wrote:
On 9/30/14 4:37 PM, Heikki Linnakangas wrote:
On 09/29/2014 05:38 PM, Marko Tiikkaja wrote:
Maybe I just suck at $SEARCH_ENGINE, but extracting armor headers
programmatically doesn't seem to be very popular. I could only find one
example, which
I have pushed this fix, except that instead of parsing the OID from the
dropStmt as in your patch, I used te-catalogId.oid, which is much
simpler.
I tested this by pg_restoring to 8.4 (which doesn't have
pg_largeobject_metadata); there is no error raised:
LOG: sentencia: SELECT CASE WHEN
On 29 September 2014 18:59, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 29, 2014 at 7:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you were an ORM developer reading the PostgreSQL Release Notes for
9.5, which URL would you visit to see a complete description of the
new feature,
2014-09-30 17:18 GMT+02:00 Alvaro Herrera alvhe...@2ndquadrant.com:
I have pushed this fix, except that instead of parsing the OID from the
dropStmt as in your patch, I used te-catalogId.oid, which is much
simpler.
yes, it is much better
I tested this by pg_restoring to 8.4 (which
On 09/30/2014 04:56 AM, Heikki Linnakangas wrote:
There seems to be no decisive consensus here. I'm going to put my foot
on the ground and go remove it, as I'm leaning towards that option, and
we need to get the release out. But if someone objects loudly enough to
actually write the
On Tue, Sep 30, 2014 at 8:30 AM, Simon Riggs si...@2ndquadrant.com wrote:
No explanation of why the CONFLICTING() syntax differs from OLD./NEW.
syntax used in triggers
Why should it be the same?
Because it would be a principled approach to do that.
That is just an assertion. The MERGE
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
I see the following Valgrind warnings in a recent build of the master branch:
[...]
This appears a few times, but always seems to occur with the same call stack.
Many thanks, I've worked out the issue (rsecpolname needs to be filled
in with the
On 9/29/14, 2:30 PM, Andres Freund wrote:
Can we explain those reasons in the form of documentation?
Yes. Try and benchmark it. It'll be hardware and workload dependant.
I missed this whole thing, and eventually I have to circle back to it.
I could do it this week. Could you (or someone
On Tue, Sep 30, 2014 at 8:30 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 29 September 2014 18:59, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 29, 2014 at 7:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you were an ORM developer reading the PostgreSQL Release Notes for
9.5,
On 30 September 2014 16:52, Stephen Frost sfr...@snowman.net wrote:
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 29 September 2014 16:46, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Well, I think that's an acceptable approach from the point of
On 09/30/2014 11:20 AM, Peter Geoghegan wrote:
For example, this patch for UPSERT doesn't support updatable views.
But I can't see anyone that didn't read the patch would know that.
By reading the CREATE VIEW docs. Maybe there could stand to be a
compatibility note in the main INSERT
Hi,
I am using postgres 9.2.2.
The postgresql documentation says, full_page_writes is forcibly on after
executing the function pg_start_backup. But in my server full_page_writes
is still off (not changed).
Hello,
Some devices send the MAC address in RADIUS requests in the format
--. I've seen this with a 3com switch, but there may be
others. Currently, postgresql doesn't understand this format.
This patch adds an extra line to the macaddr parsing in postgres to
support this format as
How about, the format of psql duration can be set via some ...
backslash command or commdn line switch? And the default of course
remains the current behavior?
bogdan
Andres Freund and...@2ndquadrant.com writes:
On 2014-09-28 20:32:30 -0400, Gregory Smith wrote:
On 9/28/14, 7:49 AM, Bogdan
On 2014-09-30 11:49:21 -0700, Josh Berkus wrote:
On 09/30/2014 11:20 AM, Peter Geoghegan wrote:
For example, this patch for UPSERT doesn't support updatable views.
But I can't see anyone that didn't read the patch would know that.
By reading the CREATE VIEW docs. Maybe there could stand
On 09/30/2014 11:51 AM, Andres Freund wrote:
All of these things sound like good ideas for documentation
improvements, but hardly anything which should block the patch. It has
documentation, more than we'd require for a lot of other patches, and
it's not like the 9.5 release is next month.
On 09/30/2014 07:15 AM, Kevin Grittner wrote:
There are certainly other ways to do it, although they require more
work. As far as UPSERT goes, I agree that we should require such
an index, at least for the initial implementation and into the
foreseeable future. What I'm saying is that if we
On Tue, Sep 30, 2014 at 11:51 AM, Andres Freund and...@2ndquadrant.com wrote:
What's blocking it is that (afaik) no committer agrees with the approach
taken to solve the concurrency problems. And several (Heikki, Robert,
me) have stated their dislike of the proposed approach.
Well, it depends
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 30 September 2014 16:52, Stephen Frost sfr...@snowman.net wrote:
If the user only has column-level privileges on the table then I'm not
really sure how useful the detail will be.
One of the main things that detail is useful for is
On 30 September 2014 20:17, Stephen Frost sfr...@snowman.net wrote:
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 30 September 2014 16:52, Stephen Frost sfr...@snowman.net wrote:
If the user only has column-level privileges on the table then I'm not
really sure how useful the detail
Hi,
there's a #define clash between pg_config_manual.h and FreeBSD's
/usr/include/machine-amd64/param.h which also defines CACHE_LINE_SIZE.
It's probably not really a PostgreSQL bug, but it seems easy enough to
rename that definition now as it's only present in 9.4+. It's only
used in one file,
Please don't top post, initial context is important, especially Tom's! :-)
(see my reply below)
On 01/10/14 03:52, Bogdan Pilch wrote:
How about, the format of psql duration can be set via some ...
backslash command or commdn line switch? And the default of course
remains the current behavior?
On Tue, Sep 30, 2014 at 12:57 PM, Christoph Berg m...@debian.org wrote:
It's probably not really a PostgreSQL bug, but it seems easy enough to
rename that definition now as it's only present in 9.4+. It's only
used in one file, xlog.c: 375d8526f2900d0c377f44532f6d09ee06531f67
I agree. It
On 2014-09-30 13:42:11 -0700, Peter Geoghegan wrote:
On Tue, Sep 30, 2014 at 12:57 PM, Christoph Berg m...@debian.org wrote:
It's probably not really a PostgreSQL bug, but it seems easy enough to
rename that definition now as it's only present in 9.4+. It's only
used in one file, xlog.c:
On 2014-09-30 12:05:46 -0700, Peter Geoghegan wrote:
On Tue, Sep 30, 2014 at 11:51 AM, Andres Freund and...@2ndquadrant.com
wrote:
What's blocking it is that (afaik) no committer agrees with the approach
taken to solve the concurrency problems. And several (Heikki, Robert,
me) have stated
Hi all,
What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX? As
it holds data (like sequences and tables) I think we can do that.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Timbira: http://www.timbira.com.br
Blog: http://fabriziomello.github.io
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 07:15 AM, Kevin Grittner wrote:
At the risk of pushing people away from this POV, I'll point out
that this is somewhat similar to what we do for unlogged bulk loads
-- if all the conditions for doing it the fast way are present, we
do it the
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
It's got the same semantic problems as every other variant of CINE.
If there were a huge groundswell of demand for it, maybe we'd hold our
noses and
On 09/30/2014 02:39 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 07:15 AM, Kevin Grittner wrote:
At the risk of pushing people away from this POV, I'll point out
that this is somewhat similar to what we do for unlogged bulk loads
-- if all the conditions for
Since PostgreSQL started down that road for so many other relations, I
think many people just expect this to happen as a logical extension.
It certainly makes life a lot easier in combination with build
management systems.
/kirk
On 2014-09-30 16:43, Tom Lane wrote:
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 02:39 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 07:15 AM, Kevin Grittner wrote:
At the risk of pushing people away from this POV, I'll point out
that this is somewhat similar to what we do for unlogged bulk
On 09/30/2014 02:51 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 02:39 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 07:15 AM, Kevin Grittner wrote:
At the risk of pushing people away from this POV, I'll point out
that this is
On 09/30/2014 02:43 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
It's got the same semantic problems as every other variant of CINE.
If there were a huge groundswell of
On 2014-09-30 14:51:57 -0700, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 02:39 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 07:15 AM, Kevin Grittner wrote:
At the risk of pushing people away from this POV, I'll point out
On Tue, Sep 30, 2014 at 3:01 PM, Andres Freund and...@2ndquadrant.com wrote:
I think it'd be acceptable. Alternatively we'll just accept that you can
get uniqueness violations under concurrency. I many cases that'll be
fine.
I think living with unique violations is the right thing with MERGE,
On 2014-09-30 14:57:43 -0700, Josh Berkus wrote:
Regardless, I don't think there's any theoretical way to support UPSERT
without a unique constraint.
You can do stuff like blocking predicate locking. But without indexes to
support it that gets awfully complicated and unfunny. I don't think we
On 2014-09-30 17:01, Josh Berkus wrote:
On 09/30/2014 02:43 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX? It's
got the same semantic problems as every other variant of
Robert Haas wrote:
I favor option (a). There's something to be said for your proposal
in terms of logical consistency with what we have now, but to be
honest I'm not sure it's the behavior anyone wants (I would welcome
more feedback on what people actually want). I think we should view
an
Alvaro Herrera wrote:
The attached patch implements that. I only tested it on HEAD, but
AFAICS it applies cleanly to 9.4 and 9.3; fairly sure it won't apply to
9.2. Given the lack of complaints, I'm unsure about backpatching
further back than 9.3 anyway.
FWIW my intention is to make sure
Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-30 14:57:43 -0700, Josh Berkus wrote:
Regardless, I don't think there's any theoretical way to support
UPSERT without a unique constraint.
You can do stuff like blocking predicate locking. But without indexes to
support it that gets
On Tue, Sep 30, 2014 at 2:15 PM, Andres Freund and...@2ndquadrant.com wrote:
Well. People have given you outlines of approaches. And Heikki even gave
you a somewhat working prototype. I don't think you can fairly expect
more.
I don't expect anything, really. I asked nicely - that's all. I
On Tue, Sep 30, 2014 at 7:01 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 02:43 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com
writes:
What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
It's got the same semantic
Josh Berkus j...@agliodbs.com writes:
On 09/30/2014 02:43 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
It's got the same semantic problems as every other variant of CINE.
On 2014-09-30 18:47:24 -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 09/30/2014 02:43 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
It's got the same
On 09/30/2014 03:53 PM, Andres Freund wrote:
On 2014-09-30 18:47:24 -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 09/30/2014 02:43 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
What's your thoughts about we implement IF NOT
On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
On 09/30/2014 03:53 PM, Andres Freund wrote:
On 2014-09-30 18:47:24 -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 09/30/2014 02:43 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com
On Mon, Sep 29, 2014 at 6:30 PM, Herwin Weststrate
her...@quarantainenet.nl wrote:
Some devices send the MAC address in RADIUS requests in the format
--. I've seen this with a 3com switch, but there may be
others. Currently, postgresql doesn't understand this format.
This patch
On 30 September 2014 19:49, Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 11:20 AM, Peter Geoghegan wrote:
For example, this patch for UPSERT doesn't support updatable views.
But I can't see anyone that didn't read the patch would know that.
By reading the CREATE VIEW docs. Maybe there
On Tue, Sep 30, 2014 at 4:28 PM, Simon Riggs si...@2ndquadrant.com wrote:
A clear description of the feature being added is necessary to agree
its acceptance. When we implement a SQL Standard feature, we can just
look in the standard to see how it should work and compare. When we go
off-piste,
On 09/30/2014 04:16 PM, Andres Freund wrote:
On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
On 09/30/2014 03:53 PM, Andres Freund wrote:
Good point. I think it's fair enough to only allow CINE on named
indexes.
On the other hand, the way we form system-generated names is predicable,
so I
On Tue, Sep 30, 2014 at 8:47 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 04:16 PM, Andres Freund wrote:
On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
On 09/30/2014 03:53 PM, Andres Freund wrote:
Good point. I think it's fair enough to only allow CINE on named
indexes.
On 09/30/2014 04:58 PM, Fabrízio de Royes Mello wrote:
On Tue, Sep 30, 2014 at 8:47 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 04:16 PM, Andres Freund wrote:
On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
On 09/30/2014 03:53 PM, Andres Freund wrote:
Good point. I think it's
Hi Álvaro,
I have a stack trace from a crash to share, when querying a table with
a brin index. Let me know what else you need in addition to the stack trace:
#0 0x0077b0eb in pfree (pointer=0x1dcf1a8) at mcxt.c:754
#1 0x0045fe4a in bringetbitmap (fcinfo=optimized out) at
On Tue, Sep 30, 2014 at 9:12 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 04:58 PM, Fabrízio de Royes Mello wrote:
On Tue, Sep 30, 2014 at 8:47 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 04:16 PM, Andres Freund wrote:
On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
On Wed, Oct 1, 2014 at 10:03 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Done.
You should consider adding that to the next commit fest.
--
Michael
On Tue, Sep 30, 2014 at 10:22 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 10:03 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Done.
You should consider adding that to the next commit fest.
Sure. Added [1]
Regards,
[1]
70 matches
Mail list logo
