On 11.01.2013 04:16, Tom Lane wrote:
[explanation of a race condition]
Good catch.
Also, it looks like we'll need two code paths in PostPrepare_Locks to
deal with the possibility that a conflicting entry already exists?
I'm not sure this is possible, but I'm not sure it's not, either.
If I
Is there any simple way of getting a query for which a trigger was
executed? debug_query_string and ActivePortal-sourceText return the top
query when there are nested triggers.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wednesday, January 09, 2013 4:57 PM Simon Riggs wrote:
On 9 January 2013 08:05, Amit kapila amit.kap...@huawei.com wrote:
Update patch contains handling of below Comments
Thanks
Test results with modified pgbench (1800 record size) on the latest
patch:
-Patch-
On 11 January 2013 10:40, Amit Kapila amit.kap...@huawei.com wrote:
Test results with original pgbench (synccommit off) on the latest patch:
-Patch- -tps@-c1- -WAL@-c1- -tps@-c2- -WAL@-c2-
Head1459 1.40 GB2491 1.70 GB
WAL
Hello
this is very simple patch - it enables hidden_queries for commands
\sf and \ef to be consistent with other describing commands.
bash-4.1$ ./psql postgres -E
psql (9.3devel)
Type help for help.
postgres=# \sf+ foo
* QUERY **
SELECT pg_catalog.pg_get_functiondef(16385)
Here is a proposed patch for the issue discussed in
http://archives.postgresql.org/pgsql-hackers/2012-07/msg00569.php:
I'd propose getting rid of lanplistrusted, at least for access
checking. Instead, just don't install USAGE privileges by
default for those languages.
On Friday, January 11, 2013 4:28 PM Simon Riggs wrote:
On 11 January 2013 10:40, Amit Kapila amit.kap...@huawei.com wrote:
Test results with original pgbench (synccommit off) on the latest
patch:
-Patch- -tps@-c1- -WAL@-c1- -tps@-c2- -
WAL@-c2-
Head
Hello
We use successfully use auto_explain. We miss support cancelled
queries - we need same info for queries, that we cancel after x
minutes.
Subtask of this feature can be dumping currently executed query with
plan and with complete query string to log after receiving some signal
- maybe
On 11 January 2013 12:30, Amit Kapila amit.kap...@huawei.com wrote:
Is this just one run? Can we see 3 runs please?
This average of 3 runs.
The results are so variable its almost impossible to draw any
conclusions at all. I think if we did harder stats on those we'd get
nothing.
Can you do
On 28 December 2012 10:21, Simon Riggs si...@2ndquadrant.com wrote:
* There is a fixed 75% heuristic in the patch.
I'm concerned that we're doing extra work while holding the buffer
locked, which will exacerbate any block contention that exists.
We have a list of the columns that the UPDATE is
On Friday, January 11, 2013 6:18 PM Simon Riggs wrote:
On 11 January 2013 12:30, Amit Kapila amit.kap...@huawei.com wrote:
Is this just one run? Can we see 3 runs please?
This average of 3 runs.
The results are so variable its almost impossible to draw any
conclusions at all. I
On Friday, January 11, 2013 6:45 PM Simon Riggs wrote:
On 28 December 2012 10:21, Simon Riggs si...@2ndquadrant.com wrote:
* There is a fixed 75% heuristic in the patch.
I'm concerned that we're doing extra work while holding the buffer
locked, which will exacerbate any block contention
Simon Riggs wrote:
On 28 December 2012 10:21, Simon Riggs si...@2ndquadrant.com wrote:
* There is a fixed 75% heuristic in the patch.
I'm concerned that we're doing extra work while holding the buffer
locked, which will exacerbate any block contention that exists.
We have a list of the
On 11 January 2013 14:29, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
But that doesn't include columns changed by triggers, AFAIR, so you
could only use that if there weren't any triggers.
True, well spotted
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL
The only animal in the buildfarm running AIX is grebe
(http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=grebebr=HEAD)
It is likely that the server running this animal will go away sometime
this year and the machine replacing it isn't running AIX.
If someone else in the community is
Andres Freund wrote:
On 2013-01-10 18:00:40 -0300, Alvaro Herrera wrote:
Here's version 28 of this patch. The only substantive change here from
v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive
or LockTupleNoKeyExclusive, depending on whether the key columns are
On 2013-01-11 12:11:47 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
On 2013-01-10 18:00:40 -0300, Alvaro Herrera wrote:
Here's version 28 of this patch. The only substantive change here from
v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive
or
Peter Eisentraut pete...@gmx.net writes:
It turned out that actually getting rid of lanpltrusted would be too
invasive, especially because some language handlers use it to determine
their own behavior.
So instead the lanpltrusted attribute now just determined what the
default privileges of
Pavel Stehule pavel.steh...@gmail.com writes:
What do you thinking about this feature?
The idea of expecting an add-on module to execute operations in an
already-failed transaction seems pretty dubious to me. I also think
it's not a great idea to add partial executions into a query's stats.
For
Am 04.01.13 21:26, schrieb Tom Lane:
Samuel Vogel s...@muel-vogel.de writes:
I'm trying to print out the tuples in the b-tree nodes for analysis, but
when iterate over more than the first entry of the tuples (scanKey++), I
strangely get the error below on query execution:
ERROR: relation
2013/1/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
What do you thinking about this feature?
The idea of expecting an add-on module to execute operations in an
already-failed transaction seems pretty dubious to me. I also think
it's not a great idea to add
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
My propose is proposed for different dimensions and purpose - for
example - we have a limit 20 minutes for almost all queries, and after
this limit we killing queries. But we have to know little bit more
about these bad queries - and we hope, so
Pavel Stehule pavel.steh...@gmail.com writes:
My propose is proposed for different dimensions and purpose - for
example - we have a limit 20 minutes for almost all queries, and after
this limit we killing queries. But we have to know little bit more
about these bad queries - and we hope, so
2013/1/11 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
My propose is proposed for different dimensions and purpose - for
example - we have a limit 20 minutes for almost all queries, and after
this limit we killing queries. But we have to know little bit
Tom Lane escribió:
Pavel Stehule pavel.steh...@gmail.com writes:
My propose is proposed for different dimensions and purpose - for
example - we have a limit 20 minutes for almost all queries, and after
this limit we killing queries. But we have to know little bit more
about these bad
On 11 January 2013 14:24, Amit Kapila amit.kap...@huawei.com wrote:
http://archives.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C3828
52DE51@szxeml509-mbs
1. However Heikki has pointed, it has some problems similar to for HOT
implementation and that is the reason we have done
I have not had anyone follow up on this, so I have added docs and will
add this to the commitfest.
Recap:
This adds the following:
json_agg(anyrecord) - json
to_json(any) - json
hstore_to_json(hstore) - json (also used as a cast)
hstore_to_json_loose(hstore) - json
Also, in
On 01/11/2013 11:00 AM, Andrew Dunstan wrote:
I have not had anyone follow up on this, so I have added docs and will
add this to the commitfest.
Recap:
This adds the following:
json_agg(anyrecord) - json
to_json(any) - json
hstore_to_json(hstore) - json (also used as a cast)
On 2013-01-10 10:55:20 +0100, Andres Freund wrote:
On 2013-01-10 10:31:04 +0100, Andres Freund wrote:
On 2013-01-10 00:05:07 +0100, Andres Freund wrote:
On 2013-01-09 17:28:35 -0500, Tom Lane wrote:
(We know this doesn't
matter, but gcc doesn't; this version of gcc apparently isn't
2013/1/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
My propose is proposed for different dimensions and purpose - for
example - we have a limit 20 minutes for almost all queries, and after
this limit we killing queries. But we have to know little bit more
On 11 January 2013 15:54, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Tom Lane escribió:
Pavel Stehule pavel.steh...@gmail.com writes:
My propose is proposed for different dimensions and purpose - for
example - we have a limit 20 minutes for almost all queries, and after
this limit we
Andres Freund wrote:
No, I was thinking about an update without triggers present.
T0: CREATE TABLE tbl(id serial pk, name text unique, data text);
T1: BEGIN; -- read committed
T1: UPDATE tbl SET name = 'foo' WHERE name = 'blarg'; /* key update of row id
= 1 */
T2: BEGIN; -- read
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane escribió:
However, auto_explain is even worse on the other problem. You flat out
cannot do catalog lookups in a failed transaction, but there's no way to
print a decompiled plan without such lookups. So it won't work. (It
would also
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2013/1/11 Stephen Frost sfr...@snowman.net:
Why not an option to auto_explain (or whatever) to log an execution plan
right before actually executing it? If that was something which could
be set with a GUC or similar, you could just do that
Simon Riggs si...@2ndquadrant.com writes:
An even better feature would be to be able to send a signal to a
running query to log its currently executing plan. That way you can
ask Why so slow? before deciding to kill it.
That could conceivably work. At least it wouldn't require running
EXPLAIN
2013/1/11 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2013/1/11 Stephen Frost sfr...@snowman.net:
Why not an option to auto_explain (or whatever) to log an execution plan
right before actually executing it? If that was something which could
be set
2013/1/11 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2013/1/11 Stephen Frost sfr...@snowman.net:
Why not an option to auto_explain (or whatever) to log an execution plan
right before actually executing it? If that was something which could
be set
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Simon Riggs si...@2ndquadrant.com writes:
An even better feature would be to be able to send a signal to a
running query to log its currently executing plan. That way you can
ask Why so slow? before deciding to kill it.
That could conceivably work.
On Tue, Jan 8, 2013 at 11:36 PM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2013-01-07 at 17:37 -0500, Robert Haas wrote:
If we make the postgres database undroppable, unrenamable, and
strictly read-only, I will happily support a proposal to consider it a
system object. Until then, it's
On 2013-01-11 13:10:49 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
No, I was thinking about an update without triggers present.
T0: CREATE TABLE tbl(id serial pk, name text unique, data text);
T1: BEGIN; -- read committed
T1: UPDATE tbl SET name = 'foo' WHERE name = 'blarg'; /*
2013/1/11 Stephen Frost sfr...@snowman.net:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Simon Riggs si...@2ndquadrant.com writes:
An even better feature would be to be able to send a signal to a
running query to log its currently executing plan. That way you can
ask Why so slow? before deciding
Hi,
2013-01-09 10:08 keltezéssel, Amit kapila írta:
On Sunday, January 06, 2013 10:26 AM Boszormenyi Zoltan wrote:
On Saturday, January 05, 2013 12:35 PM Boszormenyi Zoltan wrote:
2013-01-05 05:58 keltezéssel, Amit kapila írta:
On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote:
2013/1/11 Pavel Stehule pavel.steh...@gmail.com:
2013/1/11 Stephen Frost sfr...@snowman.net:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Simon Riggs si...@2ndquadrant.com writes:
An even better feature would be to be able to send a signal to a
running query to log its currently executing plan.
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Jan 8, 2013 at 11:36 PM, Peter Eisentraut pete...@gmx.net wrote:
Good point. What about the other suggestion about only displaying
databases by default that you can connect to?
I would tend not to adopt that suggestion, on the grounds
Version 4.10 of the buildfarm client has been released.
Following GitHub's abandonment of their download feature, releases will
now be published on the buildfarm server. The latest release will always
be available at http://www.pgbuildfarm.org/downloads/latest-client.tgz
This particular
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2013/1/11 Stephen Frost sfr...@snowman.net:
We can send a 'cancel query', how about a 'report on query' which
returns the plan and perhaps whatever other stats are easily available?
there is only one question - that POSIX signal we can use?
On 11 January 2013 16:31, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/1/11 Stephen Frost sfr...@snowman.net:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Simon Riggs si...@2ndquadrant.com writes:
An even better feature would be to be able to send a signal to a
running query to log its
On 11.01.2013 18:38, Andrew Dunstan wrote:
The main feature of this release is that it does better logging of
pg_upgrade failures (which is why I hope Heikki applies it to chipmunk
right away ;-) )
Heh, ok :-)
I've upgraded it, and launched a new buildfarm run, so we'll now more in
a moment.
On Friday, January 11, 2013 9:27 PM Simon Riggs wrote:
On 11 January 2013 14:24, Amit Kapila amit.kap...@huawei.com wrote:
http://archives.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C3828
52DE51@szxeml509-mbs
1. However Heikki has pointed, it has some problems similar to for HOT
On Friday, January 11, 2013 7:59 PM Alvaro Herrera wrote:
Simon Riggs wrote:
On 28 December 2012 10:21, Simon Riggs si...@2ndquadrant.com wrote:
I was also worried about the high variance in the results. Those
averages look rather meaningless. Which would be okay, I think, because
it'd
On 11 January 2013 17:08, Amit kapila amit.kap...@huawei.com wrote:
Just reviewing the patch now, making more sense with comments added.
In heap_delta_encode() do we store which columns have changed?
Not the attribute bumberwise, but offsetwise it is stored.
(Does that mean numberwise??)
On 11 January 2013 17:30, Amit kapila amit.kap...@huawei.com wrote:
On Friday, January 11, 2013 7:59 PM Alvaro Herrera wrote:
Simon Riggs wrote:
On 28 December 2012 10:21, Simon Riggs si...@2ndquadrant.com wrote:
I was also worried about the high variance in the results. Those
averages
On Friday, January 11, 2013 11:09 PM Simon Riggs wrote:
On 11 January 2013 17:08, Amit kapila amit.kap...@huawei.com wrote:
Just reviewing the patch now, making more sense with comments added.
In heap_delta_encode() do we store which columns have changed?
Not the attribute bumberwise, but
On Friday, January 11, 2013 11:12 PM Simon Riggs wrote:
On 11 January 2013 17:30, Amit kapila amit.kap...@huawei.com wrote:
On Friday, January 11, 2013 7:59 PM Alvaro Herrera wrote:
Simon Riggs wrote:
On 28 December 2012 10:21, Simon Riggs si...@2ndquadrant.com wrote:
I was also worried
=?gb2312?B?wO66o8H6?= hailong...@qunar.com writes:
This time I will give you the contents of the table route_raw, the download
link is https://www.box.com/s/yxa4yxo6rcb3dzeaefmz or
http://dl.dropbox.com/u/203288/route_raw_spgist.sql.tar.gz .
Thanks for the data, but I still can't reproduce
Heikki Linnakangas hlinn...@iki.fi writes:
There was a stray postgres instance running on the box, which I killed:
FWIW, we've seen an awful lot of persistent buildfarm failures that
seemed to be due to port conflicts with leftover postmasters. I think
the buildfarm script needs to try harder
On 11 January 2013 18:11, Amit kapila amit.kap...@huawei.com wrote:
Can we identify which columns have changed? i.e. 1st, 3rd and 12th columns?
As per current algorithm, we can't as it is based on offsets.
What I mean to say is that the basic idea to reconstruct tuple during
recovery
Andres Freund and...@2ndquadrant.com writes:
The attached patch:
* adds configure checks for __VA_ARGS__ and __builtin_unreachable
support
* provides a pg_unreachable() macro that expands to
__builtin_unreachable() or abort()
* changes #define elog ... into #define elog(elevel, ...) if
On 2013-01-11 14:01:40 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
The attached patch:
* adds configure checks for __VA_ARGS__ and __builtin_unreachable
support
* provides a pg_unreachable() macro that expands to
__builtin_unreachable() or abort()
*
On 01/11/2013 01:39 PM, Tom Lane wrote:
Heikki Linnakangas hlinn...@iki.fi writes:
There was a stray postgres instance running on the box, which I killed:
FWIW, we've seen an awful lot of persistent buildfarm failures that
seemed to be due to port conflicts with leftover postmasters. I think
Andres Freund and...@2ndquadrant.com writes:
[ patch to mark elog() as non-returning if elevel = ERROR ]
It strikes me that both in this patch, and in Peter's previous patch to
do this for ereport(), there is an opportunity for improvement. Namely,
that the added code only has any use if elevel
I wish to create this data structure but GIN does not currently support an
array of ENUM. Is intarray() a good place to look into adding ENUM support
or is there already an operator class for working supports enums that I
simply don't see at the moment.
This is being done as an alternative to a
On Thu, 10 Jan 2013, Andrew Dunstan wrote:
On 01/10/2013 11:32 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
cc -o interp interp.c `perl -MExtUtils::Embed -e ccopts -e ldopts`
Hm. It would be interesting to see what ccopts expands to, but if you
compare the
On Fri, 11 Jan 2013, Tom Lane wrote:
pgbuildf...@jdrake.com writes:
Well, that's darn interesting in itself, because the error message looks
like it should be purely a linker issue. (And I note that your other
buildfarm animal mongoose uses icc but is working anyway, so that's
definitely
On 2013-01-11 15:05:54 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
[ patch to mark elog() as non-returning if elevel = ERROR ]
It strikes me that both in this patch, and in Peter's previous patch to
do this for ereport(), there is an opportunity for improvement.
On 11 January 2013 16:52, Simon Riggs si...@2ndquadrant.com wrote:
We already overload the signals, so its just a new type for the signal
handler to cope with.
See procsignal_sigusr1_handler()
I roughed up something to help you here... this is like 50% of a patch.
pg_explain_backend() calls
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-11 15:05:54 -0500, Tom Lane wrote:
And another thing: what if the elevel argument isn't safe for multiple
evaluation? No such hazard ever existed before these patches, so I'm
not very comfortable with adding one. (Even if all our own
On 2013-01-11 15:52:19 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-11 15:05:54 -0500, Tom Lane wrote:
And another thing: what if the elevel argument isn't safe for multiple
evaluation? No such hazard ever existed before these patches, so I'm
not very
Hello,
Has anyone played with this? Seen any results? It looks like most
testing is being done on Mac OSX (via buildfarm).
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion,
On 1/11/13 4:03 PM, Joshua D. Drake wrote:
Has anyone played with this? Seen any results? It looks like most
testing is being done on Mac OSX (via buildfarm).
Works fine. We also have non-OSX tests on the buildfarm for it.
--
Sent via pgsql-hackers mailing list
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-11 15:52:19 -0500, Tom Lane wrote:
I agree the scenario doesn't seem all that probable, but what scares me
here is that if we use __builtin_constant_p(elevel) (elevel) = ERROR
in some builds, and just (elevel) = ERROR in others, then if
On 2013-01-11 16:16:58 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-11 15:52:19 -0500, Tom Lane wrote:
I agree the scenario doesn't seem all that probable, but what scares me
here is that if we use __builtin_constant_p(elevel) (elevel) = ERROR
in some
Hello,
I have read the developers FAQ which directed me to this mailing list.
I am still using Postgresql on Zeta (descendant of BeOS), but it is
becoming time to upgrade, so I installed Haiku (open source
reimplementation of BeOS) on another machine and downloaded the 9.2.1
source of
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-11 16:16:58 -0500, Tom Lane wrote:
Uh ... because it's *not* unreachable if elevel ERROR. Otherwise we'd
just mark errfinish as __attribute((noreturn)) and be done. Of course,
that's a gcc-ism too.
Well, I mean with the double
On 01/11/2013 04:36 PM, Mark Hellegers wrote:
Hello,
I have read the developers FAQ which directed me to this mailing list.
I am still using Postgresql on Zeta (descendant of BeOS), but it is
becoming time to upgrade, so I installed Haiku (open source
reimplementation of BeOS) on another
Mark Hellegers mhell...@xs4all.nl writes:
- Assuming all patches are applied to get Postgresql running, what does
it require to keep it in there? I noticed you removed the BeOS port,
because no one was maintaining it. What does it take to maintain a
port?
These days, the expectation is
On 2013-01-11 16:28:13 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-11 16:16:58 -0500, Tom Lane wrote:
Uh ... because it's *not* unreachable if elevel ERROR. Otherwise we'd
just mark errfinish as __attribute((noreturn)) and be done. Of course,
that's a
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-11 16:28:13 -0500, Tom Lane wrote:
I'm not very satisfied with that answer. Right now, Peter's
patch has added a class of bugs that never existed before 9.3, and yours
would add more. It might well be that those classes are empty ...
On 11/21/2012 12:07 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/21/2012 11:11 AM, Tom Lane wrote:
I'm not sure that's the only place we're doing this ...
Oh, Hmm, darn. Where else do you think we might?
Dunno, but grepping for isupper and/or tolower should find any
Mark Hellegers mhell...@xs4all.nl writes:
- Assuming all patches are applied to get Postgresql running, what
does
it require to keep it in there? I noticed you removed the BeOS
port,
because no one was maintaining it. What does it take to maintain a
port?
These days, the
Mark Hellegers mhell...@xs4all.nl writes:
You might want to look into whether you can get the buildfarm script
to run before you go too far.
I will check that this weekend. Thanks.
Does this buildfarm member need to run continuously?
Once a day is sufficient if that's all you can manage,
On 1/11/2013 6:56 AM, Steve Singer wrote:
If someone else in the community is running PostgreSQL on AIX then it
would be good if they setup a buildfarm member, perhaps with a more
recent version of AIX.
I am and I'd love to, however, sigh, its deep behind corporate firewalls
and any attempt
I'm really surprised IBM doesn't have some program to support a worthy
project like this.
They probably do. The problem is that we don't know who to contact.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Saturday, January 12, 2013 12:23 AM Simon Riggs wrote:
On 11 January 2013 18:11, Amit kapila amit.kap...@huawei.com wrote:
Can we identify which columns have changed? i.e. 1st, 3rd and 12th columns?
As per current algorithm, we can't as it is based on offsets.
What I mean to say is that
So I started this thread on the slon forum, and they mentioned that I/we
should ask here.
Postgres 9.1.4 slon 2.1.1
-and-
Postgres 9.1.6 slon 2.1.2
Scenario:
Node 1, is on gig circut and is the master (West Coast)
Node 2, is also on a gig circuit and is the slave (Georgia)
Symptoms, slon
On Friday, January 11, 2013 10:03 PM Boszormenyi Zoltan wrote:
Hi,
2013-01-09 10:08 keltezéssel, Amit kapila írta:
On Sunday, January 06, 2013 10:26 AM Boszormenyi Zoltan wrote:
On Saturday, January 05, 2013 12:35 PM Boszormenyi Zoltan wrote:
2013-01-05 05:58 keltezéssel, Amit kapila írta:
to_date() doesn't check the date range, which results in unreadable
data like this.
foo=# create table t as select to_date('-12-10 BC', '-MM-DD
BC')::timestamp;
SELECT 1
foo=# table t;
ERROR: timestamp out of range
Attached is to add IS_VALID_JULIAN() as we do like in date_in(). I
2013-01-12 06:51 keltezéssel, Amit kapila írta:
On Friday, January 11, 2013 10:03 PM Boszormenyi Zoltan wrote:
Hi,
2013-01-09 10:08 keltezéssel, Amit kapila írta:
On Sunday, January 06, 2013 10:26 AM Boszormenyi Zoltan wrote:
On Saturday, January 05, 2013 12:35 PM Boszormenyi Zoltan wrote:
88 matches
Mail list logo
