as superuser to see
information they require, which to me is a total showstopper.
If you want control over visibility of application_name, it should be
done with a column privilige granted to a system role, or something like
that - so the ability to see it can be given to "public" on defau
at competes with queries, and
turn it off to "solve" the problem.
I'm not sure how to tackle that.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/24/2014 10:12 AM, Craig Ringer wrote:
> (Re-sending; I forgot to cc the list)
>
> On 01/20/2014 02:15 PM, Craig Ringer wrote:
>> On 01/20/2014 09:58 AM, Craig Ringer wrote:
>>> As it is I'm spending today reworking the RLS patch on top of the new
>>>
to limit or stop autovacuum's work
on some big tables, while pushing its activity even higher for small,
high churn tables.
If you stop autovacuum on a message-queue system when load gets high,
you'll get a giant messy bloat explosion.
--
Craig Ringer http://
is job; it's
good at dealing with recursion problems already. That won't work so long
as security barrier qual expansion happens during planning, not rewrite,
though - and we've already explored the fun problems with doing upd.
s.b. qual expansion in rewrite.
--
.
>
>
> [Problem]
> The customer is using 64-bit PostgreSQL 9.1.x
Which "x"?
Does this issue also occur on 9.3.2, or in 9.4 HEAD, when tested on Win2k12?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
o away" land.
BTW, the JSSE docs also claim that "TLS 1.0 is a modest upgrade to the
most recent version of SSL, version 3.0. The differences between SSL 3.0
and TLS 1.0 are minor".
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
plement?
> Does anyone know if this has been done before with Postgres? I would
> have assumed yes, but I'm not finding anything in Google about people
> having done this.
AFAIK (and I don't know much in this area) the storage manager isn't
very pluggable compared to
d people that are have
> special measures in place for their apps. We won't lose much by
> accepting that restriction for 9.4 and re-addressing the issue in a
> later release.
Yep, I'd be happy with that.
--
Craig Ringer http://www.2ndQuadrant.com/
Postgre
tance wouldn't get detected by rewriter based checking.
The original RLS patch only detects direct recursion, btw, it looks like
it won't catch mutual recursion.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & S
f the flag fields on RangeTblEntry into a
bitfield.
Comments?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
can
point and say "I'm not crazy, we already do it here". Will follow up
with a patch.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On 01/28/2014 04:39 PM, Craig Ringer wrote:
> I'm looking for where I found the code that already does this so I can
> point and say "I'm not crazy, we already do it here". Will follow up
> with a patch.
I spoke to soon. The code I'm talking about is
expand_inher
worry here is that a fair bit of work gets done before inheritance
expansion. Partitioning already performs pretty poorly for anything but
small numbers of partitions.
If we're expanding inheritance in the rewriter, won't that further
increase the already large amount of duplicate work inv
inheritance, but
frankly, there's not much about inheritance that _is_ good taste. I
don't see that this patch makes it worse, and it's functional.
It might be interesting to revisit some of these broader questions in
9.5, but what can we do to get this functionality in place for 9.
On 01/28/2014 02:11 PM, Craig Ringer wrote:
>> > My first thought is to add a boolean flag to RangeTblEntry (similar to
>> > the "inh" flag) to say whether RLS expansion is requested for that
>> > RTE. Then set it to false on each RTE as you add new RLS quals
On 01/29/2014 09:47 PM, Craig Ringer wrote:
> https://github.com/ringerc/postgres/compare/rls-9.4-upd-sb-views
>
> i.e. https://github.com/ringerc/postgres.git ,
> branch rls-9.4-upd-sb-views
>
> (subject to rebasing) or the non-rebased tag rls-9.4-upd-sb-views-v2
Pushe
bination of inheritance and
row-security for 9.4. That won't upset updatable security barrier
views, only actual row-security policy. People who want row-security
over partitioned tables will just have to be patient.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQ
On 01/30/2014 01:25 PM, Craig Ringer wrote:
> On 01/29/2014 09:47 PM, Craig Ringer wrote:
>> https://github.com/ringerc/postgres/compare/rls-9.4-upd-sb-views
>>
>> i.e. https://github.com/ringerc/postgres.git ,
>> branch rls-9.4-upd-sb-views
>>
>> (subj
x27;d be no way
to see rows via the parent that you can't see via the child.
>> 4. attempt to pull quals from parents when querying a child rel
>> directly.
>
> That strikes me as borderline insane. ;)
I'm glad to hear it, because it'd be inefficient and horrify
On 01/31/2014 01:18 AM, Robert Haas wrote:
> On Thu, Jan 30, 2014 at 2:39 AM, Craig Ringer wrote:
>> Earlier discussions seemed to settle on each relation having its own
>> row-security quals applied independently. So quals on a parent rel did
>> not cascade down to child rel
barrier views (and views in general)
work, and it means that the policy on a relation is applied consistently
to all rows, including rows from child relations. As we discussed, it's
also consistent with relation-level GRANTs for access to relations. The
trade-off is that it creates inco
On 01/31/2014 02:50 AM, Pavel Stehule wrote:
>
> 5. I didn't test it on windows
I guess that's my cue. I'll be home later today, and will take a look at
it on my Windows test setup.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 2
asing updated installers
that set IFEO flags to disable ASLR on postgres.exe .
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Nonetheless, your fix seems a lot cleaner, especially in the target-view
case.
I've updated the commitfest app to show this patch.
> Anyway, please test if this works with your RLS code.
It does. Thankyou.
I'm still working on the other issues I outlined yesterday, but that's
for the
a new child context is created
at every call, so every MemoryContextResetChildren call has to deal with
more child contexts. I'm going to take a quick look now, I just wanted
to get this written up before I got sidetracked.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x
me places on the MSVC
build, so far it's looking like we auto-export functions, but not
necessarily variables. I'd need to read the fairly scary MSVC build
genreator scripts in detail to confirm that, to see how they produce
their DEF files; that'll have to wait until after I'v
On 02/03/2014 09:09 AM, Craig Ringer wrote:
> At a guess, we're looking at a case where a new child context is created
> at every call, so every MemoryContextResetChildren call has to deal with
> more child contexts.
That would be "yes". After a short run
On 02/03/2014 11:10 AM, Ashesh Vashi wrote:
> On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer <mailto:cr...@2ndquadrant.com>> wrote:
>
> On 02/02/2014 09:03 AM, Tom Lane wrote:
> > According to the buildfarm database, narwhal is running a gcc build on
> &
On 02/01/2014 05:28 AM, Bruce Momjian wrote:
> On Fri, Aug 2, 2013 at 04:00:03PM +0800, Craig Ringer wrote:
>> FOR SHARE|UPDATE NOWAIT will still block if they have to follow a ctid
>> chain because the call to EvalPlanQualFetch doesn't take a param for
>> noWait, so it
On 02/03/2014 06:37 PM, Andres Freund wrote:
> On 2014-02-03 12:00:40 +0800, Craig Ringer wrote:
>> I think it's a good thing personally - we shouldn't be exporting every
>> little internal var in the symbol table.
>>
>> If we built with -fvisibility
ting this flag is appropriate, at least while Pg
relies on having the shared memory segment mapped in the same zone in
every executable. Just pointing out that there's a workaround in the
mean time.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development,
xpansion, _is_ expanded. At least, if it proves
necessary, which I'm not entirely convinced of.
> I suggested it as a solution for a requirement worded upthread as "It
> makes absolutely zero sense, in my head anyway, to have rows returned
> when querying the parent which sh
On 01/30/2014 04:05 PM, Craig Ringer wrote:
> On 01/30/2014 01:25 PM, Craig Ringer wrote:
>> On 01/29/2014 09:47 PM, Craig Ringer wrote:
>>> https://github.com/ringerc/postgres/compare/rls-9.4-upd-sb-views
>>>
>>> i.e. https://github.com/ringerc/postgres.git ,
On 02/04/2014 03:14 PM, Tom Lane wrote:
> Craig Ringer writes:
>> I landed up adding a field to RangeTblEntry that keeps track of all the
>> oids of relations row-security expanded to produce this RTE. When
>> testing an RTE for row-security policy, this list is checked to
roblem.
>
> I added this patch to the CommitFest.
It's really a bugfix suitable for backpatching IMO.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-h
ances rapidly becomes
problematic.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
h and have it automatically build
and "make check" on Windows. I've got that running for internal use, but
it's on a host I can't share access to (and an unreliable one, at that).
I'd be happy to share the setup for the Jenkins instance and the Windows
integration p
w up post-CF4.
I'm kind of horrified that the dynamic linker doesn't throw its toys
when it sees this.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
ostgresql.org/wiki/Building_With_MinGW> which is either
> free or very cheap. Do I need to give instructions on how to do this for
> MSVC builds too? It's really not terribly hard.
I've got some guidance on that here:
https://github.com/2ndQuadrant/pg_build_win
fr
On 02/05/2014 01:52 PM, Tom Lane wrote:
> Craig Ringer writes:
>> On 02/05/2014 06:29 AM, Tom Lane wrote:
>>> I had been okay with the manual PGDLLIMPORT-sprinkling approach
>>> (not happy with it, of course, but prepared to tolerate it) as long
>>> as I believ
On 02/06/2014 10:14 AM, Craig Ringer wrote:
> On 02/05/2014 01:52 PM, Tom Lane wrote:
>> Craig Ringer writes:
>>> On 02/05/2014 06:29 AM, Tom Lane wrote:
>>>> I had been okay with the manual PGDLLIMPORT-sprinkling approach
>>>> (not happy with it, of co
On 02/04/2014 02:43 PM, Craig Ringer wrote:
> On 01/30/2014 04:05 PM, Craig Ringer wrote:
>> On 01/30/2014 01:25 PM, Craig Ringer wrote:
>>> On 01/29/2014 09:47 PM, Craig Ringer wrote:
>>>> https://github.com/ringerc/postgres/compare/rls-9.4-upd-sb-views
>>>
On 02/06/2014 04:54 PM, Yeb Havinga wrote:
> On 2014-02-06 05:43, Craig Ringer wrote:
>> Based on Tom's objections, another approach is presented in
>> rls-9.4-upd-sb-views-v5 on g...@github.com:ringerc/postgres.git . The
>> Query node is used to record the recur
On 02/06/2014 12:43 PM, Craig Ringer wrote:
> 1. Try (again) to do row-security in the rewriter. This was previously
> impossible because of the definition of row-security behaviour around
> inheritance, but with the simplified inheritance model now proposed I
> think it's possibl
On 02/06/2014 10:19 PM, Craig Ringer wrote:
> On 02/06/2014 12:43 PM, Craig Ringer wrote:
>> 1. Try (again) to do row-security in the rewriter. This was previously
>> impossible because of the definition of row-security behaviour around
>> inheritance, but with the simplified
On 02/06/2014 11:11 PM, Tom Lane wrote:
> Craig Ringer writes:
>> We don't rerun rewrite on plan invalidation.
>
> Don't we? plancache.c certainly does, in fact it starts from the raw
> grammar output. Skipping the rewriter would mean failing to respond
> to CREA
On 02/05/2014 01:52 PM, Tom Lane wrote:
> Craig Ringer writes:
>> On 02/05/2014 06:29 AM, Tom Lane wrote:
>>> I had been okay with the manual PGDLLIMPORT-sprinkling approach
>>> (not happy with it, of course, but prepared to tolerate it) as long
>>> as I believ
On 02/10/2014 01:59 PM, Amit Kapila wrote:
> On Mon, Feb 10, 2014 at 8:51 AM, Craig Ringer wrote:
>> On 02/05/2014 01:52 PM, Tom Lane wrote:
>>> Craig Ringer writes:
>>>> On 02/05/2014 06:29 AM, Tom Lane wrote:
>>>>> I had been okay with the manu
ather than sending text when the binary
is requested, we just require clients to use text for this type.
That way it's possible to add the desired binary format later, without
rushed decisions.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
On 02/11/2014 01:28 PM, Tom Lane wrote:
> If there are no objections, I'll push this patch into HEAD tomorrow,
> along with the upthread patches from Craig Ringer and Marco Atzeri.
> We might as well see if this stuff is going to work ...
I'd love to test my patch properly bef
On 02/06/2014 10:19 PM, Craig Ringer wrote:
> On 02/06/2014 12:43 PM, Craig Ringer wrote:
>> 1. Try (again) to do row-security in the rewriter. This was previously
>> impossible because of the definition of row-security behaviour around
>> inheritance, but with the simplified
On 02/11/2014 06:05 PM, Yeb Havinga wrote:
> On 2014-02-11 09:36, Craig Ringer wrote:
>> On 02/06/2014 10:19 PM, Craig Ringer wrote:
>>> On 02/06/2014 12:43 PM, Craig Ringer wrote:
>>>> 1. Try (again) to do row-security in the rewriter. This was previously
>>>
On 02/11/2014 08:19 PM, Yeb Havinga wrote:
> On 2014-02-11 12:09, Craig Ringer wrote:
>> rls-9.4-upd-sb-views-v7
>>
> Hi Craig,
>
> I compared output of psql -ef of the minirim.sql script posted earlier
> in http://www.postgresql.org/message-id/52f54927.1040...@gm
side note, I'm starting to suspect - and need to verify - that as
a result of not using PGDLLIMPORT on exported functions we're actually
doing old-style thunk function calls from extensions into postgres.exe,
not direct function calls, for a similar reason.)
I'm going to go wash my
On 02/11/2014 11:04 PM, Amit Kapila wrote:
> On Tue, Feb 11, 2014 at 11:01 AM, Craig Ringer wrote:
>> On 02/11/2014 01:28 PM, Tom Lane wrote:
>>> If there are no objections, I'll push this patch into HEAD tomorrow,
>>> along with the upthread patches from Craig
except for by dynamic linkage).
I don't see any use for that with plperl, but it might be a valid thing
to be doing for (e.g.) hstore.dll. Though you can't really link to it
from another module anyway, you have to go through the fmgr to get
access to its symbols at rutime, so we can probabl
On 02/12/2014 08:30 AM, Tom Lane wrote:
> Craig Ringer writes:
>> On 02/12/2014 07:22 AM, Tom Lane wrote:
>>> So the early returns from currawong are interesting:
>
>> Great, that's what I was hoping to see - proper errors where we've
>> omitted t
On 02/12/2014 09:45 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 02/11/2014 08:04 PM, Craig Ringer wrote:
>>> Looks like currawong doesn't build postgres_fdw.
>
>> It sure used to:
>> <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=curraw
he Python package maintainers to see
if they can fix that and bundle the .lib ?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
ot totally unfair to compare the level of weirdness of Cygwin to
that of WINE, though they operate in completely different ways. I
wouldn't suggest making any conclusions about the _other_ platforms
based on Cygwin.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL
On 02/13/2014 05:23 AM, Peter Eisentraut wrote:
> On 2/11/14, 7:04 PM, Craig Ringer wrote:
>> I don't see any use for that with plperl, but it might be a valid thing
>> to be doing for (e.g.) hstore.dll. Though you can't really link to it
>> from another module any
y it looks like there's not going to be any getting around
having something that can turn into __declspec(dllimport) in the headers
for compiling things that link to postgres.exe, though.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, T
hough we're generating .DEF files, I don't think we can avoid
that, because we at minimum need to have the hstore exported symbols
*not* annotated __declspec(dllimport) when compiling hstore, but have
them so annotated when importing the header into anything else.
(Come to think of it,
This is the normal way it's done on Windows builds, not stuff I'm
looking into and saying how _I_ think we should do it. AFAIK this is
just how it's done on Windows, horrible as that is. I'll see if I can
find a couple of relevant links.
BTW, BUILDING_DLL is so-
tmasterMain (argc=argc@entry=4,
> argv=argv@entry=0x10a8750) at postmaster.c:1235
> #25 0x005d692c in main (argc=4, argv=0x10a8750) at main.c:205
> (gdb)
It's crashing while pulling up the query over "emp" (hl7.employee) and
"part" (hl7.participation).
On 02/13/2014 02:42 PM, Marco Atzeri wrote:
> My personal experience is that a UNIX-vanilla source build 99% right
> on recent cygwin.
Yeah, I freely admit my experience with _recent_ cygwin is not abundant.
Things may well have improved.
--
Craig Ringer http
#x27;re then defined in a single module, that's not
the case.
Only if they're *not* declared extern, and thus added to each
compilation unit then de-duplicated during linking, may they be safely
referred to without a __declspec(dllimport) because each module gets its
own copy.
--
This is fascinating - I spent some time chasing the same symptoms in my
Jenkins build slave, and eventually tracked it down to path lengths. gcc
was just hanging uninterruptibly in a win32 syscall, and nothing short
of a reboot would deal with it.
--
Craig Ringer http://www.2nd
(Top post, on phone)
The @number part is optional. It indicates an export ordinal. (You don't want
to know, if you do, see MSDN).
If you remove them or change them then binaries linked to the older version
will fail to link to the newer; it breaks binary compat. The ordinals are part
of the li
run is attached. I don't expect to have a chance to dig
into this right away, as I haven't touched the regexp code before and
would need to spend a bit of time studying it to achieve anything.
Hopefully the test, confirmation, and profile is useful.
--
Craig Ringer http:
On 02/22/2014 12:04 AM, Florian Pflug wrote:
> On Feb21, 2014, at 16:46 , Craig Ringer wrote:
>> The real question IMO is why it's taking so long. It looks like
>> cfindloop(...) is being called multiple times, with each call taking a
>> couple of seconds.
>
>
2617 DIGEST-MD5 authentication method used in SASL, or
even CRAM-MD5 (RFC 2195). Both of which are imperfect, but at least not
trivially replayable.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
outine to prompt the user to decrypt a client
certificate. With PgJDBC you use JSSE's keystore support.
Client certificates are a *much* stronger way to do this. Another good
option can be Kerberos. Either way, encrypting .pgpass seems utterly
pointless.
--
Craig Ringer h
atch from Merlin, then. It will need to be clear enough
>> that an ordinary user can distinguish which type they want.
>
> Sure.
Please also highlight that any change will require a full table rewrite
with an exclusive lock, so data type choices on larger tables may be
hard to cha
would improve.
It's also make it a lot harder to use in other extensions, something
that's already an issue with hstore.
It should be a core type.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via
ng work_mem for those
> is dangerous.
Good point. Especially with pagination involved. Those OFFSET 40000
LIMIT 100 queries can be a killer.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailin
; supporting.
Urgh, really?
That's not something I'd be excited to be stuck with into the future.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On 02/25/2014 01:28 AM, Dean Rasheed wrote:
> On 13 February 2014 04:12, Craig Ringer wrote:
>>
>> It's crashing while pulling up the query over "emp" (hl7.employee) and
>> "part" (hl7.participation).
>>
>> Given the simplicity of what th
On 03/04/2014 09:41 PM, Yeb Havinga wrote:
> On 04/03/14 02:36, Craig Ringer wrote:
>>
>> I've pushed an update to the branch with the fix for varno handling.
>> Thanks. It's tagged rls-9.4-upd-sb-views-v8 .
>>
>> I've almost run out of time
and pass that down into all the rewriter internal
functions, then return the outer query wrapped in it.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
adness: A DML statement that affects *a different set of
rows* depending on whether or not it has a RETURNING clause.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
but it's possible to do
it with much saner semantics there. And with row security, it'll be
possible with security definer functions. I intend to add a "row
security exempt" flag for functions down the track, too.
--
Craig Ringer http://www.2ndQua
On 03/06/2014 02:58 AM, Tom Lane wrote:
> Craig Ringer writes:
>> One of the remaining issues with row security is how to pass plan
>> invalidation information generated in the rewriter back into the planner.
>
>> With row security, it's necessary to set a field in P
On 03/05/2014 11:02 AM, Craig Ringer wrote:
> The main known issue remaining is plan invalidation.
I've pushed a version with a plan invalidation implementation. It's tagged:
rls-9.4-upd-sb-views-v9
in
g...@github.com:ringerc/postgres.git
The invalidation implementation
On 03/07/2014 09:33 PM, Craig Ringer wrote:
> On 03/05/2014 11:02 AM, Craig Ringer wrote:
>> The main known issue remaining is plan invalidation.
>
> I've pushed a version with a plan invalidation implementation. It's tagged:
>
> rls-9.4-upd-sb-views-v9
>
&
On 03/07/2014 10:07 PM, Craig Ringer wrote:
> On 03/07/2014 09:33 PM, Craig Ringer wrote:
>> On 03/05/2014 11:02 AM, Craig Ringer wrote:
>>> The main known issue remaining is plan invalidation.
>>
>> I've pushed a version with a plan invalidation implementation.
#x27;m not too sure what the best way to do that is. Time permitting I'll
see if I can work out the RowMark code and set something up.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hac
On 03/08/2014 01:56 AM, Tom Lane wrote:
> Craig Ringer writes:
>> What I'm concerned about is the locking. It looks to me like we're
>> causing the user to lock rows that they may not intend to lock, by
>> applying a LockRows step *before* the user supplied q
ions? Is this something that's even worth thinking about further or
a non-starter?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
unbounded in time. Autovacuum does not remove dead tuples and neither do
> the manual vacuum. We are running PostgreSQL 9.2.4 on Linux 2.6.18 x86_64.
>
> Nobody's holding an open transaction for long periods.
Got any prepared transactions?
SELECT * FROM pg_prepared_xacts;
SHOW max_prepared_
s" though.
Why extend the create table / alter table syntax with "USE_SCHEMA"? Is
there a compatibility/standards reason to do this? If not, what
advantage does this provide over using a suitable CHECK constraint?
IIRC there were some memory management issues with li
you're planning on relying on libxml in core (and it'll have to
be in core if you're adding new syntax) then you'll need a solid, well
researched answer to that one or an alternative XML library that's
portable and doesn't have those issues.
--
Craig Ringer
tured messages would be saner, but of
course most clients would not then display it so the user would never
know it was there, much the same way few people seem to realise you can
get the function, source file and line from error messages already.
After all, how many people do you think run with V
On 08/10/2013 02:43 AM, Stephen Frost wrote:
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
>> More seriously, with interpolated strings for relation names etc
>> it can be hard to know which chunks to search for, and search
>> engines aren't always good at having t
handles multiple
spec-compliance items. I'll grab the patch and try it out.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
having issues upgrading
due to the 8.3 removal of implicit casts from text, and even the removal
of add_missing_from .
If we want people to upgrade this century it's worth minimising the
amount of unnecessary breakage. SRF-in-SELECT might be ugly, but simply
ripping it out certainly coun
ckup so it was easier for people to
use ad-hoc and without all the shell access wrangling.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
On 08/26/2013 08:15 PM, Hannu Krosing wrote:
> On 08/26/2013 12:50 PM, Antonin Houska wrote:
>> > On 08/22/2013 03:33 PM, Craig Ringer wrote:
>>> >> On 08/22/2013 01:39 PM, PostgreSQL - Hans-Jürgen Schönig wrote:
>>> >>
>>>> >>> wha
est does not overlap with the current patch.
I totally agree; I was getting off topic for this thread, and it's not
relevant to the patch as it stands.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via
801 - 900 of 2076 matches
Mail list logo
