On Mon, Aug 19, 2013 at 9:33 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>>> Amit Kapila escribió:
1>.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101:
'isnull' : unreferenced local variable
>
>> The macro is pretty gcc-specific, isn't it?
>
> If that's the problem, why i
> From: 'Bruce Momjian' [mailto:br...@momjian.us]
> On Tue, Aug 13, 2013 at 05:59:05PM +0900, Etsuro Fujita wrote:
> > > Thanks for the many suggestions on improving the 9.3 release notes.
> > > There were many ideas I would have never thought of. Please keep
> > > the
> > suggestions
> > > comin
Andrew Dunstan writes:
>> Amit Kapila escribió:
>>> 1>.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101:
>>> 'isnull' : unreferenced local variable
> The macro is pretty gcc-specific, isn't it?
If that's the problem, why isn't Amit seeing a boatload of similar
warnings elsewhere?
Andrew Dunstan escribió:
>
> On 08/18/2013 05:08 PM, Alvaro Herrera wrote:
> >Amit Kapila escribió:
> >>1>.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101:
> >>'isnull' : unreferenced local variable
> >>
> >>It seems this variable is used only under macro USE_ASSERT_CHECKING,
> >>so
On 08/18/2013 10:20 PM, Dimitri Fontaine wrote:
> Hi,
>
> I had the chance to being at OSCON this year and had a chat with the
> Open Shift team while there. Thanks for posting your use case!
>
> Tom Lane writes:
>> Right offhand, it seems like you have or could grant a developer
>> superuser/DBA
On 08/18/2013 05:08 PM, Alvaro Herrera wrote:
Amit Kapila escribió:
1>.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101:
'isnull' : unreferenced local variable
It seems this variable is used only under macro USE_ASSERT_CHECKING,
so it is better to declare under this macro only.
Kevin Grittner wrote:
> Noah Misch wrote:
>> Also, could you explain the use of RelationCacheInvalidateEntry()
>> in ExecRefreshMatView()? CacheInvalidateRelcacheByRelid()
>> followed by CommandCounterIncrement() is the typical pattern;
>> this is novel. I suspect, though, neither is necessary
Amit Kapila escribió:
> 1>.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101:
> 'isnull' : unreferenced local variable
>
> It seems this variable is used only under macro USE_ASSERT_CHECKING,
> so it is better to declare under this macro only.
We have a macro for this, PG_USED_FOR_AS
Hi,
I had the chance to being at OSCON this year and had a chat with the
Open Shift team while there. Thanks for posting your use case!
Tom Lane writes:
> Right offhand, it seems like you have or could grant a developer
> superuser/DBA privileges with respect to his own PG instance, so I'm not
>
On 08/17/2013 01:16 AM, Noah Misch wrote:
On Fri, Aug 16, 2013 at 06:56:45PM -0500, Michael Cronenworth wrote:
I started a thread on the general list so read that for more info.
http://www.postgresql.org/message-id/520a6e55.40...@cchtml.com
I'm also going to submit the patch to CommitFest.
+#
On 08/18/2013 05:40 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> While working on upgrading the database of the search system on
>> postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
>> that system are actually invalid and cannot be reloaded without being
>> hacked o
On 18.8.2013 17:54, Tom Lane wrote:
>
> TBH this seems like way too much cruft to be added in support of what
> are after all *unsupported* releases. And how far back do we stop,
> anyway?
>
> I'd suggest you test all the branches with the newest pgbench
> version that happens to work with the o
Steven Citron-Pousty writes:
> What we need is the ability for Postgresql to load extensions from a
> users file space.
TBH this needs a whole lot of thought. I'm prepared to grant that there
may be other useful security models besides the one we currently have,
but we need to be sure that anyth
Tomas Vondra writes:
> I do understand the versions up to 8.3 are unsupported (or soon will
> be), but I think it's handy to be able to run current pgbench on those
> versions. So I propose to:
> (a) add --no-fillfactor that actually disables adding it to the
> CREATE TABLE (now it adds d
Stefan Kaltenbrunner writes:
> While working on upgrading the database of the search system on
> postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
> that system are actually invalid and cannot be reloaded without being
> hacked on manually...
> CREATE TEXT SEARCH CONFIGURAT
Hi,
I'm running some tests comparing benchmarks on a range of versions,
going back to 8.0 (mostly because of curiosity, but actually for
practical reasons too).
I've decided to use the pgbench from 9.3, mostly to make the results
more comparable and because of features not available in older rele
Hello
is any specific reason why permissions are checked in top lo_* API and not
in inv_* API?
I am trying to write extension for bytea <-> LO conversions, but It is not
possible without code duplication due placing a permission check in top API.
Regards
Pavel
On 08/18/2013 11:36 AM, Hannu Krosing wrote:
> On 08/17/2013 11:53 PM, Steven Citron-Pousty wrote:
>> Greetings all:
>> I spoke to Josh B and company at OSCON about a feature we really need
>> for PostgreSQL extensions on OpenShift (Red Hat's Platform as a
>> Service).
>>
>> What we need is the ab
Hi all!
While working on upgrading the database of the search system on
postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
that system are actually invalid and cannot be reloaded without being
hacked on manually...
Simple way to reproduce is using the following:
CREATE T
On 08/17/2013 11:53 PM, Steven Citron-Pousty wrote:
> Greetings all:
> I spoke to Josh B and company at OSCON about a feature we really need
> for PostgreSQL extensions on OpenShift (Red Hat's Platform as a
> Service).
>
> What we need is the ability for Postgresql to load extensions from a
> user
[ Could you please trim your citations, i.e., please don’t top-post:
https://en.wikipedia.org/wiki/Posting_style#Top-posting ]
2013/8/16 Francesco :
> Thanks for your answer.
> Yes, the client is also UTF8:
>
> MyDB=# show
> client_encoding;
> client_encoding
> -
> UTF8
> (1 row)
True. I think the gripe here is that pg_sleep('42') has worked for
many releases now,
Maybe it could still work if pg_sleep(TEXT) is added as well?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
22 matches
Mail list logo
