Hi,
I found error on #define stat _stat64 occurs on Mingw-w64 (x86_64-w64-mingw32)
gcc version 4.7.0 20111203 (experimental) (GCC)
The code can be compiled with
diff --git a/src/include/port.h b/src/include/port.h
index eceb4bf..78d5c92 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@
On Sun, Dec 4, 2011 at 09:14, NISHIYAMA Tomoaki
wrote:
> Hi,
>
> I found error on #define stat _stat64 occurs on Mingw-w64 (x86_64-w64-mingw32)
> gcc version 4.7.0 20111203 (experimental) (GCC)
>
> The code can be compiled with
>
> diff --git a/src/include/port.h b/src/include/port.h
> index eceb4
On 4.12.2011 05:19, Tom Lane wrote:
> Tomas Vondra writes:
>> That might explain why it fails at first and then works just fine,
>> although it's a bit strange. Wouldn't that mean you can't access any
>> catalogs from the auth hook?
>
> It should be possible to access shared catalogs from an auth
On Sat, Sep 24, 2011 at 9:09 PM, Marti Raudsepp wrote:
> Hi list!
>
> This is the third version of my CacheExpr patch.
i wanted to try this, but it no longer applies in head... specially
because of the change of IF's for a switch in
src/backend/optimizer/util/clauses.c it also needs adjustment fo
Tomas Vondra writes:
> On 4.12.2011 05:19, Tom Lane wrote:
>> It should be possible to access shared catalogs from an auth hook.
>> pg_stat_activity is neither shared nor a catalog. Like Robert,
>> I find it astonishing that this works ever, because the info needed
>> simply isn't available until
On 12/04/2011 06:31 AM, Magnus Hagander wrote:
On Sun, Dec 4, 2011 at 09:14, NISHIYAMA Tomoaki
wrote:
Hi,
I found error on #define stat _stat64 occurs on Mingw-w64 (x86_64-w64-mingw32)
gcc version 4.7.0 20111203 (experimental) (GCC)
The code can be compiled with
diff --git a/src/include/p
On Sun, Dec 4, 2011 at 17:12, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Sun, Dec 4, 2011 at 00:43, Bruce Momjian wrote:
>> > Do we have any documentation about how to move a tablespace to a new
>> > directory? ?If not, I think we should write some.
>>
>> Do we have any support for doing
Andres Freund writes:
> I have two questions now:
> First, does anybody think it would be worth getting rid of the duplication
> from OpenIntoRel (formerly from execMain.c) in regard to DefineRelation()?
That's probably reasonable to do, since as you say it would remove the
opportunity for bugs
Magnus Hagander writes:
> And IIRC, we don't actually *use* spclocation anywhere.
Just for pg_dump, I think.
> How about we
> just get rid of them as independents? We could either:
> 1) Remove the column. Rely on the symlink. Create a
> pg_get_tablespace_location(oid) function, that could be us
On Sun, Dec 4, 2011 at 17:41, Tom Lane wrote:
> Magnus Hagander writes:
>> And IIRC, we don't actually *use* spclocation anywhere.
>
> Just for pg_dump, I think.
pg_dumpall :-)
It's also used in pg_upgrade and pg_basebackup, but those are easily
dealt with if we define a function for it.
>> H
On 11/28/2011 09:19 PM, Josh Kupershmidt wrote:
Other than those small gripes, the patch looks fine. Attached is an
updated version to save you some keystrokes.
Thanks. Committed.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On 12/04/2011 11:41 AM, Tom Lane wrote:
1) Remove the column. Rely on the symlink. Create a
pg_get_tablespace_location(oid) function, that could be used by
pg_dumpall and friends, that just reads the symlink.
Hm, how portable is symlink-reading? If we can actually do that
without big headac
Andrew Dunstan writes:
> On 12/04/2011 11:41 AM, Tom Lane wrote:
>> Hm, how portable is symlink-reading? If we can actually do that
>> without big headaches, then +1.
> I wondered that, specifically about Windows junction points, but we seem
> to have support for it already in dirmod.c::pgreadl
On 11/29/2011 04:32 PM, Brar Piening wrote:
Andrew Dunstan wrote:
Some minor nitpicks:
Do we really need to create all those VSProject.pm and
VSSolution.pm files? They are all always included anyway. Why not
just stash all the packages in Solution.pm and Project.pm?
We certainly
On Thu, Nov 17, 2011 at 09:50, Dimitri Fontaine wrote:
> Tom Lane writes:
>> What you've got here could be useful
>> to people who use emacs and understand they've got to hand-check the
>> results. I'm not sure how much further it'd be useful to go.
>
> Agreed. That's the reason why I'm proposin
Robert Haas writes:
> OK, so I tried to code this up. Adding the new amproc wasn't too
> difficult (see attached). It wasn't obvious to me how to tie it into
> the tuplesort infrastructure, though, so instead of wasting time
> guessing what a sensible approach might be I'm going to use one of my
Magnus Hagander writes:
>> I can also maintain that in a separate git repository on github, but
>> that only reduces the already very thin population that could find it
>> useful.
>
> Since people seem to be less than super-enthusiastic about putting
> into the core distro, perhaps it would at lea
Pavel Stehule writes:
> #3 0x083a1dfe in ExceptionalCondition (conditionName=0x8505474
> "!(innerstartsel <= innerendsel)", errorType=0x83db178
> "FailedAssertion", fileName=0x8505140 "costsize.c", lineNumber=1937)
> at assert.c:57
[ scratches head ... ] Given that it got past the previous asse
On 25.09.2011 05:09, Marti Raudsepp wrote:
This is the third version of my CacheExpr patch.
This seems to have bitrotted, thanks to the recent refactoring in
eval_const_expressions().
For explanation about design decisions, please read these earlier messages:
http://archives.postgresql.org/
On 4.12.2011 17:10, Tom Lane wrote:
> Tomas Vondra writes:
>> Anyway, the code I posted does not fail because of pg_stat_activity, it
>> fails because it attempts for find the dbname/username for the backends
>> (read from pg_stat_activity).
>
> Well, get_database_name tries to do a syscache look
Tomas Vondra writes:
> On 3.12.2011 18:53, Tom Lane wrote:
>> Security: it lets the DBA constrain which libraries are loadable this way.
> But local_preload_libraries can be set only in postgresql.conf, right?
No. It's PGC_BACKEND, which means it can be set at connection start by
a client (eg,
Tomas Vondra writes:
> What about the pg_stat_activity - is it safe to access that from auth
> hook or is that just a coincidence that it works (and might stop working
> in the future)?
It doesn't seem like a good thing to rely on. There's certainly no
testing being done that would cause us to n
2011/12/4 Tom Lane :
> Pavel Stehule writes:
>> #3 0x083a1dfe in ExceptionalCondition (conditionName=0x8505474
>> "!(innerstartsel <= innerendsel)", errorType=0x83db178
>> "FailedAssertion", fileName=0x8505140 "costsize.c", lineNumber=1937)
>> at assert.c:57
>
> [ scratches head ... ] Given that
On 4.12.2011 22:16, Tom Lane wrote:
> Tomas Vondra writes:
>> On 3.12.2011 18:53, Tom Lane wrote:
>>> Security: it lets the DBA constrain which libraries are loadable this way.
>
>> But local_preload_libraries can be set only in postgresql.conf, right?
>
> No. It's PGC_BACKEND, which means it c
On 11/24/2011 06:33 PM, Theo Schlossnagle wrote:
> I see the next steps being:
> 1) agreeing that a problem exists (I know one does, but I suppose
> consensus is req'd)
+1, high volume logging is also a huge problem here at Skype. Some of
the issues that immediately come to mind:
- extracting us
Pavel Stehule writes:
> 2011/12/4 Tom Lane :
>> [ scratches head ... ] Given that it got past the previous assertions,
>> surely that ought to be impossible. Could we see the values of
>> cost_mergejoin's local variables, please?
> It is strange
> when I put a fprintf(stderr, "const literal")
2011/12/4 Tom Lane :
> Pavel Stehule writes:
>> 2011/12/4 Tom Lane :
>>> [ scratches head ... ] Given that it got past the previous assertions,
>>> surely that ought to be impossible. Could we see the values of
>>> cost_mergejoin's local variables, please?
>
>> It is strange
>
>> when I put a fp
Pavel Stehule writes:
> it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was
> configured just with --enable-debug and --enable-cassert
Is this x86? I can't reproduce it on x86_64.
It's fairly easy to get a set of values such that innerstartsel *should*
equal innerendsel; but if on
Tomas Vondra writes:
> On 4.12.2011 22:16, Tom Lane wrote:
>> Um ... why would you design it like that?
> The backends are added to pg_stat_activity after the auth hook finishes,
> which means possible race conditions (backends executed at about the
> same time don't see each other in pg_stat_act
On 4 December 2011 19:17, Tom Lane wrote:
> I have not done any performance testing on this patch, but it might be
> interesting to check it with the same test cases Peter's been using.
I've attached a revision of exactly the same benchmark run to get the
results in results_server.ods .
You'll s
On 5.12.2011 00:06, Tom Lane wrote:
> Tomas Vondra writes:
>> On 4.12.2011 22:16, Tom Lane wrote:
>>> Um ... why would you design it like that?
>
>> The backends are added to pg_stat_activity after the auth hook finishes,
>> which means possible race conditions (backends executed at about the
>>
On Thu, Nov 24, 2011 at 10:54:50AM -0500, Robert Haas wrote:
> All right, here's an updated patch, and a couple of follow-on patches.
Your committed patch looks great overall. A few cosmetic points:
> --- a/src/backend/catalog/namespace.c
> +++ b/src/backend/catalog/namespace.c
> @@ -309,6 +313
32 matches
Mail list logo
