Hello. I found a bug(?) in thsi patch as I considered on another
patch.
In truncate_useless_pathkeys, if query_pathkeys is longer than
pathkeys made from index columns old patch picked up the latter
as IndexPath's pathkeys. But the former is more suitable
according to the context here.
the attche
Hello, As I was reconsidering after your advise, I came up with
an idea of hacking on query tree tranaformation phase in
subquery_planner, not on that of plan generation phase as
before. (And the older patch is totally scrapped:-)
Currently flatten_simple_union_all() flattens 'simple' UNION
'ALL'
Hello
2013/11/21 Peter Eisentraut
> On 11/21/13, 2:09 AM, Pavel Stehule wrote:
> > Hello
> >
> > I wrote new styles for psql table borders.
> >
> > http://postgres.cz/wiki/Pretty_borders_in_psql
> >
> > This patch is simply and I am think so some styles can be interesting
> > for final present
Hello
2013/11/21 Merlin Moncure
> On Thu, Nov 21, 2013 at 1:09 AM, Pavel Stehule
> wrote:
> > Hello
> >
> > I wrote new styles for psql table borders.
> >
> > http://postgres.cz/wiki/Pretty_borders_in_psql
> >
> > This patch is simply and I am think so some styles can be interesting for
> > f
3. That said, this could be handy. But it would be even more handy if you
could get Gaussian random numbers with \setrandom, so that you could use this
with custom scripts. And once you implement that, do we actually need the -g
flag anymore? If you want TPC-B transactions with gaussian distri
2013/11/21 Szymon Guz
> On 21 November 2013 21:15, Szymon Guz wrote:
>
>>
>>
>>
>> On 21 November 2013 20:20, Pavel Stehule wrote:
>>
>>> So here is patch for 9.4
>>>
>>> 7 new line styles, 2 new border styles, \pset border autocomplete
>>>
>>> Regards
>>>
>>> Pavel
>>>
>>>
>>>
>>>
>>> 2013/11/
On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote:
> The attached patch add support of domains over arrays to PL/Python (eg:
> CREATE DOMAIN my_domain AS integer[]).
>
> Basically it just uses get_base_element_type instead of get_element_type
> in plpy_typeio.c, and uses domain_check
Kyotaro HORIGUCHI wrote:
> Hello. I found a bug(?) in thsi patch as I considered on another patch.
> In truncate_useless_pathkeys, if query_pathkeys is longer than pathkeys
made
> from index columns old patch picked up the latter as IndexPath's pathkeys.
> But the former is more suitable accordin
On 11/21/2013 12:45 AM, Craig Ringer wrote:
I'm really concerned by this post on Linux's fsync and disk flush behaviour:
http://milek.blogspot.com.au/2010/12/linux-osync-and-write-barriers.html
and seeking opinions from folks here who've been deeply involved in
write reliability work.
With ex
Marko,
2013/11/22 Marko Kreen
> On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote:
> > The attached patch add support of domains over arrays to PL/Python (eg:
> > CREATE DOMAIN my_domain AS integer[]).
> >
> > Basically it just uses get_base_element_type instead of get_element_type
On 21.11.2013 21:37, Merlin Moncure wrote:
On Thu, Nov 21, 2013 at 10:37 AM, Heikki Linnakangas
In my patch, I put the barrier inside the if (!LocalRecoveryInProgress)
block. That codepath can only execute once in a backend, so performance is
not an issue there. Does that look sane to you?
oh
On Fri, Nov 22, 2013 at 08:45:56AM -0200, Rodolfo Campero wrote:
> There are other cosmetic changes in this patch, wrt previous version (not
> preexistent code):
> * adjusted alignment of variable name "rv" in line 12
> * reworded comment in line 850, resulting in more than 80 characters, so I
>
On 19.11.2013 16:20, Andres Freund wrote:
On 2013-11-18 23:15:59 +0100, Andres Freund wrote:
Afaics it's likely a combination/interaction of bugs and fixes between:
* the initial HS code
* 5a031a5556ff83b8a9646892715d7fef415b83c3
* f44eedc3f0f347a856eea8590730769125964597
Yes, the combination
On Thu, Nov 21, 2013 at 11:06 AM, Robert Haas wrote:
>
> On Wed, Nov 20, 2013 at 9:35 PM, Fabrízio de Royes Mello
> wrote:
> >> > So, with this patch we can do that:
> >> >
> >> > ALTER TABLE foo
> >> >SET (ext.somext.do_replicate=true);
> >> >
> >> > When 'ext' is the fixed prefix, 'somext'
Review: information schema parameter_default implementation (v2)
This is a review of the patch submitted in
http://archives.postgresql.org/message-id/1384483678.5008.1.ca...@vanquo.pezone.net
(information schema parameter_default implementation).
Previous review from Amit Khandekar covers technic
> "Tom" == Tom Lane writes:
Tom> I've committed this patch after some significant editorialization, but
Tom> leaving the use of TABLE( ... ) syntax in-place. If we decide that we
Tom> don't want to risk doing that, we can change to some other syntax later.
Is this intended:
create funct
When trying to add the extension with \i it writes an error message:
Use "CREATE EXTENSION uuid-ossp" to load this file.
Unfortunatly this does not work for extensions with dashes. Must CREATE
EXTENSION "uuid-ossp". Proposed patch is attached.
Regards
Mario
diff -Nurb contrib.orig/uuid-os
Amit Kapila escribió:
> On Fri, Nov 22, 2013 at 1:33 AM, Alvaro Herrera
> wrote:
> > \ib homer ~/photos/homer.jpg
> > insert into people (name, photo) values ('Homer', :homer);
>
> Isn't something similar already supported as mentioned in docs:
>
> One example use of this mechanism is to copy
On 21.11.2013 22:55, Andres Freund wrote:
On 2013-11-20 12:48:50 +0200, Heikki Linnakangas wrote:
On 19.11.2013 16:22, Andres Freund wrote:
On 2013-11-19 15:20:01 +0100, Andres Freund wrote:
Imo something the attached patch should be done. The description I came
g> >>up with is:
Fix Ho
On Thu, Nov 21, 2013 at 9:44 PM, Heikki Linnakangas
wrote:
> Here's a new version. To ease the review, I split the remaining patch again
> into two, where the first patch is just yet more refactoring.
>
> I also fixed some bugs in WAL logging and replay that I bumped into while
> testing.
Cool. He
We started with
Fri Nov 15
Status Summary. Needs Review: 79, Waiting on Author: 7, Ready for Committer: 5,
Committed: 7, Returned with Feedback: 3, Rejected: 1. Total: 102.
We are now at
Fri Nov 22
Status Summary. Needs Review: 47, Waiting on Author: 28, Ready for Committer:
10, Committed: 1
Bruce Momjian escribió:
> OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET
> from ERROR (which is new in 9.4) to WARNING.
I don't like that this patch changes RequireTransactionChain() from
actually requiring one, to a function that maybe requires a transaction
chain, and m
On 2013-11-22 15:01:10 +0200, Heikki Linnakangas wrote:
> On 21.11.2013 22:55, Andres Freund wrote:
> >On 2013-11-20 12:48:50 +0200, Heikki Linnakangas wrote:
> >>Looks ok for a back-patchable fix.
> >
> >Do you plan to commit this? Or who is going to?
>
> Ok, committed.
Thanks!
Greetings,
Andr
AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html)
(also available through gcc, but I used clang), reports one bug, which
I traced down to this code in ruleutils.c:
[elsewhere:]
#define ViewSelectRuleName "_RETURN"
/*
* Get the pg_rewrite tuple for the view's SE
Hello, Peter.
Is is possible to add small patch to the current commit fest?
You wrote:
PE> We started with
PE> Fri Nov 15
PE> Status Summary. Needs Review: 79, Waiting on Author: 7, Ready for
PE> Committer: 5, Committed: 7, Returned with Feedback: 3, Rejected: 1. Total:
102.
PE> We are now a
KaiGai
On Tue, Nov 19, 2013 at 9:41 AM, Kohei KaiGai wrote:
> Thanks for your review.
>
> 2013/11/19 Jim Mlodgenski :
> > My initial review on this feature:
> > - The patches apply and build, but it produces a warning:
> > ctidscan.c: In function ‘CTidInitCustomScanPlan’:
> > ctidscan.c:362:9:
On Thu, Nov 21, 2013 at 6:43 PM, Shigeru Hanada
wrote:
> 2013/11/22 Tom Lane :
>> Merlin Moncure writes:
>>> On Thu, Nov 21, 2013 at 9:05 AM, Bruce Momjian wrote:
I know join pushdowns seem insignificant, but it helps to restrict what
data must be passed back because you would only pas
On Fri, Nov 22, 2013 at 2:23 AM, Pavel Stehule wrote:
> Hello
>
>
> 2013/11/21 Merlin Moncure
>>
>> On Thu, Nov 21, 2013 at 1:09 AM, Pavel Stehule
>> wrote:
>> > Hello
>> >
>> > I wrote new styles for psql table borders.
>> >
>> > http://postgres.cz/wiki/Pretty_borders_in_psql
>> >
>> > This pa
2013/11/22 Merlin Moncure
> On Fri, Nov 22, 2013 at 2:23 AM, Pavel Stehule
> wrote:
> > Hello
> >
> >
> > 2013/11/21 Merlin Moncure
> >>
> >> On Thu, Nov 21, 2013 at 1:09 AM, Pavel Stehule >
> >> wrote:
> >> > Hello
> >> >
> >> > I wrote new styles for psql table borders.
> >> >
> >> > http:/
Peter Eisentraut writes:
> AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html)
> (also available through gcc, but I used clang), reports one bug, which
> I traced down to this code in ruleutils.c:
> [elsewhere:]
> #define ViewSelectRuleName "_RETURN"
> /*
> * Get
Pavel Stehule escribió:
> 2013/11/21 Peter Eisentraut
> > Maybe make the border setting a string containing the various characters
> > by index. Then everyone can create their own crazy borders.
> >
> I seriously though about it, but not sure if it is good way.
How about having a single "unico
On 22-11-2013 11:07, Pavel Golub wrote:
> Is is possible to add small patch to the current commit fest?
>
No. Deadline was 11/15. Add it to next CF [1].
[1] https://commitfest.postgresql.org/action/commitfest_view?id=21
--
Euler Taveira Timbira - http://www.timbira.com.br
Andres Freund wrote:
> While looking at the multixact truncation code (mail nearby), I've
> noticed that there's a significant difference in the way multixact
> members are accessed since fkey locks were introduced:
>
> <9.3 when heap_lock_tuple finds a XMAX_IS_MULTI tuple it executes
> MultiXact
On Fri, Nov 22, 2013 at 8:45 AM, Alvaro Herrera
wrote:
> Pavel Stehule escribió:
>
>> 2013/11/21 Peter Eisentraut
>
>> > Maybe make the border setting a string containing the various characters
>> > by index. Then everyone can create their own crazy borders.
>> >
>> I seriously though about it,
roadrunn...@gmx.at writes:
> When trying to add the extension with \i it writes an error message:
> Use "CREATE EXTENSION uuid-ossp" to load this file.
> Unfortunatly this does not work for extensions with dashes. Must CREATE
> EXTENSION "uuid-ossp". Proposed patch is attached.
[ memo to se
Tom Lane wrote:
> roadrunn...@gmx.at writes:
> regression=# \echo Use '''CREATE EXTENSION "uuid-ossp"''' to load this file.
> Use 'CREATE EXTENSION "uuid-ossp"' to load this file.
>
> Does that look reasonable to people?
+1
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreS
On 11/22/2013 10:19 AM, Alvaro Herrera wrote:
Tom Lane wrote:
roadrunn...@gmx.at writes:
regression=# \echo Use '''CREATE EXTENSION "uuid-ossp"''' to load this file.
Use 'CREATE EXTENSION "uuid-ossp"' to load this file.
Does that look reasonable to people?
+1
+1
cheers
andrew
--
Sent v
On 2013-11-22 12:04:31 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > While looking at the multixact truncation code (mail nearby), I've
> > noticed that there's a significant difference in the way multixact
> > members are accessed since fkey locks were introduced:
> >
> > <9.3 when h
Hi,
I spend some time trying to figure out why PostgreSQL builds on
S390-Linux, but Postgres-XC doesn't. Well at least this holds for the Debian
packages. So far I haven't figured it out. However, it appears to me that the
build should fail for both. I'm not an S390 expert by any means, but I was
On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane wrote:
> Also, it's not that hard to do plug-pull testing to verify that your
> system is telling the truth about fsync. This really ought to be part
> of acceptance testing for any new DB server.
>
I've never tried it but I always wondered how easy it
Greg Stark writes:
> On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane wrote:
>> Also, it's not that hard to do plug-pull testing to verify that your
>> system is telling the truth about fsync. This really ought to be part
>> of acceptance testing for any new DB server.
> I've never tried it but I alwa
Michael Meskes writes:
> I spend some time trying to figure out why PostgreSQL builds on
> S390-Linux, but Postgres-XC doesn't. Well at least this holds for the Debian
> packages. So far I haven't figured it out. However, it appears to me that the
> build should fail for both. I'm not an S390 exp
On Fri, Nov 22, 2013 at 1:16 PM, Tom Lane wrote:
>> The original mail was referencing a problem with syncing *meta* data
>> though. The semantics around meta data syncs are much less clearly
>> specified, in part because file systems traditionally made nearly all meta
>> data operations synchronou
Andrew Gierth writes:
> Is this intended:
[ I assume you forgot a create type footype here ]
> create function foo() returns setof footype language plpgsql
> as $f$ begin return next row(1,true); end; $f$;
> select pg_typeof(f), row_to_json(f) from foo() with ordinality f(p,q);
> pg_typeof |
On Fri, Nov 22, 2013 at 10:24:35AM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
>
> > OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET
> > from ERROR (which is new in 9.4) to WARNING.
>
> I don't like that this patch changes RequireTransactionChain() from
> actual
On Fri, Nov 22, 2013 at 11:27:45AM -0500, Tom Lane wrote:
> I think this is probably nonsense. I spent ten years maintaining Postgres
> for Red Hat, and I never saw any such failure on s390 in their packages.
> If -fpic weren't good enough for shared libraries on s390, how'd any of
> those builds
> "Tom" == Tom Lane writes:
Tom> [ I assume you forgot a create type footype here ]
yeah, sorry
Tom> Well, it's not insane on its face. The rowtype of f in the
Tom> first example is necessarily a built-on-the-fly record, but in
Tom> the second case using the properties of the underlyin
On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
> Good points. I have modified the attached patch to do as you suggested.
Also, I have read through the thread and summarized the positions of the
posters:
9.3 WARNING ERROR
SET
On 19 November 2013, Amit Khandekar wrote:
>On 18 November 2013 18:00, Rajeev rastogi
>mailto:rajeev.rast...@huawei.com>> wrote:
>>On 18 November 2013, Amit Khandekar wrote:
> >>Please find the patch for the same and let me know your suggestions.
>>>In this call :
> >>
ON 11 November 2013, Naoya Anzai Wrote:
>>
>> Hi Amit,
>>
> > I have uploaded your patch for next commit fest, hope you can support
> > it if there is any feedback for your patch by reviewer/committer.
> Thanks! Okay, I will support you.
1. Patch applies cleanly to master HEAD.
2. No Compilatio
On 14 November 2013, Kondo Mitsumasa wrote:
> Subject: Re: [HACKERS] Add min and max execute statement time in
> pg_stat_statement
>
> Oh! Sorry...
> I forgot to attach my latest patch.
* Is the patch in a patch format which has context?
No
* Does it apply cleanly to the current git master?
Yes
On 20 November, Amit Khandekar wrote:
I hope you meant to write test case as psql -d postgres -c "\copy tab from
stdin; insert into tab values ('lll', 3)", as if we are reading from file,
then the above issue does not come.
>>>I meant COPY with a slash. \COPY is equivalent to COPY FRO
Sending to hackers for comment; seems setting
default_transaction_read_only to true via ALTER database/user or
postgresql.conf can cause pg_dump, pg_dumpall, and pg_upgrade failures.
We are considering the right solution:
On 16/09/13 16:20, Satoshi Nagayasu wrote:
> Thanks for checking. Fixed to eliminate SnapshotNow.
Looking forward to get a new patch, incorporating the comments, that are
already given in the following mails:
1. Jaime Casanova: "The name pgstattuple2, doesn't convince me... maybe you can
use pg
On 19 November 2013 22:19, Sawada Masahiko Wrote
> >>
> >> Thank you for comment.
> >> Actually, I had thought to add separate parameter.
> >
> > I think that he said that if you can proof that amount of WAL is
> > almost same and without less performance same as before, you might
> not
> > need t
On 20 November 2013 22:12, Sawada Masahiko Wrote
> >
> > 1. Patch applies cleanly to master HEAD.
> > 2. No Compilation Warning.
> > 3. It works as per the patch expectation.
> >
> > Some Suggestion:
> > 1. Add new WAL level ("all") in comment in postgresql.conf
> >wal_level = hot_standby
9.3 documentation says:
According to the standard, the column-list syntax should allow a list of
columns to be assigned from a single row-valued expression, such as a
sub-select:
UPDATE accounts SET (contact_last_name, contact_first_name) =
(SELECT last_name, first_name FROM salesmen
WHE
On 21 November 2013, Amit Khandekar
mailto:amit.khande...@enterprisedb.com>> wrote:
>Ok. we will then first fix the \COPY TO issue where it does not revert back
>the overriden psql output file handle. Once this is solved, fix for both COPY
>FROM and COPY TO, like how it is done in the patch earl
On Fri, Nov 22, 2013 at 08:25:05AM -0600, Merlin Moncure wrote:
> On Thu, Nov 21, 2013 at 6:43 PM, Shigeru Hanada
> wrote:
> > 2013/11/22 Tom Lane :
> >> Merlin Moncure writes:
> >>> On Thu, Nov 21, 2013 at 9:05 AM, Bruce Momjian wrote:
> I know join pushdowns seem insignificant, but it hel
Andres Freund wrote:
> On 2013-11-22 12:04:31 -0300, Alvaro Herrera wrote:
> Yes, somewhat: <9.3 GetMultiXactIdMembers() didn't do any work if the
> multixact was old enough:
> if (MultiXactIdPrecedes(multi, OldestVisibleMXactId[MyBackendId]))
> {
> debug_elog2(DEBUG2, "G
2013/11/22 Alvaro Herrera
> Pavel Stehule escribió:
>
> > 2013/11/21 Peter Eisentraut
>
> > > Maybe make the border setting a string containing the various
> characters
> > > by index. Then everyone can create their own crazy borders.
> > >
> > I seriously though about it, but not sure if it is
On Thu, Nov 21, 2013 at 8:26 AM, Andres Freund wrote:
> On 2013-11-21 08:22:05 -0500, Robert Haas wrote:
>> On Thu, Nov 21, 2013 at 6:15 AM, Andres Freund
>> wrote:
>> >> > WRT performance: I agree that fixed-width identifiers are more
>> >> > performant, that's why I went for them, but I am not
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Well, it's not insane on its face. The rowtype of f in the
> Tom> first example is necessarily a built-on-the-fly record, but in
> Tom> the second case using the properties of the underlying named
> Tom> composite type is possible, and
On 2013-11-22 14:43:15 -0500, Robert Haas wrote:
> The patch as proposed puts forward a particular way of
> doing that, and I think that neither that method *nor any other*
> should be part of core.
Working on something like that, updated the patch state to "waiting on
author".
Thanks,
Andres Fr
Bruce Momjian wrote:
>> Not sure about backpatching. default_transaction_read_only has been
>> around since 7.4. Setting it to true would cause pg_dump to fail unless
>> you changed the database setting, and pg_dumpall would fail completely
>> as there is no way to turn off the database setting
AK writes:
> 9.3 documentation says:
> According to the standard, the column-list syntax should allow a list of
> columns to be assigned from a single row-valued expression, such as a
> sub-select:
> UPDATE accounts SET (contact_last_name, contact_first_name) =
> (SELECT last_name, first_name
Michael Meskes writes:
> On Fri, Nov 22, 2013 at 11:27:45AM -0500, Tom Lane wrote:
>> Furthermore, if we change that convention now, we're going to increase
>> the risk of such mixing failures for other people.
> Sure, but if this a bug we should. I'm not saying it is, I simply don't know.
Well,
Kevin Grittner wrote:
> See the attached patch.
Trying that again.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Companydiff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index 63a8009..199ffb0 100644
--- a/src/bin/pg_dump/pg_
Kevin Grittner writes:
> Kevin Grittner wrote:
>> See the attached patch.
> Trying that again.
That looks sane for pg_dump, but I would rather have expected that
pg_dumpall would need to emit the same thing (possibly more than once
due to reconnections).
regards, tom la
Tom Lane wrote:
> That looks sane for pg_dump, but I would rather have expected
> that pg_dumpall would need to emit the same thing (possibly more
> than once due to reconnections).
I was kinda surprised myself. I changed it for pg_dump, tested
that, and then tested pg_dumpall to get a baseline
On 11/22/13, 12:41 PM, Michael Meskes wrote:
> Checking the Debian logs it appears that all calls use *both* which seems to
> do
> the right thing. And yes, it appears there is a change in XC that makes it
> break. But still, I would think there has to be a correct set of options.
According to th
On 2013-11-22 12:45:25 -0800, Kevin Grittner wrote:
> Tom Lane wrote:
>
> > That looks sane for pg_dump, but I would rather have expected
> > that pg_dumpall would need to emit the same thing (possibly more
> > than once due to reconnections).
>
> I was kinda surprised myself. I changed it for
Andres Freund wrote:
> are you sure it also unsets default_transaction_readonly for
> the roles etc. it creates?
I'm not sure I understand. Could you give an example of what
you're concerned about?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent
On 2013-11-22 13:07:29 -0800, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > are you sure it also unsets default_transaction_readonly for
> > the roles etc. it creates?
>
> I'm not sure I understand. Could you give an example of what
> you're concerned about?
pg_dumpall first spits out glo
Andres Freund writes:
> On 2013-11-22 13:07:29 -0800, Kevin Grittner wrote:
>> I'm not sure I understand. Could you give an example of what
>> you're concerned about?
> pg_dumpall first spits out global data (users, databases, tablespaces)
> and then invokes pg_dump for every single database. So
Andres Freund wrote:
> On 2013-11-22 13:07:29 -0800, Kevin Grittner wrote:
>> Andres Freund wrote:
>>
>>> are you sure it also unsets default_transaction_readonly for
>>> the roles etc. it creates?
>>
>> I'm not sure I understand. Could you give an example of what
>> you're concerned about?
>
>
Claudio,
Can you elaborate how rules can help?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Why-is-UPDATE-with-column-list-syntax-not-implemented-tp5779600p5779896.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hacke
Thank you, Tom!
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Why-is-UPDATE-with-column-list-syntax-not-implemented-tp5779600p5779899.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote:
> Oddly, it didn't complain about creating users within a read-only
> transaction. That seems like a potential bug.
There's lots of things that escape XactReadOnly. I've thought (and I
think suggested) before that we should put in another layer
Kevin Grittner wrote:
This covers pg_dumpall globals. Tested with a read-only postgres
database and with default_transaction_read_only = on in the
postgresql.conf file.
It does nothing about pg_upgrade, which is sort of a separate
issue. My inclination is that connections to the new cluster
sh
On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote:
> I changed my postgres database to default to read only (which is
> not insane, given that I've seen so many people accidentally run
> DDL there rather than in the database they intended)
FWIW, I am less than convinced that it is correct for pg_
On Fri, Nov 22, 2013 at 6:36 PM, AK wrote:
> Claudio,
>
> Can you elaborate how rules can help?
Well... that specific example:
> UPDATE accounts SET (contact_last_name, contact_first_name) =
> (SELECT last_name, first_name FROM salesmen
> WHERE salesmen.id = accounts.sales_id);
Can be
I am reading the following in the documentation: "Tip: A common mistake is to
write a semicolon immediately after BEGIN. This is incorrect and will result
in a syntax error."
So, "common mistake" means semicolons after BEGIN seem consistent to many
people - it seems consistent to me as well. If Po
Andres Freund wrote:
> FWIW, I am less than convinced that it is correct for
> pg_dump[all] to emit SET default_transaction_readonly = off;
It doesn't change the database setting, just the connection which
is issuing commands to create global object -- ones that don't
reside in the database we a
I believe the section you are reading refers to the BEGIN keyword in the
procedural language plpgsql, not the SQL 'BEGIN' command. The issue stems
from confusing two distinct languages both of which, along with several
more procedural languages, are documented in the same manual.
On 11/22/2013 02:24 PM, AK wrote:
I am reading the following in the documentation: "Tip: A common mistake is to
write a semicolon immediately after BEGIN. This is incorrect and will result
in a syntax error."
So, "common mistake" means semicolons after BEGIN seem consistent to many
people - it s
On Fri, Nov 22, 2013 at 4:34 PM, Mike Blackwell wrote:
> I believe the section you are reading refers to the BEGIN keyword in the
> procedural language plpgsql, not the SQL 'BEGIN' command. The issue stems
> from confusing two distinct languages both of which, along with several more
> procedural
AK wrote:
> I am reading the following in the documentation: "Tip: A common
> mistake is to write a semicolon immediately after BEGIN. This is
> incorrect and will result in a syntax error."
>
> So, "common mistake" means semicolons after BEGIN seem consistent
> to many people - it seems consiste
On 11/22/2013 05:24 PM, AK wrote:
I am reading the following in the documentation: "Tip: A common mistake is to
write a semicolon immediately after BEGIN. This is incorrect and will result
in a syntax error."
So, "common mistake" means semicolons after BEGIN seem consistent to many
people - it
On Thu, Nov 21, 2013 at 11:43:34PM +0100, Andres Freund wrote:
> On 2013-11-21 14:40:36 -0800, Jeff Janes wrote:
> > But if the transaction would not have otherwise generated WAL (i.e. a
> > select that did not have to do any HOT pruning, or an update with zero rows
> > matching the where condition
On Fri, Nov 22, 2013 at 11:16:06AM -0500, Tom Lane wrote:
> Greg Stark writes:
> > On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane wrote:
> >> Also, it's not that hard to do plug-pull testing to verify that your
> >> system is telling the truth about fsync. This really ought to be part
> >> of accepta
On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian wrote:
> The program is diskchecker:
>
> http://brad.livejournal.com/2116715.html
>
> I got the author to re-host the source code on github a few years ago.
It might be worth re-implementing this for -contrib. The fact that we
mention diskche
On Fri, Nov 22, 2013 at 01:55:10PM -0800, Kevin Grittner wrote:
> It does nothing about pg_upgrade, which is sort of a separate
> issue. My inclination is that connections to the new cluster
> should set this and connections to the old should not.
It is going to be tricky to conditionally set/res
On Fri, Nov 22, 2013 at 03:06:31PM -0800, Peter Geoghegan wrote:
> On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian wrote:
> > The program is diskchecker:
> >
> > http://brad.livejournal.com/2116715.html
> >
> > I got the author to re-host the source code on github a few years ago.
>
> It m
On 11/22/2013 03:23 PM, Bruce Momjian wrote:
> On Fri, Nov 22, 2013 at 03:06:31PM -0800, Peter Geoghegan wrote:
>> On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian wrote:
>>> The program is diskchecker:
>>>
>>> http://brad.livejournal.com/2116715.html
>>>
>>> I got the author to re-host the
On Fri, Nov 22, 2013 at 03:27:29PM -0800, Josh Berkus wrote:
> On 11/22/2013 03:23 PM, Bruce Momjian wrote:
> > On Fri, Nov 22, 2013 at 03:06:31PM -0800, Peter Geoghegan wrote:
> >> On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian wrote:
> >>> The program is diskchecker:
> >>>
> >>> http://b
On Fri, Nov 22, 2013 at 8:51 PM, Peter Eisentraut wrote:
> On 11/22/13, 12:41 PM, Michael Meskes wrote:
> > Checking the Debian logs it appears that all calls use *both* which
> seems to do
> > the right thing. And yes, it appears there is a change in XC that makes
> it
> > break. But still, I wo
On Sat, Nov 23, 2013 at 8:06 AM, Peter Geoghegan wrote:
> On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian wrote:
>> The program is diskchecker:
>>
>> http://brad.livejournal.com/2116715.html
>>
>> I got the author to re-host the source code on github a few years ago.
>
> It might be worth
Bruce Momjian wrote:
> On Fri, Nov 22, 2013 at 01:55:10PM -0800, Kevin Grittner wrote:
>
>> It does nothing about pg_upgrade, which is sort of a separate
>> issue. My inclination is that connections to the new cluster
>> should set this and connections to the old should not.
>
> It is going to be
Andres Freund wrote:
> On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote:
>> Oddly, it didn't complain about creating users within a read-only
>> transaction. That seems like a potential bug.
>
> There's lots of things that escape XactReadOnly. I've thought (and I
> think suggested) before that
1 - 100 of 106 matches
Mail list logo
