On Fri, Mar 28, 2014 at 12:16 PM, David Johnston pol...@yahoo.com wrote:
Slightly tangential but are the locking operations associated with the
recent bugfix generated in both (all?) modes or only hot_standby? I thought
it strange that transient locking operations were output with WAL though
On 27 March 2014 21:01, Florian Pflug f...@phlo.org wrote:
First, sorry guys for letting this slide - I was overwhelmed by other works,
and this kind of slipped my mind :-(
On Mar27, 2014, at 09:04 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 26 March 2014 19:43, David Rowley
Hello
I see only one risk - it can do some slowdown of exception processing.
Sometimes you can have a code like
BEGIN
WHILE ..
LOOP
BEGIN
INSERT INTO ...
EXCEPTION WHEN ..
; /* ignore this error */
END;
END LOOP;
without this risks, proposed feature is nice, but
On Fri, Mar 28, 2014 at 1:00 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I see only one risk - it can do some slowdown of exception processing.
I think it's unlikely that you'd see ERRCODE_UNDEFINED_COLUMN in
procedural code like that in practice. In any case it's worth noting
that I
2014-03-28 9:22 GMT+01:00 Peter Geoghegan p...@heroku.com:
On Fri, Mar 28, 2014 at 1:00 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I see only one risk - it can do some slowdown of exception processing.
I think it's unlikely that you'd see ERRCODE_UNDEFINED_COLUMN in
procedural code
I went back and tried Erik's original test
(http://www.postgresql.org/message-id/dafad644f268ce1503e1b8b682aae38a.squir...@webmail.xs4all.nl).
With a fresh checkout from master, the difference between the slow and
fast queries is much less dramatic than Erik reported. The reason is
that
Very interesting idea, I'd think about optionally add similarity hinting
support to psql tab. With, say, 80% of similarity matching, it
shouldn't be very annoying. For interactive usage there is no risk of
slowdown.
On Mar 27, 2014 11:11 PM, Peter Geoghegan p...@heroku.com wrote:
With the
Peter Geoghegan wrote:
With the addition of LATERAL subqueries, Tom fixed up the mechanism
for keeping track of which relations are visible for column references
while the FROM clause is being scanned. That allowed
errorMissingColumn() to give a more useful error to the one produced
by the
Re: Albe Laurenz 2014-03-28
a737b7a37273e048b164557adef4a58b17ce8...@ntex2010i.host.magwien.gv.at
ERROR: 42703: column ol.orderids does not exist
LINE 1: ...* from orders o join orderlines ol on o.orderid = ol.orderid...
^
On Fri, Mar 28, 2014 at 4:10 AM, Peter Geoghegan p...@heroku.com wrote:
With the addition of LATERAL subqueries, Tom fixed up the mechanism
for keeping track of which relations are visible for column references
while the FROM clause is being scanned. That allowed
errorMissingColumn() to give a
As you probably know, I've studying how to implement a system to allow
replicating DDL commands to remote servers. I have a fairly good grasp
of handling CREATE commands; we have another thread discussing that
involving a JSON output for such commands. That hasn't been carried to
completion yet;
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes:
Hello. Attached is the 2nd version of 'pushdown in UNION ALL on
partitioned tables' patch type 1 - fix in equiv-member version.
Committed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hi,
after a months I've found a time to make test-case for this bug, probably:
I've got my custom type and a table stores historical data of the main table.
The problem occurs at our production servers, version 9.2.6. We've found it
after our backups wasn't
complete because of selection from
On 03/28/2014 04:30 PM, Alexander Korotkov wrote:
We have range types, and restriction col @ range can be correctly
handled by gin_extract_query, because it will be passed there as single
restriction. This is workaround itself, but it's weird to force users
express queries like this.
This
Alvaro Herrera alvhe...@2ndquadrant.com writes:
My proposal therefore is to add some more columns to
pg_event_trigger_dropped_objects(): more precisely, objname and objargs,
which would carry exactly what get_object_address() would require to
re-construct an ObjectAddress for the object being
Honza hon...@gmail.com writes:
after a months I've found a time to make test-case for this bug, probably:
Confirmed that this reproduces a problem on HEAD. Will look into it,
thanks!
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hackers,
after reading Heikki Linnakangas presentation about GIN from Nordic PGDay,
I figure out that btree_gin became much more attractive.
http://hlinnaka.iki.fi/presentations/NordicPGDay2014-GIN.pdf
But it have one weird behaviour: when you have range restriction like col
const1 AND col
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
My proposal therefore is to add some more columns to
pg_event_trigger_dropped_objects(): more precisely, objname and objargs,
which would carry exactly what get_object_address() would require to
re-construct an ObjectAddress
On Fri, Mar 28, 2014 at 5:57 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
What about the overhead that this processing creates if error
processing needs to scan a schema with let's say hundreds of tables?
It doesn't work that way. I've extended searchRangeTableForCol() so
that when it
I wrote:
Honza hon...@gmail.com writes:
after a months I've found a time to make test-case for this bug, probably:
Confirmed that this reproduces a problem on HEAD. Will look into it,
thanks!
I believe I understand what's going on here, and it's not quite as
exciting as it first appears.
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
* Euler Taveira (eu...@timbira.com.br) wrote:
On 27-03-2014 10:15, Bruce Momjian wrote:
When we made OIDs optional, we added an oid status display to \d+:
test= \d+ test
Table public.test
Hello. I've been doing some benchmarks on performance / size differences
between actions when wal_level is set to either archive or hot_standby. I'm
not seeing a ton of difference. I've read some posts about discussions as
to whether this parameter should be simplified and remove or merge these
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
I believe Bruce was suggesting to show it when it is set to *not* the
default, which strikes me as perfectly reasonable.
We seem to be split on the idea of having Has OIDs display only when
On Fri, Mar 28, 2014 at 3:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
I believe Bruce was suggesting to show it when it is set to *not* the
default, which strikes me as perfectly reasonable.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
I believe Bruce was suggesting to show it when it is set to *not* the
default, which strikes me as perfectly reasonable.
We seem to be split on
On Fri, Mar 28, 2014 at 03:50:10PM +, Tom Lane wrote:
Fix EquivalenceClass processing for nested append relations.
If this is a bug fix, shouldn't it be back-patched?
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Way way back in commit ae93e5fd6e8a7e2321e87d23165d9d7660cde598,
we established a coding rule that it was okay for composite Datums
to contain external (out-of-line) toasted fields, as long as such
toasting didn't go more than one level deep in any tuple. This meant
that heap_form_tuple had to go
Hi,
On 2014-03-27 08:02:35 -0400, Tom Lane wrote:
Buildfarm member prairiedog thinks there's something unreliable about
commit f01d1ae3a104019d6d68aeff85c4816a275130b3:
***
/Users/buildfarm/bf-data/HEAD/pgsql.13462/src/test/regress/expected/alter_table.out
Thu Mar 27 04:12:40 2014
David Fetter da...@fetter.org writes:
On Fri, Mar 28, 2014 at 03:50:10PM +, Tom Lane wrote:
Fix EquivalenceClass processing for nested append relations.
If this is a bug fix, shouldn't it be back-patched?
It's a planner improvement; it's not a bug fix in the sense that previous
plans were
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-27 08:02:35 -0400, Tom Lane wrote:
Buildfarm member prairiedog thinks there's something unreliable about
commit f01d1ae3a104019d6d68aeff85c4816a275130b3:
That's rather odd. It has survived for a couple of months on the other
buildfarm
On 2014-03-28 16:41:15 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-27 08:02:35 -0400, Tom Lane wrote:
Buildfarm member prairiedog thinks there's something unreliable about
commit f01d1ae3a104019d6d68aeff85c4816a275130b3:
That's rather odd. It has
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-28 16:41:15 -0400, Tom Lane wrote:
Any objection to separating out the have_mappings bit? It wasn't terribly
appropriate before, but it seems really out of place in this formulation.
The patch I sent removed the have_mapping thing
On 2014-03-28 16:45:28 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-28 16:41:15 -0400, Tom Lane wrote:
Any objection to separating out the have_mappings bit? It wasn't terribly
appropriate before, but it seems really out of place in this formulation.
Andres Freund and...@2ndquadrant.com writes:
I don't think it's necessary. As far as I understand LATERAL, a join to
a function returning NULL will still return the row. So, the test now
would only test whether there are rows in pg_class which seems a bit
pointless.
Yeah, after looking closer
On Fri, Mar 28, 2014 at 3:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Way way back in commit ae93e5fd6e8a7e2321e87d23165d9d7660cde598,
we established a coding rule that it was okay for composite Datums
to contain external (out-of-line) toasted fields, as long as such
toasting didn't go more than
Merlin Moncure mmonc...@gmail.com writes:
Trying to follow along here. Am I correct in saying that if you make
these changes any SQL level functionality (say, creating a composite
type containing a large array) that used to work will continue to
work?
This wouldn't change any SQL-level
On Fri, March 28, 2014 09:31, Heikki Linnakangas wrote:
I went back and tried Erik's original test
(http://www.postgresql.org/message-id/dafad644f268ce1503e1b8b682aae38a.squir...@webmail.xs4all.nl).
With a fresh checkout from master, the difference between the slow and
fast queries is much
37 matches
Mail list logo
