the next CF to keep track of it. Regards,
Committed and pushed to master and 9.5
Joe
- --
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJVnEcNAAoJEDfy90M199hlqTwP/0w87jIaAiJ86w+B72w24InP
77HYMqHd/6IB7cx6JWvDxeY
\+//'
>> errmsg("must be superuser to change bypassrls attribute.")));
>> errmsg("must be superuser to change bypassrls attribute")));
>>
>> Patch to fix attached.
>
> Will fix.
Push
; Fair point. I did try to address the language around policy vs.
> row security vs. row level security, but didn't look as closely as
> I should have at the error messages overall.
>
> Will address.
Pushed. Needed a small change to the expected regression output to match
.
Joe
--
/*
* coerce_record_to_complex
* Coerce a RECORD to a specific composite type.
*
* Currently we only support this for inputs that are RowExprs or
* whole-row Vars.
*/
8<
That explains why the first example works while the second does not.
I'm not sure how h
== INT4OID &&
argtypes[3] == BOOLOID)
{
[...]
}
else if ((numargs == 3 || numargs == 4) &&
argtypes[0] == TEXTOID &&
argtypes[1] == INT4OID &&
argtypes[2] == BOOLOID)
{
[...]
8<-
etc.
If the highest number of argumen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/05/2015 12:25 PM, Joe Conway wrote:
> On 02/22/2015 10:26 PM, Corey Huinker wrote:
>> Changes in this patch: - added polymorphic versions of
>> dblink_fetch() - upped dblink version # to 1.2 because of new
>> functions -
Nice tip -- thanks! The patch was missing two new files - I posted a
complete patch using the original thread.
- --
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJVmYWDAAoJEDfy90M199hlT7YP/1rUX6TTJcTT45bRPWagbPSa
VS6NBihFDA4Kc6IDfvr7iS3nyWaHC1TDBrk
s for dblink(),
> dblink_get_result(), dblink_fetch()
The previous patch was missing dblink--1.1--1.2.sql and
dblink--1.2.sql. I have added them, so it should apply cleanly against
git master, but not done any actual review yet.
- --
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.
ed
> in the past (by those with appropriate letters after their names)
> to stop using the Artistic licence. This is why I spent nearly a
> year working on changing pgAdmin to the PostgreSQL licence.
I committed this (1 July 2004), but cannot remember any details about
a license discussion. And
couple hundred
> lines from tablefunc.c?
Seems like a good idea -- connectby is really obsolete for quite a
while now other than as an SRF example. I guess we only keep it around
for backwards compatibility?
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and ge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/2015 12:36 PM, Tom Lane wrote:
> -c submits the entire string to the backend in one PQexec();
> therefore ON_ERROR_STOP cannot have any impact on its behavior.
> The backend will abandon processing the whole string upon first
> error, embedded
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This seems like either a psql bug or maybe just a documentation bug. I
know the psql docs say that -c behavior can be surprising, but I find
the below surprising even after reading the docs a couple of times.
Given that ON_ERROR_STOP defaults to off, i
s honest.
>
> Wow, that's radical, and interesting.
Actually, to me it sounds a lot like what we did 10 years ago before
the commitfests except with a way to track the patches (other than the
mail archives) and more people participating in patch reviews.
Joe
- --
Joe Conway
credat
.
Questions:
1) any major holes in this approach?
2) any better ideas?
3) should we consider an ALTER TABLE ALTER CONSTRAINT command
(or some such) to allow demotion of a PRIMARY KEY to a UNIQUE
constraint?
Thanks for any thoughts/comments.
Joe
- --
Joe Conway
credativ LLC: http://www
mma separated string.
To be honest I have no idea why I did not make it an empty array
instead of a NULL in that case, but that does make more sense to me
now that you mention it. Might cause some breakage for people
depending on that though...
Joe
- --
Joe Conway
credativ LLC: http://www.credat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2014 05:20 AM, Alvaro Herrera wrote:
> Alex Goncharov wrote:
>
>> This is a misfeature for the benefit of edit-lazy users only.
>
> +1
+1
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL
effect. And the effectiveness of redaction needs to
> be understood next to Rod's example.
>
> Since it relies on auditing, we need to do that first.
This is a really good summary. I definitely know of folks who would be
interested in this feature, but I also agree, as you have
make me wonder if some kind of
extension to the stats collector and pg_stat_statement might be a good
place to start?
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Sup
Does it make sense to support the whole set of DDL commands from
> the get go (or ever) when most of them are only taking locks in
> their own pg_catalog entry anyway?
Yes, I think it should cover all commands that can have an
availability impact.
Joe
- --
Joe Conway
credativ LLC: http://www.cr
if anyone is expected to take them quite so specifically.
Also, given Tom's remarks on the other part of this thread, I would
not be surprised if this turned out to be a much larger change than
Fujii-san originally hoped for, and thus may in fact get delayed to
next CF.
Joe
- --
Joe Conw
(log_checkpoints) and saw that effect
immediately in the open session. Was too tired to follow up last night
though. Have you verified for yourself that it behaves the way you say?
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training
reload, unlike other PGC_SIGHUP vars. So there is more
thought, testing, and possibly coding needed to make this a viable change.
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN P
ounds that it doesn't make much sense for them not to be applied
> system-wide; except that I think there was some idea that logging
> might be enabled per-user or per-database using ALTER
> ROLE/DATABASE.
I don't think this is a good idea because of the reason you mention.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/19/2014 03:38 PM, MauMau wrote:
> From: "Joe Conway"
>> Fair enough -- this patch does it at that level in
>> materializeQueryResult()
>
> I'm in favor of this. TBH, I did this at first, but I was afraid
ell
> worthwhile.
>
> Barring objections I'll apply and back-patch this.
Nice work! +1
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
Version: GnuPG
vel in
materializeQueryResult()
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thun
ferent opinion.
Seems unlikely to me.
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/19/2014 08:50 AM, Alvaro Herrera wrote:
> Joe Conway wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 06/18/2014 08:50 PM, Joe Conway wrote:
>>> On 06/18/2014 08:45 PM, Tom Lane wrote:
>>&g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 08:50 PM, Joe Conway wrote:
> On 06/18/2014 08:45 PM, Tom Lane wrote:
>> Well, we usually think memory leaks are back-patchable bugs. I'm
>> a bit worried about the potential performance impact of an extra
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 12:14 PM, Joe Conway wrote:
> On 06/18/2014 12:09 PM, Tom Lane wrote:
>> Joe Conway writes:
>>> I think the context deletion was missed in the first place
>>> because storeRow() is the wrong place to crea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 08:45 PM, Tom Lane wrote:
> Joe Conway writes:
>> On 06/18/2014 07:29 PM, Tom Lane wrote:
>>> With the attached patch on top of yours, I see no leak
>>> anymore.
>
>> I can confirm that -- roc
to free the tupledesc and segfaults.
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://w
Create a new, empty tuplestore */
oldcontext =
MemoryContextSwitchTo(rsinfo->econtext->ecxt_per_query_memory);
sinfo->tuplestore = tuplestore_begin_heap(true, false, work_mem);
rsinfo->setResult = sinfo->tuplestore;
rsinfo->setDesc = tupdesc;
MemoryContextSwitchTo(oldcontext);
8<-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 12:09 PM, Tom Lane wrote:
> Joe Conway writes:
>> I think the context deletion was missed in the first place
>> because storeRow() is the wrong place to create the context.
>> Rather than creating the context in st
along those lines attached.
Any objections to me back-patching it this way?
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU
the patch.
>
> http://www.postgresql.org/message-id/9C1EB95CA1F34DAB93DF549A51E3E874@maumau
That first hunk refers to dblink -- I'm guessing it does not belong with
this patch.
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consul
app has an option "bug fix" in the list of topic
> choices. I suppose the reason is that if the bug fix is only posted
> to pgsql-hackers and/or pgsql-bugs, it might be forgotten.
Yes, please add it to the commitfest and I'll claim it.
Thanks,
Joe
- --
Joe Conway
credativ
ata before the
> unused "hole" in the middle of the page, and one for after.
> Sometimes just two, if there is no hole to skip. See the loop just
> before the CRC calculation, that's where the XLogRecData entries
> for backup blocks are created.
>
> - Heikki
Ah, tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/14/2014 04:34 PM, Joe Conway wrote:
> On 04/14/2014 04:25 PM, Andres Freund wrote:
>> On 2014-04-14 16:22:48 -0700, Joe Conway wrote:
>>> That'll help performance, but lets say I generally keep WAL
>>> files
ckpoint, hopefully reducing the
> number of pages changed.
Nice idea but doesn't work well when you have two indexes with
different first column correlations.
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, &
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/14/2014 04:25 PM, Andres Freund wrote:
> On 2014-04-14 16:22:48 -0700, Joe Conway wrote:
>> That'll help performance, but lets say I generally keep WAL files
>> for PITR and don't turn that off before starting -- shouldn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/14/2014 04:17 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-04-14 14:33:03 -0700, Joe Conway wrote:
>>> checkpoint_segments = 96 checkpoint_timeout = 10min
>
>> I bet you'll see noticeably
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/14/2014 03:17 PM, Jim Nasby wrote:
> On 4/14/14, 4:50 PM, Andres Freund wrote:
>> On 2014-04-14 14:33:03 -0700, Joe Conway wrote:
>>> I realize there are many things that can be done to improve my
>>> specific scenari
latest. I have not yet tried to
reproduce on git master but intend to do so.
Thoughts?
Thanks,
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
o if you have a problem due to many tables on an older than 9.3
version of Postgres, this is the direction to head (a custom patch
applied to your old version just long enough to get successfully
upgraded).
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general
id* use a recent pg_dump ... but
> this particular issue got fixed server-side, so the new pg_dump
> didn't help against an 8.1 server :-(
Exactly. I backported the patch from 9.3 to 8.4 and saw a schema-only
dump time go from to 1 hour. This
was for a database with about 500k tables
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2014 12:26 PM, Simon Riggs wrote:
> On 11 March 2014 03:41, Tom Lane wrote:
>> Joe Conway writes:
>>> I am probably missing something obvious, but why does the
>>> AccessShareLock remain held on a table afte
* from t2;
8<-
Thoughts?
Thanks,
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment:
yes
Joe
Sent with AquaMail for Android
http://www.aqua-mail.com
On January 16, 2014 2:32:55 PM Josh Berkus wrote:
On 12/07/2013 05:50 PM, Joe Conway wrote:
> On 12/07/2013 05:41 PM, FabrÃzio de Royes Mello wrote:
> >> On Sat, Dec 7, 2013 at 11:20 PM, Michael Paquier >>
m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2014 07:22 PM, Craig Ringer wrote:
> On 01/13/2014 11:13 AM, Joe Conway wrote: What I mean is that you
> should not need a full Pg build tree to compile extensions. Just as
> we use PGXS on *nix, so it is possible to just use Visual
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2014 06:56 PM, Craig Ringer wrote:
> On 01/07/2014 12:41 AM, Joe Conway wrote:
>> Yes, this pretty much exactly describes how I build PL/R for
>> Windows. I had to match my build system SDK with the one EDB
>> uses to ge
ribes how I build PL/R for Windows.
I had to match my build system SDK with the one EDB uses to get a
compatible binary. It would be nice if we had something equivalent to
PGXS on Windows, or maybe even a community build system where authors
could get Windows binaries built.
Joe
- --
Joe Conwa
gIfDifferent() (or whatever) we can remove those
extra lines in 9.4 ;-)
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/05/2013 07:05 PM, Joe Conway wrote:
> On 12/05/2013 06:53 PM, Tom Lane wrote:
>> I seem to remember that at some point we realized that the
>> encoding ID assignments are part of libpq's ABI and so can't
>> prac
pg_encoding_to_char' too... ;-)
>
> The attached patch with my review!
Awesome, thanks for the review!
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
> integer IDs as above, rather than this.
Great feedback as always -- thanks! Will make that change.
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
Version: Gnu
lt;--
In my testing I saw a very consistent 4-5% degradation. I then did a
git bisect and traced the performance degradation to this commit:
- --
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e5de601267d98c5d60df6de8d436685c7105d149
committer
believe the 1.0 versions of the sql scripts should
probably be removed entirely. Can someone with more knowledge of the
extension facility comment on that?
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7
kind of new to the Postgresql hacker community, Can
>>>>> you please help me on submit the patch?
I have not done much in the way of real review yet, but here at least
is a context diff against git master.
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux,
e extremely useful in development. It
>> allows me to easily install an extension from a newer Pg version
>> into an older server, test against older servers, etc.
>
> This use case seems too narrow to me to justify the burden of
> keeping PGXS-enabled makefiles in contrib.
Wh
u
> please help me on submit the patch?
Hi Liming,
I might be able to help, but it will be at least a couple of days
before I have the time to look at this,
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting,
o process them together.
OK, done this way and committed.
> BTW, don't forget that the getRules move needs to be back-patched.
This too.
Thanks,
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, &
ted
getExtensionMembership() to be recursive -- instead it looks to only
go one level deep. Perhaps the longer term fix would be to identify
extension dependencies recursively, and then the reliance on strict
ordering here could be relaxed. But I don't think we want to make that
change in 9.3 at
ventTriggers() call was just added at the end; those things are
> certainly not table subsidiary objects. I don't know if we allow
> event triggers to be extension members, but if we did, that call
> would have to occur before getExtensionMembership().
Thanks! I'll ha
your proposal to fix this situation then?
I gather Tom would rather see this handled by filtering in pg_dump.
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
Ver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/01/2013 08:14 AM, Andres Freund wrote:
> On 2013-06-01 08:11:26 -0700, Joe Conway wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 06/01/2013 02:43 AM, Christoph Moench-Tegeder wrote:
>>> ##
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/01/2013 08:07 AM, Tom Lane wrote:
> Joe Conway writes:
>> On 05/31/2013 08:46 PM, Robert Haas wrote:
>>> Changing SQL syntax in the back-branches isn't normally
>>> something we do, but I confess I don't se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/01/2013 02:43 AM, Christoph Moench-Tegeder wrote:
> ## Joe Conway (m...@joeconway.com):
>
>> However there is a period of time after pg_start_backup() is
>> first executed to when it completes, during which backup_label
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/31/2013 08:46 PM, Robert Haas wrote:
> On Wed, May 29, 2013 at 6:55 PM, Joe Conway
> wrote:
>>> OK, simple enough. New patch attached. I still need to do some
>>> testing to verify this does not break anything, but o
nning.
>
> Whoa. You are right, but I'd call that a bug. I don't understand
> why we aren't just checking
> XLogCtl->Insert.(nonExclusiveBackups||exlusiveBackup)?
>
> I vote for changing this before we release pg_is_in_backup().
+1
Joe
- --
Joe Con
way to know that pg_start_backup()
has been executed and pg_stop_backup() has not?
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/31/2013 10:46 AM, Heikki Linnakangas wrote:
> On 31.05.2013 20:38, Joe Conway wrote:
>> I can check for the presence of $PGDATA/backup_label in order to
>> detect a backup in progress (i.e. pg_start_backup() has been run
>&g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/31/2013 10:42 AM, Andres Freund wrote:
> On 2013-05-31 10:38:56 -0700, Joe Conway wrote:
>> I can check for the presence of $PGDATA/backup_label in order to
>> detect a backup in progress (i.e. pg_start_backup() has
to when it completes, during which backup_label file does not
exist yet, but the backup has essentially been started. Is there any
way to detect this state?
Thanks,
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/30/2013 02:02 AM, Dimitri Fontaine wrote:
> Joe Conway writes:
>> Here's a cleaned up version, which also includes documentation.
>> I'll commit back to 9.1 in a day or two unless there are any
>> objections.
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 03:31 PM, Joe Conway wrote:
> On 05/29/2013 07:43 AM, Andres Freund wrote:
>>>>> Couldn't ALTER EXTENSION ... ADD ...; be brought up to
>>>>> speed to support this?
>> Sounds better to me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 07:43 AM, Andres Freund wrote:
> On 2013-05-29 07:35:42 -0700, Joe Conway wrote:
>> On 05/29/2013 05:52 AM, Dimitri Fontaine wrote:
>>> Andres Freund writes:
>>>> On 2013-05-29 09:30:43 +0200, Dimitri
ematic way to get the OIDs of the missing RULEs), or by
>>> maybe doing a drop/create on the RULEs?
>>
>> Couldn't ALTER EXTENSION ... ADD ...; be brought up to speed to
>> support this?
>
> I'll blame the Time Zone Difference Recovering. I felt like
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/06/2013 04:49 PM, Joe Conway wrote:
> If I create a database and install postgis as an extension, and
> then run pg_dump I get this:
>
> [...] CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public;
> [.
ries
> which are running on the replica?
This sounds a lot like having an "idle in transaction" session hanging
around. Could we use something akin to a prepared transaction to
preserve the ability to use the snapshot? Maybe with an (optional)
expiration timestamp?
Joe
- --
Joe Co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/08/2013 08:34 AM, Dimitri Fontaine wrote:
> Joe Conway writes:
>> OK, maybe I'll try to take a look in the meantime.
>
> That would be awesome :)
>
>> Did you have any comment on the other pg_dump patch (revi
we would wait a while to see how that
went before worrying again about value-per-call mode.
At this point you're looking at 9.4 for this, but I'll try to help see
it through since it has long been on my TODO list.
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQ
On 04/08/2013 07:42 AM, Dimitri Fontaine wrote:
> Joe Conway writes:
>> Shouldn't that CREATE RULE be implicitly part of the CREATE EXTENSION?
>
> Yes. It's a bug, been reported before, it's on my todo list. I have
> arranged some time to care about it while in b
; on this thread.
> Is it possible, if we can have two switches for extension in pg_dump:
> 1. extension dump with user data in extension tables.
> 2. User data-only dump from extensions.
This might be worth considering for 9.4
Thanks,
Joe
--
Joe Conway
credativ LLC: http://www.cre
LE be implicitly part of the CREATE EXTENSION?
If so, is this a pg_dump bug, PostGIS bug, or pilot error?
FWIW I see CREATE OR REPLACE RULE statements in the PostGIS extension
SQL script.
Thanks,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Tra
On 03/25/2013 08:12 AM, Vibhor Kumar wrote:
> Since, nobody has picked this one.
>
> If there is no objection,then I can test this patch against 9.1 & 9.2.
Here are diffs for 9.1 and 9.2. The previous email was against 9.3 dev.
Joe
--
Joe Conway
credativ LLC: http://www.cred
On 03/14/2013 05:23 PM, Joe Conway wrote:
> On 03/13/2013 04:16 PM, Dimitri Fontaine wrote:
>> Joe Conway writes:
>>> I think it should dump the user data portion, especially since that
>>> matches what pg_dump would do if you did not specify the table or schema.
>&
On 03/13/2013 04:16 PM, Dimitri Fontaine wrote:
> Joe Conway writes:
>> I think it should dump the user data portion, especially since that
>> matches what pg_dump would do if you did not specify the table or schema.
>
> +1
>
> If you don't have time slots to
re which - probably the latter?
+1
I think it should dump the user data portion, especially since that
matches what pg_dump would do if you did not specify the table or schema.
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Con
al_ref_sys test|grep spatial_ref_sys
pg_dump -n public test|grep spatial_ref_sys
8<--
Is this intentional, or oversight, or missing feature?
Thanks,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training,
rtitioning in C ?
>>
>> If you have some code to paste so I can start from I will really appreciate.
>
> Honestly I'd leave the trigger alone and modify the client code in
> performance sensitive places to insert directly to the correct
> partition table.
I second
On 08/30/2012 07:23 PM, Bruce Momjian wrote:
> On Thu, Jul 12, 2012 at 06:01:00PM -0700, Joe Conway wrote:
>> I'll take a look at the latter option sometime in the next few weeks and
>> submit for the next commitfest.
>
> Any news on this?
Not yet -- OBE. I'll tr
nst a stolen set of tokens and HMACs. Didn't we
add a hook some time ago for user provided password checker?
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
--
Sent via pgsql-hackers ma
ndomness
> of the salt string than replacing the md5 hash per se.
Or change to an md5 HMAC rather than straight md5 with salt. Last I
checked (which admittedly was a while ago) there were still no known
cryptographic weaknesses associated with an HMAC based on md5.
Joe
--
Joe Conway
creda
tter option sometime in the next few weeks and
submit for the next commitfest.
Is it still worth backpatching a change to has_language_privilege as a
bug fix?
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, &
On 07/10/2012 12:50 AM, Magnus Hagander wrote:
> On Tue, Jul 10, 2012 at 3:23 AM, Joe Conway wrote:
>> I verified this behavior on head as well as 9.1 (didn't bother looking
>> any further back). Looks like the reason is that CreateFunction()
>> correctly ch
---
I verified this behavior on head as well as 9.1 (didn't bother looking
any further back). Looks like the reason is that CreateFunction()
correctly checks lanpltrusted, whereas pg_language_aclmask() does not.
Seems like a bug to me -- opinions?
Joe
--
Joe
On 05/09/2012 10:01 PM, Tom Lane wrote:
> Joe Conway writes:
>> The attached one-liner seems to plug up the majority (although not quite
>> all) of the leakage.
>
> Looks sane to me. Are you planning to look for the remaining leakage?
Actually, now I'm not so sure
On 05/09/2012 05:06 PM, Joe Conway wrote:
> OK, new script. This more faithfully represents the real life scenario,
> and reproduces the issue on HEAD with out-of-the-box config settings,
> versus 8.1 which completes the query having never exceeded a very modest
>
On 05/09/2012 03:36 PM, Joe Conway wrote:
> Good call -- of course that just means my contrived example fails to
> duplicate the real issue :-(
> In the real example, even with work_mem = 1 MB I see the same behavior
> on 9.1.
OK, new script. This more faithfully represents the real l
301 - 400 of 1286 matches
Mail list logo
