On Wed, Jun 4, 2014 at 11:10 PM, Fujii Masao wrote:
> On Wed, Jun 4, 2014 at 3:26 PM, Amit Langote wrote:
>> Hi,
>>
>> Following (commit 2985e16) has not been backpatched, I guess.
>>
>> ANALYZE hs1;
>> -ERROR: cannot execute VACUUM during recovery
>> +ERROR: cannot execute ANALYZE during reco
David G Johnston writes:
> If we are planning on keeping this rule, which it seems like at least a few
> people feel is too stringent, maybe we can consider releasing an Alpha
> version and communicate the expectation that an initdb will be required to
> go from the alpha to beta1. Then hopefully
Stefan Kaltenbrunner wrote
> On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
>>
>> On 06/04/2014 11:52 AM, Tom Lane wrote:
>>
>>> I think we could possibly ship 9.4 without fixing this, but it would be
>>> imprudent. Anyone think differently?
>>>
>>> Of course, if we do fix this then the door ope
Hi,
On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao wrote:
> I like using "slot_name" everywhere, i.e, even in recovery.conf.
> primary_slot_name seems not so long name.
>
> BTW, what about also renaming pg_llog directory? I'm afraid that
> a user can confuse pg_log with pg_llog.
>
Recently I came
On Thu, Jun 5, 2014 at 9:54 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-05-09 22:14:25 +0900, Michael Paquier wrote:
>>> [ patch ]
>
> I've committed a revised version of Andres' patch.
Thanks!
> I thought even that was kind of overkill; but a bigger problem is the
> output was sensit
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund wrote:
> Hi,
>
> Due to the opened window of the pg_control/catalog version bump a chance
> has opened to fix a inconsistency I've recently been pointed
> towards:
> Namely that replication slots are named 'slot_name' in one half of the
> cases and 'sl
On Thu, Jun 5, 2014 at 9:12 AM, Andres Freund wrote:
> Hi,
>
> On 2014-06-04 10:37:48 +1000, Haribabu Kommi wrote:
>> Thanks for the test. Patch is re-based to the latest head.
>
> Did you look at the source of the conflict? Did you intentionally mark
> the functions as leakproof and reviewed that
Peter Eisentraut writes:
> On Wed, 2014-05-07 at 03:08 +0200, Andres Freund wrote:
>> As an additional issue it currently doesn't seem to work in VPATH
>> builds. That's imo a must fix.
>> A "cd $(srcdir) && .." in prove_installcheck and prove_check seems to do
>> the trick.
> Here is my proposed
Andres Freund writes:
> On 2014-05-09 22:14:25 +0900, Michael Paquier wrote:
>> [ patch ]
I've committed a revised version of Andres' patch. Mostly cosmetic
fixes, but the hash implementation was still wrong:
return DirectFunctionCall1(hashint8, PG_GETARG_LSN(0));
DirectFunctionCallN t
On Wed, 2014-05-07 at 03:08 +0200, Andres Freund wrote:
> > As an additional issue it currently doesn't seem to work in VPATH
> > builds. That's imo a must fix.
>
> A "cd $(srcdir) && .." in prove_installcheck and prove_check seems to do
> the trick.
Here is my proposed patch for this.
diff --git
On 2014-06-04 20:04:07 -0400, Noah Misch wrote:
> On Wed, Jun 04, 2014 at 10:14:42AM -0400, Tom Lane wrote:
> > It's possible that we could apply the optimization only to queries that
> > have been issued directly by a client, but that seems rather ugly and
> > surprise-filled.
>
> ... such as thi
On Wed, Jun 04, 2014 at 10:14:42AM -0400, Tom Lane wrote:
> David Rowley writes:
> > On Wed, Jun 4, 2014 at 11:50 AM, Noah Misch wrote:
> >> When a snapshot can see modifications that queued referential integrity
> >> triggers for some FK constraint, that constraint is not guaranteed to hold
> >>
On 06/04/2014 04:35 PM, Andres Freund wrote:
Hi,
On 2014-06-04 16:32:33 -0700, Josh Berkus wrote:
Can we get this patch going again for 9.5?
A patch gets going by somebody working on it.
Well yes, but it is also great to have someone remind others that it is
of interest.
JD
Greetin
Hi,
On 2014-06-04 16:32:33 -0700, Josh Berkus wrote:
> Can we get this patch going again for 9.5?
A patch gets going by somebody working on it.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
All,
Can we get this patch going again for 9.5?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund writes:
> On 2014-05-14 12:20:55 -0400, Tom Lane wrote:
>> Yeah, I don't think we want to bump the WAL version code post-beta1.
>>
>> Probably better to assign the modified spgist record a new xl_info ID
>> number, so that a beta1 slave would throw an error for it.
> Since that shi
I wrote:
> Robert Haas writes:
>> I think that's worth considering. Another idea is: suppose we set up
>> a PostgreSQL database somewhere that contained information about what
>> controldata layout corresponded to what control version:
> That seems possibly workable.
BTW, a possibly-easier-to-i
On 2014-05-14 12:20:55 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-05-14 10:07:18 -0400, Tom Lane wrote:
> >> I think that's an OK restriction as long as we warn people about it
> >> (you could update a replication pair as long as you shut them both
> >> down cleanly at the same tim
Hi,
Due to the opened window of the pg_control/catalog version bump a chance
has opened to fix a inconsistency I've recently been pointed
towards:
Namely that replication slots are named 'slot_name' in one half of the
cases and 'slotname' in the other. That's in views, SRF columns,
function parame
Robert Haas writes:
> On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan wrote:
>> I agree it's scary but in a few minutes thinking about it I haven't been
>> able to come up with a good way of checking it. Maybe we could build
>> sizeof(ControlData) into the version number, so instead of 937 we'd ha
On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan wrote:
> On 06/04/2014 03:50 PM, Robert Haas wrote:
>> On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane wrote:
>>> I just noticed that we had not one, but two commits in 9.4 that added
>>> fields to pg_control. And neither one changed PG_CONTROL_VERSION.
>>
Hi,
On 2014-06-04 10:37:48 +1000, Haribabu Kommi wrote:
> Thanks for the test. Patch is re-based to the latest head.
Did you look at the source of the conflict? Did you intentionally mark
the functions as leakproof and reviewed that that truly is the case? Or
was that caused by copy & paste?
Gre
2014-06-01 20:48 GMT+07:00 Marc Mamin :
>
> >On Sat, May 31, 2014 at 12:31 AM, Marc Mamin wrote:
> >> I have patched intarray with 3 additional functions in order to
> >> count[distinct] event IDs
> >> into arrays, whereas the array position correspond to the integer values.
> >> (mimic column o
Andres Freund writes:
> On 2014-06-03 10:37:53 -0400, Tom Lane wrote:
>> It hasn't even got a comment saying why changes here should
>> receive any scrutiny; moreover, it's not in a file where changes would be
>> likely to excite suspicion. (Probably it should be in opr_sanity, if
>> we're going
On Wed, Jun 04, 2014 at 09:16:36PM +0200, Stefan Kaltenbrunner wrote:
> On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
> > On 06/04/2014 11:52 AM, Tom Lane wrote:
> >> I think we could possibly ship 9.4 without fixing this, but it would be
> >> imprudent. Anyone think differently?
> >>
> >> Of cou
On 2014-06-03 10:37:53 -0400, Tom Lane wrote:
> It hasn't even got a comment saying why changes here should
> receive any scrutiny; moreover, it's not in a file where changes would be
> likely to excite suspicion. (Probably it should be in opr_sanity, if
> we're going to have such a thing at all.)
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> There are at least two places in inv_api.c where we have
>> "Assert(pagelen <= LOBLKSIZE)" that is protecting a subsequent memcpy
>> into a local variable of size LOBLKSIZE, so that the only thing standing
>> between us and a stack-
2014-06-05 2:37 GMT+07:00 Robert Haas :
> Please add your patch here so we don't forget about it:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
>
Added: https://commitfest.postgresql.org/action/patch_view?id=1461
> Please see also:
>
> https://wiki.postgresql.org/wiki/Submit
Greg Stark writes:
> Fwiw I tried to use the pg_lsn data type the other day and pretty much
> immediately ran into the lack of the btree operator class. Pretty much
> the first thing I did when I loaded the data was "select ... order by
> lsn".
Agreed, now that we're going to force an initdb anyw
On 2014-06-04 17:03:52 -0400, Tom Lane wrote:
> Actually, that statement makes me realize that if we fix
> PG_CONTROL_VERSION then it's a good idea to *also* do some regular catalog
> changes, or at least bump catversion. Otherwise pg_upgrade won't be able to
> cope with upgrading non-default tabl
On Wed, Jun 4, 2014 at 9:52 PM, Andres Freund wrote:
> Other things I'd like to change in that case:
Fwiw I tried to use the pg_lsn data type the other day and pretty much
immediately ran into the lack of the btree operator class. Pretty much
the first thing I did when I loaded the data was "sel
Andres Freund writes:
> On 2014-06-04 14:52:35 -0400, Tom Lane wrote:
>> I think we could possibly ship 9.4 without fixing this, but it would be
>> imprudent. Anyone think differently?
> Agreed. Additionally I also agree with Stefan that the price of a initdb
> during beta isn't that high these
Hi,
On 2014-06-04 14:52:35 -0400, Tom Lane wrote:
> I think we could possibly ship 9.4 without fixing this, but it would be
> imprudent. Anyone think differently?
Agreed. Additionally I also agree with Stefan that the price of a initdb
during beta isn't that high these days.
> Of course, if we
On 06/04/2014 03:50 PM, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers invol
Robert Haas wrote
> On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane <
> tgl@.pa
> > wrote:
>> I just noticed that we had not one, but two commits in 9.4 that added
>> fields to pg_control. And neither one changed PG_CONTROL_VERSION.
>> This is inexcusable sloppiness on the part of the committers involv
Hi Jeff,
On 2014-05-29 09:39:56 -0700, Jeff Janes wrote:
> What features in 9.4 need more beta testing for recovery?
Another thing I'd like to add to the list is wal_level=logical. Not such
much the logical decoding side, but that we haven't screwed up normal
crash recovery/wal replay.
> I also
On 2014-06-03 15:08:15 -0400, Tom Lane wrote:
> Andres Freund writes:
> > In 9.4. COSTS OFF for EXPLAIN prevents 'Planning time' to be
> > printed. Should we perhaps do the same for 'Execution time'? That'd make
> > it possible to use EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) in
> > regression test
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane wrote:
> I just noticed that we had not one, but two commits in 9.4 that added
> fields to pg_control. And neither one changed PG_CONTROL_VERSION.
> This is inexcusable sloppiness on the part of the committers involved,
> but the question is what do we do
On Fri, May 30, 2014 at 5:04 AM, Ali Akbar wrote:
> While developing some XML processing queries, i stumbled on an old bug
> mentioned in http://wiki.postgresql.org/wiki/Todo#XML: Fix Nested or
> repeated xpath() that apparently mess up namespaces.
>
> Source of the bug is that libxml2's xmlNodeDu
On Jun 4, 2014 8:52 PM, "Tom Lane" wrote:
>
> I just noticed that we had not one, but two commits in 9.4 that added
> fields to pg_control. And neither one changed PG_CONTROL_VERSION.
> This is inexcusable sloppiness on the part of the committers involved,
> but the question is what do we do now?
On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
>
> On 06/04/2014 11:52 AM, Tom Lane wrote:
>
>> I think we could possibly ship 9.4 without fixing this, but it would be
>> imprudent. Anyone think differently?
>>
>> Of course, if we do fix this then the door opens for pushing other
>> initdb-forci
On 06/04/2014 11:52 AM, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Of course, if we do fix this then the door opens for pushing other
initdb-forcing fixes into 9.4beta2, such as the LOBLKSIZE addition
that I was
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
but the question is what do we do now?
Quick experimentation says that you don't really ge
On 2014-06-04 14:50:39 -0400, Robert Haas wrote:
> The thing I was concerned about is that the system might have been in
> recovery for months. What was hot at the time the base backup was
> taken seems like a poor guide to what will be hot at the time of
> promotion. Consider a history table, for
On Wed, Jun 4, 2014 at 9:56 AM, Andres Freund wrote:
> On 2014-06-04 09:51:36 -0400, Robert Haas wrote:
>> On Wed, Jun 4, 2014 at 2:08 AM, Andres Freund wrote:
>> > On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
>> >> Incase of recovery, the shared buffers saved by this utility are
>> >> from p
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> There are at least two places in inv_api.c where we have
> "Assert(pagelen <= LOBLKSIZE)" that is protecting a subsequent memcpy
> into a local variable of size LOBLKSIZE, so that the only thing standing
> between us and a stack-smash security issue that's t
Robert Haas writes:
> On Wed, Jun 4, 2014 at 1:21 PM, Tom Lane wrote:
>> BTW, just comparing the handling of TOAST_MAX_CHUNK_SIZE and LOBLKSIZE,
>> I noticed that the tuptoaster.c functions are reasonably paranoid about
>> checking that toast chunks are the expected size, but the large object
>>
On Wed, Jun 4, 2014 at 1:21 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> I've not heard one either, but there was just somebody asking in
>>> pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
>>> That's not a big enough sample size t
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I've not heard one either, but there was just somebody asking in
>> pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
>> That's not a big enough sample size to make me panic about getting a
>> hasty fix into 9.4,
On Mon, Jun 2, 2014 at 2:10 PM, Fujii Masao wrote:
> Could you let me know the link to the page explaining this?
>
>> That would even protect against another
>> restore on the same host.
>
> What about the case where we restore the backup to another server and
> start the recovery? In this case, I
2014-06-04 18:16 GMT+02:00 Peter Eisentraut :
> On 6/4/14, 11:54 AM, Pavel Stehule wrote:
> > updated patch - only one change: query is prefixed by "QUERY: "
>
> In the backend server log, this is called "STATEMENT: ".
>
good idea
updated patch
Pavel
commit f752566830032438739b7e5ab1f55149c73
On 6/4/14, 11:54 AM, Pavel Stehule wrote:
> updated patch - only one change: query is prefixed by "QUERY: "
In the backend server log, this is called "STATEMENT: ".
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
>
>
> From: Tom Lane
>
> Hm, can you restore it into 9.2 either?
>
> AFAICS, pg_dump has absolutely no idea that it should be worried about the
> value of xmloption, despite the fact that that setting affects what is
> considered valid XML data. What's worse, even if it were attempting to do
Hello
updated patch - only one change: query is prefixed by "QUERY: "
current state:
[pavel@localhost ~]$ src/postgresql/src/bin/psql/psql postgres -q -f
data.sql
psql:data.sql:6: ERROR: value too long for type character varying(3)
Show only errors mode:
[pavel@localhost ~]$ src/postgresql/s
On Tue, Jun 3, 2014 at 8:37 PM, Haribabu Kommi
wrote:
> On Wed, Jun 4, 2014 at 5:46 AM, Keith Fiske wrote:
> >
> > Andres's changes on June 3rd to
> >
> https://github.com/postgres/postgres/commits/master/src/test/regress/expected/create_function_3.out
> > are causing patch v2 to fail for that r
Andres Freund wrote:
> On 2014-06-04 16:59:10 +0200, Alexey Klyukin wrote:
> > I've recently discovered a peculiar problem on one of our big databases
> > (more than 1TB). The database has been upgraded from 9.2 to 9.3.4 (using
> > hardlinks to speedup the process) on April 7th around 22:00 local
On Wed, Jun 4, 2014 at 7:26 PM, Andres Freund
wrote:
> On 2014-06-04 09:51:36 -0400, Robert Haas wrote:
> > On Wed, Jun 4, 2014 at 2:08 AM, Andres Freund
wrote:
> > > On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
> > >> Incase of recovery, the shared buffers saved by this utility are
> > >> fr
Magnus Hagander writes:
> On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane wrote:
>> Another thought is we could make pg_basebackup simply skip any files that
>> exceed RELSEG_SIZE, on the principle that you don't really need/want
>> enormous log files to get copied anyhow. We'd still need the pax
>> ex
Hi,
On 2014-06-04 16:59:10 +0200, Alexey Klyukin wrote:
> I've recently discovered a peculiar problem on one of our big databases
> (more than 1TB). The database has been upgraded from 9.2 to 9.3.4 (using
> hardlinks to speedup the process) on April 7th around 22:00 local time.
> When doing vacu
On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > Yeah, that is a clear advantage of that method. Didn't read up on pax
> > format backwards compatibility, does it have some trick to achieve
> > something similar?
>
> I didn't read the fine print but it sounded like t
Andres Freund writes:
> Btw, I had wondered before if we shouldn't also add sizeof(long) to
> pg_control to catch cases where a database is copied between a LLP64
> (64bit windows) and an LP64 (nearly every other 64bit system) system. I
> have my doubts that we're completely clean about the size
>
Tim Kane writes:
> Iâm migrating a database from 9.2.4 to 9.3.0 and encountering an issue with
> an XML field failing to restore.
Hm, can you restore it into 9.2 either?
AFAICS, pg_dump has absolutely no idea that it should be worried about the
value of xmloption, despite the fact that that se
Greetings,
I've recently discovered a peculiar problem on one of our big databases
(more than 1TB). The database has been upgraded from 9.2 to 9.3.4 (using
hardlinks to speedup the process) on April 7th around 22:00 local time.
When doing vacuum on any table, the system fails with the following
On 2014-06-04 10:03:09 -0400, Tom Lane wrote:
> I just chanced to notice that if someone were to change the value for
> LOBLKSIZE and recompile, there'd be nothing to stop him from starting
> that postmaster against an existing database, even though it would
> completely misinterpret and mangle any
Stephen Frost writes:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> On 06/04/2014 10:03 AM, Tom Lane wrote:
>>> I just chanced to notice that if someone were to change the value for
>>> LOBLKSIZE and recompile, there'd be nothing to stop him from starting
>>> that postmaster against an existi
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Andrew Dunstan (and...@dunslane.net) wrote:
> >> On 06/04/2014 10:03 AM, Tom Lane wrote:
> >>> I just chanced to notice that if someone were to change the value for
> >>> LOBLKSIZE and recompile, there'd be nothing to stop him fr
On 06/04/2014 10:27 AM, Andres Freund wrote:
On 2014-06-04 10:25:07 -0400, Andrew Dunstan wrote:
If we did an initdb-requiring change for 9.4 could we piggy-back this onto
it?
Do you know of a problem requiring that?
No, just thinking ahead.
cheers
andrew
--
Sent via pgsql-hackers mai
* Andrew Dunstan (and...@dunslane.net) wrote:
> On 06/04/2014 10:03 AM, Tom Lane wrote:
> >I just chanced to notice that if someone were to change the value for
> >LOBLKSIZE and recompile, there'd be nothing to stop him from starting
> >that postmaster against an existing database, even though it w
On 2014-06-04 10:25:07 -0400, Andrew Dunstan wrote:
> If we did an initdb-requiring change for 9.4 could we piggy-back this onto
> it?
Do you know of a problem requiring that?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24
amul sul writes:
> For more granularity, I think passing Form_pg_attribute to
> examine_attribute() function rather than passing Relation will be more
> relevant & makes it simple to understand.
I don't find that to be a good idea at all. It makes examine_attribute
inconsistent with most othe
On 06/04/2014 10:03 AM, Tom Lane wrote:
I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop him from starting
that postmaster against an existing database, even though it would
completely misinterpret and mangle any data in pg
David Rowley writes:
> On Wed, Jun 4, 2014 at 11:50 AM, Noah Misch wrote:
>> When a snapshot can see modifications that queued referential integrity
>> triggers for some FK constraint, that constraint is not guaranteed to hold
>> within the snapshot until those triggers have fired.
> I remember
On Wed, Jun 4, 2014 at 3:26 PM, Amit Langote wrote:
> Hi,
>
> Following (commit 2985e16) has not been backpatched, I guess.
>
> ANALYZE hs1;
> -ERROR: cannot execute VACUUM during recovery
> +ERROR: cannot execute ANALYZE during recovery
>
> Attached is a patch for this.
Why did you cut off th
I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop him from starting
that postmaster against an existing database, even though it would
completely misinterpret and mangle any data in pg_largeobject.
I think there ought to be a
On 2014-06-04 09:51:36 -0400, Robert Haas wrote:
> On Wed, Jun 4, 2014 at 2:08 AM, Andres Freund wrote:
> > On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
> >> Incase of recovery, the shared buffers saved by this utility are
> >> from previous shutdown which doesn't seem to be of more use
> >> t
On Wed, Jun 4, 2014 at 2:08 AM, Andres Freund wrote:
> On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
>> On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh wrote:
>> > On Tue, Jun 3, 2014 at 7:57 AM, Robert Haas wrote:
>> > > It seems like it would be best to try to do this at cluster startup
>> >
On Tue, Jun 3, 2014 at 11:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> I thought the reason why this hasn't been implemented before now is
>> that sending an ErrorResponse to the client will result in a loss of
>> protocol sync.
>
> Hmm ... you are right that this isn't as simple as an ereport
Hi.
Here's a patch to make pg_xlogdump print summary statistics instead of
individual records.
By default, for each rmgr it shows the number of records, the size of
rmgr-specific records, the size of full-page images, and the combined
size. With --stats=record it shows these figures for each rmgr
Hi,
examine_attribute() function accept Relation type argument, and extract
attribute from it.
For more granularity, I think passing Form_pg_attribute to examine_attribute()
function rather than passing Relation will be more relevant & makes it simple
to understand.
Thinking to change exami
On Wed, Jun 4, 2014 at 11:50 AM, Noah Misch wrote:
> On Wed, May 28, 2014 at 08:39:32PM +1200, David Rowley wrote:
> > The attached patch allows join removals for both sub queries with left
> > joins and also semi joins where a foreign key can prove the existence of
> > the record.
>
> When a sna
80 matches
Mail list logo
