I ran into a typo in the reference page on the SELECT command. Please find
attached a patch.
Best regards,
Etsuro Fujita
typo_fix_20130312.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
Hi all,
When running some QE tests at VMware, we found an error with extract
handling timezones.
Please see below:
postgres=# show timezone;
TimeZone
Asia/Tokyo
(1 row)
postgres=# select now();
now
---
2013-03-12 14:54:28.911298+09
(1 row)
> From: gsst...@gmail.com [mailto:gsst...@gmail.com] On Behalf Of Greg
> Stark
> Sent: Tuesday, March 12, 2013 12:50 AM
> To: Greg Smith
> Cc: Amit Kapila; Andres Freund; Boszormenyi Zoltan; pgsql-
> hack...@postgresql.org
> Subject: Re: Re: Proposal for Allow postgresql.conf values to be
> changed
On Monday, March 11, 2013 11:02 PM Fujii Masao wrote:
> On Mon, Mar 11, 2013 at 4:39 PM, Greg Smith
> wrote:
> > On 3/11/13 2:48 AM, Amit Kapila wrote:
> >>>
> >>> 1) When you change a sighup or user setting, it writes the config
> file
> >>> out. But it does not signal for a reload. Example:
>
Daniel Farina writes:
> I will try to make time for this, although it seems like the general
> approach should match pgsql_fdw if possible. Is the current thinking
> to forward the settings and then use the GUC hooks to track updates?
That's not what I had in mind for postgres_fdw --- rather the
On Mon, 2013-03-11 at 18:11 +0100, Andres Freund wrote:
> If we don't find a better solution, yes. Why don't we lookup type
> input/ouput function for parameters and return type during CREATE
> FUNCTION? That should solve the issue in a neater way?
A function in general has no particular use for
On 03/12/2013 03:19 AM, Greg Stark wrote:
> Think also about the case where someone wants to change multiple
> values together and having just some set and not others would be
> inconsistent.
Yeah, that's a killer. The reload would need to be scheduled for COMMIT
time, it can't be done by `SET PERS
On Mon, Mar 11, 2013 at 12:30 PM, Tom Lane wrote:
> BTW, it strikes me that dblink is probably subject to at least some of
> these same failure modes. I'm not personally volunteering to fix any
> of this in dblink, but maybe someone ought to look into that.
I will try to make time for this, alth
Josh Berkus writes:
>> Having said that, I'd still be inclined to try to set the remote's
>> timezone GUC just so that error messages coming back from the remote
>> don't reflect a randomly different timezone, which was the basic issue
>> in the buildfarm failures we saw yesterday. OTOH, there is
On Mon, Mar 11, 2013 at 7:39 AM, Greg Smith wrote:
> I wasn't complaining that the change isn't instant. I understand that can't
> be done. But I think the signal to reload should be sent. If people
> execute SET PERSISTENT, and it doesn't actually do anything until the server
> is next restar
On Thu, Mar 7, 2013 at 12:51 AM, Jim Nasby wrote:
> Something worth considering on this... I suspect it's possible to use an
> index-only scan to do this, regardless of whether the heap page is all
> visible. The reason is that the newly created index would just use the same
> access methodology a
On 11 March 2013 19:00, Greg Stark wrote:
> On Sun, Mar 10, 2013 at 10:01 PM, Tom Lane wrote:
>> Another thing that would be easy to implement is to say that the new row
>> value is fully determined locally (including defaults if any) and remote
>> defaults have nothing to do with it. But I thin
Greg Stark writes:
> It feels a bit like unpredictable magic to have "DEFAULT" mean one
> thing and omitted columns mean something else.
Agreed. The current code behaves that way, but I think that's
indisputably a bug not behavior we want to keep.
> Perhaps we should have
> an explicit LOCAL DE
On Sun, Mar 10, 2013 at 10:01 PM, Tom Lane wrote:
> Another thing that would be easy to implement is to say that the new row
> value is fully determined locally (including defaults if any) and remote
> defaults have nothing to do with it. But I think that's almost
> certainly a usability fail ---
I wrote:
> Thom Brown writes:
>> Out of curiosity, is there any way to explicitly force a foreign
>> DEFAULT with column-omission?
> That's one of the things that would have to be worked out before
> we could implement anything here. The easy answer would be that DEFAULT
> specifies the local de
> I agree with you if SET PERSISTENT reloads only postgresql.auto.conf.
> But in current conf reload mechanism, other configuration files like
> pg_hba.conf are also reloaded when pg_read_conf() is executed. Probably
> I don't like this behavior. Users might get surprised that the configuration
>
> Having said that, I'd still be inclined to try to set the remote's
> timezone GUC just so that error messages coming back from the remote
> don't reflect a randomly different timezone, which was the basic issue
> in the buildfarm failures we saw yesterday. OTOH, there is no guarantee
> at all t
On Mon, Mar 11, 2013 at 4:39 PM, Greg Smith wrote:
> On 3/11/13 2:48 AM, Amit Kapila wrote:
>>>
>>> 1) When you change a sighup or user setting, it writes the config file
>>> out. But it does not signal for a reload. Example:
>>
>>
>> I think we cannot guarantee even after calling pg_reload_conf
While looking for the cause of Erikjan Rijkers' recent report, my
attention was drawn to this hunk of the matview patch:
diff --git a/src/backend/rewrite/rewriteDefine.c
b/src/backend/rewrite/rewriteDefine.c
index
a1a9808e5d94959218b415ed34c46579c478c177..896326615753f2344b466eb180080174ddeda31d
On 2013-03-11 09:55:34 -0700, Josh Berkus wrote:
> On 03/11/2013 09:50 AM, Andres Freund wrote:
> > DO LANGUAGE plperlu ;
> > SELECT NULL::hstore;
>
> Aha, so that's what you meant!
>
> Yeah, it works if I reference both extensions before the CREATE EXTENSION.
>
> In that case, seems like th
Josh Berkus writes:
>> The remote end has entirely misinterpreted the day vs month fields.
>> Now, to hit this you need to be using a datestyle which will print
>> in an ambiguous format, so the "ISO" and "Postgres" styles are
>> not vulnerable; but "German" and "SQL" are.
> Is the "timezone" GUC
On 03/11/2013 12:30 PM, Fujii Masao wrote:
On Tue, Mar 12, 2013 at 12:43 AM, Andrew Dunstan wrote:
On 03/11/2013 10:43 AM, Andrew Dunstan wrote:
On 03/06/2013 10:55 AM, Kevin Grittner wrote:
Bernd Helmle wrote:
Looking into this issue, it seems the version check in getTables() of
pg_dump
On 03/11/2013 09:50 AM, Andres Freund wrote:
> DO LANGUAGE plperlu ;
> SELECT NULL::hstore;
Aha, so that's what you meant!
Yeah, it works if I reference both extensions before the CREATE EXTENSION.
In that case, seems like that could be added to the extension SQL, no?
--
Josh Berkus
Postgr
On 2013-03-11 09:42:18 -0700, Josh Berkus wrote:
>
> > Your error looks like youre erroring out in plperl not in hstore?
>
> Look again.
> ERROR: could not load library
> "/home/josh/pg93/lib/postgresql/hstore_plperl.so":
> /home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol: PL_
> Your error looks like youre erroring out in plperl not in hstore?
Look again.
Peter, is there any way for you to tackle this issue? I have no idea
how to fix it, myself ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
> The remote end has entirely misinterpreted the day vs month fields.
> Now, to hit this you need to be using a datestyle which will print
> in an ambiguous format, so the "ISO" and "Postgres" styles are
> not vulnerable; but "German" and "SQL" are.
Is the "timezone" GUC a problem, also, for this
On Tue, Mar 12, 2013 at 12:43 AM, Andrew Dunstan wrote:
>
> On 03/11/2013 10:43 AM, Andrew Dunstan wrote:
>>
>>
>> On 03/06/2013 10:55 AM, Kevin Grittner wrote:
>>>
>>> Bernd Helmle wrote:
>>>
Looking into this issue, it seems the version check in getTables() of
pg_dump.c
is wrong.
"Erikjan Rijkers" writes:
> With 9.3devel, I can't seem to join a matview to a view; surely that should
> be allowed?
Fixed, thanks for the report.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On 03/11/2013 10:43 AM, Andrew Dunstan wrote:
On 03/06/2013 10:55 AM, Kevin Grittner wrote:
Bernd Helmle wrote:
Looking into this issue, it seems the version check in getTables()
of pg_dump.c
is wrong. Shouldn't the check be
if (fout->remoteVersion >= 90300)
{
}
since this is where pg_r
On 03/11/2013 09:20 PM, Dmitry Koterov wrote:
> x86_64, PostgreSQL 9.2. is run within an OpenVZ container and
> generates SIGBUS.
> PostgreSQL 9.1 has no such problem.
>
> (OpenVZ is a linux kernel-level virtualization which adds namespaces
> for processes, networking, quotas etc. It works not like
On 03/06/2013 10:55 AM, Kevin Grittner wrote:
Bernd Helmle wrote:
Looking into this issue, it seems the version check in getTables() of pg_dump.c
is wrong. Shouldn't the check be
if (fout->remoteVersion >= 90300)
{
}
since this is where pg_relation_is_scannable() is introduced?
Fixed.
Th
Daniel Farina writes:
> On Sun, Mar 10, 2013 at 12:15 PM, Tom Lane wrote:
>> Hmm ... the buildfarm just rubbed my nose in a more immediate issue,
>> which is that postgres_fdw is vulnerable to problems if the remote
>> server is using different GUC settings than it is for things like
>> timezone
x86_64, PostgreSQL 9.2. is run within an OpenVZ container and generates
SIGBUS.
PostgreSQL 9.1 has no such problem.
(OpenVZ is a linux kernel-level virtualization which adds namespaces for
processes, networking, quotas etc. It works not like e.g. Xen or VMWare,
because all containers share the sam
On 3/9/13 11:39 PM, Jonathan Rogers wrote:
In an earlier implementation, I did call "cp --reflink=auto" once per
regular file, preserving the behavior of copydir. On Btrfs, this works
well, though slightly slower due to extra processes. AFAIK, there's no
way to do something equivalent on ZFS with
On 3/11/13 2:48 AM, Amit Kapila wrote:
1) When you change a sighup or user setting, it writes the config file
out. But it does not signal for a reload. Example:
I think we cannot guarantee even after calling pg_reload_conf(), as this is
an
asynchronous function call.
We already once had a dis
35 matches
Mail list logo
