On Sun, May 12, 2013 at 1:18 PM, Jim Nasby wrote:
> FWIW, I've wanted the ability to plug into the parser not for an extension,
> but so that I could programmaticly enforce certain coding conventions.
Depending on the exact requirements, that probably wouldn't be too
difficult. It'd likely entail
Please find attached a patch to take code-coverage of DBCommands (CREATE
DATABASE / ALTER DATABASE / DROP DATABASE) from 36% to 71%.
I wish to object strenuously to adding any more CREATE/DROP DATABASE
commands to the core regression tests. Those are at least one order of
magnitude more expen
On 5/11/13 11:27 AM, Tom Lane wrote:
David Fetter writes:
On Sat, May 11, 2013 at 11:17:03AM -0400, Robert Haas wrote:
Some kind of extendable parser would be awesome. It would need to tie
into the rewriter also.
No, I don't have a clue what the design looks like.
That's a direction sever
Robins Tharakan writes:
> Please find attached a patch to take code-coverage of DBCommands (CREATE
> DATABASE / ALTER DATABASE / DROP DATABASE) from 36% to 71%.
I wish to object strenuously to adding any more CREATE/DROP DATABASE
commands to the core regression tests. Those are at least one orde
On Monday, May 13, 2013 5:54 AM Kyotaro HORIGUCHI wrote:
> 2013/05/10 20:01 "Amit Kapila" :
> > > > C 2013-05-10 15:32:32.170 JST 9242 FATAL: could not receive data
> > > from WAL stream:
> >
> > Is there any chance, that there is any network glitch caused this one
> time
> > error.
>
> Unix doma
Adding & dropping a column resolved the problem. Currently vacuuming the
new cluster. Thanks for your help everybody!
On Sat, May 11, 2013 at 4:58 PM, Bruce Momjian wrote:
> On Fri, May 10, 2013 at 08:03:38PM -0400, Bruce Momjian wrote:
> > On Fri, May 10, 2013 at 12:36:21PM -0400, Evan D. Ho
Hi,
I tested this issue with 9.3beta1 , and same thing happening there too.
By making changes as done in above patch, its work fine as expected.
I am not sure, does this fixed is required to do?
If so, then what should min wait time should set as 5000 microSec is seted for
test, is this fine
On Sun, May 12, 2013 at 3:46 PM, Jim Nasby wrote:
> On 5/10/13 1:06 PM, Jeff Janes wrote:
>>
>> Of course the paranoid DBA could turn off restart_after_crash and do a
>> manual investigation on every crash, but in that case the database would
>> refuse to restart even in the case where it perfectl
2013/05/10 20:01 "Amit Kapila" :
> > > C 2013-05-10 15:32:32.170 JST 9242 FATAL: could not receive data
> > from WAL stream:
>
> Is there any chance, that there is any network glitch caused this one time
> error.
Unix domam sockets are hardly likely to have such troubles. This
test ran within sin
Hi,
Please find attached a patch that adds basic regression tests for DISCARD
command.
Any and all feedback is obviously welcome.
--
Robins Tharakan
regress_discard_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi,
Please find attached a patch to take code-coverage of DBCommands (CREATE
DATABASE / ALTER DATABASE / DROP DATABASE) from 36% to 71%.
Any and all feedback is obviously welcome.
--
Robins Tharakan
regress_db_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-ha
On 5/10/13 1:06 PM, Jeff Janes wrote:
Of course the paranoid DBA could turn off restart_after_crash and do a manual
investigation on every crash, but in that case the database would refuse to
restart even in the case where it perfectly clear that all the following WAL
belongs to the recycled f
On 5/9/13 5:18 PM, Jeff Davis wrote:
On Thu, 2013-05-09 at 14:28 -0500, Jim Nasby wrote:
What about moving some critical data from the beginning of the WAL
record to the end? That would make it easier to detect that we don't
have a complete record. It wouldn't necessarily replace the CRC
though,
> auth_failed() in src/backend/libpq/auth.c intentionally logs nothing for
> STATUS_EOF status (ie, client closed the connection without responding).
> But it looks like the PAM code path doesn't have a way to return that
> status code, even when pam_passwd_conv_proc() knows that that's what
> happ
New submission which put long options in alphabetical order, which seems
more logical.
This is for reference to the next commitfest.
--
Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c
index 24dab1f..ba36e66 100644
--- a/contrib/pgbench/pgbench.c
+++ b/contrib/pgbench
15 matches
Mail list logo